Как писать постмортем (postmortem)

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

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

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

Для фиксирования и подведения итогов (а также принятия решений и выводов) формируется такой документ: постмортем. Где подбиваются summary, итоги, анализ, и прочие полезные штуки. Мортем — это не обязательно «чтобы всё сдохло», устойчивая система и структура «дохнуть» не должна. Но вот, какие-то ожидания с реальностью явно не сошлись. Их надо — и очень полезно — зафиксировать.

В каких случаях пишем?

В айтишной и бизнесовой среде обычно постмортемы собирают:

— по итогам инцидентов и происшествий. Вот случился «ой», мы что-то с этим сделали, хорошо, плохо. Надо сделать выводы.

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

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

Нафига?

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

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

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

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

Что писать

Нам нужно, для начала, полное и всестороннее описание, собственно, ситуации:

— что произошло, что мы об этом знаем, как мы это узнали
— как мы в эту ситуацию попали, какие были предпосылки, где была точка старта (логически и календарно)
— как мы эту ситуацию оценили, когда мы начали задумываться, что «что-то идет не так»
— что конкретно происходило, в привязке ко времени, как ситуация развивалась
— какие шаги мы предприняли, что было задействовано, почему именно так (были ли процессы, или реакции были ситуативными)
— какие решения принимались, почему именно такие
— когда и как ситуация стабилизировалась
— какие люди, процессы и системы были задействованы в ходе работы над ситуацией

Дальше нам нужно сформировать блок анализа:

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

И следом, блок выводов:

— какой успешный outcome, «что пошло как надо» (Went Well)
— какой неуспешный, «что пошло не так» (Went Wrong)
— какие у нас воздействия и потери, если есть (Impact)
— какие были предпосылки у самой ситуации (Root Cause Analysis)
— какие были предпосылки у случившегося в итоге (тоже RCA)
— что нам надо сделать прямо сейчас, по итогам (Action List)
— что нам надо сделать в принципе, и чего понять/запланировать на будущее (Lessons)

К этому всему надо добавить сжатую выжимку Executive Summary:

— что случилось, чем закончилось и чего нам это стоило

Структура и шаблон

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

Шаблон не единственный, хотите — поправьте, заберите у Гугла и интернета.

Чего внутри:

• заголовок и мета: название, дата, статус (завершен или еще в процессе), сфера ответственности (где происшествие и о чем)
• executive summary: что произошло, причина кратко, затраты и потери
• хронология (timeline): пошаговый разбор наблюдений и действий, с указанием timestamp в согласованном времени. Лучше таблицей или списком
• воздействие (impact): технические последствия, бизнесовые последствия, затраты на восстановление, убытки, возросшие риски
• причины (root cause analysis): у ситуации, у последствий, у принятых решений, у возникших факторов. Вопрос «почему?» ваш друг
• went well + went wrong: что пошло по плану, что пошло не по плану, где проявился негативный эффект
• action items: план того, что надо сделать сейчас по итогу (можно прямо сразу чеклистом)
• lessons: что надо учесть и предпринять дальше, на что обратить внимание, как избежать или вообще нейтрализовать риски в дальнейшем
• документы и детали: все релевантные ссылки на данные и на документы, которые к вопросу относятся

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

Статусы

По документу надо понять, в каком он состоянии. Обычно что-то вроде:

— draft: осознали что ПМ нужен, нарисовали рыбу
— pending: заполняем данные, собираем инфу, пишем action items
— review: отдаем на проверку умным людям, дособираем action, пишем lessons
— ready: всё собрали что могли, пошли принимать меры
— process: выполняем action list
— completed: сделали что могли, оставили для референса

Цепочку по вкусу, зависит уже от ваших хотелок и внутрянки.

Опциональное

Блоки, которые в PM не всегда нужны, но часто важны.

Гипотеза: если это не «само сломалось», а мы что-то сделали явно, что-то предприняли и что-то навернулось, то надо описать — чего хотели достичь, какие предпосылки, и где вообще изначально зачесалась жопа. Что вообще нам пришло в голову, чью, как прорабатывалась концепция. На какие целевые показатели мы хотели выйти.

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

Повторяемость: может ли ситуация повториться снова? Как изменится в таком случае Impact, станет хуже / станет легче. Если станет хуже, почему, и не хотим ли мы что-то с этим отдельно сделать.

Роли, люди, функции, процессы

О том, что не надо в постмортеме писать «вот Вася был мудак и всё сломал». Во-первых, это не конструктивно, вам это особо не поможет. Во-вторых, Вася обидится. Хорошая практика — это blameless, никого ни в чем (пока) не надо обвинять. Вы собираете опыт, а не обидки.

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

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

Например, по второму варианту я сразу могу задать вопросы

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

Думаю, вы поняли цепочку рассуждений.

Применительно к людям, постмортем — это ни в коем случае не «наказание причастных». Это пристальный сбор аналитики.

Action Items, Lessons

Должен появиться список «что мы прямо сейчас собираемся со всем этим делать». Или уже сделали.

Список имеет приоритеты, не забываем. И его надо дальше пойти и делать — оформить в чек-лист, расставить задачи итп.

То, что не укладывается в «прямо сейчас», пишем в Lessons.

Если сможете, соберите по инциденту в документе диаграмму Исикавы (раз, два).
Она хорошая; не просто для того, чтобы вы «рыбную косточку» нарисовали.

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

И следом всё перечисленное разделяется на 2 группы, синие и красные:
— на что можем повлиять (и что можем изменить)
— на что не можем повлиять (значит, надо обложить проверками и свести воздействие к предсказуемому)

Куда еще посмотреть

Там больше технических подробностей и методов:

— https://sre.google/sre-book/postmortem-culture/
— https://habr.com/en/companies/slurm/articles/562758/
— https://habr.com/en/articles/878366/
— https://github.com/danluu/post-mortems (тут список примеров по источникам и по авторам)
— https://agaltsovav.ru/docs/development-managment/post-mortem/
— https://github.com/YandexClassifieds/playbook/blob/main/process/incidents/postmortem.md

Hope that helps.