В октябре 2026 года российский ИТ‑рынок наблюдал беспрецедентный по масштабу коллапс: за четверо суток физически вышли из строя три дата‑центра «Яндекса» в Центральной России (Сасово, Калуга, Владимир). Итогом стали обрушение облачной платформы Yandex Cloud, остановка ключевых сервисов экосистемы (от Такси до Директа), потеря недельных данных у ряда внешних клиентов и 11-дневная кома финтех‑вертикали («Яндекс Пэй» и «Сплит»).

В публичном поле эту аварию удобно списывать на «непреодолимый военный форс‑мажор» — мол, ни одна архитектура не рассчитана на потерю трех ЦОДов подряд.

Как архитекторы, мы обязаны смотреть на факты без розовых очков. Если препарировать поминутную хронику событий с 8 по 22 октября, становится очевидно: физическое поражение площадок стало лишь триггером. Масштаб и длительность катастрофы — это прямое следствие фундаментальных просчетов в проектировании распределенных систем, управлении мощностями (Capacity Management) и оценке рисков на уровне C‑level.

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

Глава 1. Хроника каскадного обрушения: 74 упущенных часа

В распределенных системах время между отказами решает всё. Главный миф октябрьской аварии звучит так: «Три ЦОДа упали одновременно, кворум мгновенно погиб». Это неправда. Между потерей первой основной зоны доступности и потерей второй прошло более трех суток (74,5 часа).

Посмотрим на сухие факты статус‑панели Yandex Cloud (инциденты № 2092 и № 2136) и отчеты инфраструктуры:

• 8 октября, 01:31 МСК (Час «Ч»): В результате атаки БПЛА и пожара полностью останавливается ЦОД в Сасово (Рязанская область) — зона доступности ru‑central1-b. Затронуты 85 сервисов облака. К 14:00 полностью ложатся бессерверные вычисления (Cloud Functions и Serverless Containers).

• 8 октября, 04:55 МСК (Симптом паралича): Начинаются массовые ошибки при создании виртуальных машин, кластеров Kubernetes и баз данных в остальных, живых зонах. Выясняется фатальная деталь: если мастер‑ноды региональных кластеров K8s или управляющие узлы БД находились в погибшей зоне b, кластеры потеряли управляемость, хотя рабочие ноды в других зонах оставались целыми.

• 9 октября, утро — 15:42 МСК (Кризис мощностей): Утром получает повреждения ЦОД в Калуге. В 10:38 Yandex Cloud идет на шаг, немыслимый для гиперскейлера: официально объявляет о договоренности размещать своих клиентов на мощностях прямых конкурентов (Selectel, K2Cloud, VK Cloud). Это прямое признание того, что собственный резерв емкости (Capacity) исчерпан. И только в 15:42 — спустя 38 часов после гибели Сасово! — инженеры «Яндекса» дают клиентам техническую возможность перенести управляющие компоненты K8s из мертвой зоны b и исключить погибшие хосты из кластеров управляемых СУБД.

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

• 11 октября, 04:00 — 07:13 МСК (Математический нокаут): Поражен и полностью остановлен ЦОД во Владимире — ключевая площадка, где жили суперкомпьютер «Галушкин», ядро сервисов и зона доступности ru‑central1-a. В живых остаются только зоны d и e. В 06:08 облако переходит в аварийный режим с вердиктом: «Оставшаяся конфигурация ресурсов не обеспечивает устойчивости, задействуйте внешние DR‑планы за пределами облака». К 07:13 кластеры управляемых БД принудительно переходят в Read‑Only или становятся недоступны, объектное хранилище S3 перестает принимать запись. Ложатся «Яндекс Go», «Еда», «Яндекс 360», «Директ», «Яндекс Пэй», а вместе с ними — ЦИАН, «Додо Пицца», «Магнит» и госсистема «ВетИС».

• 11 — 22 октября (Похмелье и реанимация): У части систем обнаруживается, что бэкапы лежали в том же пораженном контуре, а свежие недельные дампы не завершились — сервисы откатываются к состоянию на 4 октября (RPO = 7 дней!) со сбросом и переназначением первичных ID. Финтех «Яндекса» уходит в глубокую кому: базовые переводы возвращают лишь ночью 13 октября (компании приходится экстренно поднять ставку по накопительным «Сейвам» до 20% годовых на неделю, чтобы остановить панику и отток вкладов). Погашение сплитов чинят к 16 октября, рекламный «Директ» — к 20 октября, а основные функции «Яндекс Пэй» и кредитный «Супер Сплит» возвращают в строй только 22 октября — спустя 11 суток после падения Владимира.

Глава 2. Технический разбор: почему не спас ни Raft, ни Multi‑AZ

В кулуарах сразу после аварии появилась популярная версия: «Архитекторы Яндекса испугались недоступности, нарушили теорему CAP, переключили базы данных (включая YDB) в режим AP (Availability), из‑за чего алгоритмы консенсуса Raft/Paxos сошли с ума и устроили классический split‑brain».

С точки зрения системной архитектуры этот тезис безграмотен. Всё было одновременно и проще, и страшнее.

1. CP‑системы сработали по учебнику — их погубил паралич Control Plane и дефицит железа

Ни YDB (строго сериализуемая CP‑система архитектуры NewSQL), ни управляемые кластеры PostgreSQL с консенсусным выбором лидера не «переключались в AP». Когда 11 октября упал Владимир (ru-central1-a), базы данных и S3 сделали ровно то, что обязана сделать любая честная CP‑система при потере кворума: они заблокировали запись и перешли в Read‑Only.

Настоящий архитектурный провал кроется в вопросе: почему утром 11 октября падение Владимира вообще привело к потере кворума?

В классической трехзонной архитектуре (зоны a, b, d) для записи нужен кворум из ‭ узлов.

1. Ночью 8 октября погибла зона b (Сасово). Кластеры перешли в деградировавший, но полностью рабочий режим ‭(на зонах a и d).

2. По всем канонам проектирования отказоустойчивых систем, сразу после потери зоны b должен запуститься процесс Self‑Healing / Re‑Quorum: система выводит мертвую зону b из конфигурации консенсуса и реплицирует третью копию данных в резервную зону (например, e), восстанавливая формулу ‭

3. На эту операцию у «Яндекса» было 74,5 часа. Но к утру 11 октября подавляющее большинство кластеров так и остались стоять «на двух ногах» (с мертвым грузом зоны b в конфигурации кворума).

Почему? Сработали две архитектурные ловушки:

• Связность Control Plane и Data Plane: Управляющий слой (Control Plane) самого облака оказался завязан на погибшую зону b. Инженерам потребовалось 38 часов просто на то, чтобы дать механизмы отвязки мастеров K8s и вычистки мертвых хостов БД из метаданных.

• Отсутствие резерва мощности (Capacity Buffer): Чтобы перелить сотни петабайт данных из погибшего Сасово в уцелевшие зоны и поднять там новые реплики БД, нужно свободное железо, диски и пропускная способность сети. А свободного железа не было — утилизация ЦОДов в мирное время была выкручена под завязку ради экономии CAPEX. Ручные квоты 10 октября и отправка клиентов к конкурентам 9 октября доказали: пересобирать третий узел кворума было физически негде.

Когда 11 октября погас Владимир (a), у кластеров, не успевших пересобрать кворум, осталась 1 живая реплика из 3. Математический кворум схлопнулся.

2. Иллюзия гео‑распределенности: Metro‑Cluster выдавали за Disaster Recovery

Все четыре основные площадки «Яндекса» (Сасово, Владимир, Калуга, Мытищи) расположены в одном макрорегионе — вокруг Москвы, на удалении 200–350 км друг от друга.

Инженерная логика этого решения понятна: синхронная репликация и алгоритмы консенсуса (Raft/Paxos) чувствительны к сетевым задержкам (Latency). Чтобы транзакция в БД фиксировалась за 3–5 мс, свет в оптоволокне должен бегать на короткие дистанции. Это классический Metro‑Cluster, обеспечивающий High Availability (HA) — защиту от пожара в конкретном машзале, отказа трансформатора или перерубленного экскаватором кабеля.

Но руководство и риск‑менеджмент совершили фатальную подмену понятий: они приравняли три зоны доступности в одном регионе (ru-central1) к полноценному Disaster Recovery (DR).

В условиях 2026 года все площадки в одном радиусе досягаемости и на одном энергетическом и сетевом узле образуют единый коррелированный домен отказа (Single Domain of Correlated Failure). Отсутствие второго, физически изолированного региона (например, ru-siberia или ru-ural за тысячи километров) превратило локальную региональную аварию в общенациональный блэкаут.

3. Рекурсивная ловушка бэкапов и RPO в 7 суток

Инцидент вскрыл пугающую практику хранения резервных копий. У множества сервисов (как внутренних, так и клиентских) бэкапы хранились в том же объектном хранилище S3 и на тех же дисковых массивах региона ru-central1, которые попали под удар.

• Когда S3 деградировал и встал в Read‑Only с ошибками чтения отдельных шардов, достать свежие бэкапы оказалось невозможно.

• Архитектура резервного копирования ряда систем опиралась на тяжелые еженедельные полные дампы (Full Backup) вместо непрерывной потоковой отгрузки журналов предзаписи (Continuous WAL Archiving) во внешний контур. В результате в момент аварии 11 октября последним целым слепком оказался бэкап от 4 октября.

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

Глава 3. Анатомия 11-дневной комы Финтеха: где на самом деле случился Split‑Brain

Самый болезненный вопрос: почему такси («Яндекс Go») и доставку удалось поднять относительно быстро, а финтех («Яндекс Банк», «Пэй», «Сплит» и «Супер Сплит») лихорадило с 8 по 22 октября — две полные недели?

Если CP‑базы данных честно ушли в Read‑Only и не допустили повреждения данных на уровне дисковых блоков, откуда взялись жалобы на двойные/ошибочные списания 8–10 октября и почему инженеры 11 дней не могли включить кредитные продукты?

Ответ кроется в том, что рассинхронизация (логический split‑brain) произошла не внутри движка СУБД, а на уровне прикладной микросервисной архитектуры и распределенных саг (Sagas).

Как микросервисный «культ доступности» убивает консистентность денег

Современный финтех и BNPL‑сервис (Buy Now, Pay Later, коим является «Сплит») — это не одна база данных. Это сложнейший граф микросервисов:

1. Core Banking (Ledger / АБС) — ядро проводки балансов и корсчетов.

2. Движок Сплита — графики платежей, кредитные лимиты, шедулеры автосписаний.

3. Платежный шлюз и эквайринг — интеграция с НСПК, СБП и внешними банками.

4. Шина событий (Kafka / YDS) и кэши (Redis), связывающие всё это в асинхронные цепочки (Саги).

Продуктовая разработка в бигтехе годами живет под давлением бизнесового KPI: «Не сметь ронять конверсию! Покупатель должен оформить заказ в любой ситуации!». Чтобы выполнить это требование бизнеса, архитекторы прикладного слоя массово внедряют паттерны AP (Availability over Consistency) поверх CP‑баз:

• Асинхронные очереди с гарантией доставки At‑least‑once (доставить минимум один раз).

• Агрессивные политики повторных запросов (Retries) при таймаутах.

• Оптимистичные фоллбэки и отложенные списания, когда смежный сервис не отвечает.

А теперь посмотрим, что произошло с этой конструкцией в период с 8 по 11 октября:

1. Фаза частичной деградации (8–10 октября): Сасово уже сгорело, сеть между оставшимися ЦОДами перегружена переливом трафика, бессерверные контейнеры лежат, часть шардов БД и очередей отвечает с гигантскими задержками или падает по таймауту.

2. Разрыв распределенных транзакций: Шедулер «Сплита» инициирует очередное списание денег с карты клиента. Запрос уходит в платежное ядро, деньги реально списываются, но на обратном пути сетевой вызов или брокер сообщений отваливается по таймауту.

3. Отказ идемпотентности и шторм ретраев: Чтобы повторный запрос не списал деньги дважды, система должна проверить ключ идемпотентности (Idempotency-Key). Но кэш ключей идемпотентности (или таблица статусов саги) сам лежит в деградирующей зоне или не успел синхронизироваться! Шедулер, не получив ACK, считает операцию неуспешной и лупит повторное списание.

4. Клиническая смерть 11 октября и ад Reconciliation (11–22 октября): Когда утром 11 октября упал Владимир и базы ушли в Read‑Only, тысячи распределенных саг замерли в полуразрушенном состоянии («деньги во внешнем шлюзе списаны, в очереди сообщение потеряно, в Ledger проводка не зафиксирована, в графике Сплита долг висит»).

В этот момент перед руководством и архитекторами «Яндекс Банка» встала страшная дилемма:

• Если просто поднять базы из уцелевших реплик или старых бэкапов и включить трафик — балансы внутри банка разъедутся с реальными корсчетами в ЦБ и НСПК, клиенты увидят списанные деньги при непогашенных кредитах, а регулятор получит повод для жестких санкций.

• Единственный выход — полная остановка (Stop‑the‑World) и потранзакционная сверка (Reconciliation).

Именно поэтому с 11 по 22 октября финтех возвращали по миллиметру: инженеры вручную и наспех написанными скриптами сводили логи внешних платежных шлюзов, выжившие хвосты очередей Kafka, дампы баз и выписки корсчетов, восстанавливая целостность каждой застрявшей транзакции. А чтобы вкладчики за эти дни не устроили классический Bank Run (набег на банк с выводом средств после включения переводов 13 октября), бизнесу пришлось заливать пожар деньгами — вводить экстренную ставку 20% годовых по «Сейвам».

Глава 4. Управленческий приговор: кто на самом деле виноват?

Было бы нечестно повесить всех собак на рядовых инженеров и SRE‑команды «Яндекса» — эти люди сутками без сна вытаскивали инфраструктуру из огня. Корень катастрофы лежит на уровне корпоративной архитектуры (Enterprise Architecture), риск‑менеджмента и C‑level руководства.Здесь сошлись три классических управленческих порока современного бигтеха:

1. Искаженная система мотивации (KPI мирного времени): Топ‑менеджеры и директора бизнес‑юнитов получают бонусы за рост GMV, запуск новых фич и экономию бюджета (EBITDA / CAPEX). Инвестиции в строительство удаленного DR‑региона в Сибири, поддержание 35%‑го буфера пустых серверов на случай гибели ЦОДа и отчуждаемые внешние бэкапы в отчетах финансистов выглядят как «замороженные миллиарды, не приносящие выручки».

2. Ослепление рисками (Threat Modeling Blindness): В октябре 2026 года, когда удары по критической и энергетической инфраструктуре в европейской части страны давно стали реальностью, продолжать держать 100% кворума облака и банковского ядра в радиусе 300 км от Москвы — это профессиональная халатность риск‑комитета. Сценарий «потеря 2–3 площадок в одном макрорегионе за неделю» обязан был лежать на столе у CTO и CEO как базовый риск (Tier-1 Risk), а не как фантастический «черный лебедь».

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

Глава 5. Как должно было быть: Архитектура Выживания (Чек‑лист для Архитектора)

Критиковать постфактум легко. Давайте сформулируем конкретный архитектурный проект: как должна быть устроена система масштаба «Яндекса» и «Яндекс Банка», чтобы физическая потеря двух и даже трех ЦОДов в европейской части России прошла без потери данных, без 11-дневного паралича финтеха и без отката бэкапов на неделю назад.\

1. Честная двухрегиональная топология (Dual‑Region: Metro HA + Geo DR)

Никакой синхронный кластер вокруг Москвы не заменит географического разнесения.

• Основной регион (ru‑central): 3 зоны доступности на расстоянии до 300 км. Синхронная репликация (YDB / Patroni Raft), RPO = 0, RTT ~3–5 мс.

• Изолированный DR‑регион (ru‑siberia / ru‑ural): Удаление 2000+ км (другой часовой пояс, другой энергокольцо, вне радиуса региональных физических угроз). Непрерывная асинхронная репликация на уровне ядра СУБД и стриминга логов (RTT ~45–60 мс, целевой RPO ‭ 5–30 секунд, RTO ‭ 30 минут).

• Жесткий закон Capacity Management: В основном регионе законодательно (на уровне архитектурного комитета и автоматических квот) бронируется неприкосновенный буфер мощности ‭

• ‬‭‬Суммарная утилизация трех зон никогда не должна превышать 65%, чтобы при мгновенном испарении любой зоны оставшиеся две гарантированно приняли на себя 100% нагрузки и третью реплику данных без введения «ручных квот».

2. Независимый Control Plane и автоматический Re‑Quorum с Fencing'ом

Управляющий слой облака и баз данных не имеет права умирать вместе с рабочей зоной на 38 часов.

• Out‑of‑Band Control Plane: Мастер‑ноды оркестрации, реестры метаданных, DNS и IAM должны иметь легковесные слепки управления во внешнем регионе.

• SLA на пересборку кворума (Automated Dynamic Re‑Quorum): Если зона доступности полностью теряет связность более чем на 15–30 минут, автоматика (без ожидания ручных патчей полтора дня!) обязана:

  1. Применить жесткий криптографический Fencing (STONITH на уровне сети и PKI) — отозвать TLS‑сертификаты и сетевые маршруты упавшей зоны b, чтобы даже при внезапном включении электричества старые ноды гарантированно не смогли вмешаться в работу и породить split‑brain.

  2. Исключить мертвую зону из состава кворума и автоматически начать фоновую дорепликацию 3-й копии данных на зарезервированные мощности резервной зоны.Если бы этот механизм отработал 8 октября за 3–4 часа, то к утру 11 октября (удар по Владимиру) все кластеры встретили бы атаку в полной конфигурации 3/3 и вообще не заметили бы потери второй площадки.

3. Архитектура Финтеха: паттерн Kill‑Switch и иммутабельный Ledger

В финансовых системах доступность витрины никогда не должна ставить под угрозу целостность главной книги (Ledger).

• Автоматический Circuit Breaker (Жесткий Kill‑Switch): Как только мониторинг фиксирует потерю одной зоны доступности и начало деградации латентности ядра БД, все вторичные асинхронные процессы (регулярные автосписания «Сплита», начисление кэшбэков, кредитные конвейеры) мгновенно и автоматически ставятся на паузу. Никаких попыток «пропихнуть транзакцию через ретраи», когда штормит инфраструктуру!

• Строгий Event Sourcing & Append‑Only Ledger: Любое движение денег фиксируется только через иммутабельный журнал проводок с глобальными детерминированными UUIDv7 (содержащими временную метку и криптографическую уникальность), которые генерируются на самом входе операции и прокидываются как Idempotency-Key до самого диска СУБД. Никаких автоинкрементных SERIAL ID, которые ломаются и переназначаются при восстановлении из дампа.

• Разделение контуров (Bulkhead Pattern): Базовые операции (посмотреть баланс, перевести собственные средства по СБП) должны быть жестко изолированы от сложных кредитных саг («Супер Сплит»). Деградация BNPL‑движка не имеет права класть базовый процессинг карт.

4. Отчуждаемые бэкапы по правилу 3-2-1-1-0 (Air‑Gapped DR)

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

• Непрерывный стриминг WAL / CDC: Вместо ожидания «воскресного полного бэкапа» (который подарил клиентам откат на 7 дней к 4 октября) все критичные БД должны в реальном времени стримить сжатые и зашифрованные сегменты WAL (Write‑Ahead Log) во внешний, полностью независимый контур хранения (другой регион, отдельные учетные данные IAM, физически изолированная сеть с WORM‑защитой — Write Once, Read Many).

• Это гарантирует, что даже при полном выгорании основного региона вы поднимете базу данных в резервном контуре с потерей данных (RPO) не в 7 суток, а максимум в несколько секунд.

5. Учения уровня «Черный лебедь» вместо тепличного Chaos Engineering

Большинство компаний играют в Chaos Engineering в песочнице: убивают один под в Kubernetes или одну виртуальную машину и гордо отчитываются об отказоустойчивости.

• Настоящая проверка архитектуры выживания — это полное отключение на рубильнике целой зоны доступности в боевом контуре раз в полгода с секундомером в руках:За сколько минут Control Plane пересоберет кворум до ?

• ‬‭‬Хватит ли физического Capacity в оставшихся зонах для автоматического рескейлинга?

• Смогут ли инженеры с нуля поднять контур банка из внешних отчужденных бэкапов в чистом поле без доступа к основному облаку?

Резюме

Октябрьский коллапс «Яндекса» — это жестокий, но бесценный урок для всей индустрии. Он наглядно показал, чего стоят красивые слайды про «99,99% SLA и облачную отказоустойчивость», когда за ними скрываются экономия на резервных мощностях, отсутствие географического DR‑региона и неспособность системы управления пересобрать кворум за трое суток.

Для нас, архитекторов, этот кейс — главный аргумент в разговорах с советом директоров и бизнесом. Когда в следующий раз C‑level спросит вас: «Зачем мы платим за простаивающий резервный контур в Сибири, за 35% пустого железа и за сложные механизмы мгновенной блокировки транзакций?» — просто положите перед ними хронологию событий 8–22 октября 2026 года и посчитайте стоимость 11 дней простоя банка. Архитектура безопасности и катастрофоустойчивости стоит дорого ровно до того дня, пока не прилетает первый «черный лебедь».