Yandex Cloud после атак на дата-центры: пошаговый план восстановления и защиты бизнеса

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

По состоянию на 15 октября 2026 года восстановление продолжается: две зоны остаются недоступными, поэтому работа отдельных облачных сервисов по-прежнему ограничена, а у клиентов возможны сбои.

Подробная хронология событий с 8 по 11 октября, последствия каждого инцидента и развитие ситуации по датам разобрали в отдельном материале – «Хроника атак на дата-центры Яндекса».

Что именно работало на пострадавших площадках

Нагрузка на три площадки делилась на три слоя.

Первый слой – Yandex Cloud

В карточке инцидента №2136 перечислено 84 затронутых сервиса: от Compute Cloud, Object Storage и Managed Service for Kubernetes до Managed Service for YDB, DataLens, Cloud DNS, YandexGPT API и Yandex Cloud Billing. Клиентов у облака около 64 тыс. на первое полугодие 2026 года – на 36% больше, чем годом ранее. Более трети компаний из рейтинга РБК-500 пользуются Yandex Cloud.

Второй слой – собственные сервисы Яндекса

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

Третий слой – продукты других компаний

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

Физические параметры площадок (по проектной документации)

Источник: Просто.

На площадках в Сасово и Владимире располагались три суперкомпьютера для машинного обучения: «Червоненкис» и «Ляпунов» – в Сасово, «Галушкин» (134-е место в июньском TOP500) – во Владимире. «Галушкин» построен на AMD EPYC и NVIDIA A100. С 2022 года ускорители этого класса в Россию напрямую не поставляются из-за экспортных ограничений США. Повреждены ли сами машины – компания не сообщает.

Почему Multi-AZ не спас: физический потолок емкости

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

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

После выхода из строя Владимира (ru-central1-a) модель исчерпала себя.

Реальные сроки восстановления: четыре горизонта

Источник: Просто.

Получается, что потеря одного дата-центра обычно решаема, двух – уже серьезная нагрузка, трех и больше – ведет к критическим проблемам.

Важно! Это общие ориентиры, а не инструкция по устранению инцидента. Конкретные решения – что переключать, что откатывать, в каком порядке – должны принимать ваши технические специалисты: DevOps/SRE, DBA, ИБ-инженеры, исходя из архитектуры именно вашей системы. Чек-лист помогает не растеряться и не упустить важное в первые часы, но не заменяет экспертизу тех, кто отвечает за вашу инфраструктуру.

Самое главное – не изменяйте базы данных при частичной доступности без свежего дампа. Это повышает риск потери целостности и делает восстановление неопределимым.

Управленческие решения (0–2 часа)

Зафиксируйте факт инцидента. Проверьте официальный статус на Yandex Cloud. Сделайте скриншот с отметкой времени – он понадобится для запроса по SLA.

Назначьте ответственных. Определите роли: DevOps/SRE (техническое восстановление), DBA (базы данных), владелец продукта (приоритеты), ИБ (безопасность данных), юрист (фиксация убытков и претензия). Документируйте все действия с отметками времени.

Определите RPO. Зафиксируйте момент последней подтвержденной резервной копии. Это ваша точка отсчета потерь данных.

Оцените критичность. Составьте список затронутых сервисов с приоритетами: что должно работать в первую очередь, что можно отложить.

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

Что можно делать дальше

Примите решение о переезде. Если платформа объявила аварийный режим и не выдает квоты – не ждите автоматического восстановления. Оцените, что быстрее: восстановление внутри облака или развертывание у альтернативного провайдера.

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

Отправьте финальное уведомление клиентам. После восстановления перечислите фактическое время простоя, подтвержденный RPO и задействованные механизмы резервирования.

Восстановление при дефиците квот

Массовый инцидент 10–11 октября обнажил критический риск: в уцелевших зонах быстро исчерпываются квоты, а их выдача временно приостанавливается. 

Действующие лимиты:

     🟡 32 снимка и 400 ГБ суммарного объема disk snapshots на облако;

     🟡 1 024 ГБ объема Object Storage и ограничение по числу бакетов на облако.

Алгоритм действий при дефиците квот

1. Подайте запрос на расширение квот через консоль или поддержку с указанием типа и требуемого объема.
2. Параллельно разворачивайте резервный контур у второго провайдера по готовым IaC-шаблонам.
3. Держите готовые IaC-шаблоны без жестко прописанных ID ресурсов одного провайдера – это позволит быстро поднять окружение на альтернативной площадке.

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

Multi-AZ защищает от отказа одной зоны. Мастер-узлы Kubernetes рекомендуется размещать в трех зонах. Но одновременный физический инцидент в двух зонах и дефицит емкости ломают эту модель: автоматический failover не завершается, упираясь в лимиты и квоты.

Получается, что Multi-AZ – необходимый, но недостаточный уровень для критичных систем. Нужна Multi-Cloud или гибридная схема:

     🟡 основной контур – Yandex Cloud (или любой другой основной провайдер);

     🟡 резервный контур – второй провайдер (VK Cloud, Selectel, K2Cloud) или on-prem;

     🟡 независимое хранение бэкапов вне площадки основного провайдера;

     🟡 раздельные учетные записи, ключи и каналы доступа – чтобы инцидент у одного провайдера не блокировал доступ к резервному контуру.

Критерии выбора резервного провайдера

Перед тем как выбрать второй контур, задайте вендору письменные вопросы:

     🟡 Где физически размещена инфраструктура и в каких зонах доступности?

     🟡 Где хранятся резервные копии – в тех же ЦОДах или независимо?

     🟡 Каков заявленный RTO и RPO по SLA?

     🟡 Как получить выгрузку данных в аварийном режиме?

     🟡 Каков порядок и срок подачи запроса на компенсацию?

Отказоустойчивый буфер для AI/RAG и интеграций

Если ваш бизнес завязан на чат-ботов, обработку лидов или RAG-пайплайны на базе LLM, прямая привязка входящих вебхуков к одной SaaS-платформе или виртуальной машине – неприемлемый риск.

Принцип разделения контуров: архитектура должна строго изолировать прием входящих событий (Ingress Buffer) от оркестрации логики и баз данных.

Нюансы эксплуатации

Промежуточный сервер – тоже точка отказа, но дешевая, изолированная и поднимаемая из базового образа за минуты. Если внешний API требует handshake (challenge-запросы), буфер должен уметь отдавать эхо-ответ.

В буфере оседают персональные данные: диск должен быть зашифрован (LUKS), а площадка должна отвечать требованиям Федерального закона от 27.07.2006 № 152-ФЗ «О персональных данных».

Учитывайте лимиты сервиса очередей: например, около 300 вызовов ChangeMessageVisibility в секунду для стандартной очереди.

Статья 15 Гражданского кодекса РФ определяет убытки просто: это реальный ущерб плюс упущенная выгода. Реальный ущерб – конкретные расходы на восстановление инфраструктуры, доплаты специалистам, стоимость утраченных данных и затраты на экстренный переезд к другому провайдеру. Упущенная выгода – доходы, которые бизнес не получил из-за простоя.

Для расчета общей суммы потерь используется базовая формула:

     🟡 Потери = (Целевой SLA − Фактический SLA) × Стоимость часа простоя + Прямой ущерб.

Пример расчета

Интернет-магазин с выручкой 500 тыс. рублей в сутки (≈ 20 833 руб./час). Простой составил 18 часов. 

Прямые расходы на восстановление (DevOps-специалисты, аренда ресурсов у альтернативного провайдера) – 150 тыс. рублей.

Упущенная выгода: 20 833 × 18 = 375 тыс. рублей.

Итого убытки по ст. 15 ГК РФ: 525 тыс. рублей.

По общему правилу (ст. 15, 393 ГК РФ) убытки подлежат возмещению в полном объеме, если законом или договором не предусмотрено возмещение в меньшем размере. В стандартных договорах облачных провайдеров (IaaS/PaaS) традиционно закрепляется ограничение ответственности реальным ущербом и исключение упущенной выгоды (п. 1 ст. 15 ГК РФ), а предельный совокупный размер ответственности зачастую ограничивается стоимостью услуг за соответствующий расчетный период. Взыскание упущенной выгоды в суде требует преодоления договорных ограничений ответственности.

Важно! 10 октября 2026 года Яндекс внес дополнения в пользовательское соглашение, включив атаки БПЛА и ракет в перечень обстоятельств непреодолимой силы. Однако само по себе одностороннее включение событий в договорную оферту не предрешает квалификацию события судом: в силу п. 3 ст. 401 ГК РФ и разъяснений Постановления Пленума Верховного Суда РФ от 24.03.2016 № 7 бремя доказывания признаков чрезвычайности, непредотвратимости и причинной связи лежит на стороне, нарушившей обязательство. Кроме того, по п. 4 ст. 401 ГК РФ заключенное заранее соглашение об устранении или ограничении ответственности за умышленное нарушение обязательства ничтожно.

Фиксация инцидента и подача претензии по SLA

Актуальные условия и порядок компенсаций публикуются в Yandex Cloud SLA. Для отдельных сервисов действуют свои нормы. Например, для Yandex Cloud Functions:

     🟡 при доступности ниже 99,00% и не ниже 95,00% – компенсация 15% стоимости сервиса за период;

     🟡 при доступности ниже 95,00% – компенсация 30%;

     🟡 при утрате данных по вине провайдера – компенсация до 100% стоимости за период.

Срок на подачу запроса – 30 календарных дней с момента инцидента (см. Yandex Cloud SLA). При пропуске срока право на компенсацию утрачивается. Компенсация предоставляется скидкой на услуги, а не денежной выплатой.

Досудебный порядок при арбитражных спорах

Досудебный претензионный порядок в арбитражном процессе императивно установлен ч. 5 ст. 4 Арбитражного процессуального кодекса РФ (АПК РФ): спор о взыскании денежных средств по требованиям из договоров может быть передан на разрешение арбитражного суда по истечении 30 календарных дней со дня направления претензии, если иной срок или порядок не установлены законом либо договором. Направление претензии допускается через систему юридически значимого ЭДО с квалифицированной электронной подписью (УКЭП).

Минимальный пакет документов для претензии

1. Шкала инцидента с отметками времени (скриншоты статус-страницы с временными метками).
2. Логи и метрики за период инцидента.
3. Список затронутых сервисов и пользователей.
4. Перечень использованных бэкапов/снимков и результаты восстановления.
5. Расчет простоя, прямых потерь и упущенной выгоды.
6. Переписка с поддержкой провайдера.

Что делать, если консоль Yandex Cloud недоступна?

Используйте CLI/API; проверьте профиль yc config list. Пустая страница статуса не гарантирует, что все работает: в ходе инцидента пользователи видели статус «работает» при недоступном интерфейсе.

Нужно ли менять провайдера сразу после сбоя?

Резкий переезд в разгар инцидента повышает риски. Разверните критические узлы в гибридном формате (Multi-Cloud), решение о полной миграции принимайте после пост-мортема и сравнения альтернатив. Сравните также условия у VK Cloud SLA.

Сохраняются ли данные на дисках Compute Cloud при аварии?

Сетевые диски дублируются и, как правило, сохраняются; доступ восстанавливается после поднятия сетевой и дисковой подсистем. Данные на локальных дисках (Local SSD) при физическом повреждении оборудования могут быть утрачены безвозвратно.

Что делать с Яндекс Директом и Метрикой во время сбоя?

Если кабинет Директа недоступен, а заявки по CRM идут в обычном объеме – реклама работает, трогать ее не нужно. Если кабинет открывается, но показы около нуля – включайте запасной канал заявок, кампании не удаляйте. Не меняйте стратегии автооптимизации на основе данных за дни сбоя: выборка неполная и смещенная. Поставьте в Метрике примечания на даты 8, 9 и 11 октября с пометкой «сбой Яндекса».

^{Статья носит информационный характер и не является технической или юридической рекомендацией. Указанные в статье условия SLA, лимиты компенсаций и сроки подачи претензий действительны на октябрь 2026 года. Данные могут изменяться, актуальную информацию следует уточнять в официальных источниках компании Яндекс и у конкретных провайдеров.}

^{Источники*:}

^{1. Гражданский кодекс Российской Федерации (часть первая) от 30.11.1994 № 51-ФЗ (в том числе ст. 15, 393, 401) // КонсультантПлюс. – URL: https://www.consultant.ru/document/cons_doc_LAW_5142/} 

^{2. Арбитражный процессуальный кодекс Российской Федерации от 24.07.2002 № 95-ФЗ (в том числе ст. 4) // КонсультантПлюс. – URL: https://www.consultant.ru/document/cons_doc_LAW_37800} 

^{3. Постановление Пленума Верховного Суда РФ от 24.03.2016 № 7 «О применении судами некоторых положений Гражданского кодекса Российской Федерации об ответственности за нарушение обязательств» // КонсультантПлюс. – URL: https://www.consultant.ru/document/cons_doc_LAW_195783/} 

^{4. Федеральный закон от 27.07.2006 № 152-ФЗ «О персональных данных» // КонсультантПлюс. – URL: https://www.consultant.ru/document/cons_doc_LAW_61801/} 

^{5. Yandex Cloud SLA. Условия уровня обслуживания // Yandex Cloud. – URL: https://yandex.cloud/ru/docs/overview/sla} 

^{6. Yandex Cloud. Глоссарий SLA // Yandex Cloud. – URL: https://yandex.cloud/ru/docs/glossary/sla} 

^{7. Yandex Cloud Status. Статус инцидента №2136 // Yandex Cloud. – URL: https://status.yandex.cloud/ru/incidents/2136} 

^{8. Яндекс включил атаки БПЛА в перечень форс-мажорных обстоятельств // «РБК». – URL: https://www.rbc.ru/business/10/10/2026/6aca95716ff6d5fdafc490b8} 

^{9. Рунет в огне, оборудования нет. Эксперты оценили возможные последствия атак на дата-центры «Яндекса» // «Фонтанка». – URL: https://www.fontanka.ru/2026/10/11/76693413/} 

^{10. Суперкомпьютер на вес золота. Что это за машины и почему они нужны России // «Фонтанка». – URL: https://www.fontanka.ru/2026/10/12/76696055/} 

^{*Ссылки ведут на действующие на октябрь 2026 года редакции документов и официальные страницы ведомств.}