Шаблон постмортема, по которому мы разбираем инциденты

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

Главное правило: blameless

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

Структура шаблона

1. Summary: 2–3 предложения о том, что произошло, для нетехнического читателя.
2. Impact: какие пользователи и как пострадали, длительность, количественная оценка (потерянная выручка, заблокированные транзакции).
3. Timeline: минута за минутой, от первого алерта до полного восстановления. Без интерпретаций - только факты.
4. Root cause analysis: 5 whys или fishbone - что фундаментально привело к проблеме.
5. Contributing factors: что усугубило, замедлило обнаружение или фикс.
6. What went well: что сработало в реакции (важно - без иронии).
7. Action items: конкретные задачи с ответственными и сроками.
8. Lessons: что мы узнали об архитектуре/процессах, что не зависело от конкретного инцидента.

Что часто упускают

• Action items без owner и срока - гарантированно не выполнятся.
• Слишком много action items (>7) - половина утонет. Лучше 3–4 серьёзных.
• Отсутствие «what went well» - команда теряет мотивацию писать постмортемы вообще.
• Постмортем без распространения - должен быть прочитан всей инженерной командой, а не только участниками инцидента.

Триггеры для постмортема

Не каждый инцидент требует постмортема. Мы пишем его при: SEV1/SEV2 (полный или частичный отказ для пользователей), любом инциденте с потерей данных, любом security-event, и при near-miss - когда чудом не упало.