Комментарии 7
По критичным сбоям мы организуем Post mortem — подробный разбор хронологии инцидента с привлечением сотрудников, устраняющих сбой, руководителей ИТ и ситуационным центром.
Это же административное, не культурное. Авария - ну-ка быстро все на созвон! Механизм распространённый, но это про иерархию, обязаловку, подчиненность, доставку информации наверх. С применением такой практики лучше, безусловно, становится, если раньше ничего подобного не было. Как конкретно проводится процедура, с чем на неё приходят и с чем уходят - да, тут могут быть элементы культуры. Если все договорились руками на проде не шурудить, не деплоить в обход пайплайна и соблюдают эти договорённости - это элемент культуры. Если раньше была обратная картина, то чтобы прийти к подобному состоянию нужен серьезный культурный сдвиг. Чтобы созваниваться после аварии - не нужен. Если раньше все просто суетились и где-то что-то как-то фиксили, а после решения проблемы не могли вспомнить, где чего поменяли, какими действиями фактически устранили последствия инцидента, и в чем он заключался - это отсутствие культуры. Если все дружно стали вести в правильных местах хронологию своих манипуляций, большую часть манипуляций до возникновения инцидента и проделываемых после возникновения перевесили на автоматику, которая ведёт подробный лог, и потом это можно как-то склеить и получить ту саму хронологию - это высокий и технический, и культурный уровень. А созвониться можно и без всего этого.
Мы регулярно мониторим статусы всех задач, поставленных на ретроспективе или при проведении Post mortem, а также организовываем Problem‑борды — встречи по задачам и проблемам, которые выполняются длительное время.
Есть дейлик, на котором нужно озвучивать проблемы и трудности в решении задач. Есть ретро, где нужно разбирать в том числе проблемы и трудности. И потом еще отдельный регламентно-ритуальный созвон, теперь уж точно по проблемам и трудностям? "Пахнет" не очень хорошо. И точно не про культуру, а опять про администрирование.
Мы регулярно мониторим статусы всех задач ... при проведении Post mortem
Подозрительное совмещение в одном предложении. Тоже "пахнет" не очень.
Цель F#ckUp Review не только обсуждение произошедшего, но и извлечение системных выводов, которые могут быть полезны и для других команд.
Больше созвонов богу созвонов. Кросс-командное ретро/пост-мортем? Вероятно, здравое зерно есть. Может даже и не связанное напрямую с самой разбираемой проблемой. Не менее вероятным кажется и то, что некоторые заросли малины хоть и выглядят со стороны свежо и соблазнительно, выжить смогут только в присутствии уверенной руки с секатором.
Это же административное, не культурное. Авария - ну-ка быстро все на созвон! Механизм распространённый, но это про иерархию, обязаловку, подчиненность, доставку информации наверх. С применением такой практики лучше, безусловно, становится, если раньше ничего подобного не было. Как конкретно проводится процедура, с чем на неё приходят и с чем уходят - да, тут могут быть элементы культуры.
В нашем случае Post mortem - это все же больше про культурное, и про то, что мы готовы говорить открыто не только внутри команды, но и с коллегами из других подразделений. У нас на этих встречах не летят головы, а обсуждаются затыки, фиксируются результаты - здесь не просто про поговорить ни о чем для галочки.
Больше скажу - когда команды понимают, что проблема кросс-системная или есть спорный вопрос с бизнесом, где они сами не знают как подступиться, они приходят к нам и просят такого формата встречи. Их мы, к слову, проводим не только по критичным сбоям, а если просят команды по любым. Когда компания большая, а команд много - это идеальная площадка обсудить все, что не успели в суматохе на конференции во время аварии.
Если говорить про формат - это встреча, на которой мы читаем подробно хронологию ранее зафиксированную дежурной службой во время сбоя (она не как-то там и где-то там на коленке пишется, а по оговоренному порядку и в оговоренной форме инцидента, что очень удобно всем сотрудникам дежурки).
Во время встречи:
- мы останавливаемся на отдельных шагах, пишем какие-то моменты, на которых споткнулись и думаем как с ними работать,
- отмечаем, что получилось быстро и успешные практики в решении сбоя
- обсуждаем наличие мониторинга и корректировки алертинга у дежурной службы и команды
Как правило к проведению встречи команда уже знает корневые причины, и здесь мы штормим именно на тему того, как себя обезопасить от повторения.
По итогам регистрируем проблему и в ней фиксируем sub-task со сформулированными по смарту задачами, назначаем на ответственного по согласованию с ним во встрече. Это удобно отслеживать как команде, на которую назначили, так и команде, которая попросила доработать.
Есть дейлик, на котором нужно озвучивать проблемы и трудности в решении задач. Есть ретро, где нужно разбирать в том числе проблемы и трудности. И потом еще отдельный регламентно-ритуальный созвон, теперь уж точно по проблемам и трудностям? "Пахнет" не очень хорошо. И точно не про культуру, а опять про администрирование.
Дейлик по бэклогу команда проводит у себя внутри, обсуждает проблемы со своим руководителем. А что делать если на уровне команды вопрос не решается? Мы как раз и ведем мониторинг таких задач вместе с командами, чтобы не потерять то, что они хотели сделать как меры по недопущению.
Если у них есть трудности в решении задач, которые связаны опять же с кросс-функциональным воздействием (например, застряли и не поняли куда идти дальше), то как раз Problem-board отличная площадка это подсветить и попросить помощи. Он проводится по командам, где больше всего вопросов и долгоиграющих задач не с целью поругать, а с целью спросить на каком они этапе и что планируют делать. Это не значит, что задача должна быть выполнена и все тут – если проведя анализ команда понимает, что делать мониторинг дорого и не нужно (например), она подсвечивает это заключение и мы не идем продолжать выполнять то, что нерентабельно.
Я не очень понимаю, чем созвон так плох - разве лучше вести долгоиграющие переписки в почте? Люди наоборот просят занять час времени, и рассказать про задачи быстро, чем потом отвечать на каждое отдельное письмо с вопросом. А здесь все максимально прозрачно, с минутками, результатами.
Больше созвонов богу созвонов. Кросс-командное ретро/пост-мортем? Вероятно, здравое зерно есть. Может даже и не связанное напрямую с самой разбираемой проблемой. Не менее вероятным кажется и то, что некоторые заросли малины хоть и выглядят со стороны свежо и соблазнительно, выжить смогут только в присутствии уверенной руки с секатором.
Почему не очень? Ритуалы про прозрачность, про культуру, про то что вы можете зайти на деш, найти инцидент с влиянием, в нем увидеть результаты ретроспективы, запланированные задачи, заведенные Problem если есть, ссылки на все Post mortem, открыть интересующие задачи и провалиться в них, увидеть в каком они статусе. Разве если вы, например, сотрудник сетевой инфры, и вам нужно посмотреть как в итоге развернулась история по инциденту у определенного сервиса, который на вашем куске инфры лежит, это не было бы удобно? Именно для этого мы и проводим эту работу, чтобы соединить все пазлы воедино. Иначе все остается на уровне «поговорили и забыли»
Спасибо за статьи, обе прочёл с удовольствием! Есть вопрос про обсуждение проблем: достаточно ли факап-ревью, чтобы в команде сохранялось спокойное отношение к ошибкам? Или как-то ещё поддерживаете нужную атмосферу?
Спрашиваю, потому что признавать ошибки трудно. Если менеджмент собственным примером не показывает, что ошибки — это нормально, со временем команда может вернуться в естественное состояние с «отрицательным ростом»)
Факап-ревью – это скорее неформальное мероприятие, позволяющее с юмором и цинизмом посмотреть на случившуюся ситуацию. Более формальная проработка происходит на ретроспективах и post-mortem`ах, и, само собой, на внутренних встречах команд.
Все руководители – от уровня CIO до тим-лидов команд, поддерживают безобвинительную культуру обсуждения произошедших «эпизодов». Фокус не на наказании (его нет), а на совместном поиске решений, за счёт которых снижается вероятность повторения факапа.
При этом мы разделяем ошибки и нарушения. Если сотрудник не учится на своих ошибках и откровенно нарушает договорённости, то могут быть адекватные последствия.
И показалось, что пример факап-ревью выбран безопасный. Вы столкнулись с проблемами из-за ошибки, но выкатили решение — и рассказали об этом только потом. А если взять более негативный сценарий?
Допустим, проект был переведён на технологию, которая не оправдала ожиданий — и теперь нужно выбить у бизнеса время на ещё один переезд. В этом случае будете проводить факап-ревью или другими инструментами воспользуетесь?
Факап-ревью – это публичное мероприятие для проф. сообщества, чтобы все смогли прочувствовать произошедшее и сделать выводы для себя. Это не операционный инструмент, а инструмент развития насмотренности в профессии.
Про ваш пример с неоправданной технологией. Перед раскаткой новой технологии, мы обычно ее сначала опробируем (mvp), затем уже делаем rollout, чтобы, как раз, снизить риски негативных последствий.
Но, если случилось то, о чем вы пишите, мы обратимся к ИТ-лидеру, solution-архитектору и владельцу системы, чтобы выбрать верное решение/
Как активный корпоративный клиент разных банков, с уверенностью говорю - ПО от росбанка самое наихудшее. Банк-клиенты (а их зачем-то несколько) ужасно неудобны, неиформативны, с кучей ненужных операций. Начиная с авторизации, заканчивая поддержкой. Создается впечатление, что никто из росбанка никогда не работал со стороны клиента. Поэтому вы можете хоть каждый день хвалить свою команду, но работать с вашим банком жутко неудобно.
Инженерная культура Росбанка: что это и какие у нее принципы. Часть 2