Русский
Русский
English
Статистика
Реклама

Процессы

Странные управленческие решения внутри хостинга

15.06.2021 14:10:21 | Автор: admin
Звонит как-то вендор и говорит, что в возврате бракованного железа не их жёсткий диск.


Это местный вендор. Для прода мы покупаем серверное железо у крупных поставщиков, часто возим его в разные страны из одного центра. Но для тестовых новых конфигураций обращаемся к локальным поставщикам, берём железо на тесты или разовые проекты. Один из жёстких дисков оказался бракованным, и мы вернули его назад поставщику по гарантии. Причём знатно ругаясь, что связались с маленькой компанией, что задержало нам график тестов.

Гарантийный отдел ковыряется с диском, а потом звонят:

А зачем вы подменили диск?

Мы такие:

В смысле подменили?

Мы вам продавали другой. А тут корпус тот, а внутри другой. Какие-то следы от отвёртки.

Дичь полнейшая! Мы начали было ругаться, но потом стали разбираться. Начали смотреть на камеры и увидели, что наш сотрудник очень подозрительно себя вёл, когда работал с этим диском в стойке. Как в плохих комедиях про жуликов: постоянно осматривался по сторонам, отходил в сторону, возвращался. Оказалось, что он подменил диск. Честно, я не знаю зачем. Его финансовая выгода минимальная, скорее всего, даже не окупает время работы по замене корпуса.

У нас было ещё несколько странных ситуаций, и сейчас я о них расскажу.

Форекс-трейдер


VDS часто покупаются для торговли на биржах. Ну, на нормальных биржах: я имею в виду тех, где важно географическое расположение сервера для минимизации задержек. Но есть и биржи уровня Форекса. Вернее их даже биржами назвать нельзя. Это на сленге трейдеров кухня. Напомню, что многие из них попали в список компаний с признаками нелегальной деятельности, который завёл ЦБ. У меня есть глубокое личное убеждение, основанное на здравом смысле и математике, что система работает как качели для вытаскивания денег из не самых разбирающихся в вопросе клиентов. Возможно, это не так, но свою точку зрения я могу аргументировать и обосновать при необходимости. Но в истории важно другое. Звонит мой знакомый, который взял у нас сервер в Швейцарии. И вот он начинает в открытую меня и всех наших сотрудников обвинять в том, что мы залезаем к нему на сервер в процессе торгов и вмешиваемся в его форекс-сделки.

По его словам, он придумал великую стратегию, а убыточные сделки берутся рынком, плюсовые же вовремя не берутся, игнорируются. И в этом виноваты мы. Точнее, сначала он обратился с задачей, что его не устраивает производительность сервера. С его слов, она радикально падала в момент выхода новостей. В 16:30, когда выходит мировая статистика. В этот момент времени все трейдеры, кто работает с помощью автоматических торговых систем, начинают многократно усиливать свою активность. Если, грубо говоря, внутри дня он делает десять сделок, то в эти 16:30 и одну минуту он может сделать сто сделок. Естественно, это создаёт пик нагрузки, причём не локально, а на принимающем сервере. Но трейдер этого не понимает, он думает, что у нас сервер именно в 16:30, когда ему надо выставить заявку или закрыть заявку, тормозит. А это совпадает с самым нужным временем. И не верится, что это просто совпадение.

Поскольку это был мой знакомый, сначала я потратил неделю на то, чтобы провести ему курс ликбеза про то, как работают серверы и как работают биржи. Потом выделил админа, чтобы он проверил лично его сервер. Потом началось: Ты меня привёл сюда, ты там лазишь, воруешь мою торговую стратегию, ты вор, ублюдок Ты мне врёшь. Вы залезаете ко мне, ты знаешь, что у меня там классный торговый робот, ты хочешь его своровать. Ты залезаешь ко мне на сервер, ты мне гадишь статистику. Это ты подкручиваешь настройки, чтобы у меня ничего не работало. Перешёл на другой хостинг. Потом вроде ещё и ещё. И только через два года мы начали общаться снова, он признал, что я был прав. Но к этому моменту он уже влез в долги.

Здесь главная проблема работа со знакомым. Если бы это был просто клиент, то мы бы провели диагностику и не получали оскорблений.

Игровые серверы школьников


Школьники довольно часто размещают у нас игровые серверы. Это, скажем так, сложные клиенты, потому что они выбирают третий по цене тарифный план. Первый это промо за 30 рублей в месяц (по цене IP), второй урезанная версия стандартных конфигураций за 130 рублей и третий уже полноценный сервер от 300 рублей в месяц.

Итак, дети открывают сервер, начинают играть. Через некоторое время их с завидным постоянством начинают дидосить. Не каждого, условно примерно каждый десятый сервер. После начала дидоса наша система их блокирует. Ещё через пять минут ребёнок с большим гонором и богатым трёхэтажным матом начинает писать в нашу поддержку о том, какие мы тут все плохие люди. Обрезали ему, значит, игру, у него там нет дохода из-за этого, мы там попали на миллионы из-за него теперь. Он нас побить приедет.

Поддержка вежливо объясняет суть проблемы и предлагает подключить защиту от DDOS-атак за 400 рублей (причём первый месяц бесплатно). По нашей практике, потом можно будет играть совершенно спокойно. На что клиент начинает нас обвинять в том, что это мы специально дидосим его, чтобы он нам заплатил ещё. Далее закономерно встаёт вопрос о возврате средств, и обычно мы средства возвращаем и с лёгкостью расстаёмся с таким клиентом.

Один из тикетов был похож на подобный, но с нюансом. Блокировки не было, дидоса не было, трёхэтажного мата тоже не было. Просто клиент запросил возврат средств с сервера, который был оплачен на несколько месяцев. А тут надо сказать, что у нас есть ссылка для оплаты, которую можно выставить наружу, и любой человек может оплатить хостинг для какого-то клиента. Это удобно, потому что бухгалтерии не обязательно логиниться в админпанель. Школьники использовали эту ссылку для краудфандинга, скинулись на сервак и начали играть.

Клиент пишет заявку на возврат средств, мы отправляем её в платёжный шлюз. И вдруг владелец удаляет сервер, начинаются тот самый мат и дикие крики про то, что вернуть надо на его счёт, а не на счета плательщиков. То есть условно у них было порядка сорока оплат по 100 рублей, и все их платёжный шлюз собирался распихать обратно по тем самым карточкам, с которых они платили. Но главному герою нужен был возврат на один свой счёт. В общем, в ходе диалога с поддержкой он уже прямо признался, что хотел получить чужие деньги. Через пару месяцев эта же история повторилась с минимальными вариациями с другим школьником.

Самый короткий детектив


Бывает, наши серверы берутся для обхода блокировок. Люди разворачивают VPN и просто ходят через наш сервер в большой интернет, если на работе он заблокирован. Ну или просто берут сервер в другой юрисдикции типа Швейцарии и ходят через него. Почему это важно, есть вот тут про маски-шоу.

И вот пишет клиент, что наш сервер не отвечает.

Мы просим трассировку. Клиент делает, присылает. Мы сообщаем, что RDP блокирует его отель, и желаем приятного отпуска в Таиланде. Клиент немного в панике, но мы поясняем, что его Wi-Fi-точка названа именно по отелю. И даём ссылку на то, как это обойти. В тот раз помогло.

Регистрации под ботами


Очень странная ситуация была с тестовыми периодами на наших 32-ядерных машинах. Кто-то научился брать американские номера, парсить голос, русский текст и цифры. Как только криптовалюты совершали очередной прыжок, начинались авторегистрации, а дальше серверы использовались (судя по характеру нагрузки) для майнинга криптовалют. Не знаю, что это было, но майнить биткоин на VDS без видеокарты идея откровенно так себе. Процессор уходит в потолок, три дня они пытаются что-то там сделать, потом период заканчивается. Мы обновили капчи, но на следующей волне скачка курса биткоина снова начались авторегистрации. Я откровенно не понимаю, какой в этом смысл, ведь аренда американского номера стоит дороже, чем возможный профит с майнинга на процессоре три дня. Сейчас эти волны мы наконец-то победили.

Блокировки по IP


Мы выдаём один статический IP клиенту при аренде сервера. Это не карусель динамических адресов, не замены раз в месяц, а конкретный IP, привязанный к клиенту. Сначала мы проверяем его чистоту и отсутствие во всяких чёрных списках, а потом даём клиенту.

Дальше клиент может испортить этот айпишник. Например, инста-блогерки и инста-блогеры часто разворачивают у нас средства накрутки Инстаграма. Инстаграм их ожидаемо банит через некоторое время. Дальше в поддержку начинаются обращения: Почему меня забанил Инстаграм?! с кучей смайликов. Или: Почему меня забанило Авито, смените мне IP-адрес, но про Авито смайликов почти нет.

Ещё накручивают отзывы и просмотры на Амазоне. Потом в поддержке: Ребята, это мой не первый аккаунт, можете, пожалуйста, сменить мне IP-адрес, потому что меня забанило?

Бывает так, что админ настраивает клиенту работу на сервере, но забывает уточнить вопрос про лицензии. Звонит генеральный директор, у которого 25 сотрудников, и они все сидят на удалённом рабочем столе, у нас размещали соответственно. Весь замес в том, что системный администратор, который это настраивал, был на аутсорсе. Он настроил кучу виртуальных рабочих мест. Человек платил около 35 тысяч. У него там размещалось 25 сотрудников, и 120 дней человек вообще не знал никакой проблемы с подключением к удалённому рабочему столу. А цимес в том, что Майкрософт даёт триалку на размещение этого удалённого сервера рабочих столов 120 дней ровно. Человек четыре месяца, получается, пользуется, и тут внезапно посреди пятого месяца обнаруживает, что у него ни один сотрудник не может зайти. Диктует нам ошибку, мы всё прекрасно понимаем, что у него там происходит. И предлагаем ему два варианта:

Вы либо удаляете эту службу, которая не даёт вам подключиться вообще в принципе, либо платите за каждую лицензию.

В общем, ребят, я не буду платить тройную цену от сервака.

Неудивительно, потому что лицензия стоит 91 тысячу рублей, а у него сервак стоит 36 тысяч.

Ребята, надо, короче, решать. Давайте так: мне по-любому нужно это бесплатно. Что если мы оформим договор на другое лицо, и таким образом у меня будет ещё 120 дней? А что если вы измените человека, у меня сейчас есть знакомый, он зарегистрируется?

А вы точно понимаете, что сейчас у официального партнёра MS спрашиваете, как их же обмануть?

Да! Ребята, какие ещё варианты есть?

Неожиданный уход коллеги


Текучка у нас минимальная, поэтому, когда человек уходит, это целое событие. Главное в этом событии то, что на выходном интервью сотрудник уже может быть полностью откровенным, и мы часто узнаём про какие-то вещи, которые раздражают, но про которые обычно не говорят. Это самая полезная обратная связь для найма и удержания людей.

И вот одна из ситуаций. Сотрудник взял и не пришёл на работу. Работал-работал и потом пропал. Выходного интервью нет. Начали разбираться, что же случилось, может быть, обиделся на что-то. Никаких внутренних предпосылок. Уже потом начали общаться с ним удалённо, он прислал ссылку на статью на Хабре про профессиональное выгорание.

Это ничего не объясняло, но дальше удалось поговорить. Сотрудник сказал, что внимательно всё прочитал и не хочет, чтобы это случилось с ним. Поэтому увольняется.

Никаких выводов и действий. Просто, возможно, он счастлив где-то ещё.

Дебош


На корпоративе сотрудник устроил жутчайший дебош. Страшнее представить сложно! Сначала дрался с коллегами, потом начал нападать на случайных людей вокруг. Кое-как скрутили и прижали к полу. Подошёл мужик, начал кричать, что мы ограничиваем свободу человеку, столкнул с него двух человек. Наш герой встал и дал правозащитнику мощного леща, после чего уже и он помогал его держать. Приехали на это все: скорая, полиция, охрана местная. При запаковке в наручники он умудрился вырваться и разбить нос полицейскому.

В итоге уголовку он не получил, полицейские оказались добрыми. Оставили всего до утра к КПЗ и отпустили домой к жене и детям. Как бы конец истории, но непонятно, что делать дальше, потому что в беседе он пояснил, что нет гарантии того, что ровно такое же не повторится. Например, в офисе. Или в серверной. Или на переговорах с клиентом или ЦОДом.

Долго думали, что делать. Увольнять вроде неправильно. По работе претензий нет, всё хорошо.
Но вроде, если человек облажался в соцсетях и кого-то оскорбил, в крупных компаниях увольняют. Тут похожая ситуация. Непонятно. В общем, в итоге перевели на полную удалёнку ещё до того, как это стало мейнстримом.

Уничтоженный сервер 1С


Мы ужасно серьёзны в плане защиты финансовых данных своих клиентов, поскольку довольно часто наши ЦОДы в других юрисдикциях выбираются именно для этого. Одно из следствий если клиент отдаёт прямую команду из личного кабинета на удаление машины, то она именно удаляется, а не помещается в хранилище на несколько месяцев. Для подтверждения этого действия нужно ещё раз ввести пароль от ЛК.

Итак, бухгалтерше одного из клиентов нужны закрывающие документы о том, что услуга оказана. Документы есть в личном кабинете, они автоматически формируются. Она сообщает, что доступ утерян. Но она знает номер договора и все реквизиты. ОК, говорим мы: пришлите письмо на бланке организации с подписью генерального и печатью, восстановим вам доступ.

Письмо приходит, в нём просьба поменять основную почту доступа.

Мы соответственно меняем почту.

Потом нам пишет генеральный директор и сообщает, что бухгалтерша удалила его сервер 1С с базой. И слёзно просит нас его восстановить. Сотрудницу к этому моменту он уже уволил.

Это трагедия в чистом виде, потому что всё юридически правильно, но понятийно нет. Мы долго думали, что можно было сделать в этой ситуации, и решили, что у нас будет отдельная роль внутри аккаунта для биллинга (закрывающих документов и оплат). Сейчас это в планах релизов.

Общие выводы и чем закончилась история с жёстким диском


Мы стараемся разобраться и понять, что можно сделать, чтобы риск не повторялся.
В случае с заменённым жёстким диском сотрудник написал по собственному и уволился тем же днём. Мы не предъявляли ему претензий, поскольку понимали, что будет крайне тяжело это доказать. И, несмотря на всю иррациональность ситуации, у нас есть правило: если ты знаешь риск, то надо постараться его минимизировать на будущее. В этой истории было не очень понятно, что делать. В итоге посовещались и выделили отдельную комнату в офисе для сборок оборудования, над столом там поставили камеру. В этом случае мы, наверное, больше параноики, чем оптимизаторы, но таков принцип. Возможно, это потому, что мы из финансовой сферы, и с этим очень серьёзно. Здесь мы страхуемся не только от хищения, но и от того, чтобы ложно не обвинить своего сотрудника, если будет какая-то путаница от вендора или что-то подобное, потому что оборудование довольно дорогое.


Подробнее..

Новая работа

25.04.2021 14:23:00 | Автор: admin
Что вы думаете о глобальном потеплении?
Спросила с экрана гигантская морда хаски в черных солнечных очках
В каком смысле? Это уже интервью?
Я прошу вас сфокусироваться. Как я только что сказала, сейчас я буду задавать вопросы на которые прошу вас давать максимально емкие ответы. Если у вас есть какие-то вопросы по процессу, пожалуйста я готова на них ответить. Нам нужно уложиться в отведенное время.
Я просто не понял что мы перешли к официальной части. У вас какие-то проблемы с камерой.
Секунду
В на экране появилось лицо в сине-зеленой маске натянутой на уши с красным логотипом БК по середине
Согласно политике компании, все интервью мы проводим в масках. Мне подождать вас или мы не сможем продолжить?
Боитесь подхватить что-нибудь по видео-связи?
Мы принимаем здоровье наших сотрудников и близких максимально серьезно и считаем, что вправе требовать того же от кандидатов.
Беглову потреобвалось чуть меньше минуты чтобы нащупать в ящике стола марлевую маску.
Спасибо. Какие-то вопросы с вашей стороны перед тем как мы начнем?
Сколько всего вопросов?
Вы куда-то спешите?
У меня есть 6 часов на общение с вами
Постараемся уложиться. Что-то еще?
Мы же обсуждаем позицию техника по обслуживанию лифтов в ваших небоскребах, правильно? Причем тут глобальное потепление?
Верно. Если какой-то из вопросов для вас покажется оскорбительным или неприемлемым, немедленно сообщите мы сразу прекратим. Еще вопросы? Можем продолжить?
Беглов кивнул
Что простите?
Да-да можем продолжать. Я просто кивнул несколько раз в камеру.
Отлично. Итак, мы остановились на глобальном потеплении. Что вы об этом думаете?
Я думаю это плохо.
Занимались ли вы улучшением рабочих процессов на предыдущем рабочем месте?

Это было не первое интервью Беглова. На предыдущем месте никаких процессов он не улучшал, ничего и никого не менеджерил, не выстраивал работу, не отвечал за найм и тд. И не будет ничего из этого делать на следующем. Но не место и не время обсуждать вопросы нанимающего менеджера.

Занимался
Как вы поняли что процессы улучшены?
За улучшение процессов я получил 30 Отличных работ от руководства.
Какие процессы вы предпочитаете улучшать?
Процессы в которых я максимально некомпетентен. Свежий подход со стороны позволяет генерировать революционные идеи, которые как правило не видно замыленным взглядом изнутри.
Отлично мы как раз ищем людей которые на каждый процесс смотрят по-новому и в своей работе стремятся переизобретать индустрии. Вам это интересно?
Что? Переизобретать? Да конечно. Переизобретать индустрии это то чем я занимаюсь в свободное от ремонта лифтов и стиральных машин время.
Что последнее вы переизобрели?
Меня очень волнует проблема выбросов вредных газов в атмосферу. И я заметил что все игнорируют такой гигантский фактор особенно густнонаселенных городах, как кишечные газы людей. Вы знаете, я долго работаю с лифтами в тесном пространстве эта проблема особенно актуальна. Мы носим шлемы бактериологической защиты на головах возможно пришло время и для
Вы говорите про затычки? Это нельзя назвать переизобретением. Они уже довольно популярны. Кстати являются частью стандартной униформы наших техников.
Они не решают проблему. Газы все равно остаются и выходят в другом месте. Атмосфере так или иначе наносится урон. Я придумал выключать ген который отвечает за кишечные газы. Я мало что понимаю в генетике, но все мы знаем что гены это такие штуки в клетках, которые включают и выключают фичи в организме. Почему бы нам просто не выключить
Да это действительно хорошее переизобретение. С текущим решением выполнять сидячую работу долгое время становится дискомфортно. Следующий вопрос сколько времени в процентном соотношении вы тратили на менеджерские задачи а сколько на инженерные?
80 процентов на инженерные 20 на менежерские
Мы рассчитываем найти на эту позицию человека с управленческим опытом так как здесь вы можете рассчитывать на перспективы вертикального роста. Вы заинтересованы больше в вертикальном или горизонтальном росте
Вертикальный мне как-то ближе. Я же буду работать с лифтами.
Причем тут лифты?
Хотя от горизонтального тоже не откажусь. У вас же есть траволаторы.
Я не совсем поняла ответ. Можете повторить?
Вертикальный
Мы рассчитываем, что если вы хорошо себя проявите, со временем сможете отвечать не только за оборудование во всех лифтовых шахтах наших небоскребов, но и за шахты пусковых установок. Это интересно для вас?
Да действительно звучит, как довольно сильный вертикальный рост.
Вы занимаетесь самообразованием в своей области?
Да
Какую литературу вы прочли в за прошлый год или может быть прошли какие-то онлайн курсы?
Моя настольная книга Гидравлические лифты Архангельского. Подтверждал 4ю категорию электробезопасности.
Отлично. Продолжим. Чей Крым?
Крымчан
Сколько слоганов и лозунгов для корпоративных подразделений вы придумали за свою карьеру? Примерно. Необязательно только для своего подразделения.
Ну штук 10 наверное.
Можете вспомнить самый удачный?
Выше быстрее сильнее!
Хороший слоган для команды обслуживания лифтов
Нет, это я придумал для команды обслуживания лестниц между этажами. Есть в этом некая отсылка к спорту. Зайти на 135й этаж вполне себе спорт, как мне кажется.
Да помню в моем детстве были какие-то соревнования с похожим лозунгом. Французы вроде придумали. Но мы отвлеклись. Я вам сейчас дам ссылку на IQ тест. Перед этим нам необходимо чтобы вы предоставили нам доступ в своему фитнес-браслету и микрофону. Во время его прохождения мы будем записывать все звуки в вашей комнате, сердечный ритм и расположение рук. Напомню руки до конца теста должны быть только на клавиатуре.
Я готов.

1250 вопросов спустя

Спасибо за уделенное время. Мы свяжемся с вами по поводу дальнейших шагов. В случае успеха вам нужно будет собрать отзывы о своей работе со всех предыдущих мест записанных в вашем личном кабинете на Госуслугах.
Подробнее..

Перевод Как мы потерпели неудачу, а затем преуспели в переходе на TypeScript

02.06.2021 18:06:54 | Автор: admin

К старту курса о Fullstack-разработке на Python, где также рассматривается TypeScript, мы перевели статью о миграции в Heap.io компании, которая предоставляет платформу аналитики продуктов, c языка CoffeeScript на TypeScript; TS в Heap.io начали использовать более 4 лет назад. Несмотря на широкое предпочтение TypeScript среди инженеров, миграция была медленной, а чёткого пути к 100 % кода TS не было.


На самом деле, если цель состояла в том, чтобы полностью переключиться на TS, мы двигались в неправильном направлении. Да, код на TS добавлялся, но количество кода на CoffeeScript росло быстрее. TypeScript и CoffeeScript нацелены на один и тот же рантайм Node.js, который, как ожидалось, должен был облегчить переход, но, несмотря на желание большого числа разработчиков перейти на TypeScript, мы не набрали большого импульса и не направлялись к будущему без CoffeeScript.

В начале 2019 года мы возобновили наши усилия по переходу с CoffeeScript на TypeScript. На этот раз мы решили: чтобы вдохнуть жизнь в нашу миграцию, от нас потребуется переосмысление стратегии преобразования существующего кода. Это привело нас к новому набору руководящих принципов. Следуя им, мы превратили то, что казалось трудноразрешимой задачей, в управляемый, хорошо понятный процесс и сумели значительно изменить форму кривых на графике:

Количество строк кода в разработкеКоличество строк кода в разработке

Миграция стека в равной степени касается и технологий, и людей

Самое важное, что мы осознали в ходе этого нового процесса, заключалось в том, что успешная миграция должна быть сосредоточена не только вокруг технологий, но и вокруг людей. Как инженеров нас, как правило, привлекают технические мотивы и (особенно) детали миграции: нам всем нравится идея обрести уверенность в нашем коде, перейдя на TypeScript, а также мы рады потратить часы на то, чтобы точно выяснить, как настроить конфигурацию TypeScript.

Как оказалось, более важные соображения лежат на стороне уравнения с людьми: как заставить наших коллег принять новую парадигму? Этот вопрос поднимает множество других. Например: как сделать разработчиков счастливыми и продуктивными в этой новой модели? Какие барьеры или трения мы можем устранить, чтобы преимущества новой парадигмы стали очевидными? Ответы на эти вопросы помогли нам разработать новый процесс миграции, которым сегодня очень гордимся.

Новый опыт разработки должен предлагать очевидное улучшение

Мы быстро поняли, что для того, чтобы ввести команду в новую парадигму, наши разработчики должны были чувствовать, что они будут более продуктивными, когда будут работать на TS. Если бы команда рассматривала это изменение просто как нейтральный сдвиг между синтаксисами, мы бы никогда не получили общее согласие. Если бы переключение не сделало каждый их день продуктивнее, инерция победила бы даже в случае предпочтения инженером типизированного кода.

Мы начали с определения областей кодовой базы, которые в случае преобразования приведут к существенному повышению производительности, зная, что стратегическое преобразование файлов будет привлекательнее произвольного преобразования. Например, наш слой доступа к данным (ORM) покрывает всё, и большинство файлов каким-то образом работают с ORM. Введение типов на уровне доступа к данным было множителем всей работы; почти каждый преобразованный в будущем файл выиграет от хорошо типизированных моделей баз данных и утилит.

Кроме того, мы сделали приоритетом оснастку и конфигурацию. Большинство разработчиков использовали один из нескольких редакторов, поэтому мы создали конфигурации редактора, которые будут работать сразу. Мы также добавили конфигурации отладки, облегчающие установку точек останова и пошаговое выполнение кода.

Наконец, мы сошлись на наборе согласованных правил линтинга, которые позволили нам писать код в едином стиле по всей организации и сделать переход более удобным.

Когда команды начали видеть плоды этих усилий по преобразованию, весь проект получил одобрение, и импульс к переходу увеличился. Когда наши инженеры начали рассматривать доступ к типизированным данным как незаменимый инструмент, они стали лучше понимать, как подготовить к преобразованию другие части кода.

Технические барьеры нужно ломать

Когда мы начали анализировать шаблоны внедрения TypeScript, стало ясно, что использование TypeScript для наших инженеров не было простым, им часто приходилось импортировать специальные утилиты (ts-node/register) или создавать промежуточные файлы CoffeeScript, которые не делали ничего, кроме импорта их эквивалентов TypeScript. Короче говоря, история взаимодействия языков существовала, но требовала много бойлерплейта и слишком много проб и ошибок.

Были ли эти трения основным блокирующим миграцию фактором? Трудно сказать, но мы знаем, что путь наименьшего сопротивления даёт большую силу, и, если мы хотим, чтобы люди переключались, нам нужно сделать TypeScript простым и очевидным выбором.

Чтобы добиться этого, мы отдавали приоритет усилиям, которые позволили бы разработчикам писать на TS в любом компоненте или сервисе. Будь то бэкенд, фронтенд, скрипты или задачи devops, мы хотели, чтобы наши инженеры могли писать код в TypeScript и чтобы он просто работал. В итоге мы прописали переменную среды NODE_OPTIONSс -r ts-node/register, чтобы существующие (использующие команду coffee для запуска файлов CoffeeScript) рабочие процессы также продолжали работать.

Преобразование должно быть простым, безопасным и автоматизированным

Миграция на другой язык может быть рискованной: то, что может показаться эквивалентным синтаксисом между CoffeeScript и ES6/TypeScript, на самом деле может вообще не быть эквивалентным. И разработчики могут рассматривать преобразование как хорошую возможность для рефакторинга, а это ещё хуже; переписывание делает рискованную миграцию ещё более рискованной.

Чтобы снизить риски, нам нужен был дисциплинированный процесс преобразования файлов без введения регрессий, а также нужно было помочь уйти от соблазна сделать больше, чем просто конверсия один языка в другой. Кроме того, процесс должен был быть быстрым.

Мы остановились на процессе из двух этапов это автоматическое преобразование файла CoffeeScript, за которым немедленно следует ручное добавление аннотаций основных типов и изменений, связанных с линтером. Ключевой момент состоял в том, чтобы противостоять искушению рефакторинга кода любым осмысленным способом. Такое преобразование становится механическим применением простых, безопасных правил, не влияющих на поведение во время выполнения.

Для первоначального преобразования мы использовали скрипт, преобразующий файл .coffee в файл .ts. В целях перехода от CoffeeScript к JavaScript ES6 Под капотом работал decaffeinate. Поскольку весь JavaScript ES6 является синтаксически правильным TypeScript, на выходе получался рабочий файл. (Мы обнаружили, что decaffeinate очень зрелый и надёжный инструмент.) В истории Git шаг преобразования представлен одним отдельным коммитом.

Однако работа ещё не была закончена. Мы используем TypeScript в строгом режиме, поэтому была отключена такая функция, как "implicit any". Мы использовали это окно преобразования как возможность создавать аннотации типов для элементов, где вывод типов был невозможен. Также мы избегали использования any в этой фазе, вместо этого выбрав более строгий неизвестный. Цель на этом этапе состояла в том, чтобы внести изменения, которые не приведут к изменению поведения во время выполнения. Мы не занимались никаким рефакторингом, а просто выполняли минимальный объём работы, чтобы привести код в состояние, в котором он компилировался, линтовался и проходил тесты.

Если зависимости модуля уже были преобразованы в TypeScript, усилий нужно было очень мало: о типах в основном заботились с помощью импортированных модулей. Это привело к эффекту снежного кома, когда по мере преобразования большего количества модулей преобразование в целом стало проще и безопаснее.

Этот второй шаг также прошёл отдельным коммитом; такой подход сильно упростил ревью: ревьюер мог легко увидеть, какие изменения были внесены после шага c decafeinate.

Весь процесс был задокументирован в руководстве по преобразованию машинописного текста. Любой разработчик кучи может преобразовать файл и открыть запрос на вытягивание, чтобы он был объединён всего за 5 минут.

#typescript: канал дискуссий и вопросов

Решение проблемы миграции, подобной этой, означает, что вы просите своих товарищей по команде отказаться от эффективного и удобного им метода работы. Идея заключается в том, что новый подход к работе сделает их более продуктивными. Но достижение этой точки требует времени и усилий с их стороны. Последнее, чего мы хотели, это сбой перехода, когда разработчики в конечном счёте будут биться головой о стену из-за сломанных инструментов, запутанных сообщений об ошибках и загадочных ошибок компилятора. Поэтому нашим следующим приоритетом было выяснить, как использовать опыт всей команды.

Для этого мы создали канал #typescript в Slack и гарантировали, что застрявшие разработчики могут выйти из положения. Разработчики, управляющие миграцией, стали отвечать на вопросы и остановились на поиске общих проблем и камней преткновения. Если возникала одна и та же проблема, они знали, что нужно сделать лучше.

Разработчики должны знать, что на любые вопросы о языке и инструментах, которые у них есть, будут даны быстрые ответы. Мы решили, что чемпионы TypeScript должны отдать приоритет ответам, а не собственной работе. Хотя такой подход замедлил их работу, он также устранил ряд потенциально серьёзных препятствий в миграции.

Отслеживание прогресса

С самого начала мы знали, что массовая миграция за одну ночь невозможна и что, скорее всего, для завершения процесса потребуется год или больше. И это было прекрасно: мы решили, что прогресс важнее совершенства.

Отслеживание усилий во времени оказалось полезным. Таким образом возможно было понять, продолжается ли прогресс в миграции. Для визуализации количества строк мы воспользовались Grafana. Вот ещё одна визуализация, показывающая количество файлов во времени:

Уважающее инженеров руководство

К сожалению, одним из факторов, который в наибольшей степени способствует вашему успеху в подобных проектах находится чуть вне вашего контроля, является готовность руководства предоставить вам пространство для выполнения проекта. Проект миграции был направлен снизу вверх: он начался с того, что я представил план руководителям команд и руководителям инженерных подразделений, и после его утверждения нам предоставили свободу выбора наилучшего способа его реализации. Несмотря на то, что мы говорили о включающем сотни тысяч строк переходе, миграция была на 100 % внутренней.

В целом лучшие защитники подобных проектов это, как правило, команды, ежедневно использующие инструмент, в направлении которого идёт миграция. В Heap нам повезло: наше руководство тоже верит в это, а вера поддерживает идею о том, что лидерство наиболее полезно, когда даёт инженерам возможности и уходит в сторону.

Продолжая эту миграцию, мы надеемся продолжать учиться и использовать то, чему мы научились, чтобы ещё больше упростить следующий проект.

Многим людям без большого опыта в программировании кажется, что писать код на статически типизированном языке сложнее, однако здесь мы видим повышение продуктивности программистов после перехода на язык со статической типизацией.

Ситуации могут быть разными, и если вам не хочется ограничивать себя только одним подходом, владеть языками с разными системами типов, то вы можете обратить внимание на наш курс Fullstack-разработчик на Python, где, кроме Python и TS, студенты также изучают чистый JavaScript.

Узнайте, как прокачаться и в других специальностях или освоить их с нуля:

Другие профессии и курсы
Подробнее..

Что такое SASE и зачем это нужно?

30.03.2021 22:07:52 | Автор: admin


В последнее время активно набирает обороты SASE это один из восходящих трендов в сетевой отрасли. Что это такое? Если кратко, то это технологическая корпоративная стратегия, которая объединяет функции сети и безопасности с возможностями глобальной сети. Зачем? Для того, чтобы обеспечить потребности сетевого доступа современных организаций, причем доступ должен быть одновременно надежным и безопасным.

В целом, можно сказать, что SASE своего рода объединение возможностей SD-WAN и служб сетевой безопасности, включая брандмауэр следующего поколения (NGFW), безопасный веб-шлюз (SWG), сетевой доступ к сети с нулевым доверием (ZTNA) и посреднические службы облачной безопасности (CASB), в единую модель обслуживания. Это если кратко, подробности под катом.

Кому и зачем это нужно?


В общем-то, ответ остается неизменным SASE, в первую очередь, нужна для компаний, преимущественно средних и крупных. Им всегда нужен надежный и главное, непрерывный доступ к облачным ресурсам и данным, которые находятся в облаках. Вся эта информация критически важна для бизнеса, поэтому проблемы не допускаются.

К сожалению, большинство современных решений для обеспечения безопасности не способны обеспечить необходимый уровень скорости, производительности, безопасности и контроля доступа, которые нужны организациям и их пользователям. Можно сказать, что SASE качественный, а не количественный этап развития сетевых технологий и бизнес-стратегий, которые на них базируются.

Сам термин SASE появился только в 2019 году его автором можно считать компанию Gartner, которая употребила термин в своем отчете Будущее сетевой безопасности в облаке. Эксперты агентства в этом ответе указали, что SASE одна из важнейших тенденций рынка. В частности, об этом говорится в разделе Требования клиентов к простоте, масштабируемости, гибкости, низкой задержке и постоянной конвергенции сетевой безопасности WAN и рынков сетевой безопасности.

В отчете дается следующее определение стратегии: SASE объединяет функции сетевой безопасности (такие как SWG, CASB, FWaaS и ZTNA) с возможностями WAN (т.е. SD-WAN) для обеспечения потребности организаций в динамическом безопасном доступе к ИТ-ресурсам. Эти возможности предоставляются в основном в виде -aaS и основаны на определении учетных записей, актуального контекста и политик безопасности и регуляторного соответствия. По сути, SASE это новый пакет технологий, включающий SD-WAN, SWG, CASB, ZTNA и FWaaS в качестве основных возможностей, обладающий способностью идентифицировать конфиденциальные данные или вредоносное ПО, а также способностью дешифровать контент на линейной скорости, с непрерывным мониторингом сессий на предмет адекватного уровня риска и доверия".

Особенности SASE


Главным отличием SASE от других технологических стратегий является размещение механизмов управления безопасностью сети на периметре в пограничной с облаком зоне. В большинстве традиционных моделей управление безопасностью осуществляется централизованно. В итоге SASE ликвидирует необходимость в сервисах, которые нуждаются в индивидуальной конфигурации и управлении. Вместо этого SASE предоставляет стандартизированный набор сетевых сервисов и сервисов безопасности, которые позволяют создать надежную и эффективную сетевую архитектуру в зоне объединения сети и облака.

Компоненты стратегии SASE


Простой стратегию назвать нельзя, она включает несколько компонентов. Но цель всего этого обеспечение безопасного корпоративного доступа к ресурсам.



Основные компоненты:
  • Защита SD-WAN. Включает основные возможности сети WAN, например, динамический выбор пути, самовосстанавливающиеся возможности WAN, поддержка требовательных высокопроизводительных приложений и единообразное взаимодействие с пользователями.
  • Доступ с нулевым доверием (Zero Trust). Главная задача этого компонента многофакторная аутентификация пользователей. Здесь, в числе прочих технологий, используется идентификация на основе ролей.
  • NGFW (физический) или FWaAs (облачный) брандмауэр. Обеспечивает безопасность для периферии и предложений, предоставляемых через облако. Это нужно для защиты периферийных устройств и пользователей не только в сети компании, но и за ее пределами. Благодаря этому компоненту обеспечивается внутренняя сегментация, которая позволяет предотвратить угрозы гостям и/или Интернету вещей, одновременно обеспечивая согласованные политики безопасности для пользователей, которые работают вне сети.
  • Безопасный веб-шлюз. Этот компонент требуется для защиты пользователей и устройств от внешних угроз. Благодаря ему обеспечивается соблюдение нормативных требований подключения сети Интернет. Кроме того, фильтруется потенциально вредоносный интернет-трафик.
  • CASB. Этот компонент представляет собой услугу, которая дает возможность компаниям контролировать собственные SaaS-приложения, включая безопасный доступ к приложениям. CASB и DLP дают комбинированную защиту критически важных данных. Компонент выполняет сразу несколько функций обеспечения безопасности для облачных сервисов, включая выявление теневой активности, защиту конфиденциальности данных и обеспечение соответствия с требованиям регламентов по защите данных.

Какие преимущества дает SASE компании?


В целом, их немало. Всего можно выделить четыре основных плюса.

  • Гибкая и последовательная безопасность. Стратегия предоставляет широкий спектр возможностей по обеспечению безопасности, от предотвращения угроз до политик NGFW, для любой периферии, обеспечивая доступ к сети с нулевым доверием. В итоге компания всегда знает, кто и с какой целью находится в сети компании. Кроме того, все ресурсы компании, как в сети, так и вне защищены, а у сотрудников есть доступ.
  • Снижение общей стоимости инфраструктуры. SASE единая стратегия, объединяющая сразу несколько решений. Благодаря этому не нужно использовать изолированные продукты и зоопарк самых разных решений. Соответственно, снижаются капитальные и эксплуатационные расходы.
  • Снижение сложности инфраструктуры. SASE упрощает архитектуру решений за счет консолидации ключевых сетевых функций и функций обеспечения безопасности из разрозненных систем и решений в единое целое. Все они управляются из единого центра.
  • Оптимизация производительности. Благодаря доступности облачных технологий, все сотрудники компании без проблем подключаются к внутренним или внешним ресурсам, не опасаясь разного рода киберугроз.

На что нужно обратить особенное внимание?



Как и в любой другой ситуации, при внедрении SASE требуется аккуратность при выборе архитектуры и программного обеспечения. Компании стоит быть осторожной с поставщиками, которые предлагают множество функций на основе чейнинга виртуальных машин. Да, все это ускоряет разворачивание инфраструктуры, но одновременно инфраструктура разделяется на сегменты, управлять ею будет достаточно сложно. Лучше всего выбирать тех поставщиков SASE, кто предлагает лицензирование на основе учетных записей во всех продуктах.

А что у Zyxel?




В частности принцип Zero Trust, о котором мы писали выше, позволяющий эффективно контролировать безопасность сети дажи при большом количестве удаленных устройств реализован в Централизованной системе управления сетью Zyxel Nebula. Система предлагает единое, удобное управление распределенной сетью предприятия, а также удаленными локациями и сотрудниками. Все сетевые компоненты находятся в одной экосистеме, управляемой из облака: безопасность, коммутация, беспроводка. В базовой бесплатной версии выполняется большая часть функционала, подходящая для большинства сетей. В частности в одной из гостиниц Голландии базовая версия работает на более чем 300 устройствах.

12 апреля 2021 года Nebula ждет большое обновление, так что многие данные по ссылке выше будут изменены. Узнать самую актуальную информацию о новой Zyxel Nebula и задать свои вопросы вы сможете на серии наших вебинаров.

Вебинар 1 для европейской части России и Беларуси

Вебинар 2 для Украины

Вебинар 3 для Казахстана, Сибири и Дальнего Востока

Вебинар 4 Новая модель лицензирования и сопутствующий функционал Nebula

Добро пожаловать!
Подробнее..

Методологический скачок от таблиц-портянок к понятному каталогу услуг в ITSM-системе

14.10.2020 14:07:29 | Автор: admin


Если вы аналитик-внедренец ITSM-решений, то точно знаете, какой гигантский клубок информации приходится разматывать в каждом клиентском проекте. Разобраться в процессах, собрать требования, заполнить десятки документов и согласовать их На любом из этих этапов легко попасть в ловушку данных. Спасает итеративный подход и опыт.

На этапе проектирования в ИТ-системе клиентского каталога услуг, задач не меньше. В этой статье хотим рассказать, как мы попробовали разные подходы к созданию сервисных каталогов, почему отказались от многостраничных документов и таблиц, а также как организован процесс сейчас.

Эволюция подхода к созданию сервисного каталога


В клиентских проектах мы пробовали разные подходы к составлению сервисных каталогов.

Таблицы в Word. Еще несколько лет назад по каскадной модели разработки (Waterfall) скрупулезно собирали информацию в текстовые файлы. В этих документах фиксировали всё от наименования услуг, основных ответственных до видов деятельности по определенной услуге и SLA.

image

Пример табличного описания услуги Электронная почта в формате текстового документа

Процедура такой описи нетривиальна и отчасти бесполезна. Пока поочередно перебираешь услуги и добираешься до последней, первая уже теряет актуальность: исполнитель изменился, сроки пересогласованы, набор возможностей пересмотрен. Всю работу можно делать заново.



К концу аудита услуг заполненные таблицы могли исчисляться десятками


Мало того, что информация корректируется на ходу, так и сам набор параметров с каждым обновлением таблицы пухнет и пухнет. Ведь по услуге недостаточно знать SLA и ответственность. Лучше помнить всех получателей поименно, а также выяснить, какие ресурсы инфраструктуры услуга предоставляет и от каких ресурсов зависит.

В то же время в любой компании процессы не статичны. Появляются новые сервисы, развиваются существующие. Услуги обрастают огромным слоем объектов: запросами, справочниками, связями, параметрами, КЕ.

Сколько бы ни длилась разработка документа, конца и края не видать. Документ сложно согласовать, да и его пригодность сомнительна. Это как с ремонтом, который нельзя закончить, а можно только приостановить. Так и в наших прошлых проектах работа с многостраничными свитками обычно заканчивалась фразой: Довольно! Пора перебираться в систему.

Таблицы в Excel. Взамен многостраничных документов в нашу практику ворвались другие таблицы. Описательную часть для клиента мы по-прежнему оставляли текстом. А к нему прикладывали таблицу со списком услуг и их параметрами. Сложить нужную информацию в один документ опять не получалось. По факту каталог услуг вырастал в сеть взаимосвязанных таблиц.



Сопровождать в Excel множество вкладок и столбцов вручную неудобно. На эту работу аналитик внедрения тратил сотни часов


Такой способ составления списка услуг нами рассматривался как почва для первичного импорта в систему автоматизации. Далее развитие и оптимизацию планировали вести уже в ИТ-системе. Но и этот подход оказался не без минусов.

Как показывает наш проектный опыт, подготовка каталогов в виде статичных документов экономически не оправданная задача. Трудозатраты огромны, выхлоп нулевой. Кроме как для подписания документа и закрытия актов он больше не понадобится. Если внедрен удобный инструмент автоматизации, никто эти таблицы-портянки не пересматривает.

Другое дело динамический каталог, который изначально проектируется со своей структурой и ценностью в инструменте автоматизации. Подобный каталог начинает функционировать только с появления в нем первой услуги. Нельзя на этапе внедрения разработать каталог услуг под ключ. За этот период удается запустить процесс по его наполнению и актуализации. А значит оптимальный подход собрать минимум информации и сразу идти в ИТ-систему.

В чем ценность каталога услуг



Пользу грамотно спроектированного сервисного каталога почувствуют все участники процесса.

Получатель услуг быстро в пару кликов сможет сформировать обращение и не запутается, где и что выбрать.



Интерфейс Портала самообслуживания с удобной группировкой услуг. Реализован на базе платформы Naumen SMP

Практикам процессов по услугам не нужен каталог как таковой. Заданная структура помогает упростить процесс классификации заявок и их последующую обработку. Становятся понятны сроки, шаги выполнения, затронутые услуги, заинтересованные лица в согласовании и эскалации.

Менеджерам процессов срез данных по портфелю предоставляемых услуг необходим для управленческих решений: аудит объема обращений, информации о достижении договоренностей и соблюдении процессных процедур.

Владельцам и Заказчикам интересны параметры качества и финансов.

Какие шаги помогут создать каталог услуг в ИТ-системе


В основу разработки понятного каталога услуг лучше положить итеративный подход и двигаться по шагам.

Шаг 1. Определение цели


Главный вопрос в любой деятельности зачем?. Для себя цели сервисного каталога сформулировали так:

  1. Организовать продуктивное взаимодействие с получателями услуг.
  2. Использовать единую платформу для построения ITSM-процессов и применения сервисного подхода во всех подразделениях компании.
  3. Заложить основу для управления и развития всех бизнес-процессов.

Шаг 2. Проведение обследования


Нередко клиенты говорят: Каталог услуг у нас готов. Но его не покажем, чтобы не сбивать подходом по наитию. Предложите нам правильный каталог с нуля.

В наше время с нуля это как вернуться в каменный век или попробовать заново изобрести велосипед. Не стоит отказываться от наработок. Берем все, что есть, и упаковываем в ИТ-систему.

Если каталог услуг в компании не формализован, анализируем такие артефакты:

  • журнал обращений;
  • (если используются) классификаторы и справочники для заявок;
  • список информационных систем и оборудования;
  • оргструктуру;
  • сервисные контракты с внешними поставщиками.

Далее алгоритм следующий:

  1. Выделяем популярные вопросы к сервисным службам.
  2. Формируем набор услуг на понятном пользователю языке.
  3. Группируем и приземляем обращения на управляемые ресурсы.
  4. Предлагаем наименование услуги, которое увидит пользователь в ИТ-системе при подаче обращения.



Пример корреляции: Обращение пользователя-Оборудование-Услуга в ИТ-системе


Изначально в каталоге стоит предусмотреть услугу Прочее/Заявка в свободной форме. Негласно ее называют Канал подачи мусора. При периодическом анализе подобных обращений можно определить:

  • неудачно сформулированные наименования услуг. Например, конкретная услуга присутствует в каталоге, но пользователи ее не находят и выбирают универсальную;
  • потребность в обучении персонала. Например, пользователи конкретного отдела систематически указывают услугу Прочее, в то время как большинство подразделений выбирают корректные классификаторы;
  • тенденции и потребности в развитии сферы услуг. Например, поступает большой объем повторяющихся обращений на услуги, которые не предоставляются сервисной организацией.

Шаг 3. Распределение ответственности


Когда стартовый набор услуг готов, необходимо установить и зафиксировать исполнителей.

Важно определить уровни ответственности:

  • Исполнитель обращений.
  • Менеджер услуги.
  • Менеджер каталога.

Исполнителя найти проще. Для этого в опоре на статистику журнала обращений сопоставляем должностные инструкции с функциональными обязанностями и компетенциями.

Менеджером услуги будет тот, к кому в первую очередь приходят Заказчики, если услуга не функционирует либо ее качество не устраивает потребителей. Скорее всего, это руководитель исполнителя либо вышестоящий по ветке оргструктуры сотрудник.

Выбор ответственного за весь каталог задача посложнее. Как показывает практика, чаще такими менеджерами назначаются:

  • Руководитель проекта внедрения ПО. Видит картину в целом и может принимать управляющие централизованные решения.
  • Руководитель сервисной организации (ИТ-департамента). Наиболее заинтересован в развитии взаимоотношений заказчиков и исполнителей, владеет знаниями стратегии сервисной организации и знает, как они коррелируют со стратегией основного бизнеса.
  • Группа компетенций. Ответственность закрепляется не за конкретным специалистом, а формируется на основе знаний участников проекта внедрения: РП, главных консультантов, сотрудников, которые способны передавать знания другим участникам.

Шаг 4. Подготовка каталога


Когда первичная версия каталога собрана, можно приступать к более глубокой проработке.

Здесь сразу делимся нашими наработкам: какие параметры на практике оказались наиболее востребованными и зачем они нужны.



Готовый перечень параметров услуги. Скачать полную версию

Результатом формирования каталога услуг в ИТ-системе становится качественный классификатор, при этом еще обновляемый и управляемый.

Шаг 5. Развитие каталога


Важный этап развития каталога услуг настройка связи с ресурсно-сервисной моделью (РСМ). Ее проектирование и поддержка может поглощать бесконечные трудоресурсы. Но пользы от нее гораздо больше.

Ценность этой связи покажем на простом примере. В компании не работает интернет. Инцидент зарегистрирован. Именно РСМ поможет быстрее узнать, в чем источник проблемы (по связям с поддерживающим оборудованием) и какие зависящие от этого узла сервисы будут отваливаться дальше.

Финальный аккорд расписать взаимозависимости между услугами, добавить перечень КЕ и завести в ИТ-систему процесс управления конфигурациями. И главное жить по процессу, чтобы все это нежно собранное не расплескать!



Пример части каталога услуг, который одновременно служит классификатором КЕ


Когда каталог услуг сформирован, КЕ загружены и связи прописаны, останется провести интеграцию с системой бухгалтерского учета. Рассчитать себестоимость услуг, стоимость их поддержки. Но это уже другая история
Подробнее..

Перевод Простота на службе ваших ITSM процессов

06.12.2020 16:18:24 | Автор: admin

Простое описание процесса, созданное с помощью участников процесса, может быть крайне полезным, но если описание запутанное и сложное для понимания, попробуйте его переделать.

Как нас когда-то учили переходить дорогу

Когда я был маленьким ребенком, нас учили переходить дорогу, давая такие инструкции:

  • Остановись на краю дороги

  • Посмотри направо

  • Посмотри налево

  • Снова посмотри на право

  • Прислушайся

  • Если все чисто и тихо, переходи

И мы напевали эти слова всякий раз, когда требовалось перейти дорогу.Конечно, из-за юного возраста мы не понимали реальную опасность, но, как и многие другие, я думал, что повторение этих магических слов мне помогает защититься от этих гадких машин. Сейчас я не уверен осознавал ли тогда, что меня подталкивают быть осторожным и услышать, чтобы заметить автомобили, которые не видны взгляду. А что я должен был сделать, если бы определил? Спрятаться от них? Очень быстро перебежать через дорогу? Все что я знал - это чтобы перейти дорогу я должен повторить правильные слова. Позже анализируя я понял, что слова детского заклятия были руководством пользователя по пересечению проезжей части.В начале 60-х из исследований стало понятно, что зубрежка бордюрной считалочки работает плохо. Сейчас считается, что дети, заучивая через многократное записывание, (привет, заставка от Симпсонов) не всегда понимают смысл, и что, еще хуже, дети младше девяти не различают бордюр от сточной канавы или разницу право и лево - joemoran.net

Я вижу нечто похожее во многих процессах управления ИТ сервисами у моих клиентов. Слишком часто они требуют у своих людей следовать предустановленным процедурам без необходимого понимания зачем им это делать и видят ли они в этом смысл.

Посещение Комитета по изменениям (change advisory board, CAB)

Многие организации запустили регулярные встречи Комитета по изменениям для рассмотрения изменений. Я видел достаточно много их, чтобы заметить, что часто их деятельность очень похожа на проведение детишек, выучивших очередную бордюрную считалочку. Знание, что CAB - это место встреч, где предотвращаются негативные последствия ошибок при изменениях, не сильно проясняет, что именно делать для снижения рисков наступления этих негативных последствий.

Что нужно делать на встрече CAB, что инициатор изменения не может сам сделать без CAB?

Какую ценность добавляет изменение, которая перевешивает его негативные последствия и позволяет утвердить его на реализацию?

Действительно ли данный вариант лучше для того, чтобы изменение рассмотренное и утвержденное кем-то компетентным было бы реализовано так, что об изменениях узнали все заинтересованные и что скорость реализации соответствовала бы потребностям бизнеса?

Дословно change advisory board (CAB) - консультационный совет по изменениям, т.е. название содержит намек на совещательный его фокус, а не решающий.

Решение инцидентов

Я видел практически одно и тоже во многих службах техподдержки. Сотрудники, получив сценарии, четко им следуют, считая, что должны давать ответы из этих сценариев без учёта особенностей конкретной ситуации, а также искренне уверены, что все ими сказанное нужно фиксировать в в истрии решения инцидента нужно. Сотрудники техподдержки особенно четко следуют сценариям решений, если в них написано, что нужно перезагрузить компьютер, даже если очевидно, что это не поможет решить текущую проблему. Хуже всего, что это раздражает и разочаровывает пользователей в оценке возможностей техподдержки, и усложняет общение при следующих обращениях пользователей. Обеспечивать сотрудников техподдержки рекомендациями и чек-листами для общения с пользователями - это важно и нужно, но это не заменяет обучение сотрудников думать, что они говорят, а затем ожидать от них, чтобы они говорили правильные вещи.

Даже хирургам нужны чек-листы

Операции в больницах лучший пример того, как чек-листы могут быть полезны. Не вызывает сомнения, что хирурги знают, что им не стоит оставлять тампоны или инструменты внутри пациента, но ошибки все равно случаются. Использование чек-листов в этих ситуациях дает заметное уменьшение количества ошибок.

Исследование показало, что использование простых хирургических чек-листов в течение важных операций помогает избегать в более, чем 40% смертей, и осложнений в более чем трети случаев - BBC.

Что интересно, в этом случае чек-лист не рассказывает хирургу, как делать свою работу. Этому его учат годы обучения и практики. Чек-лист - это просто одна страничка, которая можно заполнить за несколько минут, но это это помогает предотвратить большинство общих ошибок.Но все не так просто. Сами по себе хирургические чек-листы не гарантируют улучшения клинических результатов. Анализ того, как и почему конкретный чек-лист работает показывает, что эффективная реализация требует обучения и тренировки и изменения в культуре безопасности, но это уже другой урок, который мы можем применить в ITSM.

Так что это все может означать для ITSM?

Все это определенно не означает, что стоит выбросить все ITSM процессы. Но важно быть уверенным, что они также, как и хирургические чек-листы, были простые и эффективные. Если вы создаете сложные описания процессов со множеством действий, покрывающих все возможные ситуации, то это не лучший вариант добавить ему ценности. Вот, что стоит в таком случае сделать:

Обучать персонал до уровня навыков необходимых для оценки изменений, решения инцидентов, исследования проблем и т.д. Предоставлять знания персоналу необходимые для анализа рабочих ситуаций и принятия правильных решений.

Улучшать инструменты, используемые персоналом для работы. Помогать сотрудникам создавать простые чек-листы и процессы, чтобы быть уверенным, что они будут правильно выполнять работу И ЗАТЕМ доверять сотрудникам.

Заключение

Если ваши ITSM процессы объемны и сложны, это мешает вашим сотрудникам эффективно работать, и, возможно, пора их пересматривать и упрощать. Может казаться, что самый простой путь реализации этого придумать более простые чек-листы и процессы, а затем заставить всех ими пользоваться. Но если так сделаете, то можете к своему удивлению обнаружить удручающий результаты, как те взрослые, которые учили меня бордюрной считалочке. Новую культуру не удастся насадить, а вот вовлечение людей в разработку простых процессов, сработает гораздо лучше и может запустить культурные изменения. И все это может вызвать гигантские изменения в удовлетворенности и заказчиков, сотрудников, а также может дать возможность классно делать свою работу. Попробуйте дать сотрудникам возможность воспользоваться их навыками, знаниями, инструментами и верой в то, что они нужны для того, чтобы делать классную работу? И вы можете быть поражены, как успешно они решат задачу.

Подробнее..

Как создают и поддерживают веб-страницы tinkoff.ru

22.04.2021 14:23:53 | Автор: admin

Всем привет! Меня зовут Сергей Михайлов, в Тинькофф я работаю руководителем интерфейсов: занимаюсь внутренними сервисами, а также отвечаю за дизайн-составляющую Отдела привлечения клиента. Расскажу, как мы быстро собираем страницы с помощью нашего конструктора.

Как это работает сейчас

В Тинькофф около 2000 страниц с разным дизайном и за все эти страницы отвечает отдел привлечения. Он состоит из подразделений, которые отвечают за карточные продукты, депозиты, инвестиции, страхование, мобайл, путешествия и так далее.

Все наши страницы состоят из блоков. Например, на главной странице есть шапка, блоки с главным баннером, с заголовком и с карточкой продуктов.

Макет блока в FigmaМакет блока в Figma

Страницы собираются из блоков в нашем Конструкторе.

Конструктор страницКонструктор страниц

Вот пример такого блока с карточками:

Блок Продуктовые карточкиБлок Продуктовые карточки

В него уже вшита логика с отступами, возможность выключить заголовок или изменить стиль кнопки. Также в блок уже вшита логика растягивания. На примере блок для экрана 1024, а при разрешении 1360 блок растянется. Так у нас работают все блоки.

Конструктор, в котором собираются страницы, это часть нашей CMS. Главное преимущество админки возможность быстро и безрелизно вносить правки на страницу, настраивать аналитику и персонализацию.

Экран собранных страниц и черновиковЭкран собранных страниц и черновиков

Мы тестируем много страниц и иногда для теста создаём новые блоки. Раньше создание нового блока занимало у команды разработки до 2 недель. При этом если если тест не проходит, то от блока отказываемся.

Поэтому, чтобы экономить время, мы можем собрать в Конструкторе блок, сразу его протестировать и, если тест успешен отдать его в команду разработки для добавления в библиотеку блоков.

Также в Конструкторе мы отдельно собираем десктопную и мобильную версии страницы. Например, есть страница, на ней два одинаковых блока, но выглядят они совершенно по-разному.

Десктоп и мобильная версия страницы Тинькофф ПлатинумДесктоп и мобильная версия страницы Тинькофф Платинум

На мобильных версиях мы обычно делаем меньше текста, меньше изображений и тем самым разгружаем трафик пользователя. С помощью тестов мы выяснили, что конверсия не проседает. Однако так было не всегда.

Как было раньше

Вернемся на пять лет назад и посмотрим, как у нас был выстроен процесс создания страниц.

В 2016 году аналитики и разработчики задались вопросом: У нас же большая часть страниц продающие лендинги. Почему бы не сделать сервис, который обрабатывал бы все эти страницы?.

Тогда придумали систему, назовем ее версия 0. К сожалению, ее скриншоты не сохранились. Вся страница выглядела как один большой блок с формой. Даже такой подход всех устроил, его стали активно использовать и сделали админку с Конструктором версии 1.0.

Конструктор версии 1.0Конструктор версии 1.0

У старой админки еще не было интерфейса, в котором можно было собирать лайв-превью страниц, не было превью блоков, но она уже обладала рядом функций, которые всех устраивали. Функционала становилось все больше, добавилась, например, возможность просматривать историю публикаций и изменений, появилась сложная настройка блоков. Админка превратилась в версию 2.0.

Конструктор версии 2.0.Конструктор версии 2.0.

Дизайнеров у нас в команде конструкторов тогда не было, админку собрали на Material Design. Большим минусом стало то, что из-за сложности системой могли пользоваться только наши контент-менеджеры, которые умели собирать страницы и настраивать сложные блоки. Было бы неплохо сделать нормальную систему, с которой смогли бы работать все пользователи.

Сформулировали цели для новой админки:

  • Уменьшить порог вхождения новых пользователей. Нам было важно, чтобы не только контент-менеджеры могли собирать страницы, но и дизайнеры, заказчики и менеджеры.

  • Сделать понятный процесс сборки страниц, а процесс подготовки пользователя не занимал больше одного дня. Важно, что человек, более или менее знакомый с любым конструктором типа Тильды, мог сразу же собирать страницы и в нашей админке.

  • Сократить время выпуска новых страниц.

Собрали команду из аналитика, дизайнера, контент-менеджера и разработчика. У нас не было привычного флоу, когда дизайнеры и аналитики придумывают интерфейс и отдают разработчикам. Вместо этого мы с самого начала собирались всей командой, проводили дважды в неделю встречи, на которых составляли разные фреймворки, писали сценарии по User Story Mapping. То есть все участники процесса имели слово и вместе собирали админку.

Результатом стала админка версии 3.0.

Конструктор версии 3.0.Конструктор версии 3.0.

Новая админка сократила сроки выпуска: если раньше любой релиз можно было вносить раз в две недели, потому что у каждой команды был свой график релизов, то теперь, благодаря админке, это время сократилось до пяти минут. Пользователи заходят на нужную страницу, вносят правки (например, меняли процентную ставку) и нажимают кнопку Опубликовать и страница тут же была на продакшене. Таким образом мы закрыли одну проблему. Однако вместе с этим появилась другая проблема.

Проблема с блоками

Например, у нас есть команда страхования, в которой есть свой дизайнер, контент-менеджер, разработчик и аналитик. Им понадобился новый блок карточка с иконкой и кнопкой. Они разрабатывают карточку и вносят ее в библиотеку блоков админки. И вроде бы все хорошо, только они не знали, что вместе с ними параллельно еще две команды делали точно такой же блок.

На таком уровне не было синхронизации, и, например, одна команда сделала блок с большой иконкой, другая с маленькой, кто-то добавил две кнопки, кто-то убрал бейдж.

Все три команды добавили блоки в админку. Во-первых, непонятно, какой блок использовать. Во-вторых, у каждого продукта свое приложение для отрисовки страниц и это порождало проблему: если одна команда сделает блок под себя, то у другой команды, взявшей этот блок к себе на страницу, полетит вся верстка.

Какие у этого минусы::

  • Затраты на разработку. Разные команды делают одно и то же.

  • Много одинаковых блоков.

  • Один и тот же блок выглядит по-разному на разных страницах, из-за этого у нас нет консистентности.

Тогда мы приняли решение создать команду для разработки и поддержки блоков, которая экономила бы нам ресурсы и отвечала за то, чтобы новые блоки могли использовать все. Например, если команда инвестиций прибегает и говорит: Нам нужен блок, то команда админки уже делает так, чтобы этот блок могли использовать и другие команды, а также следит за тем, чтобы лишних блоков не было, а в новых учитывались дополнительные кейсы.

Например, команда продукта нарисовала блок с двумя карточками и хотят его разработать Команда админки, уже учитывая свой опыт, понимает, что такой же блок может понадобиться другой команде, но они захотят сделать не две, а три карточки. Для этого не надо делать новый можно добавить функционал в текущий. А может, кому-то понадобится большее число карточек, и тогда можно сделать карусель. Такими задачами занималась команда админки.

Проблема с процессом сборки страниц

Из-за того, что админка настолько всем зашла, все хотели ею пользоваться, но у нас не было унифицированного флоу, по которому бы все работали. Появилось много новых пользователей, которые сами придумали себе процесс работы.

Давайте посмотрим на средний состав участников процесса создания страниц:

  • Заказчик человек, которому нужна страница, чаще всего это product owner.

  • Копирайтер пишет текстовый прототип страницы.

  • Дизайнер собирает макет.

  • Разработчики подключаются, когда нужна разработка нового блока.

  • Контент-менеджеры все еще специалисты нашей админки, которые настраивают сложные блоки (футер, шапку, формы с различными шагами).

  • Аналитики вносят свои настройки в страницу.

Например, заказчик мог пойти в админку, собрать и опубликовать страницу. Либо он мог отдать задачу на создание текстового прототипа копирайтеру. Копирайтер все это передает контент-менеджеру, а контент-менеджер в админке собирает страницу. Либо заказчик ставит задачу дизайнеру, дизайнер в Figma собирает макет, контент-менеджер по макету из Figma собирает в админке страницу. Таких процессов у нас было очень много, но усредненно процесс выглядел так:

Заказчик ставит задачу копирайтеру, копирайтер отдает текстовый прототип дизайнеру, дизайнер собирает в Figma макет, контент-менеджер по figma-макету собирает в админке страницу, все ребята его согласовывают. Если нужен блок, ставят задачу разработчикам и затем передают аналитику для окончательной настройки, после чего страница запускается.

Минусы такого подхода:

  • Планирование времени участниками. Случались ситуации, когда новый участник процесса узнавал о задаче за неделю до выпуска.

  • Блоки в макетах не соответствуют реальности. Помимо сторибука, где хранятся все наши блоки, эти же блоки есть и в Figma, откуда их берут дизайнеры. Бывало так, что дизайнер собирая страницу может добавить новый элемент в блок, не зная, как он на самом деле работает. Впоследствии, когда контент-менеджер начинал собирать страницу по figma-макетам, ставил блок из админки и понимал, что блок так не работает. В итоге много времени уходило на разбирательство, как поступить в этой ситуации.

  • Новый блок для страницы ждем долго. Как я упомянул выше, мы очень поздно предупреждали разработчиков о том, что нам нужен новый блок. Разработчики не успевали его подготовить либо, очень злясь на нас, были вынуждены готовить его быстро, но говорили, что это в последний раз.

  • Нет консистентности. Разные участники собирают страницы, шаблонов нет, многое каждый делает по-своему из-за этого страницы могут выглядеть по-разному.

  • Нет понимания зон ответственности и результатов работы.

  • Увеличивается срок выпуска страниц.

Решение

Столкнувшись с вышеописанными проблемами, мы решили:

  • Описать правильный и понятный процесс выпуска страниц, потому что у ребят уже были свои чек-листы, гайды и так далее.

  • Описать зоны ответственности. Собрать все вместе и превратить в нормальный процесс.

  • Дизайнеры собирают страницы в Конструкторе. Перевести всех дизайнеров со сборки страниц в Figma в наш Конструктор, чтобы они понимали, как работают блоки, и из них составляли страницы.

  • Все команды подключаются на старте.

Что мы для этого сделали? Для начала я нарисовал весь процесс работы из тех чек-листов, которые у нас были. По этому процессу заказчик по шаблону заводит эпик и прилинковывает задачи копирайтеру, ставит задачи дизайнеру, контент-менеджеру и аналитику. То есть ребята уже заранее знают, что понадобится страница, понимают, что им предстоит делать, и планируют свое время соответственно.

Копирайтер может использовать артефакты: он может пойти в сторибук, посмотреть, как работают блоки, если ему так проще составлять прототип; может пойти в Figma либо в Конструктор. Результатом его работы будет текстовый прототип (на самом деле не только текстовый прототип может быть собран в PDF или в Figma, и это будет результатом работы).

Затем этот прототип передается дизайнеру. Дизайнер может по-прежнему использовать сторибук, Figma, гайд по сборке страниц, который у нас есть, но все равно результатом его работы будет ссылка на десктопную и мобильную версии страницы.

Но бывает проблема: уже в процессе сборки страницы дизайнер понимает, что ни один из текущих блоков не подходит и понадобится новый блок. Тогда он заводит задачу для разработчиков, и те уже начинают его создание.

Как создают новые блоки?

Дизайнер рисует мобильную версию страницы и в процессе понимает, что ему нужен блок (карточка с иконкой), которого у нас еще нет. Согласно процессу, он идет в команду дизайна и говорит: Нам нужен новый блок. Ребята понимают, что это многофункциональный блок, который может понадобиться всем, его можно встраивать и на другие страницы. Тогда задача передается в команду админки, у которой есть два варианта:

  1. Команда админки видит, что есть похожий блок, но без иконки это просто текстовая карточка со своим набором полей. Они решают дополнить эту карточку иконкой и добавить новые настройки. После миграции все могут использовать этот блок и нет необходимости создавать и поддерживать новый.

  2. Нужного блока нет, и похожего тоже нет. Тогда дизайнер идет в Figma и там собирает макет для разработчиков, отрисовывает все состояния и, когда макет собран, он передается в команду админки, которая создает схемы и UI блока. То есть команда админки решает, какие опции должны быть в настройках карточки. Команда блоков верстает и тестирует этот блок.

Макет блока для вёрсткиМакет блока для вёрстки

При разработке блоков используют инструмент Multistory, который разработала команда блоков.

Multistory показывает все возможные варианты и состояния этого блока, все текстовые стили, все варианты его поведения, при которых мы понимаем, все ли мы учли в макете, можем отследить возможные проблемы и решить их.

MultiStoryMultiStory

Когда блок уже сделан, он попадает в библиотеку блоков нашего Конструктора, где его могут все использовать.

Библиотека блоков в КонструктореБиблиотека блоков в Конструкторе

Для отслеживания поведения блоков команда блоков разработала инструмент RealStory. Например, есть карточка с картинкой (заголовком, кнопкой), и мы можем в реальном времени посмотреть, на каких страницах сейчас эта карточка присутствует и как она выглядит. Это позволяет дизайнерам и разработчикам отслеживать поведение блока: как он работает и нет ли в нем ошибок.

RealStoryRealStory

Вернемся к процессу

Когда дизайнер сделал десктопную и мобильную версии страницы, задача попадает к контент-менеджеру, и он идет настраивать блоки через Конструктор. Он настраивает шапку и футер для блока, делает сложные настройки и затем передает задачу аналитику. На самом деле чаще всего контент-менеджер и аналитик могут работать параллельно, а иногда контент-менеджер уже знает настройки аналитики и заполняет их самостоятельно.

Если, например, контент-менеджер не настроил аналитику сам, то задача аналитика настроить эти блоки: какие блоки надо трекать, настройки шеринга либо настройки оптимизации и персонализации. После задача попадает обратно в эпик.

Я нарисовал схему, как ее представлял, и пошел по всем участникам процесса. Стал рассказывать, что мы хотим ввести новый единый процесс, по которому могли бы все работать, и все восприняли это с энтузиазмом, стали помогать, у нас собралась большая команда.

После я перенес схему в Notion, где каждый мог оставлять комментарии, мы что-то перерабатывали, а результатом стала как раз та схема, которую я показал выше. Сейчас этот новый процесс на этапе реализации.

Процесс в NotionПроцесс в Notion

Что будет дальше?

Во-первых, из-за того, что у нас много команд и они большие, нельзя просто взять и сказать: Теперь вы будете делать так, как мы решили. Конечно, так нас просто пошлют. Для начала мы решили протестировать на небольших процессах, на сборке шаблонных страниц, и процесс начал себя показывать достаточно хорошо. Конечно, есть нерешенные проблемы (например, на какой стадии подключать команды), но процесс двигается хорошо. Более того, команда блоков уже работает по новому процессу, и это экономит много ресурсов и времени.

Всегда думайте о том, что можно улучшить в ваших процессах. Если у вас есть предложения и идеи, всегда привлекайте членов команды для участия в процессах на самом деле каждому человеку есть что рассказать и так может получиться крутой проект. И будьте активнее: чем активнее вы собираете команду, тем больше людей будут вовлекаться в ваш процесс и его можно улучшать, не дожидаясь кого-то. Вряд ли кто-нибудь выступит против конечно, все с удовольствием будут улучшать процесс.

Подробнее..

Рассказываем про библиотеку для Process Mining теперь SberPM в открытом доступе

27.04.2021 14:21:47 | Автор: admin
Process Mining это подход к извлечению, анализу и оптимизации процессов на основе данных из так называемых журналов событий (event logs), доступных в корпоративных ИТ-системах. Являясь своеобразным мостиком между Data Mining и Process Management, он выводит исследование бизнес-процессов на принципиально новый уровень. Подробнее о том, чем полезен такой подход и как мы его применяем вот здесь .

В конце 2020 года в открытый доступ вышла разработанная Сбером python-библиотека SberPM первая в России мультифункциональная библиотека для интеллектуального анализа процессов и клиентских путей. Ниже про то, как она устроена и как ей пользоваться.

image



DataHolder


Основу для применения Process Mining формируют данные лог-файла, в котором хранится информация о выполненных в рамках одного процесса действиях. Работа с библиотекой начинается с загрузки лога в DataHolder, под капотом которого производится автоматическая предобработка данных удаление нулевых значений, сортировка по времени и т.д. Как следует из названия, DataHolder хранит исследуемые данные с указанием ключевых атрибутов, необходимых для анализа ID (идентификатор события), активности, временные метки начала и/или конца событий. Также для более глубокой и интересной аналитики могут быть добавлены дополнительные атрибуты: ID и роли пользователей, территориальный и продуктовый разрезы, текстовые комментарии и другое.

image

Помимо этого, с помощью методов DataHolder можно быстро выполнить основные операции с лог-файлом, например, рассчитать длительность каждой активности или сгруппировать данные по ID и указанным колонкам.

image

image

Понятие DataHolder является базовым, поскольку большинство алгоритмов библиотеки работают с экземпляром именно этого класса.

Майнеры, визуализация и BPMN


Хранящийся в DataHolder лог-файл обеспечивает достоверную и детализированную информацию о ходе исполнения бизнес-процесса. С ее помощью можно реконструировать модель реального, а не предполагаемого процесса. Для построения графа AS-IS процесса в библиотеке реализовано несколько алгоритмов, называемых майнерами:

  • SimpleMiner рисует все ребра, найденные в логе;
  • CausalMiner рисует только прямые связи;
  • HeuMiner удаляет наиболее редкие связи в зависимости от порога (threshold) чем он больше, тем меньше ребер на графе;
  • AlphaMiner рисует граф в виде сети Петри с учетом прямых, параллельных и независимых связей между активностями;
  • AlphaPlusMiner Alpha Miner, который может работать с одноцикловыми (one-loop) цепочками.

Визуализировать полученный в результате работы майнера граф процесса можно встроенными средствами Graphiz следующим образом:

image

Можно также сохранить (импорт) или загрузить (экспорт) граф в формате BPMN (Business Process Model Notation):

image

Визуальная схема позволяет не только получить полное представление о цепочке событий, но и исследовать актуальное состояние процесса на любом уровне детализации. В качестве примера рассмотрим графы, построенные различными майнерами, для одного и того же синтетического процесса:

image

Итак, CausalMiner позволяет отобразить процесс наиболее линейно, HeuMiner показывает самые частотные цепочки, а AlphaMiner наглядно демонстрирует параллельные участки процесса.

Метрики


Process Mining, как известно, не ограничивается восстановлением моделей бизнес-процессов из лог-файлов. Важной составляющей анализа является расчет и мониторинг ключевых индикаторов исполнения процесса. За это в библиотеке отвечает модуль метрик, в котором на данный момент реализованы следующие виды статистик:

  1. ActivityMetric метрики по уникальным активностям;
  2. TransitionMetric метрики по уникальным переходам;
  3. IdMetric метрики по ID;
  4. TraceMetric метрики по уникальным цепочкам активностей;
  5. UserMetric метрики по уникальным пользователям;
  6. TokenReplay fitness, который показывает, насколько хорошо граф описывает бизнес-процесс.

В первых пяти случаях для объекта группировки рассчитываются число появлений, число уникальных ID / активностей / пользователей, процент зацикливаний, временные характеристики (средняя, медианная, максимальная и другие виды длительности) и т. д.

Пример работы класса UserMetric:

image

Несомненным преимуществом данного модуля является быстрота расчетов. Допустим, перед аналитиком стоит задача определить среднюю длительность самых частотных цепочек событий процесса. Решение методами pandas займет 5 минут и более 10 строк кода, в то время как решение методами SberPM 1 минуту и 3 строчки кода.

image

Помимо этого, в библиотеке реализована возможность добавить метрики на граф процесса. Сделать это можно следующим образом:

image

В результате на графе можно, например, изменить ширину ребер и цвет нод в зависимости от значений метрик и тем самым отследить самые частотные пути и долгие этапы процесса.

image

Таким образом, анализируя модель реконструированного процесса вместе с данными о длительности и особенностях его исполнения, можно выявить задержки по времени реализации отдельных действий, взаимосвязи между пользователями, зацикленности в процессе, неэффективных исполнителей, а также скрытые недостатки и проблемы в процессах, из-за которых может существенно снижаться производительность целой организации.

Модуль ML


Помимо классических инструментов Process Mining, SberPM предлагает функционал методов машинного обучения. На данный момент пользователям доступны векторизация и кластеризация процессов, а также модуль автопоиска инсайтов. Расскажем подробнее, для чего это нужно и как этим пользоваться.

Допустим, необходимо провести анализ крайне загруженного процесса, сложного по структуре и с большим количеством активностей и связей. Например, как этот:

image

Даже при беглом взгляде на граф понятно, что анализ подобного процесса займет огромное количество времени и не факт, что в итоге удастся найти все узкие места и неэффективности. Но можно облегчить задачу, получив векторные представления каждой цепочки событий (trace), а затем выполнив кластеризацию процесса на его составляющие, схожие по структуре и свойствам. Получение векторных представлений, или эмбеддингов, реализовано в SberPM удобно и логично:

image

Для кластеризации предназначен класс GraphClustering. Ниже приведен пример работы с ним:

image

Таким образом, каждому trace из лога будет сопоставлена метка кластера. Объединив цепочки с одинаковыми метками, получим подпроцессы, пригодные для дальнейшего анализа. Для процесса, граф которого изображен выше, это будет выглядеть как-то так:

image

Еще одна полезная фишка SberPM модуль автоматического поиска инсайтов. С его помощью можно проанализировать лог-файл, выявить возможные узкие места процесса по нажатию кнопки и визуализировать их на графе. Поддерживается 3 режима работы: анализ по зацикленности, по времени выполнения и комбинированный анализ, где каждой активности и каждому переходу присваивается индекс оптимальности, показывающий, насколько тот или иной объект требует вмешательства.

Ниже приведен пример работы с модулем и результат визуализации инсайтов на графе:

image

image

Плохие переходы и активности, требующие оптимизации, выделены красным цветом, хорошие, т.е. не требующие оптимизации черным, нейтральные серым. Толщина ребер на графе также меняется в зависимости от оптимальности перехода.

Дополнительно для всех активностей и переходов можно вывести более детальную таблицу, где для каждого элемента отмечается, является ли он инсайтом и, если да, то по какой именно метрике. Так, 1 в графе insights означает, что объект является хорошим инсайтом, -1 плохим инсайтом, 0 не является инсайтом вовсе.

image

Более подробное описание всех модулей и классов можно найти в файле tutorial.ipynb, расположенном в репозитории библиотеки SberPM на GitHub.

Мы планируем на постоянной основе улучшать библиотеку и дополнять ее функционал. Запланированы релизы для расширения и масштабирования Open Source решения SberPM. Пожалуйста, пользуйтесь, оставляйте обратную связь, добавляйте коммиты и развивайте библиотеку вместе с нами.
Подробнее..

Учиться, учиться, и ещё раз учиться?

01.06.2021 14:09:01 | Автор: admin

TLDR: крохотные модельки обошли модные графовые нейронки в предсказании свойств молекул.
Код: здесь. Берегите Природу.


image
ФОТО: Андерс Хеллберг для Wikimedia Commons, модель Грета Тунберг


Необученная графовая свёрточная нейронная сеть [1] (uGCN) со случайной инициализацией весов уже пару лет занимает первое место в моём списке алгоритмов для задач машинного обучения на графах из-за копеечной стоимости, простоты реализации, да вполне очевидной элегантности решения. В то же время, насколько мне известно, никто ещё не не проводил соревнований между этой простой моделью и её старшей сестрой полноценно обученной графовой свёрточной нейронной сетью (GCN) в режиме обучения с учителем. Вот я сделал.


Мотивация: показать, что uGCN выдаёт качественные представления, которые можно использовать в последующих задачах машинного обучения в индуктивном режиме, когда модели обобщаются к не виденным ранее данным (вдохновлено недавним отчётом [2] о производительности простых моделей в трансдуктивном случае).


Полученные результаты занимательны. В худшем случае простые модели (uGCN + degree kernel + random forest) показали счёт 54:90 против полноценно обученных GCN, в то время как реалистичный сценарий закончился разгромным реваншем 93:51, указывающим на то, что мы можем позволить себе почти бесплатные эмбеддинги, которые превосходят или показывают результаты на уровне полноценно обученных GCN в задаче предсказания свойств графа (например эффекта медикаментов: яд или лекарство) за долю стоимости. Простые модели обучались ~10 минут в то время как весь эксперимент продлился ~4 часа. Перейдём же к деталям и разберёмся с тем, что произошло!


Основные понятия


Многие из важных наборов данных об окружающем нас мире имеют связный характер: социальные сети, графы знаний, взаимодействия белков, всемирная паутина WWW и т.д. (просто несколько примеров) [1].


Граф, обыкновенно записываемый как G=(V, E) это математическая модель, множество множеств, состоящее из набора вершин V и множества рёбер E попарных связей e(i, j) между вершинами i и j. Расширением Графа является модель Граф со Свойствами (Labeled Property Graph), позволяющий задать вектор признаков xi для вершины i (мы также можем определять свойства для рёбер, однако это выходит за рамки сегодняшнего эксперимента). Графовая нейронная сеть [3] (GNN) это модель машинного обучения (параметрическая функция, которая подбирает, другими словами выучивает, параметры из данных), расширяющая возможности хорошо известного семейства алгоритмов, вдохновлённых биологией, до работы с неструктурированными данными в виде графов. На мой взгляд, передача сообщений это самая простая интуиция для понимания механики работы GNN и вполне оправдано обратиться к мнемоническому правилу 'скажи мне, кто твой друг и я скажу тебе кто ты'. Графовые свёрточные нейронные сети (GCN) очень подробно описал их изобретатель здесь (https://tkipf.github.io/graph-convolutional-networks/) и мне, право, непросто что-то ещё добавить к этой замечательной истории.


Дабы не заниматься самоцитированием, предложу читателю ознакомиться с рассказом о том, где и как врубиться в эмбеддинги графов, а также с примером использования GCN в структурном моделировании организационных изменений и ощущениях стейкхолдеров во время кадровых перестановок, неизбежных при внедрении больших информационных систем, вроде SAP. Эти два текста стоит воспринимать как первые главы повествования о методах анализа связанных систем, также там в деталях рассматривается используемая форма математической записи.


image


Многослойная GCN с фильтрами первого порядка.


Данные


Проведём серию экспериментов на общедоступных данных. Мы обратимся к (i) коллекции TUDatasets [4] и (ii) ограничим наше упражнение задачей бинарной классификации (предсказанием свойств) небольших молекул. Ещё одним условием нашего мероприятия будет (iii) использование графов с признаками вершин.


Заданные ограничения оставляют нам несколько наборов данных, широко используемых для сравнения современных алгоритмов. Вот наш итоговый список: AIDS, BZR, COX2, DHFR, MUTAG и PROTEINS. Все обозначенные наборы данных доступны как часть Pytorch Geometric [5] (библиотека для глубокого обучения на графах) в двух версиях: оригинальной и очищенной от дубликатов [6]. Итого у нас будет 12 датасетов.


AIDS Antiviral Screen Data [7]


Результаты экспериментов по выявлению химических соединений, негативно влияющих на вирус иммунодефицита человека. Представляет собой результат тестирования и химическую структуру соединений не покрытых соглашениями о неразглашении. В оригинальном наборе содержится 2000 молекул, а очищенная версия оставляет нам 1110 точек данных, каждая из которых представляет собой граф, вершины которого описывают 37 признаков.


Benzodiazepine receptor (BZR) ligands [8]


Оригинальный набор содержит 405 молекул, очищенная версия 276, по 35 признаков на вершину.


Cyclooxygenase-2 (COX-2) inhibitors [8]


Оригинальный набор содержит 467 молекул, очищенная версия 237, по 35 признаков на вершину.


Dihydrofolate reductase (DHFR) inhibitors [8]


Оригинальный набор содержит 756 молекул, очищенная версия 578, 35 признаков на вершину.


MUTAG [9]


В наборе содержится 188 химических соединений, разделённых на два класса согласно их мутагенному воздействию на бактерии. В очищенной версии 135 молекул, 7 признаков на вершину.


PROTEINS [10]


Энзимы и не-энзимы. В оригинальном наборе содержится 1113 молекул, по 3 признака на вершину. Очищенная версия 975 структур.


Дизайн Эксперимента


Мы устроим турнир!


Для каждого набора данных проведём 12 раундов обучения и тестирования.


В каждом раунде:


(1) псевдослучайным образом разделим данные в пропорции 80/20 в Pytorch Geometric (начиная со стартового параметра генератора random seed = 42 и увеличивая его на единицу в каждом последующем раунде), таким образом 80% точек данных (графов) будут использованы в качестве обучающей выборки, а оставшиеся 20% будут тестовой выборкой;


(2) обучим модели и оценим долю верных ответов (accuracy) на тесте.


Для простых моделей это значит предобработку для того, чтобы создать признаки, на которых будет обучен классификатор.


Для GCN мы проводим 200 эпох обучения и тестирования со скоростью обучения learning rate = 0.01 и принимаем во внимание:
(А) среднее значение доли верных ответов для 10 финальных эпох обучения реалистичный сценарий;
(В) наибольшее значение доли верных ответов, достигнутое в процессе обучения (как если бы мы сохраняли промежуточное состояние для того, чтобы выбрать наилучшую модель впоследствии) наилучший сценарий для GCN (и наихудший для простых моделей);


(3) лучшей модели присуждается 1 балл;


(4) в случае ничьей балл присуждается лёгкой модели.


Всего будет распределено 288 баллов: 12 датасетов 12 раундов 2 сценария.


Модели


Degree kernel (DK) или степенное ядро гистограмма степеней вершин (количество рёбер, соединённых с вершиной), нормированная к числу вершин в графе (таким образом вектор признаков для каждого графа состоит из размеров долей вершин с количеством связей, равным индексу признака, от всего множества вершин в сумме они дают единицу).


import networkx as nximport numpy as np from scipy.sparse import csgraph# g - граф формате популярной библиотеки NetworkXnumNodes = len(g.nodes)degreeHist = nx.degree_histogram(g)# нормализуемdegreeHist = [x/numNodes for x in degreeHist]

Необученная графовая свёрточная нейронная сеть (uGCN) со случайной инициализацией весов 3 слоя с промежуточной нелинейной активацией (ReLU, т.е. f(x) = max(x, 0)). Аггрегация усреднением полученных после прямого прохода 64-разрядных векторов (эмбеддинги вершин) позволяет получить компактное представление графа. Это на самом деле очень просто.


A = nx.convert_matrix.to_scipy_sparse_matrix(g)

Воспользуемся вариантом реализации одного слоя свёртки в три строки, который пару лет назад предложил iggisv9t :


# A - матрица связности графа# X - матрица признаков вершин (np.array)D = sparse.csgraph.laplacian(A, normed=True)shape1 = X.shape[1]X = np.hstack((X, (D @ X[:, -shape1:])))

(код здесь приводится чтобы подчеркнуть очаровательный минимализм реализации метода)


Разберём его на части и пересоберём заново.


Использованная реализация uGCN выглядит так:


# A - матрица связности графа# X - матрица признаков вершин (np.array)# W0, W1, W2 - случайным образом инициализированные весаD = sparse.csgraph.laplacian(A, normed=True)# слой 0Xc = D @ X @ W0# ReLUXc = Xc * (Xc>0)# конкатенация признаков вершин с аггрегированной информацией соседейXn = np.hstack((X, Xc))# слой 1Xc = D @ Xn @ W1# ReLUXc = Xc * (Xc>0)Xn = np.hstack((Xn, Xc))# слой 2 - эмбеддинги вершинXc = D @ Xn @ W2# аггрегация усреднением - эмбеддинг графаembedding = Xc.sum(axis=0) / Xc.shape[0]

Комбинация DK и uGCN (Mix) конкатенацией представлений графа, полученных с помощью моделей DK и uGCN.


mix = degreeHist + list(embedding)

Для каждой из первых трёх моделей обучаем классификатор случайный лес из 100 деревьев с максимальной глубиной в 17 ветвлений.


Графовая свёрточная нейронная сеть (GCN) полноценно обученный классификатор, состоящий из 3 свёрточных слоёв размерностью 64 с промежуточной нелинейной активацией (ReLU), агрегацией усреднением (до этого момента архитектура GCN очень похожа на uGCN), за которой следует слой регуляризации дропаутом (произвольным обнулением разрядов с вероятностью 50%) и линейный классификатор. Мы будем обозначать результаты модели, отобранные в наилучшем для GCN сценарии (B) как GCN-B, а модели в реалистичном сценарии (А) как GCN-A.


Результаты


После 144 раундов (12 датасетов * 12 раундов) сравнения качества предсказаний на отложенной выборке между простыми моделями и полноценно обученными графовыми свёрточными сетями 288 баллов распределились как:


147:141


Доля верных ответов на тестовых выборках варьировалась между раундами и частенько случались ситуации, в которых простые модели доминировали над более сложными противниками.


image


Наборы данных, в которых простые модели побеждают: AIDS, DHFR(A) и MUTAG.


Например, DK собрала все 48 баллов для набора данных AIDS, демонстрируя отрыв более чем на 10% (абсолютное значение) от доли верных ответов полноценно обученной GCN.


image


Здесь побеждают GCN: BZR, COX2 и PROTEINS.


Индивидуальный зачёт:
90 GCN-B;
71 DK;
55 Mix (uGCN + DK);
51 GCN-A;
21 uGCN.


Достаточно подробный протокол соревнований приведён в блокнотике с кодом, таблица с результатами раундов здесь.


В целом, результаты стабильно варьировались между очищенными и оригинальными наборами данных. Это ещё раз напоминает о важности качества данных для проведения адекватных сравнений между моделями. Хорошая новость в том, что в исследовательском сообществе уже есть движение в данном направлении и значительные усилия лучших умов в области уже направлены на организацию честных турниров.


Выводы


Как видим, проведенный эксперимент подтверждает предположение о том, что в задаче предсказания свойств молекул мы можем позволить себе использовать почти бесплатные эмбеддинги, которые превосходят или показывают результаты на уровне полноценно обученных нейронных сетей. Наблюдения согласуются с вдохновляющими этот эксперимент результатами [2] в том, что концептуально метод Label Propagation очень похож на передачу сообщений в графовой свёрточной нейронной сети. Объяснение эффективности скорее всего следует искать в том, что на самом деле мощнее подбирать параметры фильтров для того, чтобы внутренние представления, выученные сетью стали линейно разделимыми, либо же просто использовать классификатор помощнее, как это сделано в рассмотренном примере.


Дисперсия результатов между раундами соревнования напоминает о том, что всякое сравнение дело непростое. Здесь стоит упомянуть Free Lunch Theorem и напомнить о том, что использовать сразу несколько моделей в построении решения скорее хороший тон. Также важно отметить влияние разбиения на выборки в ходе сравнения на одном и том же наборе данных одна и та же модель может показывать очень разное качество. Поэтому сравнивая модели, убедитесь, что обучаете и тестируете их на идентичных выборках. К слову, фиксация параметров генератора псевдослучайных чисел не панацея


image


Дальнейшими шагами может быть сравнение производительности моделей в рамках наборов данных больших размеров. Также стоит проверить результаты и в других задачах, таких как: предсказание связи, классификация вершин, регрессия на графах, и прочих графовые нейронные сети (как обученные, так и просто так) на многое способны.


Послесловие


В лекции открытого курса по графам знаний GCN названа Королевской Лазейкой Через Пространство Фурье, этот ярлык приклеился с тех пор, когда впервые выступил на публике с рассказом о силе графов и провёл первые эксперименты с классификацией картинок (как графов) для того, чтобы продемонстрировать мощь спектральных фильтров одной юной леди, запускавшей стартап в милой моему сердцу аэрокосмической области. Данная заметка появилась в результате того, что пару недель назад в реальной задаче на закрытых данных uGCN, вместе с простенькими моделями показали результат, который полноценно обученные GCN смогли превзойти всего на 2% (96 против 98) и мне вздумалось проверить вопрос о том, кто кого заборет ещё на каких-нибудь данных.


В наши дни машинное обучение на графах превратилось в знаменитость, всё больше исследователей обращают внимание на эту область и новые архитектуры графовых нейронных сетей появляются каждую неделю. Однако на самом деле мы ещё не очень хорошо понимаем почему GNN так успешны и нужны ли они для хорошего качества решения [2].


Перед тем, как ступать на очаровательный путь машинного обучения на графах, пожалуйста ознакомьтесь с основами этого дела. Значительные усилия прилагаются к тому, чтобы сделать новейшие достижения (да и классические методы тоже) доступными широкой аудитории совершенно бесплатно. Упомяну лишь несколько из таких инициатив: материалы и лекции стенфордского cs224w, площадку для тестирования качества алгоритмов Open Graph Benchmark [14] и недавнюю работу об основах геометрического глубокого обучения [15] методологию разработки новых архитектур нейронных сетей. Напоследок, ещё раз напомню о том, что начинать проекты машинного обучения стоит с простых методов, вроде ядер и необученных графовых свёрточных сетей достаточно часто эти модельки показывают неприлично хороший уровень.


Берегите Природу, используйте алгоритмы эффективно. Порою неученье сила.


image


Литература


[1] Kipf & Welling, Semi-Supervised Classification with Graph Convolutional Networks (2017), International Conference on Learning Representations;
[2] Huang et al., Combining Label Propagation and Simple Models out-performs Graph Neural Networks (2021), International Conference on Learning Representations;
[3] Scarselli et al., The Graph Neural Network Model (2009), IEEE Transactions on Neural Networks ( Volume: 20, Issue: 1, Jan. 2009);
[4] Morris et al.,TUDataset: A collection of benchmark datasets for learning with graphs (2020), ICML 2020 Workshop on Graph Representation Learning and Beyond;
[5] Fey & Lenssen, Fast Graph Representation Learning with PyTorch Geometric (2019), ICLR Workshop on Representation Learning on Graphs and Manifolds;
[6] Ivanov, Sviridov & Burnaev, Understanding isomorphism bias in graph data sets (2019), arXiv preprint arXiv:1910.12091;
[7] Riesen & Bunke, IAM Graph Database Repository for Graph Based Pattern Recognition and Machine Learning (2008), In: da Vitora Lobo, N. et al. (Eds.), SSPR&SPR 2008, LNCS, vol. 5342, pp. 287-297;
[8] Sutherland et al., Spline-fitting with a genetic algorithm: a method for developing classification structure-activity relationships (2003), J. Chem. Inf. Comput. Sci., 43, 1906-1915;
[9] Debnath et al., Structure-activity relationship of mutagenic aromatic and heteroaromatic nitro compounds (1991), J. Med. Chem. 34(2):786-797;
[10] Dobson & Doig, Distinguishing enzyme structures from non-enzymes without alignments (2003), J. Mol. Biol., 330(4):771783;
[11] Pedregosa et al., Scikit-learn: Machine Learning in Python (2011), JMLR 12, pp. 2825-2830;
[12] Waskom, seaborn: statistical data visualization (2021), Journal of Open Source Software, 6(60), 3021;
[13] Hunter, Matplotlib: A 2D Graphics Environment (2007), Computing in Science & Engineering, vol. 9, no. 3, pp. 90-95;
[14] Hu et al., Open Graph Benchmark: Datasets for Machine Learning on Graphs (2020), arXiv preprint arXiv:2005.00687;
[15] Bronstein et al., Geometric Deep Learning: Grids, Groups, Graphs, Geodesics, and Gauges (2021), arXiv preprint arXiv:2104.13478.

Подробнее..

Перевод Почему в Docker не работает Strace

02.07.2020 10:04:35 | Автор: admin
Когда я редактировала страницу о возможностях контейнеров для журнала How Containers Work, мне потребовалось объяснить, почему в Docker не работает strace. Вот что случалось при запуске strace в Docker-контейнере на моем ноутбуке:

$ docker run  -it ubuntu:18.04 /bin/bash$ # ... install strace ...root@e27f594da870:/# strace lsstrace: ptrace(PTRACE_TRACEME, ...): Operation not permitted

strace работает через системный вызов ptrace, поэтому без разрешения для ptrace ничего не заработает! Но это легко исправить, и на моем ноутбуке я все сделала вот так:

docker run --cap-add=SYS_PTRACE  -it ubuntu:18.04 /bin/bash

Но мне было интересно не решить проблему, а разобраться, почему эта ситуация вообще возникает. Так почему же strace не работает, а --cap-add=SYS_PTRACE все исправляет?

Гипотеза 1: У процессов контейнеров нет собственной привилегии CAP_SYS_PTRACE


Так как проблема стабильно решается через --cap-add=SYS_PTRACE, мне всегда казалось, что у процессов контейнеров Docker по определению нет собственной привилегии CAP_SYS_PTRACE, но по двум причинам тут кое-что не сходится.

Причина 1: В виде эксперимента я, будучи залогиненной под обычным пользователем, без труда могла запустить strace к любому процессу, однако проверка наличия у моего текущего процесса привилегии CAP_SYS_PTRACE ничего не находила:

$ getpcaps $$Capabilities for `11589': =

Причина 2: в man capabilities о привилегии CAP_SYS_PTRACE сказано следующее:

CAP_SYS_PTRACE       * Trace arbitrary processes using ptrace(2);

Вся суть CAP_SYS_PTRACE заключается в том, чтобы мы, по аналогии с root, могли перехватывать контроль над произвольным процессом любого пользователя. Для ptrace обычного процесса вашего пользователя такая привилегия не нужна.

Кроме того, я провела еще одну проверку: я запустила Docker контейнер через docker run --cap-add=SYS_PTRACE -it ubuntu:18.04 /bin/bash, затем отменила привилегию CAP_SYS_PTRACE и strace продолжил корректно работать даже без привилегии. Почему?!

Гипотеза 2: Дело в пользовательском пространстве имен?


Моя следующая (и намного хуже обоснованная) гипотеза звучала в духе хмм, возможно процесс находится в другом пользовательском пространстве имен и strace не работает просто потому что? Выглядит как набор не очень связных высказываний, но я все же попробовала посмотреть на проблему и с этой стороны.

Итак, находится ли процесс в другом пользовательском пространстве имен? Так он выглядит в контейнере:

root@e27f594da870:/# ls /proc/$$/ns/user -l... /proc/1/ns/user -> 'user:[4026531837]'

А так он выглядит на хосте:

bork@kiwi:~$ ls /proc/$$/ns/user -l... /proc/12177/ns/user -> 'user:[4026531837]'

root в контейнере это тот же самый пользователь, что и root на хосте, поскольку у них общий идентификатор в пользовательском пространстве имен (4026531837), так что с этой стороны не должно быть никаких мешающих работе strace причин. Как можно видеть, гипотеза оказалась так себе, но тогда я еще не осознавала, что пользователи в контейнере и на хосте совпадают, и этот поход казался мне интересным.

Гипотеза 3: Системный вызов ptrace блокируется правилом seccomp-bpf


Я уже знала, что для ограничения запуска большого числа системных вызовов процессорами контейнеров в Docker есть правило seccomp-bpf, и оказалось, что в его списке блокируемых по определению вызовов есть и ptrace! (На самом деле список вызовов это лист исключений и ptrace попросту в него не попадает, но результат от этого не меняется.)

Теперь понятно, почему в Docker контейнере не работает strace, ведь очевидно, что полностью заблокированный ptrace вызвать не получится.

Давайте проверим эту гипотезу и посмотрим, сможем ли мы воспользоваться strace в Docker контейнере, если отключим все правила seccomp:

$ docker run --security-opt seccomp=unconfined -it ubuntu:18.04  /bin/bash$ strace lsexecve("/bin/ls", ["ls"], 0x7ffc69a65580 /* 8 vars */) = 0... it works fine ...

Отлично! Все работает, и секрет раскрыт! Вот только

Почему --cap-add=SYS_PTRACE решает проблему?


Мы все еще не объяснили почему --cap-add=SYS_PTRACE решает возникающую проблему с вызовами. Главная страница docker run следующим образом объясняет работу аргумента --cap-add:

--cap-add=[]   Add Linux capabilities

Все это не имеет никакого отношения к правилам seccomp! В чем же дело?

Давайте посмотрим на исходный код Docker.


Если уже и документация не помогает, все что нам остается это погрузиться в исходники.
В Go есть одна приятная особенность: благодаря вендорингу зависимостей в репозитории Go вы через grep можете пройтись по всему репозиторию и найти интересующий вас код. Так что я склонировала github.com/moby/moby и прошерстила его в поисках выражений вида rg CAP_SYS_PTRACE.

На мой взгляд, тут происходит вот что: в имплементации seccomp в контейнере, в разделе contrib/seccomp/seccomp_default.go полно кода, который через правило seccomp проверяет, есть ли у процесса с привилегиями разрешение на использование системных вызовов в соответствии с этой привилегией.

case "CAP_SYS_PTRACE":s.Syscalls = append(s.Syscalls, specs.LinuxSyscall{Names: []string{"kcmp","process_vm_readv","process_vm_writev","ptrace",},Action: specs.ActAllow,Args:   []specs.LinuxSeccompArg{},})


Там еще есть код, который в moby и для profiles/seccomp/seccomp.go, и для seccomp профиля по определению проводит похожие операции, так что, наверное, мы нашли наш ответ!

В Docker --cap-add способен на большее, чем сказано


В итоге, похоже, --cap-add делает не совсем то, что написано на главной странице, и скорее должен выглядеть как --cap-add-and-also-whitelist-some-extra-system-calls-if-required. И это похоже на правду: если у вас есть привилегия в духе CAP_SYS_PTRACE, которая разрешает вам пользоваться системным вызовом process_vm_readv, но этот вызов блокируется профилем seccomp, вам это мало чем поможет, так что разрешение на использование системных вызовов process_vm_readv и ptrace через CAP_SYS_PTRACE выглядит разумно.

Оказывается, strace работает в последних версиях Docker


Для версий ядра 4.8 и выше благодаря этому коммиту в Docker 19.03 наконец-то разрешены системные вызовы ptrace. Вот только на моем ноутбуке Docker все еще версии 18.09.7, и этот коммит, очевидно, отсутствует.

Вот и все!


Разбираться с этой проблемой оказалось интересно, и я думаю, что это хороший пример нетривиально взаимодействующей между собой подвижной начинки контейнеров.

Если вам понравился этот пост, вам может понравиться и мой журнал How Containers Work, на его 24 страницах объясняются особенности ядра Linux по организации работы контейнеров. Там же вы можете ознакомиться с привилегиями и seccomp-bpf.
Подробнее..

Как работать с неизвестностью и неопределенностью в разработке

19.12.2020 12:08:03 | Автор: admin

Сталкиваясь с неопределенностью в процессе разработки, нам стоит пересмотреть взгляды на то, что для нас значит "двигаться быстро".

Создание новых продуктов связано с большим количеством неопределенности.

Нет понимания с чего начать, как начать, как подступиться. Знаешь только, что есть конкретная проблема, которую нужно как-то решать. Даже StackOverflow тебе тут уже не помощник.

Клепая простейшие CRUD приложения, проблеме планирования неоткуда взяться: общаемся с потенциальными пользователями, делаем несколько макетов будущего продукта, определяем требования, отправляем это всё команде дизайнеров и разработчиков. Готово выпускаем.

Но когда мы разрабатываем продукты с большим количеством технических и бизнесовых неопределенностей а это именно то, чем обычно занимаются стартапы и продуктовые команды то такой план трещит по швам. Методология, призванная ускорить разработку, наоборот её замедляет, команда от этого стрессует и ловит фрустрацию, отставая от сроков всё больше и больше.

Это происходит, когда беспочвенный оптимизм разбивается о жестокую реальность неопределенности, свойственной процессу разработки продукта.

Неопределенности технических продуктов

Проблема классической системы планирования в том, что она не объясняет как работать с неизвестностью и неопределенностью, с тем, из чего состоит разработка сложных продуктов.

В RankScience, где мы делаем платформу для непрерывной оптимизации и CDN для SEO вебсайтов, мы сталкиваемся с довольно большим количеством технических неопределенностей неудивительно, учитывая, что мы занимаемся тем, чего ещё никогда не было.

За последний год мы разработали систему планирования которая позволяет решать поставленные задачи, минуя проблемы классического подхода.

Основа нашей системы это три техники, пришедшие из Agile/Scrum:

  1. Анализ. Изучение проблемы и попытки найти способы её решить, учитывая их плюсы и минусы.

  2. Спайк. Простая реализация на коленке, которая позже будет выброшена, но поможет понять область проблемы.

  3. Трассер. Более предметная реализация не на выброс, для проверки, работает ли ваша идея в реальных условиях вообще или нет.

Мы идём по этим пунктам раз за разом, в зависимости от того, на каком уровне неопределенности мы находимся с текущей проблемой.

Эта методология помогает нам решать задачи, пока классическая система требует собственного обслуживания:

  • Мы можем продвигаться быстро, но не так быстро, чтобы закапывать себя в технических долгах.

  • Мы можем вносить коррективы на ходу, не привязываясь к дате начала следующего спринта.

  • Мы можем изучать вопрос итеративно, нежели надеяться, что команда знает все аспекты проблемы наперед.

Когда всё совсем непонятно мы не знаем как приступить к задаче, мы проводим анализ. Когда в результате приходит в голову возможное решение мы делаем спайк, чтобы понять предметную область. Далее мы выпускаем трассер, чтобы убедиться, что текущее решение может слаженно работать с нашей текущей архитектурой. Если всё ок, двигаемся дальше. Если нет, то можем вернуться к самому началу.

На каждом шаге система дает новую информацию для следующего шага и для выхода из неопределенности в целом. Эта постоянная обратная связь, вероятно, самая важная деталь всего подхода.

Мы, конечно, можем составить план и попробовать его выполнить от начала до конца, но шаг влево, шаг вправо и он начнёт трещать по швам.

Идея нашей системы в признании, что системы рано или поздно дают сбой, нужно принимать план Б или даже план В. Просто нужно быть к этому готовыми.

1. Анализ

Начинайте с проведения анализа если:

  • У вас есть проблема

  • Вы не знаете как её решить

Не важно, пытаетесь ли вы перестроить всю архитектуру или просто добавляете новую кнопочку на свой сайт.

Без понимания как решить проблему не торопитесь писать код. Наоборот, вам нужно заняться анализом, продумать возможные пути решения, а после прикинуть все плюсы и минусы каждого из них.

Плюсы и минусы должны быть основаны на технических факторах типа:

  • Насколько трудоёмкая будет реализация

  • Насколько дорого это выйдет

  • Сколько времени потребуется

  • Какой гибкости мы лишаемся, принимая именно это решение

  • Насколько этим удобно будет пользоваться

Под разные команды значимость тех или иных факторов может быть разная.

В RankScience мы, на данный момент, оцениваем пути решений на основе трёх главных факторов:

  • Наша операционная нагрузка

  • Наш автобусный фактор

  • Скорость нашей команды

Мы анализируем каждый из путей, оценивая то, как мы можем уменьшить нашу операционную нагрузку, уменьшить автобусный фактор и улучшить скорость нашей команды.

Одним из распространенных результатов анализа это документация типа такой:


Repository: плюсы и минусы

  • Плюсы

    • Это эффективный способ предоставлять доступ большомуобъему данных: записал один раз и читаешь отовсюду

    • Подсистемам не нужно думать как создаются и потребляются данные в других подсистемах

    • Это позволяет проще делать бэкапы, а ещё работать над безопасностью и восстановлением данных

    • Работа с данными происходит по общей схеме, поэтомулегче подключать новые подсистемы

  • Минусы

    • Подсистемы должны работать с общей схемой, что может влиять на производительность

    • Эволюция данных: "дорого" принимать новую модель данных,потому что (а) это нужно принять во всём репозитории и (б) все подсистемы должны быть обновлены, чтобы продолжать работать

    • Нет уверенности, что в вопросах безопасности и бэкапов репозиторий всегда будет удовлетворять некоторые подсистемы

    • Довольно сложно деплоить репозиторий на несколько машин, сохраняя видимость централизованного хранилища, из-за необходимости в избыточности данных и сохранении консистентности


Анализ, как целенаправленная деятельность, должен быть ограничен по времени (чтобы вы не тратить бесконечное количество времени, выбирая разные варианты) и предоставлять либо один конкретный из возможных путей решения, либо понимание, что не имеет большого смысла в это погружаться самостоятельно и лучше перепоручить это специалистам извне.

2. Spike

Спайк нужен, когда:

  • У вас есть проблема

  • У вас есть хоть какая-то идея как её решить

Спайк это решение на коленочке на выброс. Иногда это может показаться пустой тратой времени, но хороший спайк может выявить детали, которые могут остаться незамеченными, бросайся мы прямиком к серьезному проектированию.

Хотя результат спайка и будет выброшен по завершению, но используя его правильно, мы можем глубже погружаться в суть самой проблемы.

Спайк сам по себе не поможет решить задачу быстрее, но даст понимание того, как с продуктом взаимодействуют люди в настоящих условиях, от чего мы сами сможем продвигаться к решению быстрее.

Хороший пример это бумажный прототип.

Собирание бумажного макета может показаться бессмысленным, особенно сейчас, когда его можно по быстрому накидать в Sketch и экспортировать в любой удобный формат, но обыкновенным людям, тестировщикам продукта, может быть удобнее взаимодействовать с бумагой. Включаются тактильные взаимодействия с продуктом, а давать обратную связь становится ещё проще.

Минимальным вкладом в решение при обычном планировании является то, как мы начинаем фактически решать проблему. При спайках же минимальный вклад это нечто, что помогает выяснить в чем на самом деле состоит проблема.

3. Трассер

Трассирующая пуля, трассер это боевой припас особой конструкции, который оставляет луч света в полёте. В разработке трассер это техника для ситуаций, когда:

  • У вас есть проблема

  • У вас есть решение, но вы не знаете как много времени это займет.

Впервые трассер как техника встречается в The Pragmatic Programmer by Andrew Hunt and David Thomas. В самом простом смысле трассер является решением проблемы, которое:

  • очень небольшое

  • запускается в продакшен окружении

  • остается, а не выбрасывается

Представьте, что вам нужно сделать подписку на емейл рассылку с вашего сайта. В этом случае спайк может быть бумажным прототипом. Трассером может быть поле ввода на сайте и кнопка, которая:

  • успешно получает текст из поля ввода

  • отправляет этот текст в Segment

  • идёт в customer.io из Segment

  • обновляет список для рассылки

Может не быть валидации почты, да и любого количества улучшений, после которых мы будем считать дело сделанным, но если эта последовательность действий работает (в том числе в продакшен окружении), то она будет работать и после внесения финальных штрихов.

Трассер это не конечный продукт, а нечто, что более приближено к готовому, нежели спайк, который почти всегда должен идти на выброс, когда мы получили всю необходимую информацию.

Трассер здесь для того, чтобы доказать, что решение действительно работает, захватив предметную область настолько широко, чтобы взглянуть на картину в общем, но не достаточно широко, чтобы тратить на это слишком много времени.

Цикл Анализ Спайк Трассер

Сталкиваясь с неопределенностью в процессе разработки, нам стоит пересмотреть взгляды на то, что для нас значит "двигаться быстро"

Быстрое движение не сводится к тому, чтобы как можно быстрее составить законченный план, потому что никто не знает реалистичен ли такой законченный план в принципе.

Работая над проектами с большим количеством неопределенности или технических рисков, нам следует анализировать, делать спайки и трассеры, чтобы шаг за шагом, итеративно рассеивать неизвестность следовать лучикам света в темном лесу.

Благодарю Антона Сметанина @dizzy_dalvin за помощь в редактуре

Подробнее..

Перевод Как работать с неизвестностью и неопределенностью в разработке

19.12.2020 14:20:36 | Автор: admin

Сталкиваясь с неопределенностью в процессе разработки, нам стоит пересмотреть взгляды на то, что для нас значит "двигаться быстро".

Создание новых продуктов связано с большим количеством неопределенности.

Нет понимания с чего начать, как начать, как подступиться. Знаешь только, что есть конкретная проблема, которую нужно как-то решать. Даже StackOverflow тебе тут уже не помощник.

Клепая простейшие CRUD приложения, проблеме планирования неоткуда взяться: общаемся с потенциальными пользователями, делаем несколько макетов будущего продукта, определяем требования, отправляем это всё команде дизайнеров и разработчиков. Готово выпускаем.

Но когда мы разрабатываем продукты с большим количеством технических и бизнесовых неопределенностей а это именно то, чем обычно занимаются стартапы и продуктовые команды то такой план трещит по швам. Методология, призванная ускорить разработку, наоборот её замедляет, команда от этого стрессует и ловит фрустрацию, отставая от сроков всё больше и больше.

Это происходит, когда беспочвенный оптимизм разбивается о жестокую реальность неопределенности, свойственной процессу разработки продукта.

Неопределенности технических продуктов

Проблема классической системы планирования в том, что она не объясняет как работать с неизвестностью и неопределенностью, с тем, из чего состоит разработка сложных продуктов.

В RankScience, где мы делаем платформу для непрерывной оптимизации и CDN для SEO вебсайтов, мы сталкиваемся с довольно большим количеством технических неопределенностей неудивительно, учитывая, что мы занимаемся тем, чего ещё никогда не было.

За последний год мы разработали систему планирования которая позволяет решать поставленные задачи, минуя проблемы классического подхода.

Основа нашей системы это три техники, пришедшие из Agile/Scrum:

  1. Анализ. Изучение проблемы и попытки найти способы её решить, учитывая их плюсы и минусы.

  2. Спайк. Простая реализация на коленке, которая позже будет выброшена, но поможет понять область проблемы.

  3. Трассер. Более предметная реализация не на выброс, для проверки, работает ли ваша идея в реальных условиях вообще или нет.

Мы идём по этим пунктам раз за разом, в зависимости от того, на каком уровне неопределенности мы находимся с текущей проблемой.

Эта методология помогает нам решать задачи, пока классическая система требует собственного обслуживания:

  • Мы можем продвигаться быстро, но не так быстро, чтобы закапывать себя в технических долгах.

  • Мы можем вносить коррективы на ходу, не привязываясь к дате начала следующего спринта.

  • Мы можем изучать вопрос итеративно, нежели надеяться, что команда знает все аспекты проблемы наперед.

Когда всё совсем непонятно мы не знаем как приступить к задаче, мы проводим анализ. Когда в результате приходит в голову возможное решение мы делаем спайк, чтобы понять предметную область. Далее мы выпускаем трассер, чтобы убедиться, что текущее решение может слаженно работать с нашей текущей архитектурой. Если всё ок, двигаемся дальше. Если нет, то можем вернуться к самому началу.

На каждом шаге система дает новую информацию для следующего шага и для выхода из неопределенности в целом. Эта постоянная обратная связь, вероятно, самая важная деталь всего подхода.

Мы, конечно, можем составить план и попробовать его выполнить от начала до конца, но шаг влево, шаг вправо и он начнёт трещать по швам.

Идея нашей системы в признании, что системы рано или поздно дают сбой, нужно принимать план Б или даже план В. Просто нужно быть к этому готовыми.

1. Анализ

Начинайте с проведения анализа если:

  • У вас есть проблема

  • Вы не знаете как её решить

Не важно, пытаетесь ли вы перестроить всю архитектуру или просто добавляете новую кнопочку на свой сайт.

Без понимания как решить проблему не торопитесь писать код. Наоборот, вам нужно заняться анализом, продумать возможные пути решения, а после прикинуть все плюсы и минусы каждого из них.

Плюсы и минусы должны быть основаны на технических факторах типа:

  • Насколько трудоёмкая будет реализация

  • Насколько дорого это выйдет

  • Сколько времени потребуется

  • Какой гибкости мы лишаемся, принимая именно это решение

  • Насколько этим удобно будет пользоваться

Под разные команды значимость тех или иных факторов может быть разная.

В RankScience мы, на данный момент, оцениваем пути решений на основе трёх главных факторов:

  • Наша операционная нагрузка

  • Наш автобусный фактор

  • Скорость нашей команды

Мы анализируем каждый из путей, оценивая то, как мы можем уменьшить нашу операционную нагрузку, уменьшить автобусный фактор и улучшить скорость нашей команды.

Одним из распространенных результатов анализа это документация типа такой:


Repository: плюсы и минусы

  • Плюсы

    • Это эффективный способ предоставлять доступ большомуобъему данных: записал один раз и читаешь отовсюду

    • Подсистемам не нужно думать как создаются и потребляются данные в других подсистемах

    • Это позволяет проще делать бэкапы, а ещё работать над безопасностью и восстановлением данных

    • Работа с данными происходит по общей схеме, поэтомулегче подключать новые подсистемы

  • Минусы

    • Подсистемы должны работать с общей схемой, что может влиять на производительность

    • Эволюция данных: "дорого" принимать новую модель данных,потому что (а) это нужно принять во всём репозитории и (б) все подсистемы должны быть обновлены, чтобы продолжать работать

    • Нет уверенности, что в вопросах безопасности и бэкапов репозиторий всегда будет удовлетворять некоторые подсистемы

    • Довольно сложно деплоить репозиторий на несколько машин, сохраняя видимость централизованного хранилища, из-за необходимости в избыточности данных и сохранении консистентности


Анализ, как целенаправленная деятельность, должен быть ограничен по времени (чтобы вы не тратить бесконечное количество времени, выбирая разные варианты) и предоставлять либо один конкретный из возможных путей решения, либо понимание, что не имеет большого смысла в это погружаться самостоятельно и лучше перепоручить это специалистам извне.

2. Spike

Спайк нужен, когда:

  • У вас есть проблема

  • У вас есть хоть какая-то идея как её решить

Спайк это решение на коленочке на выброс. Иногда это может показаться пустой тратой времени, но хороший спайк может выявить детали, которые могут остаться незамеченными, бросайся мы прямиком к серьезному проектированию.

Хотя результат спайка и будет выброшен по завершению, но используя его правильно, мы можем глубже погружаться в суть самой проблемы.

Спайк сам по себе не поможет решить задачу быстрее, но даст понимание того, как с продуктом взаимодействуют люди в настоящих условиях, от чего мы сами сможем продвигаться к решению быстрее.

Хороший пример это бумажный прототип.

Собирание бумажного макета может показаться бессмысленным, особенно сейчас, когда его можно по быстрому накидать в Sketch и экспортировать в любой удобный формат, но обыкновенным людям, тестировщикам продукта, может быть удобнее взаимодействовать с бумагой. Включаются тактильные взаимодействия с продуктом, а давать обратную связь становится ещё проще.

Минимальным вкладом в решение при обычном планировании является то, как мы начинаем фактически решать проблему. При спайках же минимальный вклад это нечто, что помогает выяснить в чем на самом деле состоит проблема.

3. Трассер

Трассирующая пуля, трассер это боевой припас особой конструкции, который оставляет луч света в полёте. В разработке трассер это техника для ситуаций, когда:

  • У вас есть проблема

  • У вас есть решение, но вы не знаете как много времени это займет.

Впервые трассер как техника встречается в The Pragmatic Programmer by Andrew Hunt and David Thomas. В самом простом смысле трассер является решением проблемы, которое:

  • очень небольшое

  • запускается в продакшен окружении

  • остается, а не выбрасывается

Представьте, что вам нужно сделать подписку на емейл рассылку с вашего сайта. В этом случае спайк может быть бумажным прототипом. Трассером может быть поле ввода на сайте и кнопка, которая:

  • успешно получает текст из поля ввода

  • отправляет этот текст в Segment

  • идёт в customer.io из Segment

  • обновляет список для рассылки

Может не быть валидации почты, да и любого количества улучшений, после которых мы будем считать дело сделанным, но если эта последовательность действий работает (в том числе в продакшен окружении), то она будет работать и после внесения финальных штрихов.

Трассер это не конечный продукт, а нечто, что более приближено к готовому, нежели спайк, который почти всегда должен идти на выброс, когда мы получили всю необходимую информацию.

Трассер здесь для того, чтобы доказать, что решение действительно работает, захватив предметную область настолько широко, чтобы взглянуть на картину в общем, но не достаточно широко, чтобы тратить на это слишком много времени.

Цикл Анализ Спайк Трассер

Сталкиваясь с неопределенностью в процессе разработки, нам стоит пересмотреть взгляды на то, что для нас значит "двигаться быстро"

Быстрое движение не сводится к тому, чтобы как можно быстрее составить законченный план, потому что никто не знает реалистичен ли такой законченный план в принципе.

Работая над проектами с большим количеством неопределенности или технических рисков, нам следует анализировать, делать спайки и трассеры, чтобы шаг за шагом, итеративно рассеивать неизвестность следовать лучикам света в темном лесу.

Подробнее..

Как оценить процессы в компании комментарии разработчика

02.05.2021 14:07:38 | Автор: admin

Собеседование только полдела. Наинтервью невсегда очевидно, как насамом деле будут устроены рабочие процессы, иреальность может оказаться нетакой радужной. Как выбрать тот проект, где будешь по-настоящему счастлив? НаStack Overflow пользуются тестом Джоела это 12вопросов, которые должны помочь оценить качество работы команды.12простых вопросов, да/нет ответы. Ноэтому списку уже 20лет, иGergely Orosz пообщался сомножеством разработчиков иадаптировал тест ксовременным реалиям. Приводим перевод нескольким блоков икомментарии разработчика: онкак раз недавно вышел работать вновую компанию.






Необходимо, нонедостаточно: 3требования кновой компании


Есть три пункта, которые Джерджели называет базовыми: без них невозможно комфортно работать иразвиваться нановом месте.


психологическая безопасность: чувствуютли себя люди вбезопасности, высказывая мнение, которое отличается отмнения остальной команды?


достойная вашего труда компенсация: получаютли зарплату, которая соответствует рынку?
гибкие рабочие часы: могутли гибко организовывать своё рабочее время?


Последний пункт кажется неочевидным, новковидные времена произошло резкое увеличение количества позиций наудалёнке. Поэтому чтобы конкурировать между собой залучших специалистов, компании обязаны проявлять гибкость ввопросах графика.


Начиналось всё неплохо: позвали внебольшой проект. Развивается стремительно, укоманды хороший технический уровень это очень воодушевляет. Апотом всё куда-то скатилось.

Атмосфера нездоровая вечные политические игры. Например, уволили двух коллег, которые впахивали больше всех остальных, причин необъясняли. Даивообще команда малопроизводительная когда никто нехочет работать, становится скучно, хотелось задач поамбициознее.

Они стали релоцировать всех сотрудников вПрагу, иябыл вшаге оттого, чтобы подписать документы нозадумался. Ахочули яподписывать контракт надва года иоставаться скомандой идальше? Неособо.

Доэтого ягод работал вIT-гиганте большая машина, много бюрократии, если появляются свои идеи, как улучшить продукт ихтрудно продвинуть. Планы уменеджеров расписаны надва года вперёд. Поэтому решил придерживаться своей линии: искать какой-то стартап.

Хотелось, чтобы было достаточно много свободы, чтобы команда несоздавала видимость загруженности, адействительно работала. Это должно быть место, где люди горят своим делом.

Аещё мне нравится работать удалённо. Возможность выбирать свой ритм жизни хотелось сохранить.

Может, работникиIT посравнению сдругими специальностями иизбалованы: новедь сдругой стороны, если все компании примерно выровнялись поуровню компенсации, кофе иплюшкам накухне IT-специалисты реально могут себе позволить выбирать тот проект, который по-настоящему откликается, чьи ценности тыразделяешь. Зачем терпеть скучный проект инеприятную команду? Артём С.


5вопросов про взаимодействие скомандой


Самостоятельные икреативные люди процветают вкомпаниях, где есть ясность процессов, возможность автономности содной стороны исотрудничества сдругой. Накакие стороны работы команды Джерджели предлагает обратить внимание? Могут выполняться 4пункта из5.


  • Обусловленность действий. Естьли процесс, который позволяет делиться бизнес-запросами, почему нужно выполнить туили иную задачу? Дорожная карта продукта, OKR, цели компании.
  • Бэклог/дорожная карта продукта иинженеры, которые вносят вклад вэти процессы. Естьли укоманды чёткий бэклог, который позволяет ответить навопрос над чем будет работать дальше ипочему? Могутли инженеры вносить предложения вдорожную карту? Приоритизируютсяли благодаря этому предложения попогашению технического долга?
  • Прямая коммуникация при возникновении проблем. Могутли разработчики напрямую общаться сразработчиками других команд? Или они должны пообщаться ссвоим менеджером, который поговорит сдругим менеджером, который поговорит сещё одним менеджером, который поговоритс
  • Коллаборация соспециалистами других сфер. Могутли разработчики работать напрямую сдизайнерами, продакт-менеджерами, дата сайентистами идругими стейкхолдерами, неприбегая кпомощи посредников, например, менеджеров?
  • Инициатива поощряется. Вознаграждаютсяли люди сновыми идеями иинициативами, или считаются, что они лишь зря отвлекают внимание?

За12лет вIT яуспел поработать ивкрупных, ивмелких компаниях. Бросил какое-то место, просто потому что понял, что нецепляет. Ипришёл работать встартап почти бесплатно: потому что попал всуперскую идейную команду. Команда горела: вгод чемпионата пофутболу вРоссии мызапартнёрились сFIFA, Apple сделал фичеринг ивсё это без бюджетов, наодном энтузиазме. Найти правильную схему для монетизации несмогли, поэтому решили разбежаться, носама атмосфера это было круто.

Язадумался обэтом, когда увидел Wheely знал оних идопоиска работы, уменя там есть знакомые. Случайно увидел вакансию, поговорил сребятами, откликнулся через бота так действительно было удобнее. Решил, что нехочу ехать вПрагу, хочу нормально работать.

Ещё ипоидеологическим представлениям совпали: Wheely отказались предоставлять данные опередвижении своих пользователей.

Можно работать наудалёнке иэто правильно, как мне кажется. Яверю, что если человек работает, онбудет работать откуда угодно. Аесли увиливает отответственности, тоивофисе найдёт возможность еёнасебя небрать, Артём С.


5вопросов про инженерную культуру


Стабильная инженерная культура чтобы специалисты неперегорали наработе инебыли разочарованы. Это принципы, которых придерживается большинство IT-проектов иразработчики могут быстро развиваться внутри компании. Могут выполняться 4пункта из5.


  • Различаютсяли этапы функциональная готовность иготовность кпродакшену. Естьли различия между прототипом, MVP иготовым кпродакшену продукту? Естьли чеклист для оценки качества, что продукт готов квыпуску?
  • Код ревью итестирование являютсяли они частью рутинного процесса разработки, аихотсутствие редким исключением?
  • Налаженли процесс непрерывной интеграции. Естьли увас процесс непрерывного развёртывания, чтобы отправлять код прямо впродакшен, иесли нет, томогутли разработчики отправлять собственный код вэто окружение?
  • Oncall невлияет наздоровье сотрудников. Для проектов, где есть oncall, следятли затем, как онвлияет насостояние людей иработу над продуктом?
  • Доступ кисходному коду. Можетли любой разработчик просматривать ивносить свой вклад висходный код?

Настаром месте работы было очень много встреч спродактами, бесконечные обсуждения, постоянно что-то разбирали иобговаривали. Ноникак неудавалось наладить процессы внутри команды, что-то постоянно кому-то мешало. Люди были недовольны.

Аоказывается, можно созваниваниваться только раз вдень по15минут, иэтого достаточно всем. Так вообще работает? Все Agile, Scrum ипрочие методологии неработают при разлаженности команды. Достаточно самого минимального усилия, чтобы запустить процессы икоманде было удобно работать.

Ичтобы двигаться дальше, стремиться кчему-то новому нужна эмоциональная составляющая, без неё неполучится. Если проект впринципе неинтересен, успеха, скорее всего, небудет. Вобщем, корпоративная культура формирует заинтересованность разработчика, как мне кажется, Артём С.


Помимо этих двух, автор отдельно выделяет блок про развитие карьеры вконкретной компании: наличие культуры обратной связи, карьерной лестницы, менеджеры стехническим бэкграундом.


Список хорош, нонасколько онприменим напрактике? Джерджели говорит, что судя поего опыту общения сразработчиками изразных стран вполне, имногие инновационные ибыстро развивающиеся компании отFAANG доуспешных стартапов используют эти принципы.


Акак вам кажется, это возможно? Ичто важнее всего вкомпании? Напишите, пожалуйста, вкомментариях.



Подробнее..

Live site review. Разбираем инциденты

26.11.2020 18:13:16 | Автор: admin

Нам важно, чтобы Авито стабильно инадёжно работал. Нобывает, что несмотря нанаши усилия, что-то ломается. Это может быть железо или какой-то архитектурный компонент под высокой нагрузкой. Вэтом случае важно починить возникшую проблему как можно быстрее. Для этого унас есть развесистая система мониторинга иалертов, атакже служба круглосуточных дежурных.


Помимо того, чтобы быстро восстановить работу сервиса, важно избежать повторения проблем там, где это возможно. Атам, где предотвратить аварии совсем нельзя, минимизировать ущерб как для пользователей, так идля сотрудников.


Поэтому кроме круглосуточного мониторинга унас есть процесс разбора инцидентов. Исами пожары напроде, иработы поанализу проблем мыназываем live site review или LSR. Яотвечаю зачасть работ сLSR после пожаротушения ихочу поделиться нашими наработками.



Минутка контекста


Авито большая компания. Наноябрь 2020 года унас:


  • 1134 сервиса впродакшене.
  • 58команд разработки, вкаждой изкоторых отодной дочетырёх фиче-команд поменьше.
  • 200-250 релизов изменений вдень.

Ноядумаю, что процессы проблем-менеджмента окоторых расскажу дальше, легко адаптировать ккомпании любого размера.


Как устроен LSR-процесс


Работу сLSR вАвито начали в2017году. Процесс несколько раз менялся, исейчас выглядит так:


  1. Когда возникает проблема, дежурные видят еёвсистеме мониторинга.
  2. Дежурные сами чинят проблему или привлекают ответственных откоманд.
  3. Автоматика фиксирует вJira продолжительность инцидента, затронутую функциональность инедополученную прибыль. Это называется Auto LSR. Автоматикаже отмечает критичность инцидента вслучае больших финансовых потерь или большого количества жалоб отпользователей.
  4. Мызаводим постмортем тикет вJira cописанием проблемы, которая вызвала инцидент, если такого еще нет. Кнему линкуются Auto LSR.
  5. Проводим встречу скомандой иэкспертами идетально разбираем проблему.
  6. Выполняем все нужные действия попредотвращению подобных инцидентов вбудущем.
  7. Закрываем тикет идополняем базу знаний.

Простые ипонятные проблемы мыразбираем внутри команд или вслак-чатиках. Акросс-командные встречи проводим для серьёзных ибизнес-критичных проблем: инфраструктурных, процессных итех, которые затронули сразу несколько команд. Встречи открытые, иханонс мыпубликуем вотдельном канале, иприйти наних может любой человек вкомпании.


Как реагируем наинциденты


Заработоспособностью всего Авито следит команда сназванием Мониторинг 24/7. Она всегда доступна исмотрит завсеми сервисами. Если случается взрыв напроде, эта команда первой отправляется тушить пожар ипривлекает дежурных разработчиков при необходимости.


Когда сбой устранили, ответственная зафункциональность команда выясняет его корневые причины, илюбой участник процесса заводит постмортем тикет.



Что описываем впостмортем тикете


После того, как постмортем тикет заведен, его дополняют данными все желающие. Вописание мывносим любую информацию, которая кажется полезной. Есть единственное правило описание должно быть таким, чтобы через полгода можно было прочитать ипонять написанное. Например, если мыпишем оконкретном дне, тонужна точная дата 22сентября, аневчера. Если прикладываем ссылку награфик, тоследим, чтобы непотерялся таймстемп.


Впостмортем тикете есть фиксированный набор полей.


Summary (обязательное) это заголовок. Заголовок мыстараемся заполнять так, чтобы увидев его вкалендаре или вквартальном отчёте, можно было вспомнить, очём идёт речь.


Description (обязательное) здесь описываем суть проблемы, ключевую причину инцидента илюбую другую информацию, которая может быть полезна при разборе. Также сюда команды пишут пожелания поразбору, например обсудим сами внутри кластера или обязательно позовите навстречу Васю.


Priority (обязательное) приоритет тикета. Унас ихчетыре:


  • Critical проблема из-за которой недоступен весь Авито.
  • Major проблема свысокой вероятностью повторения, недоступна часть функциональности.
  • Normal проблема сневысокой вероятностью повторения, недоступна часть функциональности.
  • Minor проблема сневысокой вероятностью повторения, недоступна часть функциональности без значимого ущерба для пользователей.

Slack link ссылка наобсуждение инцидента вслаке. Если обсуждений было несколько вразных каналах, товполе мывносим наиболее ценное. Остальные вэтом случае добавляем вDescription.


Команда (обязательное) проставляем сюда только одну команду, которая стала виновником торжества.


Пострадавшие сервисы вэтом поле перечисляем все сервисы, которые сломались, кроме того, где была ошибка. Поле нужно для того, чтобы видеть неявные зависимости сервисов иотмечать места, где нужно поработать над graceful degradation.


Участники здесь указываем всех, кого стоит позвать навстречу сразбором инцидента. Вихкалендари потом придёт приглашение.


Былили раньше такие проблемы когда заводится новый постмортем, вполе ставим нет. Если происходит второй подобный инцидент, линкуем его тикет спостмортемом именяем описание нада.


Вероятность повторного возникновения ближайшие полгода экспертная оценка того, кто заполняет тикет.


Action items допроведения встречи пишем сюда идеи, предложения ипожелания поинциденту. Так при обсуждении LSR будет меньше шансов про них забыть. Вовремя обсуждения это поле редактируется.


Link from Helpdesk добавляет саппорт, если были обращения пользователей.


HDcount количество пользователей, которые обратились спроблемами поинциденту вHelpDesk. Это поле заполняется иобновляется автоматически, если заполнено поле выше.


Продолжительность абсолютное значение продолжительности инцидента вминутах.


Как разбираем инциденты навстречах


Когда пожар потушен итикет заполнен, событие переходит вмою зону ответственности. Явнимательно смотрю нанего иразбираюсь, что происходило, медленно или быстро мынашли проблему, позвали дежурные сразу тех, кого нужно, или сначала разбудили непричастных. Япроверяю, хватилоли нам графиков для анализа ситуации, что было написано влогах.


После ясоздаю встречу для разбора вспециальном LSR-календаре. Вовстречах участвуют команды, всервисе которых возникла проблема, те, кто еёустранял, иэксперты потехнологиям, вкоторых проявилась проблема.


Наразборах постмортемов мыоцениваем влияние инцидента наработу компании, смотрим напроблему сразных сторон ивырабатываем поней решение. Если предотвратить возникновение проблемы вбудущем невозможно, топридумываем, как уменьшить потери отеёвозникновения. Обычно язаранее обозначаю повестку встречи, имыидём посписку подготовленных вопросов.


Вот список типовых вопросов, которые стоит обсудить при разборе LSR:
  • Вчём была проблема икакова еёпервопричина? Если это баг вкоде, тополезно посмотреть напроцессы тестирования ипонять почему его непоймали. Если сбой произошёл из-за возросшей нагрузки, тостоит подумать про регулярное нагрузочное тестирование.
  • Как быстро иоткуда узнали опроблеме? Можноли узнавать быстрее? Возможно, нужны дополнительные мониторинги или алерты. Или стоит отдать отдать имеющиеся команде мониторинга 24/7.
  • Как быстро смогли понять, вчём именно проблема? Возможно, стоит почистить Sentry или добавить логирование.
  • Затронулали проблема основную функциональность сайта иможноли уменьшить такое влияние? Например, если сломался счётчик количества объявлений, тостраницы сайта ломаться недолжны. Тут стоит подумать про graceful degradation.
  • Можетли проблема повториться вдругих модулях или компонентах системы? Что сделать, чтобы этого непроизошло? Например, актуализировать таймауты, добавить обработку долгого ответа.
  • Естьли платформенное решение, которое помогает избегать таких проблем? Возможно пора начать импользоваться? Врешении таких проблем часто помогают тестохранилка или PaaS.
  • Можетли необходимые для решения проблемы действия сделать команда или нужен отдельный проект, объединяющий несколько команд?

Основная ценность, которую мыполучаем отвстреч это action items, тоесть действия, направленные нато, чтобы проблема невозникала вдальнейшем или чтобы мыраньше еёзамечали ибыстрее чинили. Это могут быть как правки вкоде, так ипроекты поулучшения инструментов или процессов, предложения новых best practices иинформационные рассылки навсю инженерную команду.


Хорошие action items:


  • могут быть задачей или проектом, нонепроцессом;
  • всегда имеют ответственного иожидаемый срок завершения;
  • будут сделаны вближайшие полгода.

Плохие action items:


  • похожи навысказывания Капитана Очевидность, например: нужно лучше тестировать или перестать делать глупые баги;
  • точно небудут сделаны вближайшие полгода.

Мыдоговариваемся окусочках, которые надо сделать обязательно, итаких, которые сделать желательно. Когда action items сформулированы, мызаносим ихвJira это тикеты вразных проектах, слинкованные спостмортемом. Вначале описания необязательных задач ставим вопросительный знак, чтобы ихможно было сразу отличить. Поостальным считаем, что ихжелательно сделать втечение месяца. Чтобы это работало, яотдельно слежу завыполнением всех action items ипериодически прохожусь снапоминаниями полюдям, которым они назначены.


Как ведём базу знаний


Самые интересные или общественно полезные постмортемы исписок рекомендаций поним явношу вбазу знаний. Яихотбираю вручную ираз вдве недели публикую вобщем канале разработки под заголовком стенгазета LSR. Все выпуски стенгазеты также собраны вСonfluence, чтобы можно было быстро найти, как решались теили иные инциденты.


Благодаря стенгазете многие делают исправления всвоих сервисах дотого, как они сломались. Витоге LSR содними итемиже причинами вразных командах становится заметно меньше.



Аещё поLSR можно строить любопытную аналитику


Кроме того унас есть много графиков поLSR: попричинам, виновникам, пострадавшим сервисам, продолжительности, времени возникновения, времени суток. Вних яищу тренды исовпадения. Например, если какой-то сервис падает при любой неисправности любого стороннего сервиса, стоит поработать над его стабильностью: переделать, где возможно, обращения наасинхронные, добавить graceful degradation, может быть, увеличить пул ресурсов.


Лирическое заключение


Проблем-менеджемент вАвито часть контроля качества. Авконтроле качества есть два основополагающих вопроса: когда начать тестировать икогда закончить тестировать. Если поповоду того, когда начать, существует много разных подходов, тостем, когда закончить, всё ещё сложнее.


Протестировать абсолютно всё нереально, поэтому вкакой-то момент надо сказать, что мыпротестировали достаточно хорошо, иостановиться. Ачто такое достаточно хорошо? Если врелизе нашли 100 багов это достаточно? Аесли избагов 20критичных, 50средних, аостальные некритичные это достаточно хорошо или недостаточно? Проблема втом, что ответ насамом деле зависит неоттого, сколько багов нашли, аоттого, сколько ненашли тестировщики, нозаметят пользователи.


Спомощью LSR ясчитаю тебаги, которые помешали пользователям. Мыполучаем некую финальную точку вконтроле качества, скоторой видно весь цикл разработки как онесть. Исразу становится понятно, куда прийти сотверткой иподкрутить.

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru