С 8 по 11 октября 2026 года атаки БПЛА вывели из строя три дата-центра Яндекса. Сасово и Владимир остановлены полностью, в Калуге потеряно несколько модулей. На этих площадках работают сервисы самого Яндекса, его суперкомпьютеры и Yandex Cloud: 84 сервиса платформы и около 64 000 клиентов.

Точного числа «сервисов в ЦОДе» никто не публикует. Нагрузка на этих площадках делится на три слоя, и по каждому есть свои цифры.

Первый слой — Yandex Cloud. В карточке инцидента от 11 октября перечислено 84 сервиса платформы: от Compute Cloud, Object Storage и Managed Service for Kubernetes до Managed Service for YDB, DataLens, Cloud DNS, YandexGPT API и Yandex Cloud Billing.

Клиентов у облака около 64 000 на первое полугодие 2026 года, на 36% больше, чем годом раньше. Больше трети компаний из рейтинга РБК-500 пользуются Yandex Cloud.

Второй слой — собственные сервисы Яндекса, они живут на той же сети дата-центров. 8 октября с перебоями работали поиск, Почта, Карты, Яндекс Go, Яндекс Пэй, Документы и Таблицы. 11 октября к ним добавились Яндекс Музыка, Алиса и Яндекс Еда. Функции Диска Яндекс в тот же день урезал сам, чтобы хватило ресурсов на остальное.

Третий слой — продукты других компаний. 8 октября жалобы шли на Циан, Авито, Т-Банк, Иви, «Магнит», «Пятёрочку», РЖД и операторов связи. Жалобы ещё не значат, что сервис живёт в Yandex Cloud: часть сбоев могла идти через интеграции с Яндексом, а днём 8 октября отдельно сбоила сеть Curator. Прямо связал свой сбой с инцидентом у инфраструктурного партнёра Циан. После остановки Сасово перестали открываться и некоторые сайты органов власти Калужской области, включая сайт администрации Калуги.

По железу Яндекс заполненность стоек не раскрывает, поэтому ориентироваться можно только на проектные цифры.

Отдельно стоят три суперкомпьютера для машинного обучения. «Червоненкис» (21,53 петафлопса по TOP500) и «Ляпунов» (12,81) находятся в Сасово. «Галушкин» (16,02 петафлопса, 134-е место в июньском TOP500) — во Владимире. Под удар попали площадки со всеми тремя, но повреждены ли сами машины, компания не сообщает.

Отказоустойчивость Yandex Cloud рассчитана на потерю одной зоны, и в документации это записано прямо. Зональный инцидент там определён как сбой в пределах одной зоны доступности. Про высокодоступный мастер Managed Service for Kubernetes в трёх зонах сказано, что при недоступности одной зоны он остаётся работоспособным. Про две зоны документация молчит.

8 октября всё отработало по этой модели. Через семь часов после первой записи облако отчиталось, что нагрузка переключена, а в остальных зонах сервисы работают штатно. Клиенты, у которых всё стояло только в ru-central1-b, переносили ресурсы сами: в другую зону автоматически ничего не переезжает.

9 октября открыли две ручные операции. Управляющие компоненты региональных кластеров Kubernetes стало можно перенести из ru-central1-b в другие зоны. Из отказоустойчивых кластеров Managed Databases стало можно удалить хосты ru-central1-b, и только после этого кластеру возвращаются операции управления, включая изменение настроек и добавление пользователей.

Вторая проблема — ёмкость. Резерв в зонах обычно закладывают под переезд нагрузки одной зоны, сколько его было у Yandex Cloud, компания не раскрывает.
10 октября Yandex Cloud перешёл на полностью ручное управление квотами на вычислительные ресурсы и диски. Всем дали немного ресурсов сверх уже используемых, создание сверх лимитов ограничили, приоритет отдали тем, у кого критичные сервисы ещё лежат. Параллельно команда работала над тем, чтобы увеличить количество доступных вычислительных ресурсов. То есть свободного compute уже не хватало.

После Владимира модель кончилась. В ночь на 11 октября канал Yandex Cloud Alerts написал: «Оставшуюся конфигурацию ресурсов считаем неустойчивой». Режим платформы объявлен аварийным, клиентам рекомендовано задействовать любые альтернативные планы аварийного восстановления. Статус компонентов на 05:59 мск:

• Yandex Cloud Console и API доступны;

• Compute доступен частично;

• Managed Databases: большинство HA-кластеров переключились, часть работает в read-only или недоступна;

• Object Storage доступен на чтение, с записью возможны проблемы;

• Managed Service for Kubernetes: состояние региональных кластеров оценивали, к 08:55 сервис доступен, но с проблемами у отдельных кластеров;

• IAM доступен.

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

Read-only в части баз и проблемы с региональными кластерами укладываются в арифметику кворума. Региональный мастер Kubernetes — это три хоста в трёх разных зонах. etcd в такой схеме живёт, пока доступно большинство участников, то есть два из трёх. Если мастера кластера стояли в ru-central1-a, ru-central1-b и ru-central1-d, после 11 октября живым остался один.

С HA-кластером базы на три хоста в трёх зонах та же история. Без кворума автоматика не имеет права повысить оставшуюся реплику до primary: при возврате связи получилось бы два primary с разными данными. Обычно такой кластер остаётся в read-only или встаёт, пока кто-то не вмешается руками. Как это устроено внутри Managed Databases, Yandex Cloud не описывает, но статус на 11 октября с этой картиной сходится.

Схема для случая, когда мастера кластера стояли в ru-central1-a, ru-central1-b и ru-central1-d. Если ваш кластер разложен иначе, расклад другой.

У этого вопроса четыре ответа, в зависимости от того, что считать восстановлением. Ниже моя оценка и то, на чём она держится.

Свои сервисы Яндекс поднимает переключением трафика на уцелевшие мощности. 8 октября большую часть неполадок устранили к вечеру. После Владимира быстро вернулись Кинопоиск, доставка еды и такси, хотя и не все сервисы.

Цена — деградация. 11 октября Яндекс ограничил функции Диска, чтобы сохранить работоспособность остального. Так аварийный режим и выглядит: второстепенное выключают ради ядра.

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

Как это выглядит со стороны клиента, рассказал глава TelecomDaily Денис Кусков, у которого на Яндексе сайт и приложение. После первых атак он с трудом поднял всё к пятнице, а в ночь на 11 октября всё легло снова. Восстановление Владимира он оценивает в недели и советует переезжать в небольшие дата-центры.

Я бы на месте клиента не ждал. Платформа сама называет свой режим аварийным, а новых ресурсов не выдаёт.

Ближайший прецедент — 30 марта 2025 года. Тогда ru-central1-b полностью потеряла питание из-за аварии на подстанции. Зона стала недоступна к 13:06, восстановление питания началось в 15:30. Дальше всё шло по плану: базовая инфраструктура, Compute, Managed БД, потом возврат трафика в зону через NLB и ALB. Счёт шёл на часы, потому что железо было целым.

Сейчас считать его целым нельзя. По Сасово Яндекс пока не может подтвердить, что оборудование вообще удастся восстановить. В Калуге несколько модулей выведены из строя полностью. Если железо сгорело, восстановление превращается в стройку: обследование здания, энергетика и охлаждение, закупка и монтаж серверов, потом раскатка платформы.

По закупке есть оценка ведущего аналитика Mobile Research Group Эльдара Муртазина. Цены на серверы и системы хранения в России, по его словам, за последние дни выросли на 10–15%. В наличии такого оборудования мало, а привезти его — 2–3 месяца. И это только железо, без здания и энергетики.

Для суперкомпьютеров Муртазин называет 2–2,5 года, если они уничтожены. «Галушкин» построен на AMD EPYC и NVIDIA A100. С 2022 года ускорители этого класса в Россию напрямую не поставляются из-за экспортных ограничений США. Так что срок здесь определяет доступность самих ускорителей.

Первым делом — где физически стоят хосты ваших managed-кластеров и мастера Kubernetes. Если два из трёх были в ru-central1-a и ru-central1-b, кластер без кворума, и автоматика его не вытащит. Нужна либо ручная операция со стороны облака, либо пересборка из бэкапа в другом месте.

Дальше данные. Пока Object Storage отдаёт их на чтение, бэкапы и всё ценное надо выгружать за пределы Yandex Cloud. Восстановиться из бэкапа внутри облака сейчас может не получиться: выдача квот на дополнительные ресурсы приостановлена.

И инфраструктурный код. Terraform-модули на провайдере yandex к Selectel или VK Cloud напрямую не применить: у каждого провайдера свои типы ресурсов и свои аргументы. yandex_compute_instance на другой площадке превратится в другой ресурс с другим набором полей. Переезд по IaC — это переписывание модулей, и на него надо закладывать время уже сейчас.

• Yandex Cloud Alerts — обновления по инцидентам 9–11 октября

• «Железное сердце» Яндекса — что происходит с нашими дата-центрами — заявление Яндекса

• Пользовательское соглашение сервисов Яндекса, редакция от 10 октября 2026 года

• Документация Yandex Cloud: зоны доступности, зональный инцидент, мастер Managed Service for Kubernetes

• Суперкомпьютеры Яндекса и «Галушкин» в TOP500

• HAKA Moscow: дата-центр Яндекса во Владимире

• DatacenterDynamics: дата-центр Яндекса в Калуге

• Т—Ж: хронология атаки на дата-центр в Сасове

• SecurityLab: остановка дата-центра в Сасово

• Comss.ru: повреждение дата-центра в Калуге

• Фонтанка: эксперты о последствиях атак

• Эксперт: Яндекс не может подтвердить восстановление оборудования в Сасово

• Habr: авария в ru-central1-b 30 марта 2025 года

• BFM: какие сервисы вернулись после атаки во Владимире