«Яндекс» заблокировал часть функций 360 и Диска после атаки дрона на третий ЦОД

«Яндекс» ограничил часть ключевых функций платформы «Яндекс 360» и облачного хранилища «Диск». Поводом стала атака беспилотника на третий по счёту дата-центр компании. Об экстренном решении руководства сообщает РБК: цель мер — уберечь ИТ-инфраструктуру от критической перегрузки. Перечня отключённых опций и данных о физическом ущербе в доступных материалах нет, поэтому часть выводов ниже остаётся рабочими гипотезами.

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

Фактов немного, и они укладываются в короткий список:

• Затронутые продукты: «Яндекс 360» (рабочая платформа компании) и облачное хранилище «Диск».
• Характер мер: блокировка части ключевых опций, а не полное отключение сервисов.
• Мотив: предотвратить критическую перегрузку инфраструктуры.
• Источник: РБК, пересказ в «Хайтеке» от 12 октября 2026 года.
• Номер инцидента: в заголовке речь о третьем дата-центре, значит, это не единичный эпизод.

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

Почему перегрузка опасна не меньше самого удара

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

Поэтому инженеры используют load shedding: сознательно отключают наименее критичные и самые затратные функции, чтобы сохранить базовую работоспособность. Обычно под нож идут тяжёлые фоновые операции, вроде массовой синхронизации, генерации превью, индексации или загрузки больших объёмов. Это общая практика отрасли. Какие именно опции отключил «Яндекс», компания в цитируемых материалах не уточняет.

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

Чего пока не хватает для полной картины

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

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

Что делать пользователям и компаниям

Пока «Яндекс» не опубликовал детали, разумно действовать по базовой гигиене:

• Сделайте локальную или внешнюю копию критичных файлов из «Диска», если синхронизация ещё работает. Не запускайте массовую выгрузку всего подряд: так вы добавите нагрузку на систему.
• Проверьте, какие бизнес-процессы завязаны на «Яндекс 360»: календарь, почта, совместные документы. Подготовьте обходные каналы связи для команды.
• Изучите условия SLA и порядок компенсаций, если сервисы используются в корпоративном контракте.
• Следите за официальными сообщениями компании: именно они определят, когда и в каком порядке функции вернутся.

Для ИТ-руководителей урок прикладной: единая облачная зависимость без плана деградации превращается в единую точку отказа, даже если у провайдера несколько дата-центров.