Аналоговый стол картографа инцидентов: как рисовать карты надёжности до следующего шторма пейджеров

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

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

«От чего на самом деле что зависит?»

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

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

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

Реагирование на инциденты не начинается в тот момент, когда «прод» падает. Оно начинается в переговорке (или Zoom‑колле) задолго до этого — с настольных учений (tabletop exercises).

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

Хорошо проведённые учения помогают:

Проверить плейбуки: существуют ли ранбуки? Можно ли их найти? Они вообще пригодны к использованию?
Выявить дырки в процессах: кто отвечает за внешние коммуникации? Кто принимает решения о мерах, влияющих на клиентов?
Обнажить недостатки инструментов: хватает ли вам наблюдаемости (observability), логирования и доступов? Или всё завязано на чужие личные SSH‑конфиги?
Протестировать каналы коммуникации: как вы координируетесь между инженерами, поддержкой, безопасностью и руководством?

И всё это происходит без потери доверия клиентов и выручки.

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

Такие упражнения стабильно вскрывают проблемы, которые проявляются только под давлением:

«Мы думали, у онколла есть доступ к базе — его нет».
«Мы вообще не знаем, что зависит от этого внутреннего API».
«Юристы должны быть в курсе, но их нет в инцидент‑канале».

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

Карта зависимостей — это больше, чем просто инвентаризация активов

У большинства организаций есть списки:

сервисы
базы данных
очереди
сторонние провайдеры
команды

Но во время инцидента список почти бесполезен. Реагирующим нужна структура.

Карта зависимостей отвечает на вопросы, на которые ваша инвентаризация не способна:

Что вызывает что?
Какие сервисы зависят от этой базы данных?
Если упадёт этот сторонний провайдер, какие клиентские сценарии сломаются?
Если эта команда недоступна, кто и какие изменения всё ещё может вносить?

Там, где инвентаризация говорит: «У нас 40 микросервисов», карта зависимостей говорит:

«Сервис A зависит от B и C; B использует базу данных X; C опирается на стороннего провайдера Y; и A, и C обслуживают checkout для enterprise‑клиентов».

Это разница между:

техническим радиусом поражения: какие системы откажут;
бизнес‑радиусом поражения: какие клиенты, фичи и потоки выручки пострадают.

И, что критично, карты подсвечивают скрытые единственные точки отказа:

тот самый «маленький» внутренний auth‑сервис, который использует каждый продукт;
единственный инженер, который умеет перезапускать легаси‑batch‑джоб;
общий CI/CD‑пайплайн, без которого ни одна команда не сможет выпустить экстренный фикс.

Без карты всё это остаётся невидимым — пока не сломается.

Почему аналоговый подход (ручное рисование) работает лучше, чем вы думаете

Скорее всего, у вас уже есть какие‑то диаграммы: автогенерируемые графы архитектуры, красивые сервис‑мапы в APM‑инструменте, может быть, CMDB. Всё это полезно — но недостаточно.

Когда вы по уши в инциденте, такие карты часто подводят, потому что они:

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

На сцену выходит аналоговый стол картографа инцидентов.

Представьте: белая доска. Стикеры. Маркеры. Стопка карточек. Цель — не красота, а общее понимание.

Ручное рисование карт надёжности даёт несколько важных преимуществ:

Заставляет думать осознанно
Когда вы проводите линию между двумя системами, вы вынуждены спросить себя: «Она правда от этого зависит? В какую сторону? При каких условиях?»
Делает сложность осязаемой
По мере того как доска заполняется, люди физически чувствуют тяжесть этого клубка стрелок. Часто это первый раз, когда команда наглядно осознаёт, насколько хрупки отдельные пути.
Улучшает запоминаемость под давлением
Физическое действие — рисовать, спорить о стрелках, переклеивать стикеры — закрепляет модель в памяти. Когда прод потом горит, люди вспоминают «тот хрупкий путь, который мы обвели красным».
Стимулирует кросс‑функциональное взаимодействие
Инфраструктура, продуктовые команды, data, SRE, безопасность и поддержка могут одновременно «тыкать пальцем» в одну и ту же доску. Разногласия всплывают и решаются в реальном времени.
Подсвечивает нетехнические зависимости
Можно картировать и людей с процессами: кто может одобрить фейловер, у кого есть доступ в прод, какие третьи стороны блокируют критичные потоки.

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

Как провести сессию по аналоговому маппингу и настольному учению

Максимальную пользу вы получите, если совместите аналоговые карты с tabletop‑упражнением.

Вот лёгкий формат.

1. Выберите сценарий, который вас реально пугает

Начните с чего‑то реалистичного и болезненного:

деградация primary‑региона базы данных;
серьёзный outage у критичного стороннего провайдера (платежи, аутентификация, DNS, email);
массовый рост латентности из‑за сетевой сегментации;
инцидент информационной безопасности: подозрительная утечка из ключевой системы.

Опишите сценарий одним абзацем: достаточно подробно, чтобы было правдоподобно, но достаточно свободно, чтобы можно было исследовать разные варианты.

2. Вместе нарисуйте первый черновик карты

В комнате (или на виртуальной доске) задайте вопросы:

Что прямо вовлечено в этот сценарий? (сервисы, хранилища данных, третьи стороны)
От чего зависят эти компоненты?
Какие клиентские сценарии на них опираются?

Рисуйте:

прямоугольники для сервисов и хранилищ данных;
другие формы или цвета для сторонних сервисов;
линии со стрелками — направление зависимости;
пометки:
- бизнес‑критичность (например, выручка, SLA);
- команда‑владелец;
- известные риски (например, «single AZ», «нет фейловера», «один мейнтейнер»).

Не гонитесь за идеальной точностью; цель — общее видение. Ожидайте много «Стоп, а оно точно от этого зависит?..» и «Надо потом проверить». Фиксируйте такие follow‑up’ы.

3. Проведите tabletop по этой карте

Теперь пройдите по инциденту так, как будто он уже случился:

смоделируйте срабатывания мониторинга;
спрашивайте: «На что вы смотрите в первую очередь?»
используйте карту, чтобы отследить возможный радиус поражения:
- «Если эта БД деградировала, какие сервисы начинают шуметь?»
- «Кого нужно звать в инцидент‑канал?»
- «Какие клиентские journeys под угрозой?»

По ходу помечайте карту:

красные линии — хрупкие зависимости;
вопросительные знаки там, где вы не уверены в поведении;
звёздочки — вероятные точки смягчения последствий (feature flags, фейловеры, graceful degradation).

Очень быстро вы увидите:

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

4. Превратите находки в конкретные улучшения

Закончите сессию извлечением конкретного списка задач:

добавить или починить мониторинг и алерты;
создать или обновить ранбуки;
прояснить роли в инциденте и маршруты эскалации;
уменьшить single point of failure — технические и человеческие.

Затем зафиксируйте «очищенную» цифровую версию карты (фото, диаграмма в wiki или лёгкая документация), но сохраняйте аналоговый дух: это живой инструмент, а не статичный артефакт.

Как поддерживать карты и не утонуть в обновлениях

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

Практичные принципы:

Фокус на критичных путях: онбординг клиентов, checkout, аутентификация, data‑пайплайны под SLA.
Регулярный пересмотр: раз в квартал или после серьёзных архитектурных изменений.
Обновление после инцидентов: если реальность вас удивила — карта была неверной, поправьте её.
Привязка к владению: на каждой карте должно быть понятно, какие компоненты за какой командой.

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

От тушения пожаров к выстроенной компетенции

Если организация игнорирует маппинг и tabletop‑упражнения, инциденты выглядят так:

хаотичные Slack‑каналы;
бесконечные попытки «попробуем вот это» вслепую;
постоянные сюрпризы по поводу того, что затронуто;
постмортемы, полные формулировок «мы не понимали» и «мы думали, что…».

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

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

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

Итог: подготовьте стол картографа до шторма

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

До того, как грянет следующий шторм пейджеров:

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

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

И именно это отличает тех, кто теряется в шторме, от тех, кто выводит остальных из него.