Коротко. Постмортем — это документ-разбор после инцидента, цель которого не найти виноватого, а понять, как система допустила сбой, и не повторить его. «Blameless» означает фокус на процессах и системах, а не на людях. Хороший постмортем содержит таймлайн, влияние на пользователей, корневые причины и конкретные действия с ответственными и сроками.
Почему blameless
Если за инцидент наказывают, люди начинают скрывать ошибки — и организация теряет возможность учиться. Безвинный подход делает обратное: поощряет честность.
Человек, нажавший «не ту кнопку», — это симптом, а не причина. Причина в том, что система позволила одной кнопкой устроить аварию без защиты.
Когда писать постмортем
- Любой инцидент, затронувший пользователей или нарушивший SLO.
- Близкие промахи (near-miss), которые чуть не стали авариями.
- Срабатывания, потребовавшие ручного вмешательства дежурного.
- Повторяющиеся мелкие сбои — даже если каждый по отдельности невелик.
Структура постмортема
Стандартный шаблон, который легко адаптировать:
ПОСТМОРТЕМ: <короткое название инцидента>
Дата: 2026-06-22
Авторы: <имена>
Статус: draft / финал
== РЕЗЮМЕ ==
1–2 предложения: что сломалось и какое влияние.
== ВЛИЯНИЕ ==
- Длительность: 14:02–14:47 (45 мин)
- Затронуто: ~30% запросов API возвращали 503
- SLO: израсходовано 45 мин бюджета ошибок из 43,2
== ТАЙМЛАЙН (UTC) ==
14:02 Деплой v2.4.1
14:05 Рост ошибок 503, сработал алерт
14:09 Дежурный подтвердил инцидент
14:23 Найдена причина: исчерпан пул соединений к БД
14:31 Откат на v2.4.0
14:47 Метрики в норме, инцидент закрыт
== КОРНЕВЫЕ ПРИЧИНЫ ==
1. Новый код открывал соединение на каждый запрос без возврата в пул.
2. Нагрузочное тестирование не покрывало пиковый трафик.
== ЧТО СРАБОТАЛО ХОРОШО ==
- Алерт пришёл за 3 минуты.
- Откат занял меньше 5 минут.
== ДЕЙСТВИЯ ==
[ ] Вернуть соединения в пул — @ivan — до 25.06 (P1)
[ ] Добавить нагрузочный тест пика — @olga — до 30.06 (P2)
[ ] Алерт на насыщение пула БД — @ivan — до 27.06 (P1)Как искать корневую причину
- Стройте таймлайн по фактам и логам, а не по памяти.
- Задавайте «почему?» несколько раз подряд (метод 5 Whys), пока не дойдёте до системной причины.
- Различайте триггер (деплой) и реальную уязвимость (нет защиты пула).
- Ищите не одну причину, а цепочку условий — у сложных аварий их обычно несколько.
Что отличает хорошие действия
| Плохое действие | Хорошее действие |
|---|---|
| «Быть внимательнее» | «Добавить алерт на насыщение пула БД» |
| Без ответственного | Назначен владелец и срок |
| Без приоритета | P1/P2 и понятный дедлайн |
Как enterno.io помогает с постмортемом
Точный таймлайн начинается с точных данных. enterno.io как внешний (synthetic) мониторинг сайтов фиксирует момент начала и конца недоступности, коды ответов и время реакции — это основа раздела «таймлайн». Проверки HTTP, SSL, Ping и DNS идут каждую минуту или раз в 30 секунд, мультирегионально из России, Европы и США, а инциденты автоматически создаются и закрываются.
История на мониторах и публичная статус-страница дают объективные временные метки. Для контроля фоновых задач используйте heartbeat. Связку с реакцией см. в плане реагирования.
Частые вопросы
Кто должен писать постмортем?
Обычно инцидент-менеджер или дежурный, но вклад дают все участники. Документ принадлежит команде, а не одному человеку.
Как быстро после инцидента писать разбор?
В течение 1–3 дней, пока детали свежи. Затягивание ведёт к потере фактов и точности таймлайна.
Нужно ли публиковать постмортемы наружу?
Для крупных публичных инцидентов — да, краткую версию для клиентов. Внутренний полный разбор остаётся для команды.
Что делать с действиями после постмортема?
Заводить их как задачи с владельцем, приоритетом и сроком, и проверять выполнение. Постмортем без выполненных действий бесполезен.
Соберите точный таймлайн инцидента. Подключите мониторы enterno.io, чтобы каждый сбой имел объективные временные метки для разбора.