Шаблон post-mortem, который реально работает
В среднем post-mortem пишется 4 часа и порождает ноль action items, которые команда закрывает в течение 30 дней. Мы посмотрели на 120 post-mortem документов у трёх наших on-prem клиентов перед тем, как собрать этот шаблон. 83% action items оставались в статусе "open" через полгода. Это не разбор инцидента — это кладбище документов.
Post-mortem имеет смысл писать только если он что-то меняет. Всё остальное — прикрытие.
{/* truncate */}
Почему большинство post-mortem бесполезны
Google SRE Workbook — неофициальный стандарт с 2018 года. Идея blameless правильная, но команды переусердствуют с тоном и недорабатывают с follow-up. Исследование Atlassian State of Incident Management 2022 показало: 61% инженерных команд делают post-mortem, но только 23% отслеживают закрытие action items. Ритуал есть. Результата нет.
В документах, которые мы смотрели, повторяются три паттерна:
- Раздутый нарратив — 3 страницы таймлайна, 4 предложения про фикс. Читатель пролистывает до фикса и идёт дальше.
- Action items без владельца — "надо улучшить мониторинг" без имени, даты и критерия готовности.
- Нет follow-up через 30 дней — action items лежат в документе, а не в трекере. Испаряются.
Полезный post-mortem — короткий, хирургический и привязанный к трекеру задач. Всё остальное — театр.
Шаблон 5W
Мы называем его 5W потому что каждый раздел отвечает на вопрос с буквы W. Весь документ должен помещаться на одном экране и писаться не дольше 90 минут.
| Раздел | Вопрос | Длина |
|---|---|---|
| Что случилось | Абзац про impact для клиента | 3-4 предложения |
| Когда | Таймлайн в UTC, только ключевые события | 5-8 пунктов |
| Почему | Цепочка 5 Whys до системной причины | 1 абзац |
| Кто пострадал | Пользователи, тенанты, деньги (если применимо) | 2-3 строки |
| Что меняем (action items) | 3-5 конкретных задач с владельцем и дедлайном | Таблица |
Пять разделов. Никаких "героев", "благодарностей", "lessons learned" (уроки — это и есть action items).
Жизненный цикл post-mortem, который реально приводит к изменениям. Петля follow-up — то место, где 83% команд ломаются.
Раздел 1 — Что случилось
Один абзац. Написан для того, кто не был на дежурстве. Должен отвечать: что сломалось, что видел клиент, сколько длилось, что починило.
"3 апреля 2026 с 14:12 по 14:47 UTC подтверждения платежей падали у 12% чекаутов на
api.example.com. Корневая причина — исчерпание connection pool в PostgreSQL после планового vacuum. Решено ручным рестартом пула и откатом миграции, поднимавшейmax_connections. 280 заказов клиентов успешно переотправлены; 4 дубликата списания потребовали ручного возврата."
Обратите внимание, чего тут нет: драмы, обвинений, сюжета. Только факты.
Раздел 2 — Когда (таймлайн)
Только UTC. Не смешивайте зоны — путаница "2:47 AM vs 2:47 PM" стоила командам часов на реконструкцию. Логируйте события, которые действительно меняли ход инцидента: первый алерт, первый ответ человека, первый откат, конец impact на клиента.
14:12 — первый алерт (PG pool saturation)
14:14 — on-call инженер подтвердил
14:19 — открыли war room, подключились 3 инженера
14:28 — первая попытка митигации (failover на read replica) — без эффекта
14:41 — мёрджнули откат миграции
14:47 — pool восстановился, impact на клиента закончился
15:10 — all-clear сообщили support-у
7 строк. Если ваш таймлайн длиннее 15 строк — вы логируете сообщения из Slack, а не события.
Раздел 3 — Почему (5 Whys)
Единственный раздел, где проза помогает. Пишите цепочку 5 Whys, но останавливайтесь на системной причине — не на человеке.
Почему упали платежи? Исчерпался connection pool. Почему pool исчерпался? Vacuum full держал блокировки таблицы дольше, чем ожидалось. Почему не заметили в staging? Staging-база — 0.3% от прод, vacuum там заканчивается за секунды. Почему не проверили нагрузку на pool до vacuum? В runbook для ручного vacuum нет pre-flight проверки. Почему её нет в runbook? Runbook-и пишутся реактивно после инцидентов, а не проактивно. Раньше vacuum никогда не вызывал saturation.
Системная причина: пробел в покрытии runbook для редких maintenance-операций. Именно эту проблему атакуют action items.
Раздел 4 — Кто пострадал
Важны две цифры: сколько пользователей и сколько денег (если релевантно). Без нарратива. Таблица работает.
| Impact | Число |
|---|---|
| Затронутых клиентов | 280 |
| Дубликатов списания | 4 |
| Revenue в зоне риска (1 час) | $14 200 |
| Тикетов в support | 31 |
| Часов senior-инженеров на решение | 9 |
Последняя строка имеет значение для разговора про cost per feature — см. анализ стоимости фичи для того, как мы считаем incident burn.
Раздел 5 — Что меняем (action items)
Единственный раздел, который аудиторы будут читать через полгода. Правила:
- У каждого action item один владелец, не команда. "Platform team" — ничья задача. "Марат" — чья-то.
- У каждого action item есть дедлайн. Не "Q2". Конкретная дата.
- У каждого action item есть критерий готовности. "Улучшить мониторинг" не измеримо. "Алерт на saturation пула срабатывает на 80%, протестирован в staging" — измеримо.
- Каждый action item — тикет в трекере. Не буллет в документе. Если не в Jira/Linear/ClickUp — не существует.
| # | Action item | Владелец | Дедлайн | Критерий готовности |
|---|---|---|---|---|
| 1 | Добавить алерт на saturation pool 80% | Марат | 10 апр | Алерт срабатывает в staging-тесте; runbook ссылается |
| 2 | Pre-vacuum чеклист в runbook | Алия | 12 апр | Чеклист ревьюнули 2 SRE; использован на следующем vacuum |
| 3 | План масштабирования staging-датасета | Данил | 1 мая | Документ ревью; выбран подход 10% сэмплирование |
| 4 | Автодетект дубликатов списания | Жанна | 15 мая | Срабатывает на тестовой транзакции; скрипт возврата прилинкован |
Четыре action items. Не десять. Команда, которая пишет десять, закрывает ноль.
Типичные ошибки
- Фетиш "blameless" — blameless не значит "без ответственности". Колонка "владелец" — не обвинение. Это ответственность за фикс.
- Писать post-mortem пока инцидент свежий (и злит) — подождите 24 часа. Черновик в 2 часа ночи склонен к overload нарративом и underload action-ами.
- Считать документ продуктом — продукт — action items в трекере, закрытые к дедлайну.
- Одна и та же корневая причина в 3 инцидентах подряд — если "у нас не было мониторинга для X" встречается трижды, action item — не "добавить мониторинг для Y", а "выделить 20% времени инженеров в этом спринте на закрытие monitoring gaps".
Как измерить, что post-mortem-ы реально работают
Две метрики. Обе простые.
Процент закрытых action items. Посчитайте action items с дедлайном за последние 6 месяцев. Разделите на те, что закрыли к дате. Цель: ≥ 70%. Если ниже 50% — ритуал это театр.
Recurrence rate. Посчитайте инциденты, где та же корневая причина встречается во второй или третий раз. Цель: ≤ 15%. Выше — значит action items не чинят системную причину.
В PanDev Metrics мы связываем инциденты с деплоями, которые их вызвали, и задачами, которые их починили — вытягиваем имена веток типа fix/INC-204 в запись инцидента автоматически. Это та же конвенция имён веток, что и для lead time, так что follow-through по post-mortem виден на том же дашборде, что и change failure rate.
Наш датасет смещён в B2B SaaS и on-prem enterprise. У нас нет сигнала по игровым студиям и consumer mobile командам, где динамика инцидентов другая. Шаблон всё равно работает; бенчмарки — возможно нет.
Шаблон для copy-paste
# Post-Mortem: [ID инцидента] — [одна строка названия]
## Что случилось
[Один абзац, без драмы, в контексте impact на клиента]
## Когда (UTC)
- HH:MM — событие
- HH:MM — событие
## Почему (5 Whys)
Q1: Почему X упало? A: ...
Q2: Почему Y? A: ...
(продолжайте до системной причины)
Системная причина: [одно предложение]
## Кто пострадал
| Impact | Число |
|--------|--------|
| Затронутых клиентов | ... |
| Revenue в риске | ... |
| Часов на решение | ... |
## Action items
| # | Задача | Владелец | Дедлайн | Критерий готовности |
|---|--------|----------|---------|---------------------|
| 1 | ... | @имя | YYYY-MM-DD | измеримый сигнал |
Сохраните в трекере инцидентов, свяжите с ветками Git, которые это чинят, и запланируйте review через 30 дней в том же спринте, где делаете retro.
Post-mortem — это не работа. Работа — это review через 30 дней.