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

Когда на вас сваливается худшая дежурная неделя, кулер ноутбука воет, в Slack сплошная стена красных точек, Jira штампует инциденты, и все вам пишут, пейджер не замолкает, а кто‑то уже звонит на телефон.

И именно в этот момент ваш мозг становится наименее надёжным инструментом во всём стеке.

Аналоговый атлас инцидентов — это складная бумажная карта, которая лежит на столе или в вашем go‑bag, и даёт ощутимый, низкотехнологичный, но очень понятный ориентир посреди хаоса. Он не заменит вам мониторинг и ранбуки, но организует то, как вы думаете, действуете и коммуницируете под давлением.

В этом посте разберём, как спроектировать такой атлас, опираясь на ключевые элементы современной on‑call‑модели: стадии инцидента, инструменты, диаграммы и формализованные стандарты.

Зачем бумажный «атлас» для инцидентов?

Цифровые инструменты прекрасны — пока не перестают работать для людей. Во время стресса люди:

• Кликают по кругу в инструментах вместо того, чтобы следовать плану
• Забывают, как эскалировать и по каким правилам коммуницировать
• Теряют общую картину происходящего

Складная бумажная карта решает несколько ключевых проблем:

• Снятие нагрузки с памяти: процесс лежит на бумаге, а не в голове.
• Минимальное трение: не нужно бесконечно Alt+Tab‑аться между доками и дашбордами.
• Всегда доступна: не страдает от проблем с Wi‑Fi, SSO и хаоса из вкладок.
• Общее поле зрения: её легко развернуть на столе во время war room‑сессии.

Ваш аналоговый атлас инцидентов — это не замена полной документации. Скорее, это аварийный чек‑лист + карта, которая связывает воедино мониторинг, алертинг, документацию и коммуникации.

Хребет атласа: простой flowchart реакции на инцидент

В центре атласа должен быть простой flowchart (блок‑схема) обработки инцидента. Это «позвоночник», на который навешано всё остальное. На нём должны быть чётко обозначены стадии:

1. Обнаружение (Detection)
2. Триаж (Triage)
3. Коммуникация (Communication)
4. Стабилизация / смягчение последствий (Mitigation)
5. Разбор инцидента (Post‑incident review)

Старайтесь уместить это в одну страницу, идеально — первый разворот.

1. Обнаружение (Detection)

Здесь вы отвечаете на вопрос: «Как мы понимаем, что что‑то сломалось?»

На карте укажите:

• Основные системы мониторинга (например, Prometheus, Datadog, CloudWatch)
• Интегрированную систему алертинга (например, Jira Service Management, PagerDuty, Opsgenie)
• Типичные каналы обнаружения: сообщения от пользователей, автоматические алерты, внутреннее QA, системы безопасности

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

• Блок с надписью «Получен алерт / репорт»
• Стрелки от Monitoring и User Reports

2. Триаж (Triage)

На этом этапе вопрос: «Насколько всё плохо и кто за это отвечает?»

Flowchart должен подсказывать:

• Классификацию по серьёзности: короткая таблица с определениями Sev1/Sev2/Sev3
• Ответственность: кто становится Incident Commander (IC) и когда нужно вызывать узких специалистов
• Базовые первичные проверки: простые вопросы вроде:
  • Это влияет на клиентов или только на внутренние системы?
  • Уже есть известный инцидент по этой проблеме?
  • Есть ли простой немедленный rollback или failover?

3. Коммуникация (Communication)

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

Нанесите на карту:

• Внутренние каналы (например, #incidents-sev1, #on-call, видеомост)
• Внешние обновления (status page, Customer Success, Support)
• Частоту обновлений для каждой серьёзности (например, Sev1: каждые 15–30 минут)

Простой решающий блок вроде «Sev1?» может ветвиться на: «Создать отдельный канал инцидента + назначить IC + писаря» против «Обновить существующий тикет и продолжать работу».

4. Стабилизация / Mitigation

Mitigation — это ответ на вопрос: «Что мы делаем прямо сейчас, чтобы остановить утечку крови?»

На бумаге не нужно расписывать все ранбуки. Вместо этого:

• Укажите ссылки / ID ключевых ранбуков
• Покажите, где их искать (пространства в Confluence, индекс ранбуков по сервисам)
• Выделите безопасные действия «по умолчанию» (например, «откатиться на последнюю стабильную версию», «порезать rate‑limit на конкретном endpoint», «переключиться на регион X» — если применимо)

5. Разбор инцидента (Post‑incident review)

Здесь вопрос: «Что мы поняли и как сделать так, чтобы это не повторилось?»

Ваш flow всегда должен заканчиваться:

• Документацией произошедшего (в выбранном инструменте документации, например в Confluence)
• Назначением разбора инцидента (в фиксированные сроки, например, в течение 48–72 часов)
• Обновлением ранбуков, диаграмм и стандартов на основе выводов

Смысл блок‑схемы в том, что посреди хаоса вы буквально можете ткнуть пальцем, где вы находитесь:

«Сейчас мы на стадии триажа; мы ещё не задали серьёзность и не назначили IC. Сначала делаем это».

On‑call‑фреймворк, который стоит за картой

Атлас настолько хорош, насколько хороша система, которую он описывает. Эффективное дежурство — это целостный фреймворк: процессы, инструменты и протоколы, которые координируют каждый аспект реакции на инциденты.

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

• Процессы: жизненный цикл инцидента (обнаружение → триаж → коммуникация → стабилизация → разбор)
• Инструменты:
  • Стек мониторинга
  • Алертинг и тикетинг (например, Jira Service Management)
  • Документация (например, Confluence)
  • Коммуникация (Slack/Teams, Zoom, email)
• Протоколы:
  • Кто становится Incident Commander
  • Правила эскалации
  • Когда подключать руководство, юристов или PR

Этот разворот — не про красоту дизайна, а про схему проводки вашей системы реагирования.

Интеграция алертинга и мониторинга: карта должна отражать реальность

Если в атласе нарисован прекрасный процесс, который не совпадает с тем, как на самом деле работают ваши инструменты, его просто перестанут открывать.

Убедитесь, что карта отражает реальную интеграцию мониторинга и алертинга:

• Инструменты мониторинга шлют алерты в Jira Service Management (или вашу систему)
• Графики дежурств и on‑call‑расписания живут там же
• Пейджинг и политики эскалации максимально автоматизированы

В атлас стоит включить:

• Небольшую схему потока:
  • Monitoring → Alert → Jira Incident → On-call Pager → IC
• Короткий cheat sheet:
  • Где посмотреть, кто сейчас on‑call
  • Где настраиваются политики эскалации
  • Как эскалировать вручную, если автоматизация даёт сбой

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

«Если на этот пейдж никто не реагирует, какова моя следующая ступень эскалации?»

Этот путь должен быть в атласе.

Фиксируем бой: как эффективно использовать инструменты документации

Отдельный инструмент документации вроде Confluence критичен и во время инцидента, и после.

В атласе стоит подсветить два режима документации:

1. Живое состояние инцидента (online‑заметки)
2. Постмортем‑анализ

Во время инцидента

Карта должна подсказывать:

• Какой шаблон или пространство использовать для живых заметок по инциденту
• Напоминать IC или писарю отслеживать:
  • Хронологию событий
  • Ключевые решения (кто принял и почему)
  • Проверенные гипотезы и результаты

Простой чек‑лист творит чудеса:

• Создать документ инцидента из шаблона
• Приложить все связанные тикеты
• Записывать ключевые решения + timestamps

После инцидента

Для разбора инцидента атлас должен описывать:

• Где создавать postmortem‑документ
• Обязательные разделы (summary, impact, root cause, timeline, contributing factors, actions)
• Кто должен участвовать и кто утверждает результаты разбора

Можно даже оставить пустой блок или место под стикеры с подписью «Follow‑up‑задачи, которые нужно завести в Jira».

Диаграммы под огнём: сначала просто, красиво — потом

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

В атласе опишите правила для диаграмм в боевом режиме:

• Во время инцидента:

  • Используйте базовые фигуры и текст (прямоугольники — сервисы, стрелки — вызовы, молнии — отказы)
  • Подойдёт whiteboard, лист бумаги или простой drawing‑tool
  • Фокус на «что сломано и как течёт трафик», а не на идеальной архитектурной схеме

• После инцидента:

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

Включите в атлас маленькие пример‑скетчи:

• Минимальная карта зависимостей сервисов
• Примитивный before/after для митигирующего изменения (например, добавили circuit breaker, поменяли роутинг)

Сделайте акцент: быстрые, некрасивые диаграммы в живом инциденте не просто допустимы — они ожидаемы.

Не импровизируйте: стандарты планирования инцидентов

В последнем разделе аналогового атласа инцидентов сосшлитесь на ваши стандарты планирования инцидентов.

У любой сервисной компании должны быть формализованные стандарты, которые описывают:

• Серьёзности инцидентов и правила классификации
• Роли и зоны ответственности (IC, писарь, communications lead, предметные эксперты)
• Требования к инструментам (мониторинг, алертинг, документация)
• SLA/OLA по реакции и коммуникации
• Периодичность и формат разборов

В атласе это стоит ужать до:

• Cheat sheet по ролям (кто что делает при Sev1)
• Матрица серьёзностей (с примерами для каждой категории)
• Одно короткое предложение про вашу философию работы с инцидентами, например:

  «Сначала стабилизировать, потом объяснять. Коммуницировать рано и часто».

Полный стандарт может жить в Confluence, но его суть должна жить в атласе.

Как физически собрать ваш аналоговый атлас инцидентов

Вам не нужна команда дизайнеров. Вам нужны листы для принтера и немного структуры.

Предлагаемый макет:

1. Обложка: название, версия, владелец и дата последнего обновления
2. Разворот 1: блок‑схема реакции на инцидент (обнаружение → триаж → коммуникация → стабилизация → разбор)
3. Разворот 2: обзор on‑call‑фреймворка (процессы, инструменты, протоколы)
4. Разворот 3: интеграция мониторинга и алертинга, шпаргалка по эскалации
5. Разворот 4: workflow по документации (живые заметки + процесс postmortem)
6. Разворот 5: гайд по диаграммам + минимальные примеры
7. Разворот 6: стандарты по инцидентам (роли, серьёзности, принципы)

Распечатайте, сложите и держите атлас:

• Рядом с ноутбуком
• В офисной зоне команды
• В выделенных incident room / war room

Обновляйте его регулярно, как обновляете цифровые ранбуки.

Вывод: карта, когда она нужна больше всего

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

Аналоговый атлас инцидентов не пытается вместить всё. Он фиксирует скелет:

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

Сделайте его заранее. Когда начнётся «неделя из ада», эта складная карта может оказаться самым спокойным объектом в комнате.