Сообщить об ошибкеКороткий ответ
Поспешный постмортем рискует зафиксировать поверхностную причину ("сервер упал") вместо корневой ("отсутствовал алерт на насыщение диска, и это заняло 40 минут для диагностики"), что приведёт к повторению инцидента; нужно выделить время на восстановление полного таймлайна, анализ по методике "5 почему" и согласование действий с владельцами.
Как это работает подробнее
качественный постмортем требует собрать точный таймлайн (когда появился первый сигнал, когда дежурный заметил, когда начались действия, когда восстановили), затем для каждой причины задавать "почему это произошло" несколько раз, пока не дойдут до системной, а не поверхностной причины, и до причин, почему обнаружение/реакция заняли именно столько времени (Time to Detect, Time to Mitigate).
Пример / кейс
Ожидаемое поведение: такой разбор даёт несколько конкретных action items (добавить в чеклист ревью, настроить ротацию, снизить порог и частоту проверки алерта на диск), а не один поверхностный вывод "увеличить диск".
Пример кода
5 почему (сокращённо):
1. Почему сервис упал? — Диск заполнился логами.
2. Почему диск заполнился? — Не было ротации логов для нового модуля.
3. Почему не было ротации? — Модуль добавили без обновления конфигурации logrotate.
4. Почему это не поймали на review? — Чеклист ревью не включает проверку логирования.
5. Почему не было алерта на заполнение диска? — Алерт настроен на 95%, инцидент произошёл за 20 минут между проверками.Что использовать на практике
- Практический подход. Постмортем лучше писать через 1-2 дня после инцидента (пока детали свежи, но стресс спал), привлекая всех, кто участвовал в реагировании, в формате совместного обзора, а не единоличного написания одним человеком. Action items должны быть конкретными, с владельцем и сроком, и их выполнение нужно трекать отдельно — "закрытый" без выполненных action items постмортем бесполезен.
Подводные камни
- Частые ошибки. Фиксировать только техническую причину, игнорируя процессные (почему заметили поздно, почему эскалация задержалась); делать постмортем формальностью для "галочки" без реальных action items; писать постмортем в одиночку сразу после инцидента, когда детали ещё не восстановлены полностью или память участников уже искажена стрессом.