Чёрный октябрь «Яндекса»: три ЦОД упали, Yandex Cloud восстанавливали 11 дней

· ·

Чёрный октябрь «Яндекса»: три ЦОД упали, Yandex Cloud восстанавливали 11 дней

PrimeCoder · 2026 · формат: news

Что произошло, почему это важно и что взять в работу.

Три зоны доступности в одном регионе — это не Disaster Recovery: без второго георегиона и резерва мощностей локальная авария превращается в общенациональный блэкаут, и SMB пора требовать у провайдеров реальный DR-план и RPO в часах, а не в сутках.

Связанные услуги: каталог, AI Boost Team, стать клиентом.

Одиннадцать суток на пальцах

Восьмое октября, 01:31 по Москве. ЦОД в Сасово, зона доступности ru-central1-b. Остановка. Восемьдесят пять сервисов облака уходят вниз, к середине дня ложатся Cloud Functions и Serverless Containers.

Одиннадцатое октября, 04:00–07:13. Владимир, зона ru-central1-a. Кластеры управляемых баз принудительно уходят в Read-Only, объектное хранилище S3 перестаёт принимать запись. Двадцать второе октября — возвращают основные функции «Яндекс Пэй» и кредитного «Супер Сплит». Одиннадцать суток между этими датами.

Теперь главная цифра, из-за которой весь этот разбор вообще имеет смысл. Часть сервисов откатили к состоянию на 4 октября. RPO семь дней. Не семь минут, не семь часов. Неделя.

Форс-мажор тут был. Три площадки за четверо суток, атаки, пожары. Спорить с этим бессмысленно. Вопрос в другом: почему физический удар по трём зданиям превратился в одиннадцатидневный паралич финтеха и потерю недели данных у внешних клиентов. Ответ на этот вопрос лежит не в плоскости «война», а в плоскости архитектурных решений, которые принимались задолго до октября.

Хроника: где именно посыпалось

  • 8 октября, 01:31. Сасово, зона b. Остановка ЦОД. Минус 85 сервисов облака. Формально у платформы остались живые зоны — и это важно для дальнейшего.
  • 8 октября, 04:55. Массовые ошибки при создании виртуальных машин, кластеров Kubernetes и баз в живых зонах. Причина: мастер-ноды K8s и управляющие узлы СУБД физически жили в погибшей зоне b. Рабочие ноды целы, управление потеряно. Кластер есть, а сделать с ним ничего нельзя.
  • 9 октября, утро — 15:42. Повреждение ЦОД в Калуге. Облако официально договаривается размещать клиентов на мощностях Selectel, K2Cloud и VK Cloud. Гиперскейлер признаёт: своего резерва ёмкости нет. И только в 15:42, через 38 часов после Сасово, клиентам дают техническую возможность перенести управляющие компоненты K8s из мёртвой зоны и вычистить погибшие хосты из кластеров СУБД.
  • 10 октября. Выделение квот на вычисления и диски переводится в ручной режим. Эластичность закончилась. Клиенты с рабочими бэкапами не могут развернуть их на живых площадках: лимитов нет. В это же время в «Супер Сплите» начинают жаловаться на ошибочные и несанкционированные списания.
  • 11 октября, 04:00–07:13. Владимир. Ключевая площадка. Живыми остаются зоны d и e. К 06:08 облако фиксирует: «Оставшаяся конфигурация ресурсов не обеспечивает устойчивости, задействуйте внешние DR-планы за пределами облака». К 07:13 базы в Read-Only, S3 не пишет. Внизу «Яндекс Go», «Еда», «Яндекс 360», «Директ», «Яндекс Пэй», а вместе с ними ЦИАН, «Додо Пицца», «Магнит» и госсистема «ВетИС».
  • 13–22 октября. Базовые переводы возвращают ночью 13-го. Для остановки оттока вкладов ставку по накопительным «Сейвам» экстренно поднимают до 20% годовых на неделю. Погашение сплитов чинят к 16-му, «Директ» к 20-му, финтех к 22-му. На фоне этого выясняется, что часть бэкапов лежала в том же поражённом контуре, а свежие недельные дампы не завершились. Отсюда откат на 4 октября и переназначение первичных ID.

74,5 часа, которые никто не использовал

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

Что должно было произойти за эти часы по учебнику? Кластер выводит мёртвую зону b из конфигурации кворума и реплицирует третью копию данных в резервную зону. Self-healing, re-quorum, восстановление формулы «два из трёх». К утру 11 октября большинство кластеров так и остались стоять на двух ногах с мертвым грузом зоны b в конфигурации. Когда Владимир выпал, кворум кончился математически, без всякой мистики.

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

Отдельно стоит объяснить миф про CAP и split-brain, который сразу пошёл гулять по чатам. Мол, архитекторы переключили базы в режим AP, алгоритмы консенсуса сошли с ума. YDB и управляемый PostgreSQL сделали ровно то, что обязана сделать честная CP-система при потере кворума: заблокировали запись. Никакого развала консенсуса. Базы сработали по учебнику. Их убил паралич управляющего слоя и отсутствие свободного железа.

Вот это и есть развилка, из которой растёт вся история. Data Plane работал как задумано. Control Plane был привязан к той самой зоне, которую потеряли первой. Получается красивая и очень дорогая конструкция: система технически жива, но никто не может ею управлять. Инженеры 38 часов не имели инструмента, чтобы просто отвязать мастер-ноды от мёртвого хоста.

Чёрный октябрь «Яндекса»: три ЦОД упали, Yandex Cloud восстанавливали 11 дней — иллюстрация

Ручные квоты: момент, когда облако перестало быть облаком

Десятое октября — самая недооценённая дата во всей хронике. Именно там закончилась подписка на облако в том виде, в каком её продают.

Перевод квот в ручной режим означает простую вещь: мощность больше не выдаётся по API, её выдают по звонку и по остаточному принципу. Клиент с готовым бэкапом и написанным runbook'ом не может ничего развернуть, потому что нет лимита на диски и vCPU. Договор с конкурентами от 9 октября — честный и довольно жёсткий сигнал: собственный запас ёмкости кончился, дальше только чужая стойка.

Capacity management — скучная дисциплина, её обычно режут первой при оптимизации бюджета. Резерв на случай, когда половина парка уходит в аварию, стоит денег и не приносит выручки. Ровно до того дня, когда он нужен весь сразу.

Metro-cluster, который выдали за Disaster Recovery

Все основные площадки «Яндекса» стоят в одном макрорегионе: Сасово, Калуга, Владимир, Мытищи. Радиус 200–350 км от Москвы. Для высокой доступности это нормальная и даже правильная схема: задержка между зонами минимальна, синхронная репликация работает, отказ одного здания переживается без потери данных.

Но это Metro-Cluster. Это не DR.

Они приравняли три зоны доступности в одном регионе (ru-central1) к полноценному Disaster Recovery (DR).

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

Есть ещё один слой, который добил историю. Бэкапы. Часть дампов физически лежала в том же поражённом контуре, что и прод. Резервная копия в той же зоне, что и данные, это не бэкап, это вторая копия проблемы. Отсюда и RPO в семь дней: восстанавливать было не из чего, кроме неполных недельной давности слепков.

И финальная ремарка про управляемость. Когда облако само себе выписывает вердикт «задействуйте внешние DR-планы за пределами облака», оно перекладывает на клиента работу, которую клиент по определению не мог сделать в момент аварии. У SMB нет второго облака, поднятого в режиме горячего резерва. У SMB есть договор и надежда.

Что это значит для SMB: вопросы без ответа «у нас три зоны»

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

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

  1. RPO и RTO в цифрах и в часах. Не «надёжное резервирование», а конкретно: сколько данных мы теряем в худшем сценарии и за сколько часов сервис возвращается. Семь дней RPO — это не резервное копирование, это археология.
  2. Где физически лежат бэкапы. Отдельный регион, отдельный провайдер, отдельный аккаунт с другими учётными данными. Если ответ «в нашем же облаке, но в другой зоне» — вы покупаете файл, а не защиту.
  3. Сколько зон остаётся после потери одной и что происходит с кворумом. Три зоны — хорошо. Три зоны без автоматического перестроения кворума — декорация.
  4. Есть ли capacity-резерв. Прямой вопрос: если завтра половина парка уходит в аварию, найдутся ли квоты на развёртывание из бэкапа без ручного согласования.
  5. Куда уедет управляющий слой. Kubernetes, панель, биллинг, API. Если control plane живёт в той же зоне, что и данные, отказ площадки отключит вам руки, а не только серверы.
  6. Когда последний раз проводили реальное переключение. Не учения на бумаге. Дата, акт, список участников, замеренное время восстановления.
  7. Что вы подписываете в части компенсаций. Прочитать пункт про ответственность до аварии, а не после.

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

Цена вопроса

Сравнивать стоимость второго региона со стоимостью простоя принято на эмоциях, потому что точных цифр простоя никто заранее не считает. Но один маркер из этой истории показателен: экстренное поднятие ставки по накопительным счетам до 20% годовых на неделю. Это цена остановки оттока денег. Прямая, публичная и очень наглядная. Бизнес платит за восстановление доверия сразу, а за архитектуру — потом, и обычно уже под давлением.

Георезерв стоит денег постоянно, авария — эпизодически. В спокойный год первый вариант выглядит расточительством, во втором полугодии 2026-го — страховкой. Решение принимается не по калькулятору, а по ответу на вопрос: переживёт ли ваш бизнес одиннадцать дней тишины в кассе.

Вердикт

Три зоны доступности в радиусе 300 км — это защита от отказа железа, а не от катастрофы. Их выдали за DR, и весь октябрь показал цену этой подмены: 74,5 часа упущенного времени, 38 часов паралича управления, ручные квоты, RPO в семь дней и одиннадцать суток реанимации финтеха.

Для SMB вывод короткий и неприятный. Пока у вас в договоре не написаны RPO и RTO в часах, а бэкап не лежит за пределами контура провайдера, вы не защищены — вы просто ещё не попали в неудачное окно. Требуйте цифры и дату последнего реального переключения. Остальное — маркетинг.

Читайте также