Инциденты у «бумажного костра»: рассказываем истории аварий вместо статусов

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

Появляется другой подход: «бумажный костёр» для инцидентов.

Вместо жёсткой статус‑встречи с слайдами вы собираетесь в круг — офлайн или онлайн — чтобы рассказать историю инцидента от лица людей, которые её прожили. Никаких экранов, дашбордов и досок в JIRA. Только написанный постмортем, распечатанный (или открытый у всех), который читается вслух как история, а затем обсуждается вместе.

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

Почему традиционные разборы инцидентов не работают

Многие постинцидентные разборы срываются по вполне предсказуемым причинам:

Их проводят как оценку эффективности, а не как сессию обучения.
Руководители явно или неявно дают понять, что ищут «ту самую ошибку».
Участники сосредотачиваются на том, чтобы доказать, что они всё делали правильно, а не на честном исследовании того, что произошло.
Разговор уходит в технические детали и чек‑листы статусов, вместо фокуса на человеческих решениях.

В такой среде люди:

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

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

Основа SRE: безоценочные, системные постмортемы

Прежде чем говорить о «кострах», нам нужно топливо: SRE‑стиля постмортемы.

Когда они сделаны хорошо, SRE‑постмортемы:

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

Критически важно, что они безоценочные (blameless).

«Безоценочные» не значит «никто никогда ни за что не отвечает» или «мы игнорируем откровенную халатность». Это значит:

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

Вместо вопроса «Кто накосячил?» вы спрашиваете:

Что сделало это действие разумным в тот момент?
Какой информации не хватало или что вводило в заблуждение?
Какие давления (по времени, по нагрузке, по ожиданиям) влияли на решения?

Такой фрейм сдвигает фокус с людей на систему и делает обучение возможным.

От статус‑митинга к кругу историй

Большинство разборов инцидентов крутятся вокруг слайдов, дашбордов и тикетов. Формат «костра» всё переворачивает.

Что такое «бумажный костёр инцидентов»?

Это ритуал разбора через историю с тремя ключевыми свойствами:

Сначала бумага (или текст): SRE‑постмортем пишется до встречи и оформляется в виде цельного текста. На «костре» его читают и обсуждают — без статус‑дек, без живого копания в логах.
Круг историй: все собираются на равных (если офлайн — стулья в круг; если онлайн — камеры включены, следим за равным доступом к слову). Акцент на том, чтобы понять именно историю инцидента.
Разговор вместо презентации: цель не презентовать, что произошло, а исследовать, как всё разворачивалось — особенно человеческие решения и неожиданные повороты.

«Костёр» — это место, где постмортем становится общим обучающим артефактом, а не ещё одним PDF в общей папке.

Как писать нарративный постмортем

Чтобы поддержать этот формат, ваш постмортем должен читаться скорее как история, а не как чек‑лист.

Оставьте привычные SRE‑разделы:

Краткое резюме и влияние
Симптомы, видимые пользователям
Таймлайн событий
Корневые причины и сопутствующие факторы
Ремедиации и follow‑up задачи

Но расширьте нарратив вокруг человеческих решений:

Что люди видели и во что верили на каждом этапе?
Какие сигналы были запутанными, неоднозначными или отсутствовали?
Какие компромиссы приходилось держать в голове (например, скорость против безопасности)?
Где ожидания и ментальные модели расходились с реальностью?

Этот нарратив и станет сценарием для вашего «костра».

Как проводить «костёр»: пошаговый формат

Ниже — практическая схема, которую можно использовать.

1. Явно задать рамку

Фасилитатор (часто это SRE или incident manager) открывает сессии чётким месседжем:

Это сессия обучения, а не performance review.
Мы не здесь, чтобы искать виноватых.
Наша цель — понять: «Почему это выглядело разумным решением в тот момент?»

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

2. Читаем историю вместе

Кто‑то (часто лидер инцидента) читает вслух нарративные части постмортема или медленно проговаривает их, делая паузы:

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

Приглашайте людей, которые участвовали в инциденте, добавлять детали:

«Что вы видели тогда на своих экранах?»
«Что вы думали, что происходит в тот момент?»
«В чём вы больше всего сомневались в этой точке?»

Цель — восстановить прожитый опыт, а не просто перечислить события по логам.

3. Задаём вопросы из любопытства, а не с осуждением

Формулируйте вопросы так, чтобы они будили любопытство, а не защиту. Вместо:

«Почему вы перезапустили сервис без canary‑деплоя?»

спросите:

«Что сделало перезапуск лучшим вариантом в тот момент?»
«Какие сигналы подсказывали, что это безопасно?»
«Были ли ограничения или давления, которых не видно в таймлайне?»

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

4. Исследуем систему, а не человека

Когда вы находите «ошибку», не останавливайтесь на этом:

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

Переводите это в системные изменения, а не в пожелания вроде «В следующий раз будь внимательнее».

5. Проверяем и дорабатываем процесс реагирования

Используйте историю, чтобы оценить не только сам сбой, но и процесс реагирования:

Сработали ли алёрты тогда и там, где должны были?
Отработали ли маршруты ответственности и on‑call так, как ожидалось?
Насколько эффективными были каналы коммуникации (Slack, Zoom, инцидент‑рум)?
Runbook соответствовал реальности или людям пришлось импровизировать?

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

Психологическая безопасность: критически важный компонент

Одной смены формата недостаточно.

Можно сидеть в кругу с распечатанным постмортемом — и всё равно получить:

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

Чтобы «костёр» заработал, нужно активно снижать страх последствий, провалов и суждений.

Несколько конкретных практик:

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

Со временем это строит культуру, в которой признавать ошибки и задавать «глупые» вопросы — безопасно и ожидаемо.

Как превратить истории у костра в долгоживущие артефакты

Результат «костра» — не просто приятный разговор. Это уточнённый артефакт, из которого может учиться вся организация.

После сессии:

Обновите постмортем с учётом новых инсайтов из обсуждения.
Подсветите ключевые моменты истории: неожиданные сигналы, неоднозначные cues, сложности координации.
Зафиксируйте согласованные системные изменения и гипотезы (например: «Мы считаем, что это изменение сократит время детекции на X»).
Распространите: через внутреннюю базу знаний, обучающую рассылку или SRE‑сообщество внутри компании.

Со временем такие нарративные постмортемы становятся:

материалом для онбординга новых инженеров;
реалистичными кейсами для тренингов и game day;
видимой хроникой того, как вы развиваете надёжность и культуру.

Как привнести «костёр» в вашу команду

Полный культурный «капремонт» не нужен, чтобы начать. Попробуйте этот формат уже на следующем серьёзном инциденте:

Напишите безоценочный, нарративный постмортем.
Назначьте 60‑минутную сессию «инцидент у костра» для всех ключевых участников и стейкхолдеров.
Явно оформите её как круг историй и сессию обучения.
Проведите по этому формату один раз, затем соберите обратную связь.

Спросите людей после:

Чувствовали ли вы себя в безопасности, рассказывая, как всё было на самом деле?
Узнали ли вы что‑то, чего раньше не знали об этом инциденте?
Появились ли у нас изменения, которые действительно улучшат систему или процесс?

Используйте эту обратную связь, чтобы донастроить ритуал.

Вместо эпилога: от страха к любопытству

Инциденты неизбежны. Но «потраченные впустую» инциденты — те, которые мы пробегаем поверхностно и сопровождаем тихим поиском виноватых, — вполне опциональны.

«Бумажный костёр» для инцидентов — простой, но сильный способ:

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

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

И именно там начинается настоящая надёжность.