Это же административное, не культурное. Авария - ну-ка быстро все на созвон! Механизм распространённый, но это про иерархию, обязаловку, подчиненность, доставку информации наверх. С применением такой практики лучше, безусловно, становится, если раньше ничего подобного не было. Как конкретно проводится процедура, с чем на неё приходят и с чем уходят - да, тут могут быть элементы культуры.
В нашем случае Post mortem - это все же больше про культурное, и про то, что мы готовы говорить открыто не только внутри команды, но и с коллегами из других подразделений. У нас на этих встречах не летят головы, а обсуждаются затыки, фиксируются результаты - здесь не просто про поговорить ни о чем для галочки.
Больше скажу - когда команды понимают, что проблема кросс-системная или есть спорный вопрос с бизнесом, где они сами не знают как подступиться, они приходят к нам и просят такого формата встречи. Их мы, к слову, проводим не только по критичным сбоям, а если просят команды по любым. Когда компания большая, а команд много - это идеальная площадка обсудить все, что не успели в суматохе на конференции во время аварии.
Если говорить про формат - это встреча, на которой мы читаем подробно хронологию ранее зафиксированную дежурной службой во время сбоя (она не как-то там и где-то там на коленке пишется, а по оговоренному порядку и в оговоренной форме инцидента, что очень удобно всем сотрудникам дежурки).
Во время встречи:
- мы останавливаемся на отдельных шагах, пишем какие-то моменты, на которых споткнулись и думаем как с ними работать,
- отмечаем, что получилось быстро и успешные практики в решении сбоя
- обсуждаем наличие мониторинга и корректировки алертинга у дежурной службы и команды
Как правило к проведению встречи команда уже знает корневые причины, и здесь мы штормим именно на тему того, как себя обезопасить от повторения.
По итогам регистрируем проблему и в ней фиксируем sub-task со сформулированными по смарту задачами, назначаем на ответственного по согласованию с ним во встрече. Это удобно отслеживать как команде, на которую назначили, так и команде, которая попросила доработать.
Есть дейлик, на котором нужно озвучивать проблемы и трудности в решении задач. Есть ретро, где нужно разбирать в том числе проблемы и трудности. И потом еще отдельный регламентно-ритуальный созвон, теперь уж точно по проблемам и трудностям? "Пахнет" не очень хорошо. И точно не про культуру, а опять про администрирование.
Дейлик по бэклогу команда проводит у себя внутри, обсуждает проблемы со своим руководителем. А что делать если на уровне команды вопрос не решается? Мы как раз и ведем мониторинг таких задач вместе с командами, чтобы не потерять то, что они хотели сделать как меры по недопущению.
Если у них есть трудности в решении задач, которые связаны опять же с кросс-функциональным воздействием (например, застряли и не поняли куда идти дальше), то как раз Problem-board отличная площадка это подсветить и попросить помощи. Он проводится по командам, где больше всего вопросов и долгоиграющих задач не с целью поругать, а с целью спросить на каком они этапе и что планируют делать. Это не значит, что задача должна быть выполнена и все тут – если проведя анализ команда понимает, что делать мониторинг дорого и не нужно (например), она подсвечивает это заключение и мы не идем продолжать выполнять то, что нерентабельно.
Я не очень понимаю, чем созвон так плох - разве лучше вести долгоиграющие переписки в почте? Люди наоборот просят занять час времени, и рассказать про задачи быстро, чем потом отвечать на каждое отдельное письмо с вопросом. А здесь все максимально прозрачно, с минутками, результатами.
Больше созвонов богу созвонов. Кросс-командное ретро/пост-мортем? Вероятно, здравое зерно есть. Может даже и не связанное напрямую с самой разбираемой проблемой. Не менее вероятным кажется и то, что некоторые заросли малины хоть и выглядят со стороны свежо и соблазнительно, выжить смогут только в присутствии уверенной руки с секатором.
Почему не очень? Ритуалы про прозрачность, про культуру, про то что вы можете зайти на деш, найти инцидент с влиянием, в нем увидеть результаты ретроспективы, запланированные задачи, заведенные Problem если есть, ссылки на все Post mortem, открыть интересующие задачи и провалиться в них, увидеть в каком они статусе. Разве если вы, например, сотрудник сетевой инфры, и вам нужно посмотреть как в итоге развернулась история по инциденту у определенного сервиса, который на вашем куске инфры лежит, это не было бы удобно? Именно для этого мы и проводим эту работу, чтобы соединить все пазлы воедино. Иначе все остается на уровне «поговорили и забыли»
В нашем случае Post mortem - это все же больше про культурное, и про то, что мы готовы говорить открыто не только внутри команды, но и с коллегами из других подразделений. У нас на этих встречах не летят головы, а обсуждаются затыки, фиксируются результаты - здесь не просто про поговорить ни о чем для галочки.
Больше скажу - когда команды понимают, что проблема кросс-системная или есть спорный вопрос с бизнесом, где они сами не знают как подступиться, они приходят к нам и просят такого формата встречи. Их мы, к слову, проводим не только по критичным сбоям, а если просят команды по любым. Когда компания большая, а команд много - это идеальная площадка обсудить все, что не успели в суматохе на конференции во время аварии.
Если говорить про формат - это встреча, на которой мы читаем подробно хронологию ранее зафиксированную дежурной службой во время сбоя (она не как-то там и где-то там на коленке пишется, а по оговоренному порядку и в оговоренной форме инцидента, что очень удобно всем сотрудникам дежурки).
Во время встречи:
- мы останавливаемся на отдельных шагах, пишем какие-то моменты, на которых споткнулись и думаем как с ними работать,
- отмечаем, что получилось быстро и успешные практики в решении сбоя
- обсуждаем наличие мониторинга и корректировки алертинга у дежурной службы и команды
Как правило к проведению встречи команда уже знает корневые причины, и здесь мы штормим именно на тему того, как себя обезопасить от повторения.
По итогам регистрируем проблему и в ней фиксируем sub-task со сформулированными по смарту задачами, назначаем на ответственного по согласованию с ним во встрече. Это удобно отслеживать как команде, на которую назначили, так и команде, которая попросила доработать.
Дейлик по бэклогу команда проводит у себя внутри, обсуждает проблемы со своим руководителем. А что делать если на уровне команды вопрос не решается? Мы как раз и ведем мониторинг таких задач вместе с командами, чтобы не потерять то, что они хотели сделать как меры по недопущению.
Если у них есть трудности в решении задач, которые связаны опять же с кросс-функциональным воздействием (например, застряли и не поняли куда идти дальше), то как раз Problem-board отличная площадка это подсветить и попросить помощи. Он проводится по командам, где больше всего вопросов и долгоиграющих задач не с целью поругать, а с целью спросить на каком они этапе и что планируют делать. Это не значит, что задача должна быть выполнена и все тут – если проведя анализ команда понимает, что делать мониторинг дорого и не нужно (например), она подсвечивает это заключение и мы не идем продолжать выполнять то, что нерентабельно.
Я не очень понимаю, чем созвон так плох - разве лучше вести долгоиграющие переписки в почте? Люди наоборот просят занять час времени, и рассказать про задачи быстро, чем потом отвечать на каждое отдельное письмо с вопросом. А здесь все максимально прозрачно, с минутками, результатами.
Почему не очень? Ритуалы про прозрачность, про культуру, про то что вы можете зайти на деш, найти инцидент с влиянием, в нем увидеть результаты ретроспективы, запланированные задачи, заведенные Problem если есть, ссылки на все Post mortem, открыть интересующие задачи и провалиться в них, увидеть в каком они статусе. Разве если вы, например, сотрудник сетевой инфры, и вам нужно посмотреть как в итоге развернулась история по инциденту у определенного сервиса, который на вашем куске инфры лежит, это не было бы удобно? Именно для этого мы и проводим эту работу, чтобы соединить все пазлы воедино. Иначе все остается на уровне «поговорили и забыли»