Blameless Postmortem

Лист — про ритуал: что команда делает на встрече, в каком порядке, с какими артефактами. Норма (почему вообще разбираем blameless, психологическая безопасность, факторы вклада вместо корневой причины) — в соседнем листе Postmortem Culture. Я регулярно вижу команды, в которых первое (ритуал, шаблон) есть, а второго (норма) нет — формальный шаблон без культурной поддержки даёт blameless-театр, и любой реальный конфликт интересов его ломает. Оба листа читаются вместе.

Что должен уметь

Главный навык на уровне L5 — формулировать action items с критерием готовности, а не «улучшить мониторинг». Я регулярно вижу постмортемы, в которых через полгода никто не помнит, что имелось в виду под «улучшить мониторинг» — потому что не было «как мы поймём, что это сделано». Action item без четырёх атрибутов (владелец, дедлайн, приоритет, критерий) — это «доброе пожелание», и через два-три невыполненных списка команда теряет доверие к ритуалу.

Участвует в постмортеме как источник фактов: описывает свои действия в хронологии без интерпретаций; не задаёт вопросов «кто это сделал».
Читает чужие постмортемы и понимает структуру: summary, timeline, impact, factor analysis, action items, lessons learned.

Пишет документ по шаблону: хронология с отметками времени по событиям и решениям, влияние на пользователей, факторы вклада, action items с метаданными.
Собирает хронологию из разных источников (логи, алерты, графики, треды в Slack, голосовые звонки) и сводит в один связный рассказ, разделяя «что произошло» и «что решили».

Ведёт встречу разбора: распределяет роли (кто пишет, кто ведёт, кто ревьюит), удерживает тон blameless, помогает формулировать корректные action items.
Формулирует action items с владельцем, дедлайном, приоритетом и критерием готовности; защищает от пустых формулировок типа «улучшить мониторинг».
Проводит follow-up через 2–4 недели после публикации постмортема: проверяет статус, обновляет документ; невыполненные пункты возвращаются в приоритеты с явным решением.

L6+

Внедряет процесс разбора в организации: шаблоны, платформа, сортировка по severity, метрики (доля закрытых задач, срок от инцидента до готового документа).
Защищает тон blameless от давления «найти виноватого» сверху; ведёт переговоры с руководством, юристами и комплаенсом.

Материалы

Книги

Betsy Beyer et al. — Site Reliability Engineering (O’Reilly, 2016), глава 15. Фундамент ритуала и канонический шаблон постмортема.
Betsy Beyer et al. — The Site Reliability Workbook (O’Reilly, 2018), глава 10. Разбор плохого и хорошего постмортема на одном реальном инциденте.

Статьи и доклады

John Allspaw — Blameless PostMortems and a Just Culture (Etsy, 2012). Классическая статья, заложившая словарь.
PagerDuty — Postmortems. Открытый набор руководств по проведению постмортема: культурная рамка, написание документа, ведение встречи, чеклисты. Лицензия Apache 2.0 — можно брать и адаптировать под себя.
Cloudflare incident reports. Регулярные публичные постмортемы — эталон, на который многие команды ориентируются.

Инструменты

Шаблоны — Google SRE Example Postmortem (реальный шаблон Google), PagerDuty Postmortem Template, dastergon/postmortem-templates (агрегированная коллекция).
Markdown в репозитории команды — самый простой формат: один постмортем — один файл в postmortems/<YYYY-MM-DD>-<slug>.md. По моим наблюдениям, для команды до десяти постмортемов в месяц этого достаточно.
Платформы — incident.io, FireHydrant. Автоматический сбор хронологии из Slack и алертов, конспект от модели, ведение ретро. Полезны, когда команда выходит за десяток постмортемов в месяц.

Best practices

Три вещи держат весь ритуал, и первая — чистота timeline. Там только факты. «X не справился с нагрузкой в 14:23» — уже интерпретация, хотя выглядит как наблюдение; фактом будет «в 14:23 сервис вернул 503 при такой-то нагрузке». Всё, что похоже на объяснение, уезжает в factor analysis, где рядом стоит честное «почему мы так думаем».

Вторая — форма action item: владелец, дедлайн, приоритет, критерий готовности. Без всех четырёх это доброе пожелание. «Улучшить мониторинг» через полгода не расшифрует даже тот, кто это написал, а после двух-трёх невыполненных списков команда перестаёт верить в сам ритуал.

Третья — тон. Постмортем существует для обучения, и если на встречу пришёл человек с настроением найти виноватого, остальные замыкаются и факты начинают прятаться. Фасилитатор такое останавливает сразу. Одна встреча с поиском виноватого рушит культуру быстрее, чем десять плохо написанных документов.

Постмортем пишется по горячим следам, не через месяц. «Дадим команде успокоиться» звучит гуманно, а на деле через две недели память уже подредактирована, треды в Slack не собрать, а ключевые участники переключились на другое. Норма такая: timeline собирается за 24–72 часа, встреча проходит в течение недели. Крупный инцидент может получить отсрочку, но с явным дедлайном. По моим наблюдениям, качество падает с задержкой очень быстро — на третьей неделе получается реконструкция, а не разбор.

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

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

Связанные листья

Postmortem Culture — норма, на которой держится ритуал; читать вместе. Этот лист — что делаем, родственный — почему так.
Incident Response — постмортем — разбор по следам инцидента; качество хронологии в нём прямо зависит от того, насколько аккуратно события фиксировали в моменте.
Runbooks — каждый постмортем должен порождать обновление runbook, иначе извлечённый урок нигде не закреплён.
SLO / Budget Review — постмортемы показывают, на что уходит бюджет ошибок; ревью — точка, где извлечённые уроки превращаются в приоритеты.
Service Ownership — владелец сервиса отвечает и за постмортем, и за его action items.
Action Items Tracking — соседняя практика: постмортем задачи порождает, action items tracking отвечает за их выполнение. Без второй половины цикл разорван.
Postmortem Database — куда отправляется готовый постмортем; схема тегов определяет, найдётся ли документ через год; регулярный разбор паттернов поверх базы — место, где урок одного инцидента становится знанием команды.

Открытые вопросы

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