Аналоговый инцидентный театр: разыгрываем сбои в проде с бумажными реквизитами до запуска

Современные системы опираются на продвинутый мониторинг, автоматизацию и инструменты управления инцидентами. Но когда в продакшене что‑то ломается, чаще всего важнее всего оказывается не ваш стек, а то, как реагируют люди.

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

В этом посте разберём, как работают настольные упражнения и премортемы, почему «разыгрывать» отказы полезно, и как сочетать аналоговые симуляции с современными SRE‑практиками.

Зачем вообще разыгрывать инциденты?

У большинства команд есть какой‑то план реагирования на инциденты: документ, ранбук, страница в вики. На бумаге он часто выглядит вполне убедительно — но первый настоящий тест случается уже во время боевого сбоя, под давлением, с раздражёнными пользователями.

Это перевёрнутая логика.

Вместо того чтобы обнаруживать изъяны посреди кризиса, вы можете прорепетировать реакцию заранее — как учебную тревогу при пожаре. Это и есть суть настольных учений по реагированию на инциденты (incident response tabletop exercises):

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

Цель не в том, чтобы «выиграть» симуляцию. Цель — подсветить несоответствия, вроде:

Шаги в ранбуке, которые никто фактически не может выполнить.
Неясная ответственность: «Кто вообще может принять решение о фейловере?»
Пробелы в коммуникациях: «Мы сообщаем клиентам? Когда? Кто пишет текст?»

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

Что такое настольное учение по реагированию на инцидент?

Tabletop‑учение — это структурированная, низкотехнологичная ролевая игра инцидента. В отличие от полноценных chaos‑экспериментов в продакшене, всё происходит на бумаге (или виртуальной доске): реальные системы вы не трогаете.

Ключевые характеристики:

Сценарий в основе: вы начинаете с реалистичного сценария сбоя (например: «Латентность базы данных растёт, а уровень ошибок увеличивается для пользователей из ЕС»).
Фокус на ролях: каждый участник берёт на себя конкретную роль — incident commander, on‑call инженер, ответственный за коммуникации, product owner и т.д.
Разговор вместо команд: вместо того чтобы вводить команды в прод, вы проговариваете, что бы сделали: какие инструменты проверили, какие приняли бы решения, кого уведомили.
Фасилитация: фасилитатор по ходу выдаёт новую информацию («в логах теперь видно…», «клиенты начинают писать в Twitter…») и следит, чтобы группа двигалась вперёд.

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

Какие решения они вправе принимать сами.
Когда и к кому эскалировать.
Как координироваться с другими ролями под давлением времени.

К концу сессии команда должна намного лучше понимать, кто что делает, когда и как — не только в теории, но и на практике.

Разрыв между бумажным планом и реальностью

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

Типичные «дыры», которые всплывают:

Устаревшие ранбуки — «В шаге 3 сказано проверить Graphite. Мы же год назад переехали на Prometheus».
Размытая ответственность — двое считают себя incident commander; при этом никто не занимается коммуникацией с клиентами.
Скрытые зависимости — единственный человек, который понимает легаси‑auth‑сервис, не приглашён на сессию.
Ошибочные допущения про инструменты — план предполагает метрики или логи, которых в природе нет.

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

Обновить или написать с нуля ранбуки.
Прояснить роли и цепочки эскалации.
Добавить недостающие мониторы, алерты или дашборды.
Задокументировать «племенное знание».

По сути, вы делаете QA вашего процесса реагирования на инциденты.

Премортемы: намеренно придумываем будущие отказы

Обычно tabletop‑учения начинаются с уже заданного сценария. Но как понять, какие именно сценарии стоит разыгрывать? Здесь помогают премортемы (premortem).

Премортем переворачивает привычный формат постмортема:

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

Типичный процесс выглядит так:

Объявить фиктивную катастрофу: «Прошло шесть месяцев, и у нас только что случился худший сбой в истории компании».
Стимулировать свободный, без ограничений брейншторм о том, как к этой катастрофе могли прийти.
Зафиксировать все идеи, особенно странные: провалы процессов, организационные проблемы, сбои у вендоров, крайние баги, рискованные миграции.
Сгруппировать идеи по темам: дыры в мониторинге, single point of failure, неясная ответственность и т.п.
Выбрать самые правдоподобные или самые критичные по ущербу сценарии как вход для будущих tabletop‑учений.

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

Нетехнические риски (например, уход ключевых сотрудников, юридические ограничения, урезание бюджета).
Межкомандные непонимания («Мы думали, они отвечают за бэкапы». «Нет, мы думали, это вы.»).
Режимы отказа, которые сегодня не отслеживает ни один дашборд.

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

Как построить аналоговый инцидентный театр

Вам не нужна лаборатория или идеальная среда для симуляций. «Инцидентный театр» можно сделать из базовых материалов и простой структуры.

Что понадобится

Комната (офлайн или виртуальная), где можно спокойно разговаривать.
Фасилитатор и скрам‑мастер/секретарь (scribe).
Доска или цифровой борд (Miro, FigJam и т.п.).
Стикеры или виртуальные карточки, которые будут представлять:
- системы и сервисы
- алерты
- «снимки» логов/метрик
- обращения клиентов
- внешние ограничения (например, комплаенс, юристы)

Как провести простую сессию

Выберите сценарий
- Используйте идею из премортема или реальный прошлый инцидент с изменёнными условиями.
Назначьте роли
- Incident commander
- On‑call инженеры (по подсистемам)
- Ответственный за коммуникации (клиенты, внутренние стейкхолдеры)
- Опционально: продакт, поддержка, безопасность, юристы
Задайте исходные условия
- Опишите, что команда знает в момент времени T=0 (например, сработал алерт, выросла ошибка, посыпались тикеты в поддержку).
Проигрывайте по раундам
- Каждый раунд по 5–10 минут — это скачок по времени (T+10, T+20 и т.д.).
- Команда рассказывает, что бы делала. Фасилитатор выкладывает новые «улики» на бумаге: метрику, строку лога, волну твитов.
Фиксируйте решения и трения
- Scribe записывает: принятые решения, моменты замешательства, нехватку данных, неясную ответственность и все «нам бы надо было…».
Разбор полётов и улучшения
- Отметьте, что сработало хорошо, а что развалилось.
- Превратите находки в конкретные действия: новые ранбуки, алерты, дашборды, обучение или изменения процессов.

Это и есть ваш аналоговый театр: вы разыгрываете инцидент, не трогая продакшен, но сохраняя реалистичные роли и ограничения.

Как сочетать аналоговые репетиции с современным SRE‑стеком

Речь не о замене инструментов, а о том, как использовать их более эффективно.

Комбинируя аналоговые репетиции с практиками SRE, вы получаете более целостную стратегию готовности:

Мониторинг и observability: используйте сценарии из tabletop‑учений, чтобы понять, какие сигналы нужны. Потом добавьте или уточните метрики, логи и трейсы.
Автоматизация и ранбуки: если видите, что люди постоянно повторяют одни и те же ручные шаги, зафиксируйте их в ранбуках или скриптах автоматизации.
Инструменты управления инцидентами: во время симуляции потренируйтесь пользоваться теми же чат‑каналами, таймлайнами инцидентов, on‑call ротацией и статус‑страницей.
Шаблоны постмортемов: после учения проведите мини‑постмортем по тому же процессу, что и для реальных инцидентов.

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

Формирование культуры психологической безопасности

Одна из самых важных долгосрочных выгод регулярных tabletop‑учений и премортемов — культурная, а не техническая.

Регулярные сессии:

Нормализуют разговоры о сбоях, near miss‑ситуациях и неопределённости.
Показывают, что руководство ценит обучение, а не поиск виноватых.
Дают людям структурированный способ поднимать вопросы о хрупкости системы.

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

Команды, которые регулярно практикуются, как правило:

Быстрее замечают реальные инциденты.
Точнее эскалируют.
Лучше коммуницируют между функциями.
Быстрее учатся — и на симуляциях, и на реальных сбоях.

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

Как начать: сделайте первый шаг маленьким

Не нужны ни директивы от топ‑менеджмента, ни трёхмесячный проект, чтобы стартовать.

Чтобы начать:

Запланируйте 60–90‑минутное tabletop‑учение с небольшой продуктовой или сервисной командой.
Возьмите простой сценарий (например, частичный outage в пике трафика).
Раздайте роли, пройдите через инцидент и запишите все точки трения.
Выберите 1–3 улучшения, которые можно внедрить прямо сейчас.
Сразу поставьте в календарь следующую сессию.

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

Заключение

Продакшен‑сбои неизбежны. Ваш выбор в том, станет ли первый серьёзный тест процесса реагирования боевой аварией или безопасной репетицией на бумаге.

Комбинируя:

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

вы создаёте Аналоговый инцидентный театр, который укрепляет и системы, и команды.

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