Post Mortem (безвинительный разбор инцидента, blameless postmortem) — структурированный разбор конкретного технического сбоя или инцидента, в котором анализ намеренно сфокусирован на системных причинах — почему процессы, инструменты и коммуникация допустили сбой, а не на том, кто именно нажал не ту кнопку. Ключевое методологическое допущение: все участники инцидента действовали добросовестно и с той информацией, которая была им доступна в момент принятия решения — значит искать нужно не виноватого человека, а условия, в которых его решение оказалось ошибочным.
Происхождение и исследовательская база
Практика безвинительного разбора происходит из отраслей, где цена ошибки — человеческая жизнь: авиации и здравоохранения середины XX века, где сложилась культура, воспринимающая каждую «ошибку» как возможность укрепить систему, а не как повод наказать конкретного сотрудника. В технологическую индустрию концепцию системно перенёс Джон Олспо (John Allspaw), на тот момент технический директор Etsy — в 2012 году он опубликовал в инженерном блоге Etsy материал «Blameless PostMortems and a Just Culture», который стал операциональным описанием того, как конкретно проводить такой разбор в разработке ПО, а не абстрактным философским тезисом.
Практику системно формализовала и популяризировала команда Site Reliability Engineering (SRE) Google — отдельная глава «Postmortem Culture» в открытой книге Google SRE Book разбирает, как безвинительная культура разбора инцидентов встраивается в операционную практику крупной технологической компании, и остаётся одним из наиболее цитируемых источников по теме в индустрии.
Ключевые идеи и принципы
Принцип: допущение добросовестности
Формальное условие «безвинительности» разбора — не риторический жест, а конкретное методологическое допущение: каждый, кто был вовлечён в инцидент, действовал добросовестно и делал то, что казалось правильным решением с той информацией, которая была доступна ему в момент действия. Вопрос «кто виноват» заменяется вопросом «почему система вообще допустила, чтобы это решение оказалось ошибочным».
Принцип: фокус на системе, не на человеке
Вместо «кто совершил ошибку» разбор ищет ответ на вопрос «почему процессы, инструменты, автоматизация и коммуникация не предотвратили или не смягчили последствия инцидента» — и что конкретно в этих системных элементах нужно изменить, чтобы снизить вероятность или последствия похожего сбоя в будущем.
Принцип: инцидент рассматривается изолированно от конкретного события
Post Mortem — разбор именно ЭТОГО инцидента, а не общая ретроспектива работы команды или проекта — формат предельно предметный: конкретная хронология событий, конкретная точка отказа, конкретные корректирующие действия для этого класса сбоев.
Принцип: письменный документ, а не только устное обсуждение
Разбор фиксируется как структурированный письменный документ (обычно: хронология событий, влияние на пользователей/бизнес, корневая причина, что сработало хорошо в реагировании, конкретные корректирующие действия с ответственными и сроками) — не только проговаривается на встрече. Письменная фиксация делает разбор доступным для команд, не участвовавших в инциденте напрямую, и создаёт базу для поиска похожих инцидентов в будущем.
Ограничения, слепые зоны и критика
Формальное объявление культуры «безвинительной» не гарантирует, что она реально такова на практике — если по итогам разбора конкретный сотрудник фактически наказывается (публично или скрыто, например через премию/повышение), команда быстро перестаёт доверять декларируемому принципу и начинает скрывать детали при следующих инцидентах.
Фокус исключительно на системных причинах иногда используется как оправдание для того, чтобы не давать никакой персональной обратной связи вообще — даже добросовестной, но методологически неверной, из страха «нарушить безвинительность»; правильная практика различает системную причину сбоя (не персонализируется) и профессиональное развитие конкретного человека (обсуждается отдельно, не в контексте разбора инцидента).
Разбор без письменной фиксации быстро теряет ценность для команд, не участвовавших в инциденте, и для будущего поиска похожих случаев.
Как и любой формат Lessons Learned, безвинительный разбор не гарантирует применения найденных корректирующих действий без отдельного механизма контроля их выполнения.
Типовые ошибки
Ошибка 1: формулировки указывают на конкретного человека
В документе разбора встречаются формулировки вроде «инженер X забыл проверить Y» вместо системного описания причины — даже при формально декларируемой безвинительности текст фактически персонализирует вину.
Как избежать: явно проверять каждую формулировку причины на персонализацию — фокус на том, что в процессе/инструменте позволило ошибке произойти, не на исполнителе.
Ошибка 2: разбор проводится без письменной фиксации
Инцидент обсуждается устно на встрече, выводы нигде не документируются структурированно — команды, не присутствовавшие на разборе, не имеют доступа к найденным причинам и корректирующим действиям.
Как избежать: фиксировать разбор как письменный документ с хронологией, причиной и корректирующими действиями, доступный всей организации, не только участникам инцидента.
Ошибка 3: декларируемая безвинительность расходится с реальными последствиями
После разбора конкретный сотрудник фактически наказывается (явно или через изменение отношения руководства) — при формально «безвинительном» протоколе разбора.
Как избежать: держать разбор инцидента и вопросы профессионального развития/обратной связи конкретному человеку как строго раздельные процессы, не смешивать их во времени и в одном документе.
Ошибка 4: корректирующие действия остаются без ответственных и сроков
Разбор находит правильные системные причины, но рекомендации формулируются абстрактно, без конкретного владельца и дедлайна — как и любой урок без явной рекомендации, они не реализуются.
Как избежать: у каждого корректирующего действия — явный ответственный и срок, зафиксированные в том же документе разбора.
Главное, что нужно знать
Post Mortem — структурированный разбор конкретного технического инцидента, сфокусированный на системных причинах, а не на виновном человеке.
Ключевое допущение — все участники действовали добросовестно с доступной им информацией; вопрос не «кто виноват», а «почему система допустила ошибочное решение».
Происходит из авиации/здравоохранения; в технологическую индустрию перенёс Джон Олспо (Etsy, 2012), формализовала и популяризировала культура Google SRE.
Фиксируется как письменный структурированный документ, не только устное обсуждение — иначе теряет ценность для команд вне инцидента.
Декларируемая безвинительность должна подтверждаться реальными последствиями — иначе доверие к практике быстро разрушается.
План внедрения
Сразу после инцидента: сбор фактов
Зафиксировать точную хронологию событий, пока детали свежи у всех участников.
Явно зафиксировать влияние инцидента (на пользователей, бизнес-метрики, репутацию) — не только технический факт сбоя.
В течение нескольких дней после инцидента: разбор
Провести встречу разбора с явным напоминанием принципа добросовестности участников в начале.
Сфокусировать обсуждение на системных причинах — процессах, инструментах, коммуникации, а не на конкретных людях.
Сформулировать конкретные корректирующие действия с ответственными и сроками.
После разбора: документирование и распространение
Оформить письменный документ с хронологией, причиной и корректирующими действиями.
Сделать документ доступным всей организации, не только участникам инцидента.
Отслеживать выполнение корректирующих действий отдельно, не полагаясь на то, что сам факт разбора гарантирует их реализацию.
Как реализовать этот план с помощью фрейма «Post Mortem» в OrgDevTools
Живой фрейм этой методики ещё не создан — задача поставлена агенту framework-builder (скилл frameworks_ODT) в этом же цикле работы. Раздел будет дополнен фактическим описанием компонента сразу после того, как фрейм реально создан и зарегистрирован — по правилу этого же скилла блок не пишется заранее по намерению, только по факту готового кода.