Любая команда, которая занимается эксплуатацией продакшн-систем, рано или поздно сталкивается с инцидентами. База данных упала в пиковую нагрузку, деплой сломал критическую фичу, сеть отвалилась на пять минут -- все бегут тушить пожар. Проблему чинят, сервис восстанавливается, команда выдыхает и переключается на следующие задачи. Через месяц случается похожий инцидент. Потом ещё один. И команда понимает, что попала в "спираль инцидентов": время уходит на реактивное тушение, а не на развитие продукта.
Postmortem - это практика, которая помогает разорвать этот цикл. Это не просто "отчёт о происшествии", а структурированный процесс анализа инцидента с целью понять его причины и выработать конкретные действия, которые снизят вероятность или влияние повторения.
В этой статье разберём, что такое postmortem, зачем он нужен DevOps-командам, как его правильно проводить и почему blameless-подход важен для успеха.

Postmortem (или incident review) — это документированный разбор инцидента, который включает:

1. описание произошедшего;
2. временную шкалу событий;
3. анализ причин;
4. список действий для улучшения.

Главная цель постмортема не в том, чтобы найти виноватых или формально "закрыть отчёт", а в том, чтобы извлечь максимум пользы из неприятного опыта и сделать систему надёжнее.
Google в своих SRE-практиках описывает постмортем как ожидаемую часть жизненного цикла любого значимого инцидента. Не наказание, а возможность для организационного обучения. Команды, которые регулярно проводят качественные постмортемы, накапливают знания о слабых местах инфраструктуры, улучшают процессы реагирования и постепенно снижают частоту и серьёзность инцидентов.
Без постмортема команда теряет контекст: через несколько недель детали забываются, логи и метрики могут быть удалены по retention policy, а участники инцидента переключаются на другие проекты. В итоге при следующем похожем инциденте приходится заново "изобретать велосипед" вместо того, чтобы опираться на готовые выводы и улучшения.

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

• Инцидент затронул конечных пользователей
• Нарушены SLA или SLO
• Инцидент потребовал вовлечения on-call инженера или произошла эскалация
• Время восстановления превысило определённый порог (например, 30 минут)
• Инцидент повторяется или имеет неочевидную причину, которую важно задокументировать

Blameless подход — это фундамент эффективного постмортема. Суть в том, что фокус смещается с вопроса "кто виноват?" на вопрос "что в системе и процессах позволило этому случиться?".
Люди совершают ошибки — это нормально, особенно в сложных распределённых системах, где причинно-следственные связи неочевидны, а давление времени высоко. Если постмортем превращается в "охоту на ведьм", команда начинает скрывать проблемы, замалчивать детали и избегать честных обсуждений.

• Blameless-подход не означает "никто не несёт ответственности". Он означает, что ответственность смещается с индивидуального наказания на улучшение системы. Вместо "Вася ошибся в команде и уронил прод" правильная формулировка: "Команда для удаления тестовых данных выполняется на продакшне без подтверждения и доступна всем инженерам — нужно добавить safeguard и ограничить доступ".

Эффективный постмортем — это не просто "написать документ". Это итеративный процесс, который включает несколько этапов. Рассмотрим основную последовательность шагов.

Шаг 1: Собрать данные и артефакты
Сразу после устранения инцидента важно зафиксировать всё, что может понадобиться для анализа:

• логи;
• метрики;
• скриншоты дашбордов;
• переписку в Slack/Teams;
• коммиты и конфигурации, которые менялись во время инцидента.

Чем быстрее это сделать, тем меньше риск, что данные будут удалены или забыты.
Шаг 2: Восстановить хронологию (timeline)
Timeline — это детальная временная шкала событий:

• когда началась проблема;
• когда её заметили;
• какие действия предпринимали;
• какие гипотезы проверяли, когда восстановились.

Хронология помогает синхронизировать понимание между участниками и выявить "узкие места" в реагировании (например, алерт сработал через 10 минут после начала проблемы, или команда потратила час на проверку неверной гипотезы).
Шаг 3: Провести встречу или асинхронный разбор
В зависимости от сложности инцидента можно провести синхронную встречу (postmortem meeting) с участием всех вовлечённых сторон или организовать асинхронный разбор в документе с возможностью комментариев. Цель встречи — не "отчитаться", а коллективно разобрать причины, обсудить гипотезы и согласовать действия.​
Шаг 4: Разобрать root cause и contributing factors
Root cause — это непосредственный триггер инцидента (например, "деплой новой версии с багом в SQL-запросе"). Но почти всегда есть contributing factors. Условия, которые усилили проблему или замедлили восстановление. Важно зафиксировать и то, и другое, потому что работа с contributing factors часто даёт больший эффект, чем "заплатка" на конкретный баг.
Шаг 5: Определить action items
Action items — это конкретные задачи, которые снизят вероятность повторения инцидента или уменьшат его влияние. Каждое действие должно иметь владельца, срок и приоритет. Примеры хороших action items:

• Добавить алерт на рост latency 95-го перцентиля для API /checkout (владелец: Иван, срок: 2 недели, P1)
• Внедрить canary deployment для микросервиса payments (владелец: команда Platform, срок: месяц, P0)
• Провести ретроспективу процесса on-call эскалации и обновить runbook (владелец: SRE-тима, срок: неделя, P2)

Слабое место многих постмортемов — это "красивый документ", после которого ничего не меняется. Поэтому важно не только записать действия, но и регулярно отслеживать их выполнение, например, в отдельном Jira-борде.
Шаг 6: Опубликовать и распространить знания

• Постмортем нужно сохранить в доступном месте (wiki, Confluence, Google Docs) и поделиться с командами, которых он может касаться. В некоторых компаниях практикуется публикация "обезличенных" версий постмортемов в общедоступных каналах или даже в блогах — это повышает прозрачность и культуру обучения.

Структура постмортем-документа может варьироваться, но есть типичный набор секций, который покрывает всё необходимое:

1. Краткое резюме (Summary) одно-два предложения — что произошло, какие сервисы затронуло, сколько длилось.
2. Влияние (Impact) кого и как затронуло (количество пользователей, процент трафика, потери в деньгах/репутации), какие метрики нарушены (SLA/SLO).
3. Детект и реакция (Detection and Response) как обнаружили проблему (автоматический алерт, жалоба клиента, ручная проверка), как объявили инцидент, кто подключился к разбору.
4. Хронология (Timeline) детальный таймлайн с UTC/MSK временем: когда началось, когда заметили, какие действия предпринимали, когда восстановились.
5. Причины (Root Cause and Contributing Factors) что стало триггером и какие системные факторы помогли инциденту разрастись.
6. Что сработало / что не сработало (What Went Well / What Went Wrong) полезно выделить, что помогло команде быстро среагировать (например, наличие актуального runbook), и где были потери времени (например, отсутствие прав доступа у дежурного инженера).
7. Действия (Action Items) список задач с владельцами, сроками и приоритетами.
8. Дополнительные материалы (Appendix) графики, ссылки на логи, коммиты, конфигурации.

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

1. Ключевые принципы успешного постмортема: blameless-подход, фокус на системных причинах, конкретные action items с владельцами и сроками, и регулярный контроль выполнения. Если команда последовательно применяет эти практики, количество и серьёзность инцидентов со временем снижаются, а доверие внутри команды растёт.​