Постмортем инцидента: как разобрать аварию так, чтобы она не повторилась

Зачем вообще нужен постмортем

После инцидента команда обычно чувствует облегчение: сервис поднят, пользователи успокоились, бизнес перестал писать в чат. Соблазн закрыть тикет и двигаться дальше очень велик. Именно здесь большинство команд теряют главную ценность - возможность разобраться, что произошло, пока детали свежи.

Постмортем инцидента - это не отчет для руководства и не способ кого-то наказать. Это инструмент, который помогает системе стать лучше. Google SRE называет этот процесс одним из ключевых механизмов повышения надежности: без честного разбора одни и те же проблемы возвращаются снова.

Если команда не разбирает инциденты, она работает в режиме реакции. Каждый следующий сбой - сюрприз. Постмортем переводит команду в режим обучения: каждый инцидент становится данными, а не просто болью.

Когда писать постмортем

Не каждый алерт требует полного разбора. Но есть признаки, при которых постмортем нужен почти всегда:

• Инцидент затронул пользователей или бизнес-процессы
• Восстановление заняло больше 30 минут
• Команда не сразу поняла причину
• Сработало несколько алертов одновременно
• Инцидент повторился второй или третий раз
• Пришлось делать ручные действия в продакшене под давлением

Небольшие инциденты с неочевидной причиной тоже стоит разбирать - даже если они не вызвали видимого ущерба. Именно такие случаи часто предвещают более серьезный сбой.

Структура постмортема: что должно быть внутри

Хороший документ не должен быть длинным. Важна не объемность, а точность. Вот стандартные блоки, которые работают на практике.

Краткое описание

2-3 предложения: что случилось, когда, как долго, что пострадало. Этот блок читают те, кому не нужны детали, но нужно понять масштаб.

Пример: «19 марта с 14:23 до 16:47 API оформления заказов возвращал 503. Пострадало около 12% пользователей в пиковое время. Причина - исчерпание пула соединений к базе данных после деплоя новой версии сервиса.»

Таймлайн

Хронология событий с временными метками. Это самый важный блок для понимания того, как развивался инцидент. Таймлайн помогает увидеть, где была задержка в обнаружении, где потеряли время при диагностике, где сработало или не сработало автоматическое восстановление.

Таймлайн не нужно делать красивым. Достаточно простого списка:

• 14:23 - первые 503 в логах
• 14:31 - алерт по error rate, дежурный получил уведомление
• 14:45 - начало диагностики, подключился второй инженер
• 15:10 - идентифицирована проблема с пулом соединений
• 15:40 - применен временный фикс, трафик восстановлен частично
• 16:47 - полное восстановление после перезапуска сервиса

Влияние

Конкретные цифры: сколько пользователей пострадало, какие функции были недоступны, какой бизнес-процесс остановился. Если есть данные по потерянным транзакциям или SLO - добавить их сюда.

Не нужно преуменьшать. Честная оценка влияния помогает правильно расставить приоритеты для исправлений.

Корневые причины

Это самый сложный блок. Корневая причина - не «база упала» и не «кто-то задеплоил не то». Это системная проблема, которая сделала инцидент возможным.

Хороший способ найти корневую причину - метод «5 почему». Задавать вопрос «почему это произошло» несколько раз подряд, пока не дойдешь до чего-то, что можно реально исправить.

Что сработало хорошо

Этот блок часто пропускают, но он важен. Он показывает, что в системе работает: алерты сработали вовремя, дежурный среагировал быстро, runbook помог сократить время диагностики. Это мотивирует команду и помогает понять, что не нужно менять.

Что можно было сделать лучше

Честный ответ на вопрос: где мы потеряли время, где не хватало информации, где процесс подвел. Не список обвинений, а список системных пробелов.

Action items

Конкретные задачи с владельцем и дедлайном. Это единственное, что превращает постмортем из документа в изменение.

Blame-free культура: почему это не просто слова

Постмортем без blame-free подхода не работает. Если люди боятся, что их накажут за честный разбор, они будут писать безопасные тексты. «Произошел технический сбой, команда оперативно устранила проблему» - это не постмортем, это PR-текст.

Blame-free не означает, что все действия равнозначны. Это означает, что цель разбора - понять систему, а не найти виноватого человека. Люди делают ошибки в контексте: под давлением, с неполной информацией, в условиях плохих инструментов или непонятных процессов. Постмортем должен разбирать этот контекст.

Практически это выглядит так: вместо «инженер X задеплоил без проверки» пишут «деплой прошел без автоматической проверки конфигурации, потому что такой проверки не существовало». Первая формулировка указывает на человека, вторая - на системную проблему, которую можно исправить.

Как проводить встречу по постмортему

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

Несколько правил для эффективной встречи:

• Встреча не для поиска виноватых. Это нужно сказать явно в начале.
• Фасилитатор - отдельная роль. Лучше, если это не тот, кто был дежурным во время инцидента.
• Черновик документа готовится до встречи. Встреча дополняет и уточняет, а не пишет с нуля.
• Встреча не должна длиться больше часа. Если не укладываетесь - значит, слишком много участников или слишком широкий охват.
• Action items фиксируются прямо на встрече с конкретным владельцем.

Типичные ошибки при написании постмортема

Большинство проблем с постмортемами повторяются из раза в раз. Вот самые частые:

Как следить за выполнением action items

Постмортем без выполненных задач - это документ ради документа. Самая частая причина, по которой команды теряют доверие к этому процессу: action items пишут, но не выполняют.

Несколько подходов, которые работают:

Трекинг в той же системе, что и обычные задачи. Если action items живут только в документе постмортема, их легко забыть. Лучше сразу создавать тикеты в Jira, Linear или GitHub Issues.

Ревью на следующей встрече команды. Раз в неделю или раз в две недели - короткая проверка: какие задачи из постмортемов закрыты, какие застряли, что нужно разблокировать.

Метрика закрытия action items. Некоторые SRE-команды отслеживают процент выполненных задач из постмортемов как один из показателей здоровья процесса. Если он ниже 70% - что-то идет не так.

Шаблон постмортема: минимальная рабочая версия

Не нужно изобретать сложную структуру. Вот минимальный шаблон, который работает для большинства команд:

1. Краткое описание - что, когда, сколько длилось, что пострадало
2. Таймлайн - хронология с временными метками
3. Влияние - пользователи, функции, метрики SLO
4. Корневые причины - системные, не человеческие
5. Что сработало хорошо
6. Что можно улучшить
7. Action items - задача, владелец, срок

Этот шаблон можно расширять: добавлять раздел с диаграммой архитектуры, ссылки на дашборды, скриншоты из логов. Но даже в минимальном виде он дает команде всё необходимое для обучения.

Постмортем и SLO: как они связаны

Если команда уже работает с SLO и error budget, постмортем становится частью этой системы. Каждый инцидент, который сжег часть error budget, должен иметь постмортем. Это помогает принимать решения: стоит ли замедлить релизы, нужно ли инвестировать в надежность прямо сейчас.

В постмортеме стоит явно указывать, сколько error budget было потрачено на инцидент. Это переводит разговор с «у нас было падение» на «мы потратили 23% месячного бюджета на один инцидент - нужно разобраться, почему».

Чеклист: постмортем готов к публикации

• Краткое описание написано так, что его поймет человек без контекста
• Таймлайн содержит временные метки и охватывает весь инцидент - от первого сигнала до восстановления
• Влияние описано в цифрах, а не общими словами
• Корневая причина - системная, не «человеческая ошибка»
• Есть блок «что сработало хорошо» с конкретными примерами
• Каждый action item имеет владельца и срок
• Action items созданы как тикеты в трекере задач
• В документе нет имен людей рядом с описанием ошибок
• Документ написан в течение 48 часов после инцидента
• Постмортем доступен всей команде, а не только участникам инцидента

Как адаптировать постмортем под размер команды

Процесс постмортема, который работает в команде из 5 человек, может не подойти для организации с несколькими продуктовыми командами. И наоборот: тяжелый корпоративный процесс убивает культуру разбора в небольшом стартапе.

Для маленьких команд (до 10 человек) постмортем часто существует как короткий документ в Notion или Confluence. Встреча не всегда нужна. Достаточно асинхронного разбора с комментариями и зафиксированными задачами. Главное требование: документ должен быть доступен всем, а не только тем, кто был дежурным.

В средних командах (10-50 человек) уже появляется смысл в выделенном фасилитаторе и шаблоне. Постмортемы стоит хранить в одном месте и периодически делать ретроспективу: какие инциденты повторялись, какие action items не были закрыты, есть ли паттерн в причинах.

В крупных организациях постмортемы часто становятся частью формального процесса управления инцидентами. Здесь важно не потерять суть за бюрократией: документ должен оставаться честным и практичным, а не превращаться в отчет для комитета.

Постмортем для внешней аудитории: когда и как делиться

Иногда постмортем нужно показать не только внутри команды. Крупные технологические компании публикуют публичные постмортемы после серьезных инцидентов. Это не просто PR-ход: публичный разбор восстанавливает доверие пользователей и партнеров лучше, чем молчание или общие извинения.

Внутренний и внешний постмортем - это разные документы. Внутренний содержит все детали: имена систем, конкретные метрики, технические подробности, честный разбор процесса. Внешний - это адаптированная версия для пользователей и клиентов.

Что стоит включить во внешний постмортем:

• Что произошло и когда, без технического жаргона
• Как это повлияло на пользователей
• Что команда сделала для восстановления
• Что будет сделано, чтобы это не повторилось

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

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

Как оценить качество постмортема

Не все постмортемы одинаково полезны. Документ может существовать формально, но не давать команде никакой ценности. Вот критерии, по которым можно оценить, насколько хорош конкретный разбор.

Если большинство постмортемов в команде попадают в колонку «слабый», это сигнал не о плохих инженерах, а о проблеме с культурой или процессом. Стоит разобраться, что мешает писать честно: страх последствий, нехватка времени или отсутствие шаблона.

FAQ

Что такое постмортем инцидента простыми словами?

Это документ, который команда пишет после сбоя, чтобы разобраться, что произошло и почему. Цель - не найти виноватого, а понять системные причины и исправить их так, чтобы похожий инцидент не повторился.

Чем постмортем отличается от RCA (Root Cause Analysis)?

RCA - это метод анализа, направленный на поиск корневой причины. Постмортем - это более широкий документ, который включает таймлайн, влияние, корневые причины, выводы и задачи на исправление. RCA часто является частью постмортема, но не заменяет его целиком.

Как быстро нужно писать постмортем?

Черновик стоит начинать в течение 24-48 часов после инцидента, пока детали свежи. Финальный документ обычно готовят в течение 3-5 рабочих дней. Если ждать неделю и больше, таймлайн становится неточным, а часть контекста теряется.

Нужен ли постмортем для небольших инцидентов?

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

Что делать, если action items из постмортема не выполняются?

Первый шаг - перенести задачи в обычный трекер команды, а не оставлять их только в документе. Второй - добавить ревью постмортем-задач в регулярные встречи. Если задачи системно не выполняются, это сигнал о проблеме с приоритетами или процессом, а не с постмортемами.

Как убедить команду писать постмортемы честно?

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

Сколько action items должно быть в постмортеме?

Обычно 3-7 пунктов. Меньше - значит, разбор был поверхностным. Больше - задачи размываются и не выполняются. Лучше выбрать 3-5 самых важных и довести их до конца, чем написать 15 пунктов и забыть о них.

Итог

Постмортем работает только тогда, когда команда относится к нему как к инструменту обучения, а не к формальности. Честный таймлайн, системные корневые причины и выполненные action items - вот три вещи, которые реально меняют надежность системы.

Культура постмортемов строится медленно. Первые документы будут неловкими, action items будут выполняться не все. Но каждый честно разобранный инцидент - это шаг к тому, чтобы следующий был менее болезненным. Именно это и отличает команды, которые растут, от тех, кто снова и снова наступает на одни и те же грабли.