Постмортемы или как мы учимся на факапах

Если цель встречи — найти и наказать ошибившегося, участники начинают защищаться, скрывают сомнения и упрощают историю. Организация теряет данные о том, почему действие казалось разумным в тот момент. Blameless-подход исходит из другого: люди действовали внутри доступной информации, инструментов и давления. Нужно понять, какие условия сделали ошибку возможной и почему система не остановила её раньше. Ответственность остаётся, но переносится с личности на улучшение контура.

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

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

Главный выход — небольшой набор action items с владельцами и сроками. Они могут предотвращать повторение, быстрее обнаруживать похожий сбой, ограничивать радиус поражения или улучшать восстановление и коммуникацию. Абстрактное «быть внимательнее» не является действием. Пункт должен изменить код, конфигурацию, мониторинг, тест, документацию или процесс. Если задачи не попадают в обычный backlog и никто не проверяет закрытие, постмортем создаёт иллюзию обучения.

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

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