Введение

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

Премортем переворачивает сценарий. Вместо вопроса «Что пошло не так?» вы спрашиваете: «Представим, что прошло три месяца: релиз провалился с треском. Что случилось?» Вы репетируете аварию до того, как она вообще возникнет.

Теперь добавим ещё один поворот: делайте это аналогово.

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

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

Зачем нужны премортем‑репетиции инцидентов

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

«Предположим, что проект провалился катастрофически. Давайте пойдём назад и разберёмся, почему.»

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

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

Премортем особенно полезен в сложных ИТ‑ландшафтах, где ни один человек не видит систему целиком. В нём могут участвовать все — разработка, SRE, платформа/инфраструктура, безопасность, продукт, поддержка — каждый приносит свой кусочек пазла.

Свиток сценария инцидента: зачем уходить в аналог

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

• Физическое присутствие: гигантский свиток на полу или стене трудно игнорировать. Он фокусирует внимание всех в одном общем пространстве.
• Общий ментальный образ: люди буквально стоят вокруг одной карты, указывают на сервисы, рисуют стрелки, спорят о связях.
• «Втелесный» обход сценария: участники могут проходить по таймлайну, следуя по гипотетическому инциденту по минутам, шаг за шагом.
• Низкое трение: маркеры и стикеры часто быстрее, чем возиться с диаграммами на экране в ходе встречи.

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

Шаг 1: Определите чёткие цели премортема

До того как развернуть бумагу, решите, что именно вы репетируете и зачем.

Проясните:

1. Область (scope)

   • Вы фокусируетесь на конкретном изменении (например, миграция базы данных, запуск новой фичи)?
   • Или на категории отказов (например, сбой identity‑провайдера, отказ региона в облаке)?

2. Цели

   • С чем именно вы хотите уйти с сессии?
   • Примеры:
     • Приоритизированный реестр рисков
     • Список новых алертов и дашбордов для реализации
     • Улучшения ранбуков и темы для обучения дежурных

3. Участников

   • Включите людей из:
     • команд разработки приложений
     • SRE / платформы / инфраструктуры
     • безопасности
     • клиентской поддержки / операций
     • продукта или бизнес‑стейкхолдеров, где это уместно

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

Шаг 2: Разверните свиток и нарисуйте карту системы

Разверните бумагу по полу, вдоль длинного стола или на стене коридора. Это ваш холст для системы и истории.

Разделите его по двум главным осям:

1. Горизонтальная ось: время / таймлайн инцидента

   • Слева: T‑0 (изменение уходит в прод) или T‑0 (появляется первый симптом)
   • Справа: T+X часов (инцидент закрыт, начат RCA)
   • Пометьте ключевые временные точки: T+5m, T+15m, T+1h и т.д.

2. Вертикальная ось: слои системы и акторы

   • Верх: внешние акторы (пользователи, сторонние сервисы)
   • Ниже: edge / API / frontend
   • Середина: сервисы, микросервисы, бизнес‑логика
   • Ниже: хранилища данных, очереди, кэши, инфраструктура, сеть
   • Внизу: команды и роли (он‑колл, поддержка, incident commander и т.п.)

Используя цветные маркеры и стикеры:

• Нарисуйте блоки для сервисов, инструментов и внешних зависимостей.
• Обозначьте потоки данных и критические пути.
• Отметьте известные single point of failure.
• Пометьте, где у вас есть наблюдаемость (observability), а где нет.

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

Шаг 3: Продумайте «что пошло не так» в реалистичных деталях

Когда свиток разложен, переключайтесь в режим премортема.

Задайте ключевой вопрос:

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

Организуйте совместный брейншторм:

1. Тихая генерация идей (5–10 минут)

   • Каждый записывает гипотетические отказы на стикерах, например:
     • «Новый конфиг‑флаг отключил rate limiting → downstream‑БД перегружена.»
     • «Сторонний auth‑провайдер изменил API → ошибки при логине.»
     • «Миграционный скрипт застопорился на середине → неконсистентные данные в регионе B.»

2. Кластеризация по темам и размещение на свитке

   • Размещайте каждый стикер там, где он проявился бы на карте системы и на таймлайне.
   • Группируйте схожие типы отказов (например, порча данных, всплески латентности, auth‑ошибки).

3. Рассказ истории инцидента

   • Выберите один сценарий и расскажите его так, будто он уже произошёл:
     • Когда возник первый симптом?
     • Что видели пользователи?
     • Что увидел (или не увидел) он‑колл?
     • Как проблема эскалировала и распространялась по системе?

Записывайте эту историю вдоль временной оси. Рисуйте стрелки, показывая каскадные эффекты: небольшой сбой во вспомогательном сервисе перерастает в полномасштабную аварию из‑за ретраев, «стадного наплыва» запросов или неправильно настроенных фолбеков.

Шаг 4: Тщательно отобразите зависимости и каскадные риски

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

• «Некритичный» внутренний API падает, но от него тихо зависят три критичных для выручки сервиса.
• Фоновый job ведёт себя некорректно, забивает очереди и задерживает пользовательские операции.
• Общий кластер кэша настроен под один сценарий, но его забивает другой.

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

• Пройти по цепочкам сервис → хранилище данных → сторонний сервис.
• Отметить общие ресурсы (БД, кэши, message bus’ы, системы feature flag’ов, CI/CD‑инструменты).
• Выявить межкомандные зависимости, которые будут критичны во время инцидента.

Каждый раз, когда кто‑то говорит: «Подождите, я не знал, что это зависит от X», — обведите это место. Это первоочередные кандидаты на улучшение мониторинга, изоляции или надёжности.

Шаг 5: Превратите воображаемые отказы в конкретные планы

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

Для каждого крупного сценария, который вы проработали на свитке, зафиксируйте:

1. Записи в реестре рисков

   • Описание риска
   • Вероятность и влияние (даже если оценка грубая)
   • Задействованные компоненты системы

2. Планы по снижению риска (mitigation)

   • Изменения дизайна или архитектуры (например, circuit breaker’ы, bulkhead‑паттерны, корректный backpressure)
   • Изменения процессов (например, поэтапные релизы, feature flag’и, окна заморозки изменений)
   • Покрытие тестами (chaos‑тесты, нагрузочные, интеграционные)

3. Action items

   • Новые или улучшенные алерты и SLO
   • Обновления ранбуков и ролей в инцидент‑менеджменте
   • Обучение или симуляции для дежурных инженеров

Назначьте понятных ответственных и сроки. Перенесите стикеры в ваши стандартные инструменты: трекер задач, систему управления рисками или roadmap по надёжности.

Шаг 6: Интегрируйте инсайты с вашими инструментами инцидент‑менеджмента

Не позволяйте аналоговому свитку существовать в вакууме. Встройте его результаты в вашу цифровую экосистему инцидентов:

• Алертинг и мониторинг

  • Для каждого ключевого пути отказа спросите: «Как мы быстро поймём, что это происходит?»
  • Добавьте или уточните алерты, дашборды, SLO, трассировки.

• Маршруты эскалации

  • Если сценарий затрагивает несколько команд или вендоров, убедитесь, что ваши политики эскалации отражают эту реальность.
  • Обновите он‑колл ротации, списки контактов и плейбуки для incident commander’ов.

• RCA и инструменты управления инцидентами

  • Используйте премортем‑истории как готовые шаблоны для будущих RCA.
  • Когда произойдёт реальный инцидент, сравните его с ранее проработанными сценариями. Смогли ли вы его предсказать? Помогли ли принятые меры?

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

Шаг 7: Повторяйте и дорабатывайте — не давайте свитку устареть

Системы развиваются; архитектуры дрейфуют; зависимости подкрадываются незаметно. Одноразовый премортем быстро теряет актуальность.

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

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

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

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

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

Заключение

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

Процесс прост:

1. Определите чёткие цели и scope.
2. Разверните свиток и набросайте таймлайн и слои вашей системы.
3. Придумайте реалистичные истории о том, «что пошло не так».
4. Отрисуйте зависимости и выявите каскадные пути отказа.
5. Превратите сценарии в реестр рисков, меры по снижению и action items.
6. Интегрируйте инсайты с вашими инструментами инцидент‑менеджмента.
7. Повторяйте и дорабатывайте процесс по мере эволюции архитектуры.

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