Postmortem Culture

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

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

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

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

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

Фасилитирует постмортем; проводит 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 (фреймворк и книга). Для серьёзных разговоров про границу «когда обвинение оправдано, когда нет» — короткий ответ Dekker: почти никогда.
John Allspaw — Each Necessary, But Only Jointly Sufficient (Kitchen Soap, 2012). Продвинуто. Цитирую её, когда команды зациклены на поиске «root cause» — статья объясняет, почему сама постановка «найти причину» — упрощение, ведущее к плохим action items.
GitLab database outage of January 31, 2017. Эталонный публичный постмортем — см. ниже в Best practices.

Инструменты

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

Best practices

Один из самых полезных публичных кейсов в SRE-литературе — GitLab database outage 31 января 2017 года. Инженер чистил каталог данных PostgreSQL, будучи уверенным, что работает на вторичном узле, а команда ушла на primary; потеряно около шести часов данных. GitLab вёл почти live-blog хода восстановления и затем опубликовал формальный постмортем. Самое ценное в нём — не ошибка инженера, а то, что из пяти развёрнутых механизмов бэкапа и репликации не сработал ни один: восстанавливаться пришлось из LVM-снапшота, снятого шестью часами ранее для staging. Blame на одном инженере здесь бессмыслен ровно поэтому: удалить данные оказалось легко, а вернуть их было нечем, и любой из пяти механизмов, работай он, отменил бы последствия ошибки. Этот кейс — практический ответ на вопрос «как это выглядит в реальности» и публичный, что само по себе редкость. Если читаете этот лист и впервые сталкиваетесь с темой — сначала идите туда, потом сюда.

Дальше три вещи, которые в разборе работают.

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

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

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

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

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

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

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

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

Blameless Postmortem — ритуал, опирающийся на эту культурную норму. Здесь — норма, там — процедура.
Incident Response — постмортем — то, что происходит после incident response; качество timeline постмортема прямо зависит от качества фиксации событий в моменте.
SLO / Budget Review — постмортемы показывают, что именно съедает бюджет; ревью — точка, где выводы разбора превращаются в приоритеты.
Runbooks — каждый постмортем тянет за собой правку runbook; иначе вывод остаётся незакреплённым.
Dev Team Partnership — совместный разбор с продуктовой командой: без него партнёрство не переживает первый же тяжёлый инцидент.
Game Day / Chaos Drills — находки с game day разбираются в формате постмортема; предпосылка внедрения — работающая норма blameless.
Postmortem Database — здесь норма разбора, там — система хранения и извлечения уроков. Без нормы база наполняется формальными документами; без базы каждый разбор остаётся разовым, и через год его никто не найдёт.

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

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