Введение: когда в наблюдаемости гаснет свет

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

Но что, если:

• ваш кластер мониторинга лег
• у облачного провайдера «частичный сбой» (читай: хаос)
• отвалилась SSO или VPN, и никто не может дойти до дашбордов
• сетевое разделение отрезало ваши основные инструменты

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

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

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

Почему бумага всё ещё имеет значение в цифровой «war room»

Настенная бумажная карта даёт три преимущества, которых нет у дашбордов:

1. Она не падает. Не нужен логин, сеть или электричество.
2. Она по определению общая. Все в комнате буквально смотрят на одну и ту же картинку.
3. Она заземляет обсуждение под стрессом. В экстренных ситуациях людям проще думать и объяснять, когда можно на что‑то показать пальцем.

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

Когнитивные карты: чему можно научиться у пожарных

Пожарных учат строить когнитивные карты горящих зданий:

• где находятся выходы и лестницы
• какие стены — несущие
• куда с наибольшей вероятностью пойдёт огонь дальше

Они редко видят всё здание целиком, но держат в голове модель, которая позволяет действовать быстро, имея только фрагменты информации.

Вашим инженерам нужно нечто похожее.

Цель аналогового «сабвей‑чертежа» — не идеальная точность. Его задача — помочь участникам инцидента сформировать и совместно обновлять когнитивную карту того,

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

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

Шаг 1. Разбейте систему по типам зависимостей

Полезная аналоговая карта начинается с чётко выделенных слоёв зависимостей. Минимум стоит разделить:

1. Инфраструктуру
   • Compute (ноды, кластеры, autoscaling‑группы)
   • Сеть (VPC, подсети, шлюзы, балансировщики нагрузки)
   • Хранилища (блочные, объектные, общие файловые системы)
2. Приложения / сервисы
   • Пользовательские сервисы (API, веб‑приложения, мобильные бэкенды)
   • Внутренние сервисы (аутентификация, биллинг, поиск, рекомендации)
   • Batch‑/фоновые воркеры
3. Системы данных
   • Базы данных (SQL, NoSQL)
   • Кэши, очереди, event‑стримы
   • Аналитика / пайплайны
4. Внешние сервисы
   • Сторонние API (платежи, месседжинг, аутентификация)
   • Managed SaaS‑зависимости (логирование, email, CDN)

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

• «Если эта база деградировала, какие сервисы на полосе выше отваливаются?»
• «Если регион ведёт себя странно, какие пользовательские сценарии наверху страдают?»

Цель — быстрая оценка blast radius (радиуса поражения), а не подробная архитектурная документация.

Шаг 2. Нанесите зависимости приложений — на бумаге

В большинстве компаний уже есть некий service / application dependency map в инструменте: кто с кем говорит, какие сервисы ходят в какие базы данных и какие внешние API.

Аналоговый чертёж берёт эти идеи и превращает их в схему метро:

• Линии = ключевые бизнес‑флоу (например, «оформление заказа», «логин пользователя», «ингест данных»)
• Станции = важные компоненты на маршруте (сервисы, базы, очереди, сторонние API)
• Пересадочные узлы = общие зависимости для нескольких линий (auth, профиль пользователя, платежи)

Например, линия «checkout» визуально может проходить через:

Web Frontend → API Gateway → Orders Service → Payments Service → Payment Provider API → Orders DB → Notifications Service

Если нанести на одну карту несколько таких линий, вы сразу увидите:

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

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

Шаг 3. Сфокусируйтесь на самых критичных зависимостях

Настенный чертёж — не место, чтобы отображать каждый cron‑job и debug‑сервис.

Нужен подход, основанный на последствиях (consequence‑driven design):

• Включайте компоненты, отказ которых:
  • «роняет» ключевые пользовательские сценарии,
  • приводит к порче или задержке критичных данных,
  • ломает регуляторные или security‑контроли.
• Мелкие детали низкого влияния объединяйте в укрупнённые узлы (например, «auxiliary workers cluster»).

Используйте визуальные акценты, чтобы показать важность:

• толще линии — для основных бизнес‑флоу,
• крупнее станции — для высокоособенных компонентов,
• цветовая кодировка — для уровней критичности (например, красный = single point of failure).

Задача — скорость: в первые пять минут инцидента участники должны суметь протрассировать вероятные пути отказа и оценить blast radius, не перелистывая документацию.

Шаг 4. Впишите знания об наблюдаемости прямо на карту

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

Полезно добавить такие слои:

1. Типичные режимы отказа

Рядом с каждой ключевой станцией сделайте небольшой блок:

• «Типичные сбои: истощение коннекшенов, throttling, протухший кэш, lock contention в БД»
• «Частые проблемы: TLS‑ошибки провайдера, региональные всплески латентности»

Такие пометки играют роль когнитивных шорткатов, когда живых error‑дашбордов нет.

2. Паттерны аномалий

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

• «Часто падает после деплоя»
• «Чувствительно к всплескам трафика»
• «Страдает, когда Region A нездоров»

Это помогает участникам мыслить гипотезами: «А не ещё ли это один постдеплойный cache desync?»

3. Потоки алертов (когда они работают)

Даже если сейчас alerting молчит, задокументируйте, что обычно на что алертит:

• какие SLO или алерты привязаны к каждой станции,
• какие команды за них отвечают.

Если у кого‑то сохранился частичный доступ (например, через ноутбук всё ещё в VPN), он сможет сопоставить, что именно ломается, с тем, где это «должно было бы» светиться — используя бумажную карту как навигатор.

Шаг 5. Сделайте карту удобной в работе во время инцидента

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

Оснастите комнату для инцидентов:

• цветными стикерами (для текущих проблем, гипотез и мер смягчения),
• маркерами (лучше стираемыми, если карта ламинирована) — чтобы выделять подозрительные маршруты,
• простой цветовой легендой, например:
  • красный стикер = подтверждённо поражённый компонент,
  • жёлтый стикер = подозрение / в расследовании,
  • синий стикер = применена мера / временный обходной путь.

По мере развития инцидента карта превращается в живой сториборд:

• команды отмечают затронутые станции и линии,
• рисуют стрелки предполагаемого распространения сбоя,
• подписывают ключевые решения («трафик переключен в Region B в 14:32»).

После инцидента карту можно сфотографировать и использовать для реконструкции таймлайна на постмортеме.

Шаг 6. Поддерживайте и тренируйтесь — формируйте общие ментальные модели

Старая и неиспользуемая карта опасна. Относитесь к аналоговому чертежу как к полноценному операционному активу:

1. Регулярная актуализация

   • пересматривайте карту ежеквартально (или после крупных архитектурных изменений),
   • добавляйте новые критичные сервисы и убирайте выведенные из эксплуатации,
   • проверяйте, что линии зависимостей по‑прежнему отражают реальность.

2. Тренировки и обучение

   • проводите tabletop‑учения только с картой, без дашбордов,
   • отрабатывайте сценарий «вы потеряли наблюдаемость — ваши действия?»
   • меняйте фасилитаторов из разных команд, чтобы расширять зону ответственности и владения.

Со временем такие тренировки:

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

Когда случится реальное событие «observability dark», команда не будет в ступоре смотреть на пустую стену. Она будет пользоваться знакомым навигационным инструментом, с которым уже тренировалась.

Заключение: проектируйте под день, когда дашборды пропадут

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

Инвестировав в настенную бумажную карту, которая:

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

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

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