Введение: Когда постмортема недостаточно

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

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

Здесь появляется аналоговый инцидент‑диорама: физическая реконструкция вашего худшего сбоя или инцидента информационной безопасности в масштабе обувной коробки. Представьте это как:

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

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

Зачем делать аналоговый инцидент‑диорама?

Физическая модель заставляет думать иначе, чем Confluence‑док или sequence‑диаграмма. Она:

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

Вместо «упала база данных» вы получаете:

В 09:42 дежурный SRE увидел расплывчатый алерт. В 09:47 поддержка захлёбывалась в тикетах. В 09:53 из‑за неверного Slack‑упоминания команда базы данных вообще не увидела инцидент до куда более позднего момента.

Диорама становится 3D‑сторибордом, мимо этих моментов невозможно пройти.

Шаг 1: Выберите инцидент (и задайте рамки)

Выберите один значимый сбой или инцидент безопасности — лучше тот, который:

• вовлёк несколько команд
• был полон человеческих и коммуникационных «косяков»
• ощущался запутанным и хаотичным в моменте

Затем задайте рамки:

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

Вы не пытаетесь смоделировать целую компанию. Вы строите сфокусированный, сюжетный срез реальности.

Шаг 2: Соберите сырой материал (из цифры в физику)

Соберите артефакты реального инцидента:

• Таймлайны алертов и дашборды
• Логи чатов и цепочки писем
• Записи звонков или мостов инцидента
• Таймлайны тикетов (поддержка, операции, безопасность)
• Постинцидентный отчёт или root cause analysis

Из этого выделите:

• Крупные события: то, что меняло состояние системы
• Наблюдения: кто что видел и когда
• Решения: кто что выбрал и исходя из каких предположений
• Недокоммуникации: пропущенные пинги, проигнорированные каналы, неясное владение

Всё это превратится в сцены и «пропсы» вашей диорамы.

Шаг 3: Постройте мир масштаба обувной коробки

Вам не нужны художественные навыки. Вам нужны символы и ясность.

Базовые материалы:

• Обувная коробка или картонная коробка (или несколько, по одной на домен системы)
• Нитки, стикеры, карточки
• LEGO/фигурки, бумажные вырезки или простые блоки для сервисов и людей
• Маркеры, скотч, цветные наклейки, пряжа

Набросайте три основных слоя:

1. Слой топологии системы

Используйте дно коробки как мини‑диаграмму архитектуры:

• Блоки для сервисов (API, DB, cache, auth‑провайдер)
• Линии для соединений и зависимостей
• Иной цвет или форма для внешних сервисов (облако, платёжный шлюз, IdP)

Добавьте элементы моделирования надёжности:

• Резервирование: парные блоки с общим лейблом
• Single Point of Failure (SPOF): отмечайте красным
• Пути обхода: пунктирные линии к бэкапам или режимам с деградацией

2. Человеческий и организационный слой

На стенках или втором ярусе отобразите людей и команды:

• Маленькие фигурки или карточки для дежурных инженеров, incident commander, поддержки, безопасности, продукта, руководства
• Линии или пряжа для коммуникационных путей (Slack, PagerDuty, email, телефон)
• Отдельные маркеры для сломанных или запоздалых коммуникаций

3. Слой таймлайна и сториборда

Протяните полоску бумаги или карточки по верхнему краю или вокруг коробки:

• Каждая карточка = событие с отметкой времени (09:41: первый алерт, 09:47: шквал обращений в поддержку, 10:05: неверный роллбэк)
• Соединяйте события нитками с коробкой: какой сервис изменился? кто действовал?

Теперь у вас не просто диаграмма системы, а 3D‑сториборд произошедшего.

Шаг 4: Лёгкий уклон в аналоговый хоррор

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

Можно:

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

Такой фрейминг помогает команде прочувствовать сюжетное напряжение:

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

Именно это чувство двигает подготовленность вперёд.

Шаг 5: Используйте техники tabletop‑учений

Теперь, когда у вас есть физическая модель, используйте её как поле для tabletop‑экзерсайзов:

1. Пройдите по таймлайну

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

2. Останавливайтесь в точках решений

   • Где кто‑то выбрал A вместо B?
   • Какая у него была информация? Чего не хватало или что вводило в заблуждение?

3. Задавайте вопросы "Что, если...?"

   • «Что если бы этот алерт пришёл правильной команде?»
   • «Что если бы этот failover действительно сработал?»
   • «Что если бы у поддержки был более чёткий runbook?»

4. Проигрывайте альтернативные будущие

   • Переставляйте фигурки по другому маршруту
   • Меняйте линию зависимости (например, добавьте кэш или circuit breaker)
   • Смотрите, какие части коробки всё ещё заканчиваются красным

Так ваша диорама превращается в безопасную песочницу для проверки процессов детектирования, коммуникации и восстановления.

Шаг 6: Фокус на решениях и коммуникации, а не только на технике

Большинство постмортемов чрезмерно зациклены на техническом root cause. Ваша диорама должна намеренно подсветить человеческие и организационные факторы.

Добавьте явные маркеры для:

• Неясного владения («Кто вообще должен разбирать этот алерт?»)
• Путаницы ролей (два incident commander или ни одного)
• Раздробленных каналов (пять Slack‑каналов, но нет единого источника правды)
• Задержек эскалации (критичные команды подключили через 30+ минут)
• Когнитивной перегрузки (когда один человек и логи смотрит, и пишет апдейты, и отвечает клиентам)

Дальше, двигаясь по модели, задавайте:

• Где критичная информация была заперта в одной голове или одном канале?
• Где мы оптимизировали скорость в ущерб ясности — или наоборот — и это навредило?
• Где простой ритуал (статус‑апдейты каждые 10 минут, отдельный «писарь» для коммуникаций) мог бы помочь?

Записывайте это на стикеры и приклеивайте прямо к соответствующим частям диорамы.

Шаг 7: Вплетите концепции моделирования надёжности

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

Аннотируйте модель:

• Резервирование: подсветите сервисы с реальным независимым failover по сравнению с теми, которые кажутся резервированными, но делят скрытый SPOF (один регион, одно хранилище креденциалов, одна очередь сообщений).
• Blast radius: раскрасьте сервисы по уровню влияния — что падает «тихо», а что — громко? Что полностью валит клиентов, а что даёт деградированный UX?
• Режимы отказа: отметьте разные типы отказов (ёмкостной, конфигурационный, зависимость, утечка/взлом, порча данных).
• Детектирование vs. влияние: наглядно покажите, какие отказы быстро детектируются, а какие долго остаются незамеченными.

Затем проигрывайте мини‑сценарии:

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

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

Шаг 8: Сделайте это кросс‑функциональным ритуалом

Настоящая сила появляется, когда диорама становится совместным инструментом, а не одноразовым эффектом.

Пригласите:

• Инжиниринг (разработка, SRE, платформа)
• Безопасность
• Поддержку / customer success
• Продакт‑ и програм‑менеджеров
• Инцидент‑менеджеров и/или руководство

Используйте сессию, чтобы:

• Спросить: «Что пошло не так?» — с каждой точки зрения
• Спросить: «Что мы сделаем иначе в следующий раз?» — и зафиксировать конкретные изменения
• Выявить пробелы в обучении (готовность к on‑call, знание туллинга)
• Превратить инсайты в тикеты, runbook’и и обновления playbook’ов

Оставьте диораму на виду (war room, зона команды, либо сфотографируйте и задокументируйте) как живой артефакт обучения.

Шаг 9: Повторяйте на новых сценариях

Не останавливайтесь на одном.

Сделайте аналоговые инцидент‑диорамы регулярной практикой:

• Пересобирайте тот же инцидент после крупных изменений архитектуры или процессов
• Моделируйте новые, гипотетические сценарии:
  • Крупный отказ облачного провайдера
  • Атака с вымогательским ПО (ransomware)
  • Компрометация CI/CD‑пайплайна
  • Региональный сетевой раздел (network partition)
• Сравнивайте модели «старого мира» и «нового мира»: действительно ли изменения снизили риск

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

Заключение: Превращаем боль в практику

Обувная коробка, полная ниток и бумажек, не починит ваши системы. Но она:

• Покажет, как на самом деле разворачиваются сбои, выходя за рамки аккуратной формулировки root cause
• Сделает невидимые зависимости и SPOF’ы невозможными для игнорирования
• Подсветит точки решений, пути коммуникации и человеческие ограничения
• Даст командам безопасный способ тренировать реакции на сложные, «грязные» отказы

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

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