Postmortem — это не только медицинское вскрытие и не всегда «после смерти». В технологиях и менеджменте это живой и постоянно обновляющийся процесс, который помогает команде извлечь уроки из инцидента и не наступать на одни и те же грабли.
Зачем нужен Postmortem
Цель одна — сделать так, чтобы проблема больше не повторилась. А если повторится, то её заметят быстрее и ущерб будет минимален. Поэтому Postmortem:
- не служит местью «виноватым»;
- не превращается в шоу «кто кого перетопчет»;
- не прячет инцидент ради «красивых» KPI.
Три кита содержания
Любой документ-Postmortem состоит из трёх больших разделов:
Что случилось
- Затронутые проекты или клиенты.
- Точная временная шкала:
- когда инцидент начался;
- когда его заметили;
- кем и как он был обнаружен;
- как долго шёл отклик между «увидели» и «начали лечить».
- Действия по устранению.
- Фактическое время восстановления.
Почему случилось
- Краткое техническое описание «что пошло не так».
- Полная версия с логами, графиками, дампами — просьба к командам-участницам.
- Финансовый импакт: сколько реально потеряли.
- Предполагаемый импакт: сколько могли бы потерять.
- Репутационный ущерб: что говорят клиенты и соцсети.
Что делаем дальше
- Как заметить раньше? Какие алерты, метрики, чек-листы добавить.
- Как предотвратить повторение? Какие механизмы, тесты, откаты или проверки внедрить.
- Какие уроки извлекли? Короткие actionable-задачи с датами и ответственными.
Что не пишем в Postmortem
Ни одного личного имени. Пишем:
- «дежурный SRE выставил завышенный трешхолд»,
- а не «Иванов всё про… проигнорировал».
Так мы сохраняем фокус на системе, а не на «кара виноватым».
Кому писать и кому читать
Обычно текст готовит менеджер проекта или тимлид поддержки, потому что они:
- владеют общей картиной;
- общаются сразу с инженерами, финансистами, клиентами, маркетингом;
- умеют «где и кого спросить».
Документ публикуется в Confluence, Google Docs, Jira — любом доступном и прозрачном месте.
Распространённые ловушки
| Ловушка | Как избежать |
|---|---|
| «Разбор по понедельникам» превращается в ток-шоу. | Запретить публичные «разборки»; вести дискуссию в чате или доске комментариев. |
| Postmortem в KPI: «не более 3 в квартал». | Убрать количество кейсов из KPI; оставить только «качество предотвращённых инцидентов». |
| Копипаст прошлых расследований. | Разбирать только новые сценарии; старые — сводить в чек-лист «как не повторить». |
Практический чек-лист для быстрого старта
- Сразу после инцидента создайте тикет Postmortem, отметьте дату/время.
- Соберите таймлайн по UTC: начало → обнаружение → первые действия → восстановление.
- Уточните урон: SLA, деньги, NPS, соцсети.
- Напишите TL;DR (две-три строки) для руководства.
- Сформулируйте 3–5 action-items с датой и ответственным.
- Опубликуйте и разошлите линк всем заинтересованным.
- Проверьте выполнение action-items через 30 дней.
Финальное напоминание
Парадокс Postmortem в том, что чем меньше страшных инцидентов вы имеете, тем больше здоровых Postmortem’ов вы пишете. Это не показатель «плохой работы», а свидетельство зрелости команды.
Как писали братья Стругацкие: «Народу не нужны нездоровые постмортемы — народу нужны здоровые постмортемы».
04 августа 2026 г. 06:04 по UTC