Три ЦОДа за четыре дня: что случилось с дата‑центрами Яндекса и как защитить свой проект

С 8 по 11 октября 2026 года беспилотники повредили три дата‑центра Яндекса: в Сасово, Калуге и Владимире. Две площадки остановились полностью, на третьей вышли из строя несколько модулей. Вместе с ними на часы и дни пропадали Алиса, Яндекс Go, Пэй, Почта и Телемост, а в Yandex Cloud сбоили десятки сервисов. Ещё через три дня атаковали строящийся дата-центр Сбербанка в Балакове.

Для бизнеса эта неделя стала самым наглядным уроком о единой точке отказа за последние годы. Ниже мы собрали хронику по дням и разобрали, что произошло с Яндексом и его клиентами. А дальше идёт практическая часть: как разнести проект по нескольким площадкам, не потерять в скорости и во что это обойдётся.

До октября российские дата‑центры не становились целью беспилотников. По данным The Moscow Times, удар по Сасово стал первой подтверждённой атакой на российскую инфраструктуру хранения данных с 2022 года. Официально Украина ответственность не заявляла, но 8 октября Владимир Зеленский сказал о российских ударах: «они били и бьют по нашим дата-центрам. Мы им ответили».

В 01:31 по Москве Yandex Cloud сообщил о перебоях с питанием в зоне доступности ru‑central1-b. После атаки беспилотника на площадке начался пожар, и дата‑центр остановили полностью. Он работал с 2014 года в корпусах бывшего завода и был рассчитан на десятки тысяч серверов. Здесь же стояли суперкомпьютеры «Червоненкис» и «Ляпунов», на которых Яндекс обучает нейросети. Пострадавших, по словам компании, нет.

Примерно через семь часов облако переключило нагрузку на другие зоны. Клиентам, у которых ресурсы были только в ru‑central1-b, пришлось переносить их вручную. Утром с перебоями работали Поиск, Почта, Карты, Яндекс Go, Пэй, Документы и Таблицы. Перестали открываться и некоторые сайты властей Калужской области. Акции Яндекса за день подешевели примерно на 3,4%.

Второй удар пришёлся на самый мощный дата‑центр компании: 63 МВт и больше 3800 стоек. В 2022 году Яндекс объявлял, что здесь разместится зона доступности облака ru‑central1-d. По словам компании, на этот раз «несколько модулей полностью выведены из строя».

В тот же день Yandex Cloud договорился с Selectel, VK Cloud и K2Cloud об ускоренном переезде пострадавших клиентов. Партнёры выделили отдельные команды и упростили подключение. А 10 октября Яндекс внёс удары беспилотников и ракет в список форс-мажорных обстоятельств пользовательского соглашения и перевёл выдачу квот в облаке на ручной режим.

В 04:12 пропало питание в зоне ru‑central1-a. Владимирский дата‑центр примерно на 2880 стоек и 50 МВт, где работал суперкомпьютер «Галушкин», остановили полностью. Облако перешло в аварийный режим, а в сообщении для клиентов появилась фраза, которую инженеры боятся больше всего: «Оставшуюся конфигурацию ресурсов считаем неустойчивой».

Утром не работали Яндекс Go, Музыка, Пэй, Алиса и «Дом с Алисой», водители и курьеры не могли открыть Яндекс Про. По данным DownDetector, которые приводит «Коммерсантъ», сбоили и сервисы других компаний: «Магнит», «Вкусно — и точка», М.Видео, Lamoda, Dom.ru, Додо Пицца и сайт аэропорта Пулково. Часть этих сбоев, скорее всего, пришла не с хостинга, а через интеграции: карты, вход через Яндекс ID, платежи и аналитику. Губернатор Владимирской области сообщил, что из-за атаки отключились две подстанции и около 5 тысяч жителей остались без света.

Через три дня беспилотники атаковали дата‑центр Сбербанка в Балакове, самый новый из трёх собственных ЦОДов банка. Объект ещё строился: его оценивали примерно в 30 млрд рублей и планировали достроить в 2027 году. Сбер подтвердил атаку и сообщил, что «все системы и все сервисы Сбербанка работают штатно». По предварительным данным губернатора, пострадали жилые дома, один человек погиб.

Для клиентов банка эта атака прошла незаметно, потому что площадка ещё не работала. Но рынок сделал главный вывод: дата‑центр перестал быть местом, куда беда не доходит.

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

Министр цифрового развития Максут Шадаев отметил, что компании удалось оперативно перевести ключевые системы «на заранее подготовленные резервные площадки». Это, пожалуй, главный вывод недели: у самого Яндекса резерв был. Вопрос в том, был ли он у его клиентов.

Yandex Cloud входит в число крупнейших облаков страны. В первом полугодии у него было около 64 тысяч клиентов, им пользуется больше трети компаний из рейтинга РБК 500. 11 октября предупреждения о сбоях висели у 62 сервисов платформы, включая виртуальные машины, сети и объектное хранилище. Часть управляемых баз данных перешла в режим только для чтения, в хранилище не всегда записывались файлы, а дополнительные квоты выдавать перестали. Поднять замену внутри того же облака стало почти невозможно.

Самое неприятное, что не спасла и привычная схема «мы размещены в трёх зонах доступности, значит, в безопасности». Зоны b и a остановились полностью, зона d потеряла часть модулей, то есть за четыре дня пострадали все три основные площадки одного региона. Отказоустойчивость внутри одного провайдера защищает от пожара в одном зале, но не от события, которое бьёт по всему региону сразу.

Вот как неделя выглядела изнутри. Истории компаний собрал «Предприниматель»:

Последний пример лучше всего объясняет эту статью. Задело всех, но быстрее всех поднялся тот, у кого данные и копии жили отдельно от основной площадки.

Для многих компаний Яндекс — это не облако, а рабочая почта на своём домене, Диск, Документы и Телемост. В дни атак письма не отправлялись и не приходили, почтовые программы выдавали ошибки, а к встречам в Телемосте не получалось подключиться. По данным RB.RU, только 12 октября DownDetector собрал за сутки 3100 жалоб на Почту и 2300 на Телемост.

С 11 октября компания сознательно ограничила часть функций Яндекс 360, чтобы снизить нагрузку. На Диске перестали работать автозагрузка фото и скачивание папок одним архивом. Даже 16 октября пользователи жаловались на старые файлы, синхронизацию и общий доступ.

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

Атака беспилотников — редкий сценарий. Но пожар, затопление, отключение электричества, ошибка провайдера или блокировка аккаунта приводят ровно к тому же: площадка перестаёт отвечать. Хорошая новость в том, что от всех этих сценариев защищают одни и те же инструменты. Начать стоит с двух вопросов, ответы на которые и определят бюджет:

Три копии данных на двух разных типах носителей, и одна из них в другой локации. Сегодня к правилу добавляют ещё одно условие: хотя бы одна копия должна быть неизменяемой, то есть её нельзя удалить или зашифровать даже с правами администратора. И главное: копия существует только тогда, когда из неё регулярно и успешно восстанавливаются.

Для баз данных к ежедневным снимкам стоит добавить непрерывный архив журналов транзакций, например WAL у PostgreSQL. Тогда базу можно вернуть на любую минуту, а не только на ночь, когда делался снимок.

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

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

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

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

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

Корпоративную почту стоит архивировать у второго поставщика и держать запасной маршрут через резервный MX. Документы нужно регулярно выгружать в независимое хранилище, а о запасном сервисе для созвонов договориться заранее. Ещё стоит проверить внешние зависимости: если на сайте работают карты, вход через Яндекс ID, оплата через Пэй и Метрика, сайт должен открываться и без них, пусть и в упрощённом виде.

Частый страх: резервирование замедлит проект. На практике хорошо устроенный распределённый сайт работает быстрее, чем сайт на одном сервере. Вот приёмы, которые дают скорость:

Режим «актив‑актив», в котором писать можно на обе площадки одновременно, стоит включать только там, где он действительно нужен. Конфликты одновременных записей и их разрешение заметно усложняют разработку.

Ниже ориентиры для типичного веб‑сервиса или интернет‑магазина. Точные цифры зависят от объёма данных и нагрузки, но порядок величин такой.

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

Мы в Irbis берём проекты на круглосуточную поддержку, и всё, о чём говорилось выше, для нас обычный рабочий порядок, а не реакция на новости.

Поэтому доступность проектов на нашей поддержке составляет 99,9%. Если ваш проект живёт в одной зоне одного облака, начнём с технического аудита: за 2,5–⁠3 недели проверим инфраструктуру и резервные копии и составим план работ по приоритетам.

Посмотреть, что входит в поддержку и аудит или написать нам и обсудить ваш проект.