Postmortem

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

Что такое postmortem и зачем он нужен

Определение и быстрые вводные

Postmortem — это структурированная встреча и документ после инцидента, релиза или сбоя в продукте. Цель: понять, что произошло, почему, как избежать повторения. Часто встречается в разработке, операциях, службах поддержки за пределами IT. Итог — не поиск виноватых, а улучшение процессов и общая безопасность продукта.

Почему это важно в работе продукта

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

Пример: после сбоя в подписках SaaS-сервиса команда собирает postmortem: фиксирует, где был сбой (например, ошибка в интеграции платежек), находит причину (недокументированный API-изменение), предлагает контрмеры (механизмы мониторинга, улучшение документации).

Классический шаблон postmortem

Базовая структура документа

В практике выделяют короткую и расширенную форму postmortem-документа. Минимально структура такая:

1. Краткое описание инцидента
2. Дата и время события
3. Влияние: кого затронуло, как проявилось
4. Детальный разбор причин
5. Итоговые действия: что сделано для устранения
6. Предложения по предотвращению
7. Ответственные и сроки
8. Открытые вопросы

Пример структуры (адаптируй под свою команду)

1. Инцидент: массовый откат оплаты 3 марта, недоступность клиентского кабинета
2. Когда: 3.03.2024, с 13:20 до 14:40
3. Влияние: 15% пользователей не смогли войти, рост обращений в поддержку
4. Причина: merge некорректного фикса без тестов
5. Действия: ручное восстановление платежей, обратная связь клиентам
6. Предотвращение: обязательные тесты в CI, чек-лист релиза
7. Ответственные: команда back-end, сроки внесения изменений до 7.03

Подробнее о шаблонах postmortem (Atlassian)

Чек-лист для качественного postmortem

Перед postmortem

1. Зафиксируй факты в хронологическом порядке без оценок
2. Подключи всех, кто был вовлечен
3. Собери логи, метрики, записи чатов
4. Сформулируй, что случилось с позиции пользователя и бизнеса

Во время обсуждения

1. Говори по фактам, избегай обвинений
2. Проверяй все гипотезы на источниках: код, логи, документация
3. Записывай каждый шаг: что, когда, кто, почему
4. Подмечай, что сработало хорошо — лучшие находки стоит закрепить

После postmortem

1. Зафиксируй итоги, сделай короткий summary
2. Назначь ответственных за изменения
3. Сделай публичный выводы, если это политика вашей компании
4. Добавь пост-аналитические задачи в трекер

Подробный чек-лист и готовые формы (SRE Google)

Типовые ошибки и антипаттерны проведения postmortem

Главные ошибки

1. Оценочные суждения и поиск виноватых
2. Размытые действия типа “повысить ответственность”
3. Недостаток конкретики: нет даты исправления или ответственного
4. Проведение ради галочки — документ уходит в стол, не применяется
5. Отсутствие обмена итогами с командой

Пример антипаттерна: после падения сервиса команда пишет общие формулировки без конкретики: “улучшить тестирование”, “быть внимательнее”, но не выделяет времени или ресурсов на реальную работу.

Как внедрять postmortem-культуру в команде

Минимальные шаги

1. Покажи выгоду для команды: повышение прозрачности, меньше повторов ошибок
2. Дай удобный шаблон, сохраняй постморты в общем доступе
3. Делай короткие встречи сразу после инцидента (до 1 дня)
4. Поощряй открытость: публично разбирай свои ошибки первым
5. Начинай с малого: шаблон, чек-лист — и постепенно расширяй практику

Пример внедрения

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

FAQ по postmortem

Когда считать инцидент достойным postmortem?
Если затронуто значимое число пользователей, нарушены SLA, был финансовый или репутационный ущерб. В команде можно установить минимальные критерии.

Кто должен участвовать в postmortem?
Те, кто был вовлечен в инцидент, а также представители смежных функций (разработка, поддержка, продукт).

Нужно ли делиться результатами postmortem публично?
Не всегда, но внутри команды обязательно. В крупных сервисах часто делятся с клиентами — повышает доверие.

Как не скатиться в поиск виноватых?
Фокусируйся на процессе, а не на персоналиях. Пиши формулировки: не человек совершил ошибку, а процесс не защитил от ошибки.

Сколько занимает подготовка postmortem?
В среднем 1-2 часа плюс встреча, если заранее собрать факты.

Как отследить, что меры из postmortem реализованы?
Вноси задачи в трекер, устанавливай дедлайны, проверяй статус на ретро.