Город картонных отказов: настольная модель скрытых «районов риска» в вашей системе

Современные системы слишком велики, чтобы уместиться в человеческой голове.

Cloud‑native‑архитектуры разрастаются до десятков и сотен микросервисов, сторонних API, очередей, хранилищ данных и фоновых задач. Ваш реальный граф зависимостей куда больше похож не на аккуратную диаграмму, а на тарелку спагетти, которую уронили на пол.

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

А что если по ним можно было бы пройтись — буквально?

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

Почему именно город? И почему из картона?

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

• Пара сервисов? Граф прекрасно работает.
• Пара десятков? Уже шумно.
• Пара сотен? Визуализация становится нечитаемой.

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

Метафора города помогает, потому что придаёт системе структуру и пространственный смысл:

• Сервисы становятся зданиями (высокими, широкими, сгруппированными в районы).
• Зависимости становятся дорогами (односторонние улицы, магистрали, узкие переулки).
• Общая инфраструктура превращается в городские службы (электростанции, водоканалы, линии метро).

И картон здесь важен, потому что он:

• Физический – вокруг него можно собраться командой.
• Дешёвый – никто не боится что‑то оторвать, передвинуть или поменять местами.
• Творческий – снижает порог для экспериментов. Это не «формальная диаграмма», к которой страшно прикасаться; это прототип‑песочница.

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

Шаг 1. Проецируем систему на город

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

1. Выберите строительные блоки

Используйте то, что под рукой:

• Небольшие картонные коробки
• Сложенные карточки или стикеры
• 3D‑печатьные блоки

Каждое здание представляет сервис или ключевой компонент:

• Микросервисы
• Базы данных
• Очереди сообщений
• Сторонние API (как «здания за городом» на краю карты)

Подпишите каждое здание понятным названием сервиса.

2. Разметьте районы

Сгруппируйте родственные сервисы в районы:

• «Платёжный район» – биллинг, инвойсы, процессинг транзакций
• «Пользовательский район» – аутентификация, профили, права доступа
• «Контент‑район» – каталог, поиск, рекомендательный движок

Позже именно эти районы превратятся в ваши районы риска.

3. Добавьте дороги (зависимости)

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

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

Теперь у вас есть базовая физическая карта зависимостей. Но настоящая ценность появится, когда вы начнёте ходить по ней, как по настоящему городу.

Шаг 2. Выявляем скрытые районы риска

Не все районы одинаково опасны. Одни — тихие пригороды, другие — нестабильные кварталы, где аварии быстро разрастаются.

Используйте change coupling, чтобы найти рискованные районы

Change coupling — это о том, какие сервисы меняются вместе. Чаще всего это:

• Сервисы, над которыми работает одна и та же команда
• Сервисы с общими моделями данных или схемой
• Сервисы с тесно сцеплённым поведением

Чтобы отразить это в городе:

1. Посмотрите на последние месяцы деплоев.
2. Найдите сервисы, которые часто фигурируют в одних и тех же pull‑request’ах, задачах или релиз‑нотах.
3. Разместите эти здания ближе друг к другу в вашем картонном городе.

Так вы получите визуальные кварталы, вроде:

• Группы мелких сервисов вокруг общей базы данных, которые вечно выкатываются вместе.
• «Бэкэнд‑квартал», который постоянно «на ремонте».

Это нестабильные районы, которым нужны:

• Дополнительные паттерны отказоустойчивости (circuit breaker’ы, ретраи, graceful degradation)
• Более прицельное тестирование
• Более аккуратные стратегии выката (canary‑релизы, feature‑флаги)

Подсветите горячие точки

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

• Красные стикеры — сервисы с частыми инцидентами
• Жёлтые — высоконагруженные или критические сервисы
• Синие — внешние зависимости, которыми вы не управляете

Визуально начнут проявляться:

• Коридоры риска – цепочки красных и жёлтых зданий на одном критичном пути
• Единственные точки отказа – одиночный сервис, через который проходят все основные дороги

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

Шаг 3. Превращаем город в учение по реагированию на инциденты

Теперь превратите ваш город в поле для disaster‑симуляций.

Придумывайте сценарии отказов как городские события

Вместо сухого «упал payments‑service» можно сказать так:

• «В Платёжном районе отключили электричество».
• «Стройка перекрыла главную дорогу между Auth и Checkout».
• «Внешний провайдер карт ушёл из города; все эти дороги исчезли».

Для каждого сценария:

1. Физически отметьте отказ – положите карточку «Down» на здание, перережьте дорогу (уберите нитку) или накройте район карточкой «катастрофа».
2. Спросите команду: что ломается дальше? Какие улицы теперь непроходимы? Какие здания потеряли доступ? Какие пользовательские сценарии пострадали?
3. Проследите распространение отказа, двигаясь по дорогам.

Вы спрашиваете не просто: «Что делает этот сервис?» Вы спрашиваете: «Что происходит с районом, когда в этом квартале начинается пожар?»

Тренируйте командную реакцию

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

• Назначьте роли: incident commander, ответственный за коммуникации, эксперты по доменам.
• Задайте сценарий: «В 10:07 Платёжный район погружается во тьму».
• Попросите команды:
  • Определить затронутые потоки и сегменты клиентов.
  • Принять решения о мерах смягчения (обходные маршруты, feature‑флаги, фоллбеки).
  • Обсудить коммуникации: кто должен узнать и как быстро.

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

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

Картонный город намеренно сделан грубым и неточным. В этом его сила.

Как картонный самолёт в аэродинамической трубе, он — песочница для поиска слабых мест, не рискуя продом.

Используйте его, чтобы задать вопросы:

• «Что если убрать это здание?»
  • Какие потоки всё ещё смогут работать? Что нужно изменить?
• «Что если разрезать этот монолит‑небоскрёб на три меньших здания?»
  • Сколько новых дорог появится? Район станет более или менее хрупким?
• «Что если этот внешний поставщик падает раз в месяц?»
  • Можем ли мы объехать его? Нужна ли нам «объездная дорога» к другому провайдеру?

Поощряйте людей:

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

Так как это всего лишь картон, никто не боится ошибаться. Цель — обучение, а не идеальная точность.

Шаг 5. Сделайте это командной игрой

Главная ценность города картонных отказов — не в самой модели, а в разговорах, которые она запускает.

Стройте вместе, не делегируйте

Не стоит поручать создание города только архитекторам или SRE. Вместо этого:

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

Этот процесс позволит:

• Вытащить на свет скрытые допущения («Подождите, я думал, мы завязаны только на этот read‑replica»).
• Обнаружить сило знаний («Только один человек понимает, что на самом деле делает это здание»).
• Улучшить общую ментальную модель системы во всей организации.

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

Ваш город — не реквизит для одноразового воркшопа, а живая модель:

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

Со временем команда выработает общий географический язык:

• «Мы выкатываем новый сервис в Checkout‑районе».
• «Это изменение добавляет новый переулок, который обходит главную дорогу через Auth».
• «Это и так хрупкий район — давайте аккуратнее».

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

Заключение: смотрите на систему как на город, а не как на диаграмму

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

Создавая город картонных отказов, вы:

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

Вам не нужна идеальная точность. Нужно нечто достаточно хорошее, чтобы люди могли собраться вокруг, указать пальцем и спросить: «Если здесь загорится, что сгорит вместе с этим?»

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