Как писать постмортем: структура, готовый шаблон и типичные ошибки

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

Ниже — что писать в каждом разделе, готовый шаблон в markdown и ошибки, из-за которых разбор превращается в отписку. Структура собрана по трём открытым источникам: главе о постмортемах в книге Google SRE, справочнику Atlassian по инцидентам и документации PagerDuty. Шаблоны у них разные, а суть одна.

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

Критерии договариваются заранее, до инцидента. Иначе после каждого сбоя начинается спор, «достаточно ли он большой». В книге Google SRE типичные поводы такие:

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

Кроме того, разбор вправе попросить любой, кого инцидент касается. В Atlassian постмортем обязателен для инцидентов первого и второго уровня, для остальных — по желанию команды.

Писать нужно, пока детали свежие. В PagerDuty встречу по разбору назначают не позже чем через три календарных дня для SEV-1 и через пять рабочих дней для SEV-2, и к встрече документ уже заполнен.

Структура постмортема

В примере постмортема из книги Google есть ещё отдельные поля «Триггер», «Обнаружение» и «Устранение». У Atlassian — «Предыстория», «Проверка бэклога» и «Повторялось ли раньше». Эти вопросы стоит задать в любом случае, даже если отдельного раздела под них нет.

Резюме

Два-три предложения для руководителя и соседних команд: что сломалось, сколько длилось, какую долю пользователей задело, что стало триггером и как восстановили сервис. В примере из книги Google резюме укладывается в одну строку: поиск по Шекспиру лежал 66 минут на пике интереса к только что найденному сонету.

Резюме пишут последним, когда остальные разделы готовы.

Влияние

Здесь нужны цифры, а не прилагательные: сколько минут длилось влияние, какая доля запросов или пользователей пострадала, сколько заказов, платежей или сообщений потеряно, сколько обращений пришло в поддержку. Шаблон PagerDuty прямо требует точных чисел: время в SEV-1 и SEV-2, затронутые аккаунты и пользователи, обращения в поддержку. В примере Google влияние — одна строка: около 1,21 млрд потерянных запросов, на выручку не повлияло.

Длительность считают от начала влияния, а не от момента, когда его заметили: пользователи страдали и до алерта. Если у сервиса есть SLO, напишите, какую долю бюджета ошибок съел инцидент, — так его вес понятен без споров. Как считать бюджет, разобрано в статье про SLI, SLO и бюджет ошибок.

Хронология

Хронология — это факты по времени, без оценок. Правила из практики PagerDuty и Atlassian:

• одно время для всех записей, лучше UTC: участники могут сидеть в разных часовых поясах;
• начинайте с событий до инцидента, например с выкатки, которая внесла ошибку, и двигайтесь вперёд, а не назад от момента починки — так меньше соблазн задним числом решить, что всё было очевидно;
• отметьте начало влияния, обнаружение, эскалации, решения и конец влияния;
• у каждой записи — источник: ссылка на график, поиск по логам, сообщение в канале инцидента.

Собирать хронологию проще, если во время инцидента кто-то вёл заметки. Если никто не вёл — поднимайте историю чата, алертов и деплоев.

Причины

Разделите триггер и причины. Триггер — событие, которое запустило сбой: выкатка, истёкший сертификат, всплеск трафика. Причины — условия, которые позволили триггеру стать инцидентом: не было проверки, алерта, ограничения или отката.

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

Как до неё добраться:

• Задавайте «почему?» от влияния вглубь — метод «пять почему». Живой пример такой цепочки есть в постмортеме GitLab, который мы разобрали в статье о сбое GitLab 2017.
• Ищите не одну причину, а несколько. PagerDuty ссылается на работу Ричарда Кука «How Complex Systems Fail»: крупный сбой складывается из нескольких факторов, и «единственная корневая причина» — упрощение.
• Действие человека не бывает корневой причиной. Если инженер ввёл не ту команду, вопрос в том, почему система позволила ей выполниться. Подробнее — в статье о blameless-постмортемах.
• Проверьте бэклог: была ли там задача, которая предотвратила бы инцидент, и почему её не сделали. И посмотрите, не было ли раньше инцидентов с той же причиной.

Что сработало, что нет и где повезло

Этот раздел в шаблоне Google состоит из трёх вопросов. «Сработало» — то, что стоит сохранить: быстрый алерт, отрепетированный откат. «Не сработало» — то, что тормозило: не было доступа, runbook устарел, алерт ушёл не той команде. «Где повезло» — самый недооценённый пункт. Если сервис спасла случайность, это риск, который в следующий раз может не сработать. У GitLab в 2017 году базу подняли из снимка, который инженер за шесть часов до удаления сделал для staging, а не как бэкап.

Отдельно разберите обнаружение. Atlassian предлагает мысленный эксперимент: как сократить время до обнаружения вдвое?

Задачи

Ради задач постмортем и пишут. У каждой — глагол, владелец, срок и ссылка на тикет. Google помечает тип задачи: смягчить последствия, предотвратить повтор, изменить процесс. Atlassian делит задачи на приоритетные, которые устраняют корневую причину, и улучшения. У приоритетных есть согласованный срок — 4 или 8 недель в зависимости от сервиса.

Формулировка задачи должна начинаться с действия, иметь узкие рамки и понятный признак готовности. Этот принцип описали инженеры Google Джон Ланни, Сью Люедер и Бетси Бейер в статье «Postmortem Action Items: Plan the Work and Work the Plan», на неё ссылаются и Atlassian, и PagerDuty.

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

Шаблон постмортема

Скопируйте и подстройте под свою команду. Текст в угловых скобках — подсказки, строки в таблицах — пример заполнения.

# Постмортем: <короткое название инцидента>

- Дата инцидента: <ГГГГ-ММ-ДД>
- Уровень: <SEV-1 / SEV-2 / ...>
- Статус: черновик | на ревью | утверждён
- Владелец постмортема: <кто доводит документ до конца>
- Участники: <дежурный, командир инцидента, владельцы затронутых сервисов>

## Резюме
<2–3 предложения: что сломалось, сколько длилось, кого задело,
что стало триггером, как восстановили.>

## Влияние
- Длительность влияния: <с чч:мм по чч:мм UTC, всего N минут>
- Кого задело: <доля пользователей, запросов или клиентов>
- Ошибки: <число или доля неуспешных запросов>
- Бизнес: <заказы, платежи, деньги, штрафы по SLA>
- Обращения в поддержку: <число>
- Бюджет ошибок: <какую долю бюджета SLO за период съел инцидент>

## Хронология (UTC)
| Время | Событие | Источник |
|---|---|---|
| 13:40 | Выкатка версии 2.14 | ссылка на пайплайн |
| 14:02 | Начало влияния: доля 5xx выросла до 12% | ссылка на график |
| 14:09 | Алерт, дежурный подтвердил и открыл инцидент | ссылка на алерт |
| 14:31 | Решение откатить 2.14 | сообщение в канале инцидента |
| 14:49 | Доля ошибок вернулась к норме, конец влияния | ссылка на график |

## Обнаружение
<Как узнали: алерт, жалоба, коллега? Сколько прошло от начала влияния
до обнаружения? Как сократить это время вдвое?>

## Причины
- Триггер: <событие, которое запустило инцидент>
- Причины и способствующие факторы: <условия, которые позволили
  триггеру стать инцидентом>
- Пять почему: <цепочка или дерево>
- Проверка бэклога: <была ли задача, которая предотвратила бы инцидент?
  Почему её не сделали?>
- Повторения: <были ли инциденты с той же причиной?>

## Устранение
<Что сделали, чтобы вернуть сервис. Это временное решение или окончательное?>

## Что сработало и что нет
- Сработало: <...>
- Не сработало: <...>
- Где повезло: <...>

## Задачи
| Задача | Тип | Владелец | Срок | Тикет |
|---|---|---|---|---|
| Добавить алерт на долю 5xx выше 2% за 5 минут | обнаружение | <имя> | <дата> | <ссылка> |
| Добавить в пайплайн smoke-тест оплаты после выкатки | предотвращение | <имя> | <дата> | <ссылка> |
| Описать в runbook откат checkout одной командой | процесс | <имя> | <дата> | <ссылка> |

## Приложения
<Графики, запросы к логам, ссылка на канал инцидента.>

Как провести разбор

1. Черновик пишет владелец постмортема, остальные дополняют. Google ведёт постмортемы в общих документах с комментариями, чтобы факты и идеи собирались сразу от всех участников.
2. Документ рассылают заранее. В PagerDuty — минимум за 24 часа до встречи, чтобы на ней не читать текст вслух.
3. Встреча идёт по повестке. У Atlassian она такая: напомнить, что разбор без поиска виноватых и зачем это нужно; сверить хронологию; сверить причины; придумать задачи вопросом «что сделать, чтобы такой класс инцидентов не повторился?»; обсудить, что сработало, что можно было сделать лучше и где повезло.
4. Итог встречи — согласованные задачи. Руководители команд подтверждают, что возьмут их в работу, иначе список останется списком.
5. Постмортем проходит ревью и публикуется. В Google принцип звучит как «ни одного постмортема без ревью». Ревьюер проверяет, собраны ли данные, полно ли описано влияние, достаточно ли глубоко копнули причину, подходят ли задачи и их приоритеты и узнали ли о выводах все, кого это касается.

Типичные ошибки

• «Причина — человеческий фактор». Разбор на этом заканчивается, а система остаётся прежней. Следующий человек ошибётся так же.
• Влияние без цифр. «Часть пользователей испытывала трудности» — не влияние. Нужно сколько, как долго и что потеряли.
• Хронология по памяти. Без источников, в разных часовых поясах, с оценками вроде «дежурный долго думал» вместо фактов.
• Остановились на триггере. «Истёк сертификат» — это триггер. Причина — почему истечение никто не заметил за месяц и почему не было алерта.
• Задачи без владельца и срока. «Улучшить мониторинг» не закроется никогда: непонятно, когда оно готово.
• Двадцать задач вместо пяти. Длинный список размазывает внимание, и важное тонет среди «хорошо бы».
• Постмортем через месяц. Детали забыты, чат пролистан, логи ротированы.
• Постмортем как наказание. Если после разбора кого-то наказывают, в следующий раз о проблемах промолчат. В книге Google SRE это сказано прямо: постмортем — не наказание, а способ научиться для всей компании.
• Разбор, который никто не читает. Без ревью и публикации выводы остаются у трёх человек, а задачи тихо умирают в бэклоге.

Как натренировать навык

Писать постмортемы учатся на постмортемах, а инциденты на реальной работе, к счастью, случаются не каждую неделю. Начните с чужих: разберите по своему шаблону публичный отчёт GitLab, Atlassian или CrowdStrike (пример — разбор сбоя CrowdStrike 2024) и сравните, что вы нашли сами, а что пропустили. Если вы только готовитесь к первому дежурству, это лучшая подготовка к разбору собственного инцидента.

В симуляторе DevOps KAI Lab каждый из девяти месяцев заканчивается постмортемом: команда собрала факты об инциденте, вы пишете разбор, а потом сверяете его с эталоном мидла по чек-листу. Первые задания первого месяца открыты бесплатно — начать можно здесь.

Частые вопросы

Чем постмортем отличается от отчёта об инциденте? Отчёт отвечает на вопрос «что произошло». Постмортем идёт дальше: почему система это допустила и что изменится. Без раздела с задачами это отчёт, а не постмортем.

Кто пишет постмортем? Один владелец, который отвечает за то, чтобы документ дописали, обсудили на встрече и провели через ревью. В Atlassian его выбирает команда, чей сервис отказал, в PagerDuty — командир инцидента из числа участников. Пишут при этом вместе: каждый добавляет свои факты.

Нужен ли постмортем для мелкого инцидента? Если инцидент попадает под ваши критерии — да. Особенно стоит разбирать случаи, когда мониторинг промолчал и о проблеме узнали от пользователей, и «почти аварии», где просто повезло. Для мелких инцидентов хватит короткой версии шаблона.

Можно ли показывать постмортем клиентам? Можно и полезно, но отдельной версией. PagerDuty делает внешний текст из трёх частей: краткое резюме, что произошло и что компания делает, — без внутренних деталей. Публичные разборы выпускают GitLab, Atlassian, CrowdStrike, Cloudflare.

Что делать, если задачи из постмортема не выполняются? Сделать их видимыми: тикеты в бэклоге команды-владельца, сроки и регулярный отчёт по незакрытым. В Atlassian у приоритетных задач есть срок, напоминания и отчёты, а сам постмортем утверждают руководители, которые берут задачи в свой бэклог.

Источники

• Google. Site Reliability Engineering, глава 15: Postmortem Culture: Learning from Failure — поводы для постмортема, разбор без поиска виноватых, ревью.
• Google. Site Reliability Engineering, приложение D: Example Postmortem — структура и пример заполненного постмортема.
• Atlassian. Incident Management Handbook: Postmortems — процесс, повестка встречи, непосредственная и корневая причина, формулировки задач, сроки приоритетных задач.
• Atlassian. Incident postmortem template — шаблон с разделами и примерами.
• PagerDuty. The Postmortem Process — хронология, анализ, задачи, ревью, сроки встречи.
• PagerDuty. Postmortem Template и The Postmortem Meeting.
• J. Lunney, S. Lueder, B. Beyer. Postmortem Action Items: Plan the Work and Work the Plan, ;login:, весна 2017 — принципы формулировки задач (по пересказу Atlassian и PagerDuty).