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

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

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

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

В этом посте — как это работает, почему это эффективно и как провести свою первую сессию.

Что такое карандашный театр аварий из бумажных кукол?

Представьте себе смесь настольной репетиции инцидента и сторибординга.

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

Смысл не в художественных талантах. Палочки и кружочки вполне подойдут. Важно следующее:

• Нарративная структура (ясное начало, середина, конец)
• Видимые взаимодействия (кто кого вызывает, кто от кого зависит)
• Общее понимание (все видят одну и ту же «сцену»)

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

Зачем куклы, если у нас есть дашборды?

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

1. Низкорисковый и недорогой «симулятор» инцидентов

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

Карандашный театр аварий — это низкорисковый и дешёвый способ симулировать инциденты:

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

Вы быстро можете исследовать, например:

• «Что будет, если умрёт целый регион?»
• «Что, если сторонний API начнёт возвращать абракадабру вместо ошибок?»
• «Что, если алерты начнут приходить с задержкой в 10 минут?»

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

2. Выявление скрытых путей отказа и крайних случаев

Формальные ревью и автоматические тесты критически важны — но обычно они фокусируются на известных путях:

• Задокументированные зависимости
• Задуманные потоки
• Ожидаемые условия ошибок

Когда вы разыгрываете инциденты как историю, люди естественным образом начинают импровизировать:

• «Подождите, разве мобильное приложение не ходит напрямую ещё и в Сервис B?»
• «Если эта очередь забьётся, разве биллинг тоже не начнёт задерживаться?»
• «А кто вообще владеет этим легаси cron‑джобом, который ретраит до бесконечности?»

Именно в этой импровизации всплывают скрытые пути отказа.

Комбинация нарратива и визуальных «кукол» облегчает поиск:

• Неожиданных транзитивных зависимостей
• Неочевидных общих узких мест (например, «все эти сервисы ходят в один и тот же сервис feature flags»)
• Краевых случаев вокруг ретраев, таймаутов и деградированных режимов

Традиционные диаграммы архитектуры статичны; театр кукол — динамичен. Вы видите, как система ведёт себя во времени, а не просто где нарисованы квадратики и стрелочки.

Превращаем системы в персонажей и сцены

Сердце метода — относиться к компонентам как к персонажам истории.

Шаг 1. Подберите «актёров»

Сделайте для каждой важной сущности простую карточку:

• Системы и сервисы: API Gateway, Search Service, Payment Processor, Feature Flags, Auth Service
• Хранилища данных: User DB, Cache, Analytics Warehouse
• Внешние зависимости: Email Provider, SMS Gateway, Third-Party API
• Пользователи и роли: End User, On-call Engineer, SRE, Support, Manager

Добавьте на каждую карточку короткие пометки:

• Назначение: «хранит пользовательские сессии», «обрабатывает checkout»
• Фрагменты SLO/SLA: «p95 < 200 ms», «цель — три девятки аптайма»
• Известные особенности: «rate‑limited», «медленные cold start», «один регион»

Это и будут ваши куклы.

Шаг 2. Определите сюжет

Как и любой хорошей пьесе, вашей аварии нужен сюжетный каркас:

1. Завязка — Нормальная работа; как пользователи и системы взаимодействуют в хороший день.
2. Заводящее событие — Что‑то ломается или деградирует.
3. Эскалация — Влияние распространяется, появляются новые симптомы, людей пэйджат.
4. Кульминация — Ключевые решения, компромиссы и вмешательства.
5. Развязка — Системы восстанавливаются, фиксируются follow‑up’ы.

Вы можете набросать этот план на доске, а затем позволить команде заполнить детали.

Шаг 3. Разыграйте

Теперь проведите сценарий как живую репетицию:

• Один человек играет Нарратора («В 14:03 латентность до базы данных резко возрастает…»).
• Остальные берут персонажей и двигают их или говорят от их имени («Search Service: не могу получить результаты из БД, начинаю отдавать пользователям таймауты»).
• Фасилитатор задаёт вопросы: «Кто замечает первым?», «Какие алерты срабатывают?», «Кого пэйджат?», «Что вы пробуете сделать?»

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

Репетиционная техника для реальных инцидентов

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

Он помогает командам тренировать:

• Координацию под стрессом — Кто ведёт инцидент? Кто общается вовне? Кто ныряет в логи?
• Принятие решений — Откатываемся, переключаемся на другой регион или уходим в read‑only режим?
• Коммуникационные паттерны — Как держать стейкхолдеров в курсе, не мешая тем, кто чинит?

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

• Младшие инженеры видят, как выглядит «хороший» ответ на инцидент.
• Сеньоры вытаскивают наружу неявные знания, которые никогда не документировали.
• Все учатся говорить на языке влияния, рисков и компромиссов.

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

Межфункциональное обучение, а не только игра SRE

Одно из главных преимуществ формата театра кукол — он вовлекает не только инженеров в разговор о надёжности.

Поскольку вся система лежит перед глазами на столе:

• Продукт‑менеджеры могут спросить: «Если это падает, какие именно пользовательские сценарии ломаются?»
• Поддержка может рассказать: «Вот на что чаще всего жалуются клиенты, когда это тормозит».
• Безопасность может подсветить: «Такое fail‑open поведение — рискованно».

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

• Вместо «p95 латентности базы превысил порог» вы можете сказать: «Персонаж User DB отвечает медленно, поэтому Search Service заставляет пользователей дольше ждать, и они начинают постоянно обновлять страницу».

Эта общая история:

• Формирует психологическую безопасность («Не знать всё до мелочей — нормально, мы вместе разбираемся»).
• Стимулирует открытую коммуникацию («Эта часть системы всегда была для меня тёмным лесом — давайте пройдём её пошагово»).
• Делает возможными межфункциональные обсуждения компромиссов («Если мы приоритизируем этот фикс по надёжности, он уберёт вот эти три сценария аварий, которые мы только что разыграли»).

От размытых инициатив к конкретным сторибордам

Многие инициативы по надёжности стартуют с расплывчатых лозунгов:

• «Нужно повысить резилиентность».
• «Надо сократить MTTR инцидентов».
• «Нужно сделать платёжный пайплайн более надёжным».

Театр кукол превращает такие общие формулировки в конкретные, визуальные сториборды:

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

Каждая итерация быстрая:

• Меняете карточки.
• Перерисовываете стрелки.
• Пробуете новую сцену.

Вместо абстрактных споров вы просто показываете на стол и говорите:

«С этим изменением, когда падает Email Provider, мы откладываем письма в очередь и продолжаем оформлять заказы, а не валим весь order целиком».

Теперь «повысить резилиентность» — это не философия, а цепочка понятных, согласованных поведений системы.

Делаем работу по надёжности увлекательной (и запоминающейся)

Заимствование из театра и кукольного представления — ролей, сцен, сценариев — это не просто милота. Так знания лучше закрепляются.

Люди лучше запоминают:

• Истории — лучше, чем цифры
• Персонажей — лучше, чем компоненты
• Диалоги — лучше, чем диаграммы

После сессии кто‑то может сказать:

• «Помните, как Feature Flags упал и утащил за собой половину приложения?»
• «Мы тогда поняли, что On‑call Engineer вообще не знал про обходной read‑only endpoint».

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

Театральный формат делает работу по надёжности ещё и менее пугающей:

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

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

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

Не нужен большой запуск. Начните с малого.

1. Выберите область
   Возьмите один пользовательский сценарий или подсистему (например, «логин пользователя» или «checkout‑флоу»).

2. Соберите 4–8 человек
   Обязательно: хотя бы один инженер, один онколл или SRE и один не‑инженер (PM, поддержка и т.п.).

3. Подготовьте базовые материалы

   • Карточки или стикеры
   • Ручки/маркеры
   • Стол или поверхность доски

4. Нарисуйте персонажей
   Сделайте карточки для ключевых сервисов, хранилищ данных, пользователей и ролей.

5. Набросайте один сценарий инцидента
   Например: «Primary‑нода базы данных становится медленной и периодически уходит в таймауты в часы пик».

6. Разыграйте

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

7. Зафиксируйте инсайты
   На отдельном листе запишите:

   • «Неизвестности» и сюрпризы
   • Скрытые зависимости
   • Дыры в процессах или инструментах
   • Идеи улучшений

8. Определите 1–3 follow‑up’а
   Превратите инсайты в конкретные задачи (например, «Задокументировать зависимость от Feature Flags», «Добавить алерт на рост очереди», «Описать плейбук для read‑only режима»).

Проводите такие сессии регулярно. Относитесь к ним как к настольным пожарным учениям для ваших систем.

Заключение: репетируйте аварию до того, как она случится

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

Карандашный театр аварий из бумажных кукол даёт:

• Низкорисковый, недорогой симулятор инцидентов и аварий
• Способ выявлять скрытые пути отказов и крайние случаи
• Общий нарратив, выравнивающий инженеров, PM’ов и стейкхолдеров
• Пространство для репетиций, чтобы отрабатывать реакцию на инциденты до того, как они случатся
• Инструмент, который превращает размытые цели по надёжности в конкретные визуальные сториборды
• Запоминающийся, вовлекающий формат, заимствованный у театра и кукольных представлений

Не нужно никакого нового софта. Только бумага, карандаши и готовность представить свои системы персонажами на сцене.

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