Бумажная «схема метро» инцидента: как вручную проектировать подземные маршруты скрытых сигналов отказов

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

Мощный способ сократить этот разрыв удивительно низкотехнологичен: нарисуйте это.

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

Мы свяжем эту идею с классическими инструментами надёжности — Reliability Block Diagrams (RBD), Fault Tree Analysis (FTA) и наблюдением в стиле гемба — и покажем, как их комбинация выявляет скрытые пути отказов, которых вы не увидите ни в логах, ни в коде.

Зачем вам «схема метро» для инцидентов

У большинства команд есть что‑то вроде:

Конфиги мониторинга в одном репозитории
Правила маршрутизации алертов — в другом
Runbook’и — в вики
Политики эскалации — в отдельном ops‑инструменте

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

Схема метро превращает это в единую визуальную историю:

Где возникают отказы (источники алертов)
Как они двигаются (маршруты и преобразования алертов)
Где они ветвятся или застревают (роутинг, фильтры, правила заглушения)
Как и когда в процесс включаются люди (эскалации, on‑call, передачи между командами)

Увидев всю сеть сигналов и путей целиком, вы начинаете замечать:

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

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

Слой 1: Reliability Block Diagrams — кто «держит свет включённым»?

Reliability Block Diagram (RBD) визуализирует, как надёжность отдельных компонентов влияет на надёжность всей системы. Блоки в последовательном соединении представляют компоненты, где отказ любого ломает всё; блоки в параллельном — избыточность.

Для «схемы метро» инцидента RBD даёт вам инфраструктурный «хребет»:

Нарисуйте основные сервисы, зависимости и критичные компоненты как блоки.
Соедините их так, чтобы было видно, как пользовательские сценарии зависят от них.
Подсветите единичные точки отказа и ключевую избыточность.

Пример (текстом):

Запрос пользователя → API Gateway → Auth Service → App Service → DB Cluster
                                            └→ Cache Cluster

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

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

Что должно оставаться работоспособным, чтобы мы доставляли ключевые пользовательские сценарии?
Где локальный отказ превратится в отказ системы целиком?

Слой 2: диаграммирование маршрутов алертов — как на самом деле движутся сигналы?

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

У большинства команд здесь неожиданно много сложности:

Метрики → Alertmanager → роутер нотификаций → чат/почта/пейджер
Логи → SIEM → правила корреляции → инструмент инцидентов
Синтетические проверки → внешний провайдер → webhook → on‑call‑система

Когда вы рисуете это как явные пути, всплывают скрытые связи.

Что именно отображать

Для каждого критичного компонента из вашего RBD:

Источники алертов
- Метрики, логи, трейсы, синтетические проверки, health‑endpoint’ы.
Шаги преобразования
- Правила алертов, движки корреляции, дедупликация, фильтры шума.
Маршрутизация и эскалация
- On‑call‑ротации, политики эскалации, резервные каналы.
Точки взаимодействия с людьми
- Кто что видит первым? Кто может заакноледжить, эскалировать или закрыть инцидент?

Вот здесь метафора «метро» раскрывается полностью: рисуйте каждый источник алертов как линию, каждый инструмент/команду — как станцию, а эскалации — как пересадки.

Зачем вообще рисовать маршруты алертов

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

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

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

Слой 3: сделать скрытые связи явными

Большая часть логики алертинга и эскалации живёт в коде или непрозрачных конфигурациях:

Модули Terraform для Alertmanager’ов
YAML‑файлы с правилами и маршрутами
JSON‑политики в инструментах управления инцидентами

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

Показывая явные связи между:

Мониторами / правилами
Сервисами / компонентами
Командами / on‑call‑ролями
Каналами / инструментами

…вы выявляете:

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

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

Слой 4: Fault Tree Analysis — откуда на самом деле берутся инциденты?

Если RBD показывает, как системы остаются работоспособными, то Fault Tree Analysis (FTA) показывает, как они падают.

Диаграмма FTA начинается с верхнего события (например, «недоступна оплата») и движется назад:

Разбивает его на промежуточные события (сломался API, БД отвергает записи и т.п.).
Комбинирует их через логические элементы (AND/OR), показывая, какие сочетания нужны.
Опускается до базовых событий на листьях (отказ конкретного компонента или процесса).

Когда вы совмещаете FTA с вашей схемой метро, вы можете:

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

Например, вы можете обнаружить, что верхнеуровневую аварию может вызвать:

Один «тихий» отказ кеша в сочетании с замедлением фоновой джобы.
И при этом на оба события сейчас нет ни одного алерта, достойного пейджера.

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

Сила единой визуальной легенды

Всё это работает только если люди умеют читать схему.

Определите простую, последовательную визуальную нотацию:

Фигуры
- Прямоугольники: компоненты/сервисы
- Круги: алерты или события
- Ромбы: точки принятия решений (логика маршрутизации/эскалации)
- Параллелограммы: действия людей или передачи задач
Цвета
- Красный: состояния отказа
- Зелёный: здоровые состояния
- Оранжевый: деградация или риск
- Синий: инструменты/платформы (мониторинг, пейджинг, чат)
Линии
- Сплошная: синхронная зависимость или мгновенная нотификация
- Пунктир: асинхронный или отложенный путь
- Двойная линия: маршрут высокой критичности

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

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

Печатайте легенду на полях каждой диаграммы. Делайте её скучно‑последовательной.

Гемба: идите туда, где инциденты происходят на самом деле

В бережливом производстве есть понятие гемба — «реальное место», где происходит работа. В мире надёжности софта гемба — это:

Канал инцидента во время живой аварии
Ноутбук on‑call‑инженера в 3 часа ночи
Передачи между командами в первые 30 минут инцидента

Наблюдение за реальной работой в моменте позволяет увидеть:

Шаги, которые люди делают, но которых нет ни в одном runbook’е
Обходные решения, которые никогда не попадают на дашборды
Задержки, вызванные путаницей, кто за что отвечает
Инструменты, на которые люди на самом деле опираются, в отличие от того, что нарисовано на архитектурной схеме

Возьмите раннюю версию вашей схемы метро и сядьте рядом с on‑call‑инженером (или посмотрите запись) во время инцидента:

Отмечайте его действия как новые линии и станции на схеме.
Помечайте места, где он перескакивает между инструментами, задаёт вопросы или «застревает».
Фиксируйте, где реальность расходится с вашими диаграммами.

Вы быстро обнаружите:

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

Гемба превращает вашу схему из дизайнерского артефакта в полевую модель надёжности.

Комбинируя схемы, данные и наблюдение

Самые сильные модели инцидентов рождаются на пересечении трёх взглядов:

Визуальные карты отказов
- RBD для структуры системы
- Диаграммы маршрутов алертов для потоков сигналов
- FTA для путей отказа
Реальные данные
- Исторические таймлайны инцидентов
- Паттерны срабатывания/акноледжа/закрытия алертов
- MTTA/MTTR по конкретным путям или командам
Наблюдение в стиле гемба
- Наблюдение за поведением on‑call’ов
- Шэдоуинг incident commander’ов
- Дебрифы с участниками после инцидента

Наложив эти представления друг на друга, вы можете:

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

Ваша инцидентная схема‑метро превращается в:

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

Как начать свою бумажную «инцидентную схему метро»

Не нужно никакого специального софта. Начните с:

Одного ключевого пользовательского сценария (например, логин, checkout, отправка сообщения).
Доски или большого листа бумаги.
Небольшой кросс‑функциональной группы (разработчик, SRE, менеджер по инцидентам).

Дальше:

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

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

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

Эти находки — ваш roadmap для следующих улучшений надёжности.

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

Дашборды говорят вам, что происходит. Логи — где это происходит. Конфиги — что вы собирались построить.

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

Комбинируя:

RBD, чтобы отрисовать критические зависимости
Диаграммы маршрутов алертов, чтобы раскрыть и улучшить пути сигналов
FTA, чтобы приоритизировать ключевые режимы отказа
Единую визуальную легенду, чтобы обеспечить общее понимание
Наблюдение в стиле гемба, чтобы заземлить модель в реальности

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

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