Чёрный октябрь Яндекса: как три ЦОДа парализовали облако на две недели

8 октября 2026 года, половина второго ночи. В дата-центре Яндекса в Сасово пожар и остановка всего машзала. Через трое с половиной суток, 11 октября в семь утра, физически разрушен ЦОД во Владимире. Ещё раньше повреждён ЦОД в Калуге. В сумме три площадки в Центральной России за четверо суток, одна из крупнейших облачных платформ страны лежит в руинах, остановлены ключевые сервисы экосистемы (от Такси до Директа), потеряны недельные данные у ряда внешних клиентов, а банковские сервисы Яндекса будут в коме до 22 октября, одиннадцать дней.

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

Трое суток, которые всё решили

Когда 8 октября лёг ЦОД в Сасово, в облаке работало четыре зоны доступности (a, b, d, e). Потеря b была тяжёлой, но не фатальной, потому что теоретически кворум кластеров можно было пересобрать за часы, дореплицировать данные на резервные мощности, и встретить следующий удар в полной готовности. Между первой и второй аварией прошло 74 часа, это почти трое суток.

Но этого не случилась.

Почему? Ответ кроется не в сложности распределённых алгоритмов, а в трёх прозаических причинах.

Во-первых, слой управления облаком (Control Plane) находился в поражённой зоне и инженеры 38 часов не могли элементарно отвязать мастер-ноды от мёртвого ЦОДа.

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

И в-третьих, значительная часть резервных копий лежала прямо в том же хранилище S3, которое вскоре встало в Read-Only с ошибками чтения шардов.

Утром 11 октября, когда упал Владимир, большинство кластеров БД стояли с одной живой репликой из трёх. Кворум схлопнулся. Базы ушли в Read-Only. Начался полномасштабный блэкаут.

Почему «защита от сбоев» превратилась в источник катастрофы

Архитектура Яндекса была спроектирована по лекалам Metro-HA: несколько ЦОДов на расстоянии 200–350 км друг от друга, синхронная репликация, кворум Raft/Paxos. В нормальных условиях это надёжная схема: отказ одной площадки система переваривает без потерь, потому что остаются две живые копии.

Но Metro-HA это защита от локального сбоя, а не от региональной катастрофы. Все площадки находились в одном макрорегионе: одна энергосистема, один часовой пояс, одна зона поражения. Настоящий Disaster Recovery предполагает наличие физически удалённого региона — другой провайдер, другое энергокольцо, другой сетевой периметр. Этого региона у Яндекса не было. Metro-HA заменили DR, и когда регион накрыло целиком, отказоустойчивость испарилась.

Вторая системная ошибка — архитектура Control Plane. Мастер-ноды Kubernetes, база метаданных etcd, ключи шифрования и IAM жили в том же облаке, которым управляли. Инструменты спасения инфраструктуры тоже умерли вместе с инфраструктурой.

Третья — физика. Чтобы пересобрать кластер БД и восстановить кворум, нужно место: живые диски, свободные серверы, пропускная способность сети. Если утилизация площадок в мирное время 90%, то при потере одной зоны оставшиеся просто не выдерживают нагрузку, им просто не хватает капасити. Автоматическое выделение ресурсов отключается, квоты выдаются вручную. Клиентам официально предлагают мигрировать к конкурентам.

Три этих просчёта — подмена DR на Metro-HA, рекурсивная зависимость Control Plane от Data Plane, отсутствие резерва ёмкости, превратили локальный пожар в национальный блэкаут.

Почему такси подняли за часы, а банк — за две недели

Самый частый вопрос про октябрьскую аварию: как так вышло, что Яндекс Go и сервисы доставки подняли быстро, а платёжные сервисы лежали до 22 октября?

Дело не в базах данных. CP-системы (Consistency / Partition Tolerance) YDB, PostgreSQL) честно отработали: при потере кворума они заблокировали запись и не дали повредить данные на уровне дисков. Проблема была выше, на уровне прикладной архитектуры.

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

  • At-least-once доставка сообщений: когда брокер лежит, сообщение может уйти дважды или не уйти вовсе
  • Агрессивные ретраи с экспоненциальной задержкой: в момент таймаута система лупит запрос снова и снова
  • Оптимистичные фоллбэки: если сервис-сосед не отвечает, операция помечается успешной «на честном слове»

С 8 по 11 октября инфраструктура не лежала мёртвой полностью, она деградировала волнами: то сетевой таймаут, то отвал шарда БД, то потеря сообщения в очереди. В этом полуживом состоянии тысячи распределённых транзакций оказались в противоречивых статусах. Где-то деньги с карты списаны, а проводка не зафиксирована. Где-то ретрай создал дубликат списания, потому что кэш ключей идемпотентности не выдержал нагрузки. Где-то в Kafka потерялось сообщение о закрытии сделки, и в графике Сплита вечно висит открытый долг.

Когда 11 октября облако окончательно встало в RO, перед банком открылся единственный путь: Stop-the-World, полная остановка всех операций и ручная потранзакционная сверка. Инженеры сутками сводили логи платёжных шлюзов с хвостами очередей, дампами баз и выписками корсчетов, операция за операцией, баланс за балансом. Две недели работы, потому что автоматического механизма Reconciliation для такого масштаба не существовало.

Мораль: в финансовых системах ни одна асинхронная цепочка не должна продолжаться, когда инфраструктура штормит. Нужен автоматический Kill-Switch: как только мониторинг фиксирует потерю зоны доступности и деградацию ядра БД, все вторичные процессы (списания, начисления, кредитные конвейеры) мгновенно замораживаются. Лучше не списать вовремя, чем списать дважды и потерять концы.

Как должна выглядеть архитектура, которая выживает

Давайте от критики перейдём к конструкции. Что могло бы предотвратить катастрофу или хотя бы минимизировать её масштаб.

1. Два региона, а не два ЦОДа в одном. Основной регион — три зоны синхронной репликации вокруг Москвы (Metro-HA). Это защита от пожара в одном машзале. Резервный регион — за Уралом, асинхронная репликация с задержкой в секунды, полностью независимая энергосистема и сетевая инфраструктура. При потере основного региона коммерческие сервисы переключаются за минуты, банковские — за десятки минут. Цена: +30-40% к CAPEX. Цена 11-дневного простоя: на порядок выше.

2. Control Plane отдельно от Data Plane. Мастер-ноды K8s, реестр метаданных, ключи шифрования, корневые DNS-серверы должны работать даже тогда, когда весь основной регион недоступен. Решение — лёгкий снапшот управления в резервном регионе (etcd snapshot, IAM-read-only, DNS-secondaries), полностью независимый от основного облака. Никаких ситуаций «пульт сгорел, управлять нечем».

3. Неприкосновенный запас мощности. Законодательное правило архитектурного комитета: суммарная утилизация трёх зон доступности никогда не превышает 65%. При потере любой зоны оставшиеся две принимают 100% нагрузки и третью реплику данных автоматически, без ручных квот и звонков конкурентам. Да, железо простаивает. Да, это стоит денег. Нет, это не «замороженные миллиарды» — это страховка.

4. Отчуждаемые бэкапы по правилу 3-2-1-1-0. Три копии данных. Два типа носителя (блочное хранилище + объектное). Одна копия off-site (в другом регионе за 2000+ км). Одна копия air-gapped ( физически или логически изолированная от рабочих систем, корпоративных сетей и интернета) с WORM-защитой (Write Once Read Many — нельзя изменить или удалить злоумышленнику). Ноль ошибок при регулярной верификации — проверяется restore test раз в месяц, обязательно. Непрерывный стриминг журналов предзаписи (WAL/CDC) во внешний контур вместо еженедельных полных дампов. RPO укладывается в секунды, а не недели.

5. Автоматический Kill-Switch для асинхронных процессов. В момент потери зоны и деградации ядра БД все вторичные процессы (регулярные списания, начисления, кредитные конвейеры) получают сигнал «стоп» и замирают до восстановления кворума. Никаких ретраев в шторм. Никаких «maybe»-статусов распределённых саг. Идемпотентность через глобальные детерминированные UUIDv7 — никаких автоинкрементных SERIAL ID, которые ломаются при восстановлении из дампа.

6. Учения не в песочнице. Раз в полгода проводить полное отключение целой зоны доступности рубильником, без предупреждения. С секундомером. Все должны видеть: за сколько пересобрался кворум, хватило ли ёмкости, и — самое главное — может ли инженер с нуля поднять контур из внешних отчуждённых бэкапов «в чистом поле», когда ни один сервис основного региона не доступен. Большинство компаний играют в Chaos Engineering, убивая один контейнер в тестовом кластере. Это не готовит к реальной катастрофе. Это просто смешно.

Три вопроса, которые руководитель должен задать немедленно

Октябрь 2026 года в Яндексе вообще не про вину конкретного SRE. Это системный сбой на уровне Enterprise Architecture и риск-менеджмента. Нужно задать три вопроса эксплуатации и в качестве ответа потребовать не слайды, а демонстрацию работающего механизма.

Вопрос первый: где лежат наши бэкапы? Если в том же облаке, в том же регионе и под тем же Control Plane, что и прод — мы приплыли. Правильный ответ: минимум одна копия бэкапа лежит физически отдельно, в другом регионе, у другого провайдера, с защитой от модификации.

Вопрос второй: сколько у нас свободного железа? Смогут ли при выходе из строя любой зоны доступности оставшиеся принять 100% нагрузки и поднять третью реплику данных без «ручного режима»? Буфер в 30-35% это не роскошь, а условие выживания. CAPEX нужно экономить в другом месте.

Вопрос третий: когда мы последний раз поднимали резервный контур из бэкапов «в чистом поле» — без API основного облака, без централизованного IAM, без привычных инструментов? Если никогда, то наш DRP не работает. Единственная честная проверка — это регулярный GameDay с полным физическим отключением зоны.

Резюме

Крах Yandex Cloud в октябре 2026 года это не учебник по «как делать не надо». Это жестокий, редкий и очень бесценный по опыту случай, который показывает: платформа уровня гиперскейлера может рассыпаться не из-за ошибки в коде или бага в алгоритме консенсуса, а из-за четырёх прозаических причин:

  • Нет второго региона (Metro-HA без DR — защита только от локальных сбоев)
  • Control Plane завязан на Data Plane (пульт управления сгорел вместе с серверной)
  • Утилизация в ноль (нет свободного места для пересборки кластеров)
  • Бэкапы внутри того же контура (неделя потерянных данных и 11 дней ручной сверки)

Архитектура выживания — это не про красивые бесполезные слайды про "Стабильность/SLA/отказоустойчивость 99,99%". Это физическое разделение, резерв ёмкости, внешние бэкапы и регулярные учения. Не здесь нужно экономить.

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

Все конкретные рецепты есть в связанных главах книги.

См. также: