Беспилотники вывели из строя третий ЦОД «Яндекса» — во Владимире

Беспилотники нанесли удар по третьему дата-центру «Яндекса» — на этот раз во Владимире. По данным CNews, площадка полностью выведена из строя. Всего у компании пять ЦОДов, то есть физически пострадали уже три из пяти, больше половины инфраструктуры. Накануне в пользовательское соглашение сервисов «Яндекса» добавили пункт, по которому компания не отвечает перед клиентами за неработающие сервисы при атаках БПЛА.

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

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

• Площадка: дата-центр «Яндекса» во Владимире.
• Статус: полностью выведен из строя.
• Всего ЦОДов у компании: 5.
• Уже пострадали от налётов: 3.
• Изменение в оферте: добавлен пункт об освобождении от ответственности за простои сервисов при атаках БПЛА.

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

Пункт в соглашении как сигнал

Поправка в пользовательское соглашение интереснее самого удара. Оговорки о форс-мажоре есть почти у любого облачного и интернет-сервиса: стихия, перебои с электричеством, действия третьих лиц. Но прямое упоминание БПЛА показывает, что компания считает такие события не разовым риском, а повторяющимся фактором. Юристы пишут такие пункты, когда вероятность события перестаёт быть теоретической.

Для обычного пользователя «Яндекса» это почти ничего не меняет: почта, карты и поиск и так не предполагают денежной компенсации за простой. Для бизнеса картина другая. Если компания строит продукт на «Яндекс Облаке» или других платформенных сервисах и рассчитывает на SLA со штрафами, ссылка на атаки БПЛА может сделать эти штрафы недостижимыми. Подробности зависят от конкретного договора: пользовательское соглашение и корпоративные условия не всегда совпадают, и это нужно проверять.

Почему ЦОД так уязвим

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

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

Что делать командам, которые зависят от «Яндекса»

Сначала стоит прочитать актуальную редакцию соглашения и корпоративного договора: что именно там сказано про форс-мажор и компенсации. Затем сверить архитектуру. Критичные данные и резервные копии должны лежать минимум в двух независимых географиях, а лучше ещё и у другого провайдера. Скрипты переключения нужно регулярно проверять на практике, а не держать в виде документа. Бизнесу, у которого простой стоит денег, полезно заранее посчитать допустимое время восстановления (RTO) и объём допустимой потери данных (RPO) и честно сравнить их с тем, что реально способен обеспечить провайдер. Если разрыв большой, мультиоблачная схема обойдётся дешевле, чем одна неудачная неделя без сервиса.