Введение: когда дежурство похоже на бой с боссом, к которому вас никто не готовил

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

Вырубается электричество в ключевом офисе или дата‑центре. Падает критичный SaaS в часы пика. На общем диске всплывает записка с требованиями выкупа.

И внезапно все:

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

А потом, когда все более‑менее уляжется, звучит знакомая фраза:

«Нам надо бы чаще проводить учения по инцидентам».

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

Представьте смесь Dungeons & Dragons и runbook’ов по инцидентам — с таким количеством «игровости», что людям действительно захочется в это играть.

Что такое аналоговая игровая доска для инцидентов?

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

Ключевые идеи:

• Недорого и аналогово: никакого спецПО. Только распечатанная доска, листы персонажей, карточки сценариев и фасилитатор.
• Ролевая игра в основе: участники создают персонажей — по мотивам реальных ролей в вашей организации — и отыгрывают решения в ответ на развивающийся инцидент.
• Сценарии под вашу организацию: вы не тренируетесь на абстрактных проблемах, вы моделируете ваши реальные объекты, системы, подрядчиков и ограничения.
• Безопасно, но реалистично: ставки низкие и формат игровой, но проблемы, компромиссы и напряжение очень похожи на реальный онколл‑хаос.

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

Зачем превращать инциденты в игру?

1. Практика без давления и страха

Реальные инциденты — это высокие ставки. Люди:

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

В игре реальные системы не ломаются. Клиенты не страдают. Эта психологическая безопасность позволяет участникам:

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

2. Выявлять дыры до того, как это сделает реальность

Проигрывая реалистичные сценарии, вы быстро вскрываете:

• пропущенные шаги в runbook’ах и планах реагирования
• неясность, кто какие решения вправе принимать
• коммуникационные провалы между командами (IT, эксплуатация, HR, коммуникации и др.)
• невысказанные допущения, на которых всё держится, но нигде не написано

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

3. Формировать мышечную память через повторение

Как и любой навык — от СЛР до пожарных тренировок и осведомленности по безопасности — реагирование на инциденты становится лучше, когда его регулярно отрабатывают.

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

• проводить короткие сессии раз в месяц или квартал
• варьировать сценарии, покрывая разные зоны риска
• онбордить новичков через игру, а не через пачку PDF’ов

Со временем шаблоны поведения становятся автоматическими:

• кого уведомлять
• какой канал связи использовать
• какой playbook применим
• когда и кому эскалировать

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

Как устроена игра (на высоком уровне)

В основе игры четыре строительных блока:

1. Игровое поле (gameboard) — визуальная карта вашей среды:

   • ключевые объекты или офисы
   • критичные системы и сервисы
   • каналы коммуникации (Slack, email, пейджинг, телефоны)
   • группы стейкхолдеров (внутренние и внешние)

2. Персонажи — каждый участник играет роль, например:

   • дежурный инженер / SRE
   • менеджер по эксплуатации объектов (Facilities Manager)
   • HR‑бизнес‑партнер
   • руководитель по коммуникациям / PR
   • офицер безопасности / Security Officer
   • исполнительный спонсор / Incident Commander

3. Карточки сценариев — инцидентные «завязки», описывающие, что произошло:

   • «Отключение электричества в основном дата‑центре в рабочее время».
   • «Обнаружен ransomware на ноутбуках сотрудников в одном регионе».
   • «Сильный шторм одновременно угрожает двум ключевым объектам».

4. Фасилитатор и шкала времени — человек или небольшая команда, которая управляет:

   • тем, как развивается инцидент (новые факты, осложнения, ограничения)
   • давлением времени (например, сдвигая «игровые часы» на 5–10 минут
   • тем, какая информация доступна и когда

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

Ролеплей: реагирование на инциденты встречается с Dungeons & Dragons

Заимствование механик настольных RPG — это то, что делает эту практику вовлекающей, а не очередным унылым tabletop‑упражнением.

Создание персонажей (по‑корпоративному)

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

• Зоны ответственности (что он реально делает при инциденте)
• Полномочия (что может решить сам, без согласования)
• Ограничения (рабочие часы, требования закона, профсоюзные правила и т. п.)

Можно добавить и характерные черты — чисто для интереса, например:

• «Слишком осторожен, эскалирует всё подряд».
• «Чересчур уверенный в себе, почти никогда не просит помощи».

Эти черты часто рождают очень правдоподобное трение в принятии решений — как в реальной жизни.

Проживаем инцидент

Фасилитатор объявляет сценарий:

«15:12. В главном офисе пропало электричество. Включилось аварийное освещение, но сетевое оборудование погасло. Пока непонятно, это проблема здания или сбой на уровне энергосети».

Дальше:

1. Игроки объявляют действия: кому звонят, что проверяют, что говорят сотрудникам.
2. Фасилитатор описывает последствия: дает новую информацию, добавляет осложнения или ограничения.
3. Инцидент либо эскалирует, либо стабилизируется: в зависимости от решений.

Поскольку это игра, можно:

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

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

Проектирование сценариев: от одного офиса до многообъектного хаоса

Одно из преимуществ аналоговой игровой доски — то, как легко наращивать сложность сценариев.

Начните просто: одиночные инциденты

Сначала берите узкие сценарии, например:

• отключение электричества в одном объекте
• выход из строя сетевого коммутатора в одном офисе
• простой критичного SaaS‑поставщика для одного бизнес‑юнита

Они идеально подходят для того, чтобы:

• проверить базовые цепочки уведомлений
• уточнить, кто за какие решения отвечает
• убедиться, что ваши runbook’и соответствуют реальности

Повышаем уровень: мульти‑сайтовые и комбинированные события

Когда команда освоится, добавляйте новые слои сложности:

• одновременные сбои в двух регионах
• наложение инцидентов (например, ИБ‑инцидент во время стихийного бедствия)
• сбой у внешнего поставщика, который бьет по нескольким внутренним системам сразу

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

• число затронутых стейкхолдеров
• необходимость коммуникаций с руководством
• важность приоритезации и компромиссов

Одна и та же игровая доска легко масштабируется — от блэкаута в одном здании до масштабных кризисных симуляций на уровне всей организации.

Сделайте игру кросс‑функциональной — иначе она провалится

Реальные инциденты никогда не бывают «просто проблемой IT». Поэтому кросс‑функциональное участие — не опция, а требование.

Включайте представителей:

• Операционной деятельности / эксплуатации — за влияние на процессы и непрерывность
• Службы эксплуатации зданий (Facilities) — за электричество, доступ и физическую безопасность
• IT / SRE / безопасности — за системы, данные и технический триаж
• HR — за кадровые политики, безопасность людей, удаленную работу
• Коммуникаций / PR — за внутренние и внешние сообщения
• Руководства — за принятие рисков и крупные решения

По мере разворачивания игры вы очень быстро увидите:

• где цепочки подчиненности и полномочий размыты
• какие команды регулярно выпадают из информационного контура
• как сталкиваются противоречащие друг другу приоритеты под стрессом

Это «трение» превращается в практические входные данные для уточнения ролей, runbook’ов и шаблонов коммуникаций.

Как превратить мучения от блэкаута в энергию «игрового вечера»

Здесь есть приятная симметрия:

Во время настоящего отключения электричества дома люди часто достают настольные игры, карты, игры в комнате, чтобы скоротать время.

Аналоговая игровая доска для инцидентов опирается на тот же дух:

• физические компоненты на столе
• совместное решение задач
• общий сюжет, через который вы проходите вместе

Делая процесс веселым и осязаемым, вы резко повышаете вероятность, что:

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

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

После игры: где появляется основная ценность

Сама игра — это лишь половина пользы. Вторая половина — то, что вы делаете после.

Проведите короткий, но структурированный разбор (after‑action review):

1. Что вас удивило?
2. В каких местах мы тормозили или зависали?
3. Какие решения были неочевидными или спорными?
4. Какие документы или процессы нужно обновить?
5. Что вы бы сделали иначе в следующий раз?

Зафиксируйте конкретные действия:

• обновить runbook’и и playbook’и
• уточнить, кто владеет какими решениями
• скорректировать политики эскалации и списки контактов
• создать или доработать шаблоны коммуникаций

Затем встроите эти улучшения в следующую игровую сессию.

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

Заключение: от хаоса к ремеслу

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

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

• превращаете онколл‑хаос в повторяемую, низкорисковую практику
• используете ролеплей в стиле RPG, чтобы сделать серьезное обучение увлекательным
• вовлекаете кросс‑функциональных стейкхолдеров в реалистичные сценарии
• заранее выявляете и устраняете дыры в процедурах, коммуникациях и принятии решений

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

Стресс останется, но ситуация уже не будет незнакомой.

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