Postmortem Culture

Большинство blameless-постмортемов, которые я видел, безвиновны только на словах. На встрече никто не задаёт вопроса «кто это сделал», в документе не упомянуто имя — а в коридоре после встречи говорят «ну это же Х накосячил». Лист — не про шаблон документа и не про процедуру встречи. Про процедуру — в соседнем листе Blameless Postmortem. Здесь — про норму, после которой коридорной версии не остаётся.

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

Главный навык на уровне L4 — отделять факты от интерпретаций в хронологии инцидента (timeline). «X не справился» — это уже интерпретация, замаскированная под факт; «X вернул 503 в 14:23» — факт. Без этого навыка анализ факторов и задачи (action items) строятся на песке. Если в чужом тексте встречается «справился / не справился» — для меня это сигнал, что вывод уже сделан до анализа.

Понимает принцип blameless; читает чужие постмортемы без негативных коннотаций. Не задаёт вопроса «кто это сделал».
Отделяет факты от интерпретаций в чужом timeline.

Участвует в постмортеме как факт-репортёр; формулирует факты, не интерпретации («сервис вернул 503» вместо «X не справился»).
Пишет timeline с timestamp-ами событий и решений; различает «то, что произошло» и «то, что решили сделать».

Фасилитирует постмортем; проводит timeline review, выявляет факторы вклада (contributing factors), удерживает фокус на системе.
Формулирует action items с владельцем, дедлайном и критерием готовности; не позволяет «забыть» неудобные пункты.
Применяет техники анализа (5 Whys, Causal Influence Diagram, Necessary But Only Jointly Sufficient) без скатывания во взгляд задним числом (hindsight bias) и оптимистичный контрфакт («если бы только…»).

L6+

Строит культуру постмортемов в команде или организации; нормализует разбор и обучение через ошибки.
Защищает принцип blameless от давления «найти виноватого» сверху; ведёт переговоры с руководством и юристами в спорных случаях.

Материалы

Книги

Betsy Beyer et al. — Site Reliability Engineering (O’Reilly, 2016), глава 15 «Postmortem Culture: Learning from Failure». База: задаёт словарь («blameless», «contributing factors», «hindsight»). Читать первым.
Betsy Beyer et al. — The Site Reliability Workbook (O’Reilly, 2018), глава 10 «Postmortem Culture: Learning from Failure Continued». По моему ощущению — полезнее SRE Book гл. 15: вместо принципов разбирает плохой vs хороший постмортем на реальном инциденте. Если выбирать одну главу — эту.
Sidney Dekker — The Field Guide to Understanding ‘Human Error’ (CRC Press, 3-е изд., 2014). Фундамент Just Culture; не SRE-книга, читается тяжело. Беру в руки, когда команда сомневается «почему именно blameless работает» — Dekker отвечает обоснованием из медицины и авиации.

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

John Allspaw — Blameless PostMortems and a Just Culture (Etsy Code as Craft, 2012). База: статья, заложившая словарь и подход. Обязательное чтение.
Sidney Dekker — Just Culture (фреймворк и книга). Для серьёзных разговоров про границу «когда blame оправдан, когда нет» (короткий ответ Dekker: почти никогда).
John Allspaw — Each Necessary, But Only Jointly Sufficient. Продвинуто. Цитирую её, когда команды зациклены на поиске «root cause» — статья объясняет, почему сама постановка «найти причину» — упрощение, ведущее к плохим action items.
GitLab database outage of January 31, 2017. Эталонный публичный постмортем — см. ниже в Best practices.

Инструменты

postmortem-templates — публичная коллекция шаблонов, агрегированных из SRE Book и других источников. Хорошая стартовая точка — не пишите первый шаблон команды с нуля.
Внутренний шаблон постмортема в репо команды (markdown) — единый формат: timeline, факторы вклада, action items с владельцем и дедлайном, lessons learned. Без шаблона каждый постмортем превращается в свободное эссе, и читать их через год невозможно.

Best practices

Один из самых полезных публичных кейсов в SRE-литературе — GitLab database outage 31 января 2017 года. Инженер выполнил rm -rf на production-БД, потерял около шести часов данных, восстановление шло из staging-копии. GitLab опубликовал почти live-blog хода восстановления и затем формальный постмортем с пятью факторами вклада: каждый из них по отдельности предотвратил бы инцидент, и blame на одном инженере не имел бы смысла, потому что система допускала такой rm -rf пятью разными способами. Этот кейс — практический ответ на вопрос «как это выглядит в реальности» и публичный, что само по себе редкость. Если читаете этот лист и впервые сталкиваетесь с темой — сначала идите туда, потом сюда.

Что работает:

Blame направлен на систему, не на человека. Антипаттерн: вопрос «кто это сделал?». Из него следуют тишина на следующих инцидентах и увольнения вместо изменений архитектуры. Правильный вопрос: «Почему эта система допустила ошибку?» — из него следуют action items.
Action items имеют владельца, дедлайн и критерий готовности. Антипаттерн: список без follow-up. Через полгода невыполненный список убивает доверие к ритуалу: команды перестают серьёзно участвовать, потому что вывод-то очевиден — «всё равно ничего не делается».
Hindsight bias — главный враг анализа. Антипаттерн: «они должны были предвидеть» / «как они не заметили». В момент инцидента информация была неполной; задним числом всё кажется очевидным. Если в постмортеме звучит «должны были» — это сигнал остановиться и реконструировать, что человек знал в момент решения, а не что мы знаем сейчас.

Что я считаю важнее всего перечисленного:

Психологическая безопасность — предпосылка, а не следствие. Это часто понимают наоборот: считают, что если ввести «безвиновный шаблон» — безопасность появится. На практике чаще случается обратное: команда формально говорит «мы никого не виним», но реально боится фактов, скрывает свои действия, переписывает timeline. Я называю это blameless-театром, и он встречается чаще, чем настоящее отсутствие безопасности. Лечится не шаблоном, а тем, как реагирует руководство на первый «опасный» постмортем — где факт ошибки человека виден напрямую. Если в этом случае никого не наказали и публично это признали — безопасность есть. Если хотя бы намёком «такого больше быть не должно, мы поговорим с ним лично» — её нет.

Contributing factors вместо «root cause». Стандартный совет — «найдите корневую причину» — мне кажется вредной упрощённой постановкой. Один корень подталкивает к одному фиксу; реальный инцидент возникает из множества факторов (код + конфиг + человек + время + нагрузка + слабый алерт), и одна заплатка не предотвращает повтор. Подход NBJS (Necessary But Only Jointly Sufficient) формулирует это явно: перечислены все необходимые условия, и достаточно нейтрализовать любое одно, чтобы инцидент не повторился. Так в Postmortem GitLab 2017 — пять факторов, каждый отдельный fix решал бы. Не «root cause», а «вот пять выводов и пять action items». Я не видел постмортемов с одной «корневой причиной», которые через год не повторили бы инцидент в той же области.

Постмортемы распространяются за пределы команды. Антипаттерн «свой постмортем — внутренний документ команды» означает: учатся только участники инцидента, остальные команды наступают на те же грабли. Минимум — публикация на внутренней площадке, доступной всей инженерии. Лучше — public post-mortem в духе GitLab, Cloudflare, Stripe, Honeycomb. Я понимаю, что не каждый инцидент стоит публиковать наружу (security, клиентские данные, regulatory) — но решение «не публиковать» должно быть осознанным, а не дефолтом.

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

Blameless Postmortem — ритуал, опирающийся на эту культурную норму. Здесь — норма, там — процедура.
Incident Response — постмортем — то, что происходит после incident response; качество timeline постмортема прямо зависит от качества фиксации событий в моменте.
SLO / Budget Review — постмортемы выявляют источники сжигания бюджета; ритуал ревью — точка, где lessons learned превращаются в приоритеты.
Runbooks — каждый постмортем должен порождать обновление runbook; иначе lesson learned не закреплён.
Dev Team Partnership — joint postmortem с product-командой — обязательное условие сохранения partnership.
Game Day / Chaos Drills — game day findings обрабатываются через постмортем-формат; cultural prerequisite адопции — работающая blameless-норма.
Postmortem Database — норма разбора (этот лист) vs система хранения и извлечения уроков. Без культуры database заполняется поверхностными документами; без database культура теряет 60-70% долгосрочной ценности.

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

Граница со scope Blameless Postmortem зафиксирована: этот лист — про норму, соседний — про ритуал (что команда делает на встрече, в каком порядке, с какими артефактами).
Я не уверен, что нормы blameless достижимы в крупных регулируемых индустриях (банки, авиация, медицина) без явной legal-обвязки. SRE Book пишет про just culture, но конкретику для compliance-нагруженных сред в нормальной литературе я не нашёл. Если такой опыт у вас был — расскажите через PR в этот лист.