Лабиринт инцидента с карандашом и стикерами: как спроектировать «нулевой по инструментам» драй‑ран перед следующей бурей пейджеров

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

Никакого Slack. Никакого Zoom. Никакого Jira. Никакого incident‑бота. Никаких дашбордов. Только звонящий телефон, белая доска и стопка стикеров.

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

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

Зачем вообще проектировать учения без инструментов?

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

Полной наблюдаемостью и дашбордами
Каналами чата в реальном времени
Автоматическими инцидент‑тикетами и роутингом
Интегрированными runbook’ами и ботами

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

Никто толком не знает, кто объявляет уровень инцидента
Контакты хранятся только в облачных системах, которые сейчас недоступны
Роли и зоны ответственности размыты без incident‑бота, который их раздаёт
Решения тормозятся, потому что никто не видит одни и те же данные в одном месте

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

Аналоговая готовность: почему ручка и бумага всё ещё важны

Во время серьёзных киберинцидентов и масштабных сбоёв реакция часто откатывается к удивительно простым средствам:

Ручки и бумажные блокноты для логов и таймлайнов
Стикеры (Post‑it) для задач, владельцев и приоритетов
Белые доски или флипчарты для общей картины происходящего
Распечатанные деревья контактов и оргструктуры для эскалации
Печатные runbook’и и playbook’и для критически важных процедур

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

Если ваш процесс существует только внутри инструментов, у вас на самом деле нет процесса — у вас есть зависимость.

Базовая идея: сначала мануал, потом автоматизация

Учения без инструментов заставляют ответить на простейший вопрос:

«Если вся наша автоматизация исчезнет, как мы всё равно сможем компетентно управлять инцидентом?»

Отсюда рождаются три принципа проектирования:

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

Автоматизация накладывается поверх надёжного ручного каркаса — но никогда не заменяет его.

Берём идеи из SRE: роли и ритуалы — без инструментов

Site Reliability Engineering (SRE) и современный incident management дают проверенную структуру: роли, ритуалы и playbook’и. Эти паттерны можно напрямую адаптировать под офлайн‑учения.

Минимальный набор ролей для учения без инструментов:

Incident Commander (IC)
Владеет процессом реагирования, расставляет приоритеты, управляет временем, принимает финальные решения.
Operations / Tech Lead
Координирует диагностику и восстановительные работы по системам.
Communications Lead
Отвечает за коммуникации со стейкхолдерами, руководством и, при необходимости, клиентами.
Scribe / Timeline Owner
Ведёт письменный лог событий, решений и действий.

В повседневных инцидентах эти роли могут частично раздавать боты или их «по умолчанию» назначают в чате. В учении без инструментов вы осознанно назначаете и ротируете их только аналоговыми средствами.

Ритуалы, которые стоит сохранить даже офлайн:

Первые 5 минут: подтвердить роли, зафиксировать определение инцидента и поставить ближайшую цель.
Регулярные статус‑хэддлы: каждые 10–15 минут собираться, сверять статус и переприоритизировать задачи.
Явные решения: записывать ключевые решения и их обоснования на доске или в бумажном логе.
Чёткий критерий завершения: определить, что значит «стабилизировали ситуацию», и кто это объявляет.

Если вы способны стабильно выполнять это без инструментов, ваша уязвимость к их сбоям сильно снижается.

Как спроектировать свои первые учения без инструментов

Не обязательно начинать с апокалиптического сценария. Важно другое: никому нельзя полагаться на обычные инструменты.

1. Определите ограничения

Задайте правила игры:

Без Slack, Teams или аналогичных чатов
Без видеоконференций
Без incident management‑платформ и ботов
Без тикетинга на время учения
Ограниченный или отсутствующий доступ к боевым дашбордам (или смоделируйте это)

Разрешите базовые каналы связи, которые в реальности у вас, вероятно, останутся:

Телефонные звонки (мобильные и стационарные)
SMS
Очное общение

2. Подготовьте аналоговый набор инструментов

До начала учения соберите физические материалы:

Распечатанные описания ролей и зон ответственности в инциденте
Бумажный шаблон таймлайна инцидента (время, событие, кто действовал)
Распечатанное дерево контактов (on‑call инженеры, руководители, вендоры)
Распечатанные runbook’и для типовых сценариев отказов
Белые доски / флипчарты, маркеры и стикеры

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

3. Выберите сценарий

Определите реалистичную, «болевую» проблему, например:

Массовый сбой аутентификации
Ошибка в DNS, из‑за которой теряется внешний доступ
Серьёзная деградация в регионе облачного провайдера
Обнаружен ransomware в ключевом окружении

Для первого учения немного упростите техническую часть и сфокусируйтесь на сложности координации.

4. Проведите его как настоящий шторм пейджеров

Смоделируйте хаос:

Запустите учение, как реальный пейдж (в заранее оговорённых рамках)
Назначьте стартовые роли (IC, Tech Lead, Comms Lead, Scribe)
Используйте телефоны и очные хэддлы как основные каналы
Фиксируйте действия и статус на досках и в бумажных логах
Задайте давление по времени и конкурирующие приоритеты

Ключевой момент: никакого «читинга». Если кто‑то тянется к Slack «просто чтобы уточнить», считайте, что сервис недоступен.

5. Жёсткий разбор полётов

Сразу после учения проведите структурированный ретроспективный разбор. Сфокусируйтесь на:

Где ломалась коммуникация?
Какие решения задерживались — и почему?
Знали ли люди, где искать контакты и runbook’и?
Были ли роли понятны? Чувствовал ли себя IC перегруженным или без поддержки?
Какой информации всем очень не хватало, но её нельзя было получить?

Преобразуйте это в конкретные доработки:

Новые или улучшенные печатные runbook’и
Обновлённые деревья контактов и пути эскалации
Уточнённые описания ролей и бэкапов по ним
Чек‑листы для «первых 15 минут» и для «объявления стабилизации / all‑clear»

Повторяйте лабиринт: формируем мышечную память

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

Сделайте их частью регулярной операционной практики:

Проводите мини‑учение без инструментов раз в квартал для каждой ключевой команды
Выделяйте одно большее кросс‑функциональное учение раз в год
Ротируйте роль Incident Commander между разными людьми
Меняйте сценарии: киберинциденты, сбои у вендора, неудачные внутренние изменения

Со временем вы заметите:

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

Цель не в том, чтобы отказаться от инструментов. Цель в том, чтобы инструменты были опциональными ускорителями, а не единственными точками отказа.

Комбинируем автоматизацию с надёжными ручными фоллбэками

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

Incident‑боты, которые зеркалят критичную информацию в удобные для печати сводки
Тикетинговые системы, которые экспортируют офлайн‑готовые деревья контактов и ролей
Дашборды, которые можно регулярно выгружать снапшотами (например, в PDF)
Runbook’и, начинающиеся с секции «manual mode»: что делать, если сама платформа недоступна

Это и есть оптимальная точка:

Автоматизированные возможности для скорости и масштаба, когда всё работает
Надёжные ручные фоллбэки, когда эти возможности исчезают

Устойчивые операции не предполагают, что инструменты будут всегда. Они предполагают обратное — и от этого отталкиваются.

Заключение: тренируйтесь теряться, чтобы уметь находить выход

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

Проектирование и проведение учений без инструментов готовит вас не только к такому сценарию. Оно:

Выявляет скрытые зависимости от инструментов
Вызывает необходимость прояснить роли и порядок принятия решений
Укрепляет процесс так, чтобы автоматизация имела прочный фундамент
Даёт команде уверенность, что она может работать и «в темноте»

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

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