Введение

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

Это очень похоже на то, как ощущается авария типа split‑brain.

Чтобы разобраться, мы воспользуемся вымышленным, но реалистичным сценарием: Аналоговый трамвайный инцидентный пульт — старый добрый щит управления, который направляет «трамваи» (инциденты) по всей вашей системе. Это наполовину пародия, наполовину учебный инструмент и на удивление полезный способ мыслить о сложных, каскадных отказах.

Мы разберём:

• Как выглядит кейс «Аналоговый трамвайный инцидентный пульт»
• Как распределённые отказы распространяются и превращают маленькие проблемы в большие простои
• Почему сценарии split‑brain «2+1» так опасны
• Как хороший дизайн кворума и настольные учения делают реальные системы устойчивее
• Почему широкое распространение уроков после инцидентов — не опция, а необходимость

Аналоговый трамвайный инцидентный пульт (AISS)

Представьте большой физический пульт на стене:

• Каждая трамвайная линия = критический сервис (auth, billing, search, messaging)
• Каждый переключатель = решение о маршрутизации (какой регион, какая база, какой кэш)
• Каждая лампочка = сигнал здоровья или алерт
• Рядом приколота маленькая бумажная карта = диаграмма вашей системы

Это ваш Аналоговый трамвайный инцидентный пульт (Analog Incident Streetcar Switchboard, AISS). В обычный день трамваи ходят по расписанию. Огни мигают предсказуемыми паттернами. Операторы (дежурные инженеры) знают ритм работы.

Теперь внесём серьёзный инцидент.

Авария типа «split‑brain» на AISS

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

• Линки между регионом A и регионом B начинают терять пакеты.
• Мониторинг в регионе C фиксирует нестабильные heartbeat‑сигналы.
• На консолях одних операторов регион A отмечен как primary, у других — B.

На пульте:

• Лампочка региона A зелёная локально, но красная на агрегирующем дашборде.
• Лампочка региона B мигает между жёлтым и зелёным.
• Трамваи сервиса «auth» маршрутизируются и в A, и в B — в зависимости от того, на какой панели вы смотрите.

Вы оказались в мире split‑brain: разные части системы не сходятся во мнении, кто жив, кто primary и куда должны идти записи.

Здесь реальные аварии перестают быть «багом в компоненте X» и превращаются в аварии сложной системы, где замешаны:

• Частичные сетевые разделения (network partitions)
• Конфликтующие таймауты и ретраи
• Непоследовательные решения по кворуму
• Люди‑операторы, работающие с разными ментальными моделями одной и той же системы

Как распределённые отказы каскадирую́т, как трамваи

Распределённые системы редко падают «чисто». Они разваливаются, как запутанные трамвайные линии в час пик.

Ключевые свойства отказов:

1. Локальное очень быстро становится глобальным
   Тихая локальная проблема (одна «чудящая» нода, флапающий линк) может:

   • запустить ретраи и «ревущие стада» запросов;
   • выбить пул соединений;
   • перегрузить соседние ноды;
   • уронить общие зависимости (например, центральный auth‑сервис).

2. Расхождение состояния распространяется
   Разные ноды видят разную реальность:

   • Нода A: «Я не вижу ноду B; стану лидером».
   • Нода B: «Я не вижу ноду A; стану лидером».
   • Клиенты: «Иногда лидер A, иногда B; буду просто ретраить в обе».

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

   • дыры в дашбордах;
   • отсутствие логов именно там, где они особенно нужны;
   • панели, выглядящие «здоровыми», но скрывающие невидимые отказы.

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

Split «2+1»: когда правила кворума бьют по доступности

Большинство современных распределённых систем используют варианты алгоритмов консенсуса (Raft, Paxos) с кворумным принятием решений:

• При 3 нодах кворум = 2.
• При 5 нодах кворум = 3.

Это отлично для консистентности, но сетевые разделения всё равно порождают неприятные сценарии.

Сценарий 2+1

Возьмём кластер из трёх нод (N1, N2, N3):

• Частичное разделение изолирует N3.
• N1 и N2 по‑прежнему могут общаться друг с другом.

Результат:

• N1 + N2 сохраняют кворум и продолжают работать как авторитетная часть кластера.
• N3 теряет кворум и отдаёт лидерство. В идеале она становится только для чтения или вовсе недоступной.

С точки зрения консистентности это именно то, что нужно. Но операционно, на AISS, это выглядит так:

• Панель рядом с стойками N3 показывает, что локальная нода «жива, но одинока».
• Региональная страница статуса, которая опрашивает только N3, показывает зелёный.
• Глобальные control plane‑ы видят кластер как деградировавший, но обслуживающий запросы (благодаря N1 + N2).

Получаются противоречивые сигналы:

• «Моя нода жива!» (N3)
• «Кластер жив!» (N1 + N2)
• «Часть клиентов ловит таймауты» (потому что трафик “прилип” к зоне N3)

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

Почему отказ одной ноды не должен ломать кворум

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

• Кластер из 3 нод переживает отказ 1 ноды.
• Кластер из 5 нод переживает отказ 2 нод.

На практике это означает:

• Тщательный выбор фактора репликации и доменов отказа (AZ, стойки, регионы);
• Избежание дизайна, где потеря одной «особой» ноды валит всю систему.

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

Тем не менее даже идеальная математика кворума не избавляет от запутанных сценариев 2+1 с полудеградацией. Здесь вам нужен не только протокол, но и процесс.

Настольные учения: «бумажные маршруты» через аварию

Проводить свой первый сложный инцидент в проде — плохая идея.

Мощная практика — это tabletop‑учения: структурированная, малострессовая репетиция с подробными, реалистичными сценариями.

Для аварии типа split‑brain на AISS настольное упражнение может выглядеть так:

1. Подготовить сценарий

   • Сетевое разделение между регионом A и регионом B
   • Не чистый обрыв, а прерывистая потеря пакетов
   • Часть health‑чеков проходит, часть — нет
   • Несколько зависимых сервисов (например, очереди, кэши) ведут себя по‑разному в каждом регионе

2. Распечатать «бумагу»

   • Диаграммы системы
   • Упрощённые срезы логов и метрик на T+5, T+15, T+30
   • Сообщения от пользователей (тикеты в поддержку, synthetic‑чеки, жалобы со статус‑страницы)

3. Назначить роли

   • Incident commander (ведущий инцидента)
   • Ответственный за коммуникации (статус‑страница, внутренние апдейты)
   • Операторы по подсистемам (БД, сеть, приложение, наблюдаемость)

4. Пройти «трамвайные маршруты»

   • Проследить пользовательский запрос от:
     • DNS → edge → приложение → кэш → БД
   • Показать, как один и тот же запрос ведёт себя по‑разному, попадая в регион A или в регион B
   • Специально высветить противоречивые сигналы из разных «окон» наблюдения за системой

5. Вынудить принять сложные решения

   • В какой момент вы полностью переключаете трафик в один регион?
   • Когда вы разжаловываете лидера региона?
   • Какие сигналы считаются «авторитетными» при расхождении состояний?

Такие tabletop‑учения формируют мышечную память и вскрывают изъяны дизайна, пока цена ошибки ещё низка.

Обмен уроками после инцидентов: от одного пульта ко многим

Авария на AISS не должна остаться историей, которую рассказывают только те, кто дежурил в ту смену. Она должна превратиться в кейс, который влияет на то:

• Как вы проектируете новые сервисы
• Как настраиваете кворумы и failover
• Как строите наблюдаемость и статус‑страницы

Это произойдёт только если вы широко делитесь уроками.

Рабочие практики:

• Бесконтактные (blameless) разборы инцидентов, публикуемые внутри компании
• Кросс‑командные дебрифы, где команды показывают свой взгляд на таймлайн инцидента
• Архитектурные гайдлайны, обновлённые примерами из этого сбоя
• Обучающие материалы (runbook‑и, колоды для tabletop‑учений, онбординг‑курсы), повторно использующие тот же сценарий

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

Когда следующая команда будет проектировать новый control plane, она должна уже задаваться вопросами:

• Как это поведёт себя в сценарии 2+1?
• Что будет, если сама pipeline наблюдаемости окажется разделена?
• Какие сигналы считать авторитетными, если представления расходятся?

В этом и состоит реальная ценность яркого кейса вроде Аналогового трамвайного инцидентного пульта.

Заключение

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

• Распределённые отказы распространяются быстро и непредсказуемо.
• Сценарии split‑brain и 2+1 создают не только простой, но и расхождение во «взглядах на мир» между компонентами.
• Дизайн кворума должен обеспечивать, что отказ одной ноды не валит систему.
• Даже при хорошем дизайне именно люди и процессы определяют тяжесть инцидента.

Если вы будете:

• Проводить tabletop‑учения с реалистичными, «грязными» сценариями;
• Проектировать кластеры и домены отказа так, чтобы они выдерживали потерю одной ноды без потери кворума;
• И широко делиться уроками после инцидентов внутри организации,

…вы сможете превращать запутанные, стрессовые аварии в мощные, многократно используемые уроки.

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