Blameless Postmortem (Безобвинительный разбор инцидента)

31 января 2017 года инженер GitLab ввёл команду rm -rf, полагая, что находится на резервном сервере базы данных, — но оказался на основном. За две секунды было удалено 300 ГБ продуктивных данных: около 5000 проектов, 5000 комментариев и 700 новых учётных записей. GitLab считала, что защищена пятью независимыми механизмами резервного копирования — ежедневные снапшоты, бэкапы в S3, репликация, ручные архивы, потоковые логи — и в реальном времени обнаружила, что все пять отказали одновременно и незаметно. Компания не увольняла инженера: если одна команда способна обойти пять систем резервного копирования и удалить всё, проблема не в человеке, а в системе. GitLab провела разбор именно в блеймлесс-логике — с фокусом на том, почему отказали защитные механизмы, а не кто нажал команду — и трансляцию восстановления смотрели около 5000 человек на YouTube; реакция индустрии на публичную прозрачность компании была на редкость уважительной, а не осуждающей. Post Mortem (безвинительный разбор инцидента, blameless postmortem) — структурированный разбор конкретного технического сбоя, в котором анализ намеренно сфокусирован на системных причинах — почему процессы, инструменты и коммуникация допустили сбой, а не на том, кто именно нажал не ту кнопку. Ключевое методологическое допущение: все участники инцидента действовали добросовестно и с той информацией, которая была им доступна в момент принятия решения — значит искать нужно не виноватого человека, а условия, в которых его решение оказалось ошибочным.

Что такое Post Mortem и когда он нужен

Post Mortem нужен сразу после значимого технического инцидента — сбоя сервиса, потери данных, серьёзной деградации производительности, — когда команде важно не наказать виновного, а системно снизить вероятность повторения. Эта статья фокусируется именно на культурном фундаменте практики — допущении добросовестности участников и теории Just Culture Сидни Деккера, стоящей за самим термином «блеймлесс»; формат письменного документа (хронология, причина, действия) — общая часть практики, глубже разобранная в статье про Post-Mortem анализ (через опыт Google SRE). Обе статьи используют один и тот же живой фрейм OrgDevTools — намеренное решение, так как это одна практика с двумя взаимодополняющими источниками, а не две разные методики.

Происхождение и исследовательская база

Практика безвинительного разбора происходит из отраслей, где цена ошибки — человеческая жизнь: авиации и здравоохранения середины XX века, где сложилась культура, воспринимающая каждую «ошибку» как возможность укрепить систему, а не как повод наказать конкретного сотрудника. В технологическую индустрию концепцию системно перенёс Джон Олспо (John Allspaw), на тот момент технический директор Etsy — в 2012 году он опубликовал в инженерном блоге Etsy материал «Blameless PostMortems and a Just Culture», который стал операциональным описанием того, как конкретно проводить такой разбор в разработке ПО, а не абстрактным философским тезисом. Статья Олспо операционализировала для инженерных команд теорию Just Culture исследователя человеческого фактора Сидни Деккера. Ключевая идея, перенесённая из работ Деккера: за очевидным, «первым» объяснением инцидента («инженер ошибся») почти всегда стоит «вторая история» — то, как ситуация выглядела для участника в момент решения, с той неполной информацией и тем контекстом, который у него был. Когда организация по умолчанию ищет виноватого, инженеры начинают умалчивать детали своих действий и наблюдений из страха наказания — Олспо называл это «CYA-инженерией» (cover-your-ass engineering) — а руководство теряет реальную картину того, как на самом деле выполняется работа день за днём.

Практику системно формализовала и популяризировала команда Site Reliability Engineering (SRE) Google — отдельная глава «Postmortem Culture» в открытой книге Google SRE Book разбирает, как безвинительная культура разбора инцидентов встраивается в операционную практику крупной технологической компании, и остаётся одним из наиболее цитируемых источников по теме в индустрии.

Ключевые идеи и принципы

1. Принцип: допущение добросовестности

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

2. Принцип: фокус на системе, не на человеке

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

3. Принцип: инцидент рассматривается изолированно от конкретного события

   Post Mortem — разбор именно ЭТОГО инцидента, а не общая ретроспектива работы команды или проекта — формат предельно предметный: конкретная хронология событий, конкретная точка отказа, конкретные корректирующие действия для этого класса сбоев.

4. Принцип: письменный документ, а не только устное обсуждение

   Разбор фиксируется как структурированный письменный документ (обычно: хронология событий, влияние на пользователей/бизнес, корневая причина, что сработало хорошо в реагировании, конкретные корректирующие действия с ответственными и сроками) — не только проговаривается на встрече. Письменная фиксация делает разбор доступным для команд, не участвовавших в инциденте напрямую, и создаёт базу для поиска похожих инцидентов в будущем.

Ограничения, слепые зоны и критика

Типовые ошибки

1. Ошибка 1: формулировки указывают на конкретного человека

   В документе разбора встречаются формулировки вроде «инженер X забыл проверить Y» вместо системного описания причины — даже при формально декларируемой безвинительности текст фактически персонализирует вину.

   Как избежать

   явно проверять каждую формулировку причины на персонализацию — фокус на том, что в процессе/инструменте позволило ошибке произойти, не на исполнителе.

2. Ошибка 2: разбор проводится без письменной фиксации

   Инцидент обсуждается устно на встрече, выводы нигде не документируются структурированно — команды, не присутствовавшие на разборе, не имеют доступа к найденным причинам и корректирующим действиям.

   Как избежать

   фиксировать разбор как письменный документ с хронологией, причиной и корректирующими действиями, доступный всей организации, не только участникам инцидента.

3. Ошибка 3: декларируемая безвинительность расходится с реальными последствиями

   После разбора конкретный сотрудник фактически наказывается (явно или через изменение отношения руководства) — при формально «безвинительном» протоколе разбора.

   Как избежать

   держать разбор инцидента и вопросы профессионального развития/обратной связи конкретному человеку как строго раздельные процессы, не смешивать их во времени и в одном документе.

4. Ошибка 4: корректирующие действия остаются без ответственных и сроков

   Разбор находит правильные системные причины, но рекомендации формулируются абстрактно, без конкретного владельца и дедлайна — как и любой урок без явной рекомендации, они не реализуются. Тот же риск систематически разбирается в общей практике Lessons Learned — там, где выводы фиксируются, но не превращаются в конкретные назначенные задачи.

   Как избежать

   у каждого корректирующего действия — явный ответственный и срок, зафиксированные в том же документе разбора.

Как измерить эффект

• Доля формулировок причин без персонализации: в тексте разборов не встречаются фразы вида «инженер X забыл...» — все причины сформулированы как системные условия.

• Повторяемость похожих инцидентов: снижение частоты сбоев одного и того же класса после внедрения найденных корректирующих действий — главный практический показатель того, что разбор был не формальностью.

• Полнота владения и сроков у корректирующих действий: доля действий с явным ответственным и сроком, а не абстрактных рекомендаций без владельца.

• Готовность сотрудников сообщать о собственных ошибках: рост числа добровольно инициированных разборов (а не только по факту крупных публичных сбоев) — косвенный, но надёжный индикатор того, что декларируемая безвинительность подтверждается практикой, а не расходится с ней.

План внедрения

Если инцидент связан с формальным процессом реагирования (эскалация, SLA, приоритизация), Post Mortem обычно проводится как следующий шаг после закрытия инцидента по ITIL Incident Management — это два разных, последовательных процесса: сначала восстановление сервиса, затем системный разбор причин.

1. Сразу после инцидента: сбор фактов

   • Зафиксировать точную хронологию событий, пока детали свежи у всех участников.

   • Явно зафиксировать влияние инцидента (на пользователей, бизнес-метрики, репутацию) — не только технический факт сбоя.

2. В течение нескольких дней после инцидента: разбор

   • Провести встречу разбора с явным напоминанием принципа добросовестности участников в начале.

   • Сфокусировать обсуждение на системных причинах — процессах, инструментах, коммуникации, а не на конкретных людях.

   • Сформулировать конкретные корректирующие действия с ответственными и сроками.

3. После разбора: документирование и распространение

   • Оформить письменный документ с хронологией, причиной и корректирующими действиями.

   • Сделать документ доступным всей организации, не только участникам инцидента.

   • Отслеживать выполнение корректирующих действий отдельно, не полагаясь на то, что сам факт разбора гарантирует их реализацию.

Как реализовать этот план с помощью фрейма «Post Mortem» в OrgDevTools

Фрейм «Post Mortem» в OrgDevTools реализован как три вкладки. Вкладка «Post Mortem» задаёт название инцидента с напоминанием методологического допущения прямо в интерфейсе («все участники действовали добросовестно») и последовательно собирает точную хронологию событий, влияние на пользователей/бизнес, непосредственную и системную первопричину (поле для причины прямо содержит подсказку-предупреждение против персонализации — «не «инженер X забыл...», фокус на процессе/инструменте»), что сработало хорошо в реагировании, и таблицу корректирующих действий, где у каждого обязательны ответственный и срок — при их отсутствии строка подсвечивается. Вкладка «Визуализация» показывает статус корректирующих действий и полноту заполнения по 4 блокам разбора. Вкладка «Итоги» формирует пошаговый вердикт, который отдельно проверяет заполненность каждого блока и явно требует, чтобы у КАЖДОГО действия были и ответственный, и срок, а не только общий счётчик выполнения.

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

Книги по теме

Сидни Деккер — «Just Culture: Balancing Safety and Accountability» (2007/2012) и «The Field Guide to Understanding 'Human Error'» (2006/2014). Первоисточник теории справедливой культуры и «второй истории», на которую прямо опирался Джон Олспо при переносе практики в разработку ПО.

Google — «Site Reliability Engineering» (2016, доступна открыто как sre.google/sre-book). Глава «Postmortem Culture» — наиболее цитируемый в индустрии разбор того, как безвинительная культура постмортемов встраивается в операционную практику технологической компании.