Яндекс после атак на дата-центры договорился с Selectel, К2Cloud и VK Cloud

Яндекс договорился с тремя российскими облачными провайдерами, Selectel, К2Cloud и VK Cloud, об ускоренном размещении данных и сервисов своих клиентов. Поводом стали атаки на собственные дата-центры компании. Об этом 9 октября 2026 года сообщил vc.ru. Конкуренты по облачному рынку в этой схеме выступают как резервная площадка, и это один из самых прямых сигналов о том, насколько серьёзной оказалась ситуация.

Что известно на данный момент

Исходное сообщение короткое. Названы три провайдера и общая цель: быстро принять у себя данные и сервисы клиентов Яндекса. Всё остальное в опубликованном материале отсутствует.

• Кто участвует: Яндекс как источник клиентов, Selectel, К2Cloud и VK Cloud как принимающие площадки.
• Что переносится: данные и сервисы клиентов, без детализации по продуктам.
• Причина: атаки на дата-центры Яндекса. Тип атаки (кибератака, физическое воздействие или что-то иное) не уточняется.
• Не раскрыто: число затронутых клиентов, объём переносимых данных, сроки, коммерческие условия и перечень сервисов.

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

Почему конкуренты помогают друг другу

Selectel, К2Cloud и VK Cloud конкурируют с Яндексом за корпоративных заказчиков. Тем не менее они согласились принять чужую нагрузку, и у этого есть понятная логика. Клиентов, которые остаются без сервиса, проще удержать внутри национальной облачной экосистемы, чем отдать зарубежным решениям или собственным серверным. Для российских компаний, работающих с персональными данными граждан, выбор в принципе ограничен требованиями о локализации хранения. Три названных провайдера этим требованиям отвечают.

Техническая сторона переезда менее очевидна. У облаков разные API, разные сервисы управляемых баз данных, свои схемы балансировки и хранения. Простые виртуальные машины и объектное хранилище переносятся быстро. Managed-сервисы, очереди, серверless-функции и привязанные к конкретному провайдеру механизмы идентификации требуют переработки. Поэтому слово «ускоренное» в заявлении стоит читать как обещание приоритета и выделенных ресурсов, а не как гарантию мгновенной миграции.

Отдельный вопрос касается ИИ-нагрузок. Обучение и инференс моделей зависят от GPU-кластеров и быстрых сетей между узлами, а такие мощности в России дефицитны. Войдут ли GPU-инстансы и ML-платформы в договорённости, источник не сообщает.

Что делать клиентам облаков

История показывает практический урок, который не зависит от того, чем закончится конкретный эпизод. Один провайдер, даже крупный, остаётся единой точкой отказа.

• Проверьте, где лежат резервные копии. Если они в том же облаке и той же зоне, что и продакшн, это не резервирование.
• Опишите инфраструктуру как код (Terraform, Ansible, Helm). Это сокращает перенос с недель до дней.
• Избегайте избыточной привязки к проприетарным managed-сервисам там, где есть открытые аналоги: PostgreSQL, Kafka, S3-совместимое хранилище.
• Заранее понизьте TTL в DNS для критичных записей и проверьте, кто в компании может сменить маршрутизацию.
• Перечитайте договор: какие обязательства по доступности и восстановлению указаны, кто отвечает за потери, как оформляется выгрузка данных.
• Если у вас клиенты Яндекса в цепочке поставок, запросите у них актуальный план восстановления.

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