Blameless Postmortem

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

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

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

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

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

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

L6+

Внедряет постмортем-process в организации: шаблоны, платформа, severity-based triage, метрики (action item completion rate, time-to-postmortem).
Защищает blameless-tone от давления «найти виноватого» сверху; ведёт переговоры с менеджментом / юристами / compliance.

Материалы

Книги

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

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

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

Инструменты

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

Best practices

Короткие правила:

Timeline — на фактах, не на интерпретациях. «X не справился с нагрузкой в 14:23» — уже интерпретация. Правильно: «в 14:23 сервис вернул 503; ответы на нагрузку с такой-то метрикой» — факт. Интерпретации идут в раздел factor analysis с явным «почему мы так думаем».
Action items — владелец + дедлайн + priority + критерий готовности. «Улучшить мониторинг» без указаний — через полгода никто не помнит, что имелось в виду. Action item без всех четырёх атрибутов — «доброе пожелание»; через 2–3 невыполненных списка команда теряет доверие.
Постмортем = обучение, не наказание. Если кто-то пришёл с настроением «найти виноватого», остальные замыкаются, факты прячутся. Фасилитатор обязан остановить или явно вернуть к blameless tone; одна такая встреча разрушает культуру быстрее десяти плохих постмортемов.

Подробнее:

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

Severity-based triage: не каждый инцидент равно глубокий постмортем. «Постмортем для всего» — путь к выгоранию и спаму. Лёгкие инциденты (короткие, без impact на пользователей) получают облегчённый retro (заметка в команде, 15-минутная синхронизация); полноценные постмортемы — для значимых инцидентов с явными критериями (длительность, impact, регуляторика). Без triage команда либо спамит документы, либо игнорирует процесс.

Один writer на постмортем, не «коллективно напишем». Ответственность размазана на всю команду → через две недели документ пустой. Один человек владеет writeup и его дедлайном; команда вносит правки через PR/comments. Без owner постмортем не пишется — это эмпирическое наблюдение, которое подтверждается на каждой второй встрече.

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

Postmortem Culture — норма, на которой держится ритуал; читать вместе. Этот лист — что делаем, родственный — почему так.
Incident Response — постмортем — after-action для инцидента; качество timeline постмортема прямо зависит от качества фиксации событий в моменте.
Runbooks — каждый постмортем должен порождать обновление runbook; иначе lesson learned не закреплён.
SLO / Budget Review — постмортемы выявляют источники бюджет-сжигания; ревью — точка, где lessons learned превращаются в приоритеты.
Service Ownership — owner сервиса — accountable person за постмортем и его action items.
Action Items Tracking — соседняя практика: постмортем генерирует AIs, action items tracking — про их выполнение. Без обоих cycle разорван.
Postmortem Database — куда отправляется готовый постмортем; tagging schema определяет, найдётся ли документ через год; pattern review поверх database — точка превращения single-incident learning в team-level.

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

Severity-based triage methodology — детальная схема классификации инцидентов под уровень постмортема (lightweight retro vs полноценный).