Атака на дата-центр «Яндекса» в Сасово Рязанской области 8 октября привела к пожару, временной остановке части инфраструктуры и сбоям у облачных клиентов. Для российского IT это не только история об одном повреждённом объекте: инцидент показал, насколько физическая устойчивость ЦОДов теперь влияет на виртуальные машины, хранилища, ML-сервисы и бизнесы, которые могут даже не знать, где именно работают их серверы.
Ночью над Рязанской областью сбили два беспилотника, сообщил губернатор Павел Малков. В Сасовском округе загорелась кровля одного из предприятий, в частном секторе выбило стёкла; о пострадавших не сообщалось. Позже «Яндекс» подтвердил пожар в своём дата-центре в Сасово, связав его с атакой беспилотников. Работу площадки временно приостановили, а инцидент затронул часть инфраструктуры компании, сообщает vc.ru.
Наиболее заметный технический эффект пришёлся на зону доступности Yandex Cloud ru-central1-b. Компания сообщила о перебоях с электропитанием и рекомендовала клиентам, у которых есть такая возможность, перенести нагрузку в другие зоны. Проблемы затронули Compute Cloud, Object Storage, SpeechKit и Smart Web Security. Неполадки увидели не только сервисы «Яндекса», но и внешние продукты: среди них назывались «Циан», Twinby и сервис электронной отчётности «Астрал». Именно в этом и заключается неприятная математика публичного облака: один физический инцидент быстро превращается в длинный список недоступных приложений.
Сасовская площадка важна и для самой компании. Там размещены суперкомпьютеры «Червоненкис» и «Ляпунов», используемые в том числе для обучения нейросетей. О том, пострадали ли они, на момент публикации не сообщалось. Сроки полного восстановления и масштаб повреждений «Яндекс» также не раскрыл. Рынок отреагировал быстро: к 13:14 мск акции компании снизились на 2,81%. Для биржи это, скорее, оценка неопределённости, чем подсчёт ущерба: пока нет данных о состоянии оборудования, энергоснабжения и возможности вернуть сервисы в штатный режим.
Это не первый сбой в той же зоне доступности. В марте 2025 года из-за аварии на подстанции в ru-central1-b были недоступны «Яндекс Музыка», «Яндекс Лавка» и другие сервисы. Тогда критические элементы продолжили работу благодаря дизель-генераторам, а нагрузку распределили между другими дата-центрами. Нынешняя атака на дата-центр отличается причиной: резервные генераторы помогают пережить потерю внешнего питания, но не отменяют риски для здания, линий связи, систем охлаждения и доступа к площадке.
Эксперты, опрошенные деловыми СМИ, указывают на главное преимущество крупного провайдера: у «Яндекса» есть четыре собственных дата-центра, между которыми можно перераспределять сервисы и данные. Но резервирование не возникает автоматически из логотипа облачного провайдера. Алексей Бегаев, основатель InSeq, отметил, что перенос возможен, если клиент заранее выбрал соответствующую схему отказоустойчивости; отдельно должны быть сохранены конфигурации инфраструктуры. Максим Горшенин из ассоциации «26.20» также напомнил о штатных резервах питания ЦОДов. Алексей Горелкин, гендиректор Phishman, ожидает, что инцидент усилит движение к территориальному разнесению площадок и данных.
Для разработчиков вывод довольно приземлённый: проверять нужно не только SLA в договоре, но и архитектуру собственного сервиса. Одна зона доступности не равна отказоустойчивой системе, даже если внутри неё есть репликация и несколько виртуальных машин. Критичные компоненты стоит разворачивать минимум в двух зонах, а для сценариев, где простой измеряется потерянными деньгами или репутацией, — заранее продумывать восстановление в другом регионе или у второго провайдера. Бэкап без регулярно проверяемого восстановления остаётся просто набором файлов, а не планом на инцидент.
Бизнесу полезно составить карту зависимостей: какие внешние продукты работают на конкретном облаке, где находятся DNS, очереди, объектное хранилище, платёжные интеграции и каналы связи с клиентами. В день аварии часто выясняется, что формально независимый подрядчик использует ту же самую инфраструктуру, что и основной сервис. Уязвимость здесь не в облачной модели как таковой, а в ложном ощущении, что перенос вычислений в облако снимает с заказчика ответственность за архитектурные решения.
После этой атаки на дата-центр отрасли придётся обсуждать не только резервное питание и защиту периметра, но и географию распределения критической инфраструктуры. Чем больше российских компаний опираются на несколько крупных облаков, тем важнее становится вопрос: выдержит ли сервис потерю целой площадки, а не очередной сбой одного сервера. Ответ должен быть записан в схеме архитектуры и проверен учениями — до следующего пожара, а не после него.