post-mortems.js·4 scenarios
Post-mortems concept: blameless culture (Etsy/Google exemplars), document anatomy (summary/impact/timeline/root-cause/action-items/lessons), 5 Whys + fishbone RCA, action item tracking discipline, anti-patterns ("human error" root cause). Four scenarios: timeline reconstruction, 5 whys analysis, monthly action item retro, blameless vs accountability. ADR on blameless vs accountability tension.
Incident без post-mortem — это потраченные деньги, сожжённый сон on-call инженера и ноль обучения для организации. Через квартал та же системная дыра ломает сервис тем же способом — потому что lesson осталась в голове одного человека, который к тому моменту либо ушёл, либо забыл детали.
Post-mortem превращает локальный провал в organizational learning. Хороший post-mortem делает три вещи: фиксирует timeline пока память свежая, докапывается до системной причины (а не до «John накосячил»), и формулирует action items с owners/deadlines, которые реально шипятся. Без любой из трёх — это incident diary, не learning artifact.
Цена ошибки культурная, не техническая. В blame-культуре инженеры скрывают near-miss-ы, тянут с эскалацией («может, само рассосётся»), и узнаёшь о SEV-1 от твиттера клиентов вместо алерта. В blameless-культуре получаешь 5 near-miss reports в квартал — pre-incident обучение бесплатно.
Post-mortem — это анализ системы, а не суд над человеком. Если инженер смог накосячить — это дыра в системе (process, tooling, guardrails, monitoring), и закрывать надо дыру, не инженера.
Три слоя одного incident:
Если post-mortem останавливается на triggering action («Alex запустил миграцию») — это hindsight bias и анти-паттерн. Если докапывается до организационного слоя — это материал для action items, которые реально что-то меняют.
Substitution test (Sidney Dekker): если другой competent engineer в том же контексте (та же tooling-капасити, тот же on-call fatigue, тот же sprint pressure) сделал бы то же самое — это system issue. Фиксить надо систему, не человека. В 95% incident-ов substitution test проходит.
Четыре кластера, отражающие четыре среза post-mortem-процесса.
Document (top-left) — анатомия документа: 7 обязательных секций от Summary до Lessons. Sections связаны цепочкой summary → impact → timeline → root-cause → went-well → went-poorly → actions → lessons — это порядок, в котором читатель expand-ит при skim-чтении (от executive summary до deep-dive). Decisions на pm-summary и pm-actions — два ADR, которые рекомендую копировать в любую organization >50 инженеров: минимальная схема документа и SMART action items.
Process (bottom-left) — как post-mortem рождается: incident resolved → assign author (НЕ виновник) → draft 24-72h → review meeting → publish → monthly action item review. Цикл замыкается на pm-track, который кормит обратно pm-actions — это и есть отличие живого процесса от ритуала.
RCA (top-right) — 5 Whys цепочка плюс fishbone в параллель. Symptom → 5 уровней вглубь → root cause в roadmap-приоритизации. Decision на symptom — ADR про когда 5 Whys, когда fishbone, когда оба. Edge symptom → fishbone идёт параллельно цепочке whys — это и есть метод: drilling + breadth одновременно.
Blameless (bottom-right) — культурный слой: just-culture → language → substitution → system-fix → public-share. Decision на just-culture — самый load-bearing ADR во всём диаграмме: как разрешить псевдо-conflict между blameless и accountability (короткий ответ — accountability через ownership action items, не через blame в meeting).
Anti-patterns и Tooling — два маленьких кластера снизу. Анти-паттерны показывают, как один сбой («human error» как root cause) каскадно ведёт к другому (superficial analysis → theater → no tracking → recurrence). Tooling показывает, какие куски документа автоматизируются (incident.io → auto-timeline, jeli → cross-incident patterns, jira-link → action item tracking).
Scenario 1: Timeline reconstruction. Проходит реальный SEV-2: checkout 500-ки в 12
UTC, mitigation rollback к 12, resolved к 12. Показывает, какincident.io авто-pull-ит timeline из Slack-канала инцидента (47 timestamped messages), формирует UTC-точный timeline с decisions inline («decided to rollback because correlation strong»), и кормит секции Impact и Summary. Ключевая мысль сценария: timeline без scribe — это memory-based reconstruction через 24-48h, что неточно и склоняется к обвинительной нарративе. С auto-capture — factual record.
Scenario 2: 5 Whys + fishbone. Берёт тот же checkout-инцидент и докапывается до root cause. Symptom («deploy v2.4 → 500-ки») → Why 1 (миграция добавила NOT NULL без default) → Why 2 (staging имеет 100 строк, prod 50M с 12% NULL) → Why 3 (staging schema diverged 6 месяцев назад после hotfix) → Why 4 (нет automated drift detection) → Why 5 (schema-diff tool deprioritized в 2025 H2 roadmap). Параллельно fishbone расширяет: People, Process, Tools, Infrastructure, Code, Communication — 6 contributing factors. Action items, выведенные из анализа: P0 schema-diff в CI (preventive), P1 alert на drift (detective), P2 auto-rollback (corrective), P1 defensive migration template (training). Сценарий явно показывает, что остановка на «Alex deployed bad code» оставляет систему неизменной, и тот же инцидент случается через 6 месяцев с другим инженером.
Scenario 3: Action items retro. Monthly review action items за май: 11 items из 3 incident-ов. AI-3 (runbook template, Sarah) — done ahead of deadline. AI-1 (CI schema-diff, Alex) — done on time, уже поймал 1 PR с drift. AI-2 (drift alert, Maria) — slipped 2 weeks из-за dependency на AI-1, re-deadlined. AI-4 (prod replica research, Tom) — not started; sprint full of P1 features. Critical: вместо «почему не сделал?» Sarah 1
спрашивает «что blocked?» — Tom отвечает про P2 priority и отсутствие sponsor. Decision: либо raise to P1, либо явно cancel с rationale, либо reassign. Что не приемлемо — оставлять «open» бесконечно. Сценарий заканчивается метрикой: 64% on-time completion (target 70%+), и сравнением: команды без monthly review имеют 20% completion (Etsy 2012 data), с review — 70%.Scenario 4: Blameless vs blame culture. Side-by-side тот же инцидент в двух культурах. Culture A: manager в meeting спрашивает «кто запустил миграцию?», Alex признаётся, публичное «понимаешь сколько денег потеряли?». Outcome A: Alex больше не берётся за risky work, escalation на каждое решение замедляет delivery 3x, другие инженеры скрывают mistakes, тот же incident повторяется через 6 месяцев. Culture B: meeting начинается с blameless ground rules, voice в документе — «the migration was deployed», substitution test показывает что это system failure, action items targets — tooling/process/training. Outcome B: Alex становится owner-ом CI schema-diff проекта, 5 near-miss reports в следующий квартал, ship velocity стабильный, reliability up. Сценарий завершается public exemplars (Cloudflare 2019 BGP, GitLab 2017 db1, Etsy Code as Craft) и явным напоминанием: blameless ≠ consequence-free — gross negligence идёт через HR отдельно от post-mortem.
ADR PM-meta-001 (на ноде pm-summary): минимальная схема документа. Без обязательного шаблона команды пишут свободный текст — одни делают 2 страницы про timeline, другие 5 страниц про RCA без action items. Через 6 месяцев incident-ы не сравнимы, patterns не находятся, retro по action items невозможно. Решение: 7 обязательных секций (Summary 3-5 lines, quantified Impact, UTC Timeline, RCA, What went well, What went poorly, Action items), опциональные (Lucky factors, Glossary, Graphs). Конвергенция Etsy/Google/Atlassian/PagerDuty templates подтверждает выбор. Trade-off — фиксированная структура иногда не идеальна для unusual incident, но consistency для cross-incident learning важнее локальной оптимизации.
ADR PM-meta-002 (на ноде pm-actions): SMART action items. Самый частый failure mode post-mortem — action items как pious wishes («improve monitoring», «better testing»). Etsy 2012 retro: 80% items без owner не выполнены через 6 месяцев; 70% с owner+deadline — выполнены. Те же инженеры, разница в процессе. Решение: каждый action item обязан иметь owner (named, не «team»), deadline (конкретная дата), tracker ticket (auto-created из incident-tool), priority (P0/P1/P2), type (preventive/detective/corrective/mitigative). Trade-off — overhead на оформление 30-40 минут на post-mortem, окупается через monthly review где видно execution metric.
ADR PM-meta-003 (на ноде symptom): 5 Whys vs fishbone. 5 Whys (Toyoda, Toyota 1930s) — линейный, простой, может пропустить branched causes. Fishbone (Ishikawa 1968) — visual, требует категорий, может растянуть analysis. Решение: timeline-first (что и когда), потом 5 Whys на каждый contributing factor отдельно, потом fishbone для system view с 6 SRE-категориями (People, Process, Tools, Infrastructure, Code, Communication). Combine — потому что одна техника недостаточна для multi-layered failure. Trade-off — два метода вместо одного удлиняет review meeting на 20-30 минут, но дешевле, чем повторяющийся инцидент.
ADR PM-meta-004 (на ноде just-culture): blameless vs accountability. Распространённое возражение менеджмента — «если blameless, никто не отвечает, дисциплина рушится». False dichotomy. Решение по Sidney Dekker «Just Culture»: blameless фокус для post-mortems (95% incident — honest mistakes), accountability через ownership action items (missed deadline → visible в monthly review → manager 1
rm -rf prod database, backups failed silently. Live YouTube recovery + детальный публичный post-mortem. Brand парадоксально укрепился — customers увидели профессионализм response, не катастрофу./dev/null. Без SMART-структуры action items превращаются в lamentations.