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

Как сообщается на странице статуса Yandex Cloud, на данный момент команда продолжает работу по восстановлению и стабилизации ключевых сервисов. «Работа каналов технической поддержки частично восстановлена, работаем над ускорением разбора обращений, но всё ещё могут быть значимые задержки в ответах. Также мы временно приостановили выдачу квот на дополнительные облачные ресурсы», — пишет компания. Зоны ru-central1-a и ru-central1-b по-прежнему недоступны. Часть сервисов доступно, часть — нет.

Сообщается, что сервисы Yandex AI Studio и безопасности частично доступны. Managed Databases: сервис доступен, сохраняются сложности в работе Managed Service for Apache Kafka; S3: доступен на чтение и запись, возможно замедление скорости операций; Managed Service for Kubernetes: доступен, могут сохраняться проблемы с отдельными кластерами; Yandex Monium недоступен; Yandex Container Registry работает.

Источник изображения: «Яндекс»

До этого атакам БПЛА подверглись дата-центр «Яндекса» в Сасово в Рязанской области и ЦОД в Калуге. В ЦОД Сасово находятся два крупных суперкомпьютер «Яндекса» —«Червоненкис» и «Ляпунов». Во владимирском дата-центра расположен суперкомпьютер «Галушкин».

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

Пострадавший от атаки беспилотника ЦОД «Яндекса» в Рязанской области ещё не вернули в эксплуатацию, но уже появились данные о новом нападении на объекты компании. На этот раз пострадала «часть инфраструктуры дата-центра», сообщают «Ведомости».

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

Утверждается, что пострадавших нет, нанесённый компании ущерб уточняется.

Источник изображения: Daniel Lerman/unsplash.com

В ночь на 8 октября атаке БПЛА уже подвергся дата-центр «Яндекса» в городе Сасово Рязанской области, после чего произошло возгорание. Работа ЦОД была полностью остановлена, прекратила функционировать зона доступности ru-central-b. Сообщалось о сбое некоторых сервисов самой компании и её облачных клиентов федерального уровня, но основные сервисы продолжили работать в штатном режиме.

По последним данным Telegram-канала Yandex Cloud Alerts, нарушенное электропитание в зоне доступности ru-central-b пока не восстановлено, а прочие зоны доступности работают в штатном режиме. В ближайшее время планируется восстановить «прежний уровень избыточности инфраструктуры для ключевых сервисов и обеспечить наличие дополнительных мощностей и резервных компонентов».

Техническая поддержка продолжает оказывать помощь клиентам, а с другими облачными операторами имеются договорённости об ускоренном размещении и резервировании ресурсов на площадках компаний Selectel, K2Cloud и VK Cloud.

Заявлено, что по кодовому слову CloudBro коллеги «Яндекса» готовы в приоритетном порядке обработать соответствующие заявки и оказать необходимую техническую помощь совместно со специалистами пострадавшей компании. Обновлённая информация появится в Yandex Cloud Alerts в 15:00 по московскому времени.

Дата-центр «Яндекса», расположенный в городе Сасово в Рязанской области, был атакован БПЛА. Работу объекта пришлось приостановить, при этом некоторые сервисы могут оказаться недоступными для пользователей, сообщает «Коммерсантъ». «Яндекс» пока не может подтвердить возможность восстановления оборудования дата-центра в Сасово, передают «Ведомости».

Первые данные появились в 1:44 МСК в телеграм-канале Yandex Cloud Alerts, сообщившем о сбоях в работе электропитания в зоне доступности ru-central-b. ЦОД запущен в 2014 году и занимает некоторые помещения завода «Саста», для подключения к сети «Яндекса» были проложены линии оптоволоконной связи между Сасово и Москвой.

Приблизительно в 8:00 МСК от пресс-службы «Яндекса» поступили данные об инциденте, затронувшем часть инфраструктуры. В компании подчеркнули, что ситуация на площадке находится под контролем, пострадавших нет, ведутся работы по устранению последствий нападения. Сообщалось, что основные сервисы продолжали работать в штатном режиме.

В 8:25 МСК появилась информация о сохранении недоступности ru-central-b. На канале Yandex Cloud Alerts объявлено о переключении нагрузок на другие зоны доступности, в остальных зонах работа продолжалась в обычном формате. При этом подчёркивалось, что создание новых ресурсов в облачной инфраструктуре может быть «лимитировано».

Источник изображения: seth schulte/unsplash.com

Позднее появилась информация о том, что ЦОД атакован беспилотником. Хотя пострадавших нет, пожар затронул инфраструктуру, устранением последствий занялись оперативные службы. На тот момент было объявлено, что работа дата-центра полностью остановлена, часть сервисов компании может оказаться недоступной. По словам губернатора Рязанской области, ночью над регионом сбиты два беспилотника, загорелась кровля «одного из предприятий».

Последнее сообщение от 15:19 МСК гласит: «Зона доступности ru-central1-b остаётся недоступной. Причиной инцидента стал пожар, произошедший в результате атаки БПЛА на дата-центр Яндекса в Сасово и затронувший часть инфраструктуры Yandex Cloud. Работа дата-центра полностью остановлена. В настоящее время создание новых ресурсов в облачной инфраструктуре может быть лимитировано. Наша команда продолжает работу над устранением последствий инцидента. При возникновении вопросов обращайтесь в техническую поддержку. Следующее обновление опубликуем в 19:00 мск».

Ранее стало известно, что в результате нескольких атак иранских БПЛА был полностью выведен из строя облачный регион AWS в Бахрейне — компания признала, что восстановить ресурсы и данные региона me-south-1 не представляется возможным. Также стоит отметить, что в ЦОД Сасово находятся два крупных суперкомпьютер «Яндекса» — «Червоненкис» и «Ляпунов». К 23:05 МСК, как сообщается, «доступность зоны ru-central1-b пока не восстановлена».

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

В опросе приняли участие 93 представителя крупных предприятий из нефтегазовой, энергетической, финансовой, промышленной, транспортной и других отраслей. Несмотря на то, что 74 % из них сталкиваются с аварийными сбоями не чаще одного-двух раз в год, построение катастрофоустойчивости является для них высоким приоритетом: 86,9 % организаций имеют хотя бы частично спланированные сценарии Disaster Recovery (DR); 91,3 % внедряют средства репликации, включая DR-решения на уровне виртуализации и аппаратную репликацию на уровне систем хранения данных.

Столь высокий уровень декларируемой подготовки объясняется строгими требованиями к непрерывности бизнес-процессов. Для 87,7 % опрошенных время восстановления после сбоя (RTO) является строго регламентированным параметром. При этом 41,5 % компаний ставят цель восстановиться в течение одного часа (максимальный уровень критичности), ещё 46,2 % допускают простой в несколько часов, и лишь 12,3 % респондентов могут позволить себе восстановление в течение суток.

Источник изображения: Kelly Sikkema / Unsplash

Однако за фасадом внедрённых технологий скрывается отсутствие системной проверки планов в реальных условиях. Только 34,4 % компаний проводят регулярные учения чаще двух раз в год. Около 37,6 % организаций вовсе не тестируют системы аварийного восстановления либо проверяли их единственный раз при внедрении.

Кроме того, наличие специализированных DR-инструментов не гарантирует автоматизированного спасения бизнеса. Для 68,1 % опрошенных основным методом аварийного восстановления остаётся традиционное резервное копирование и ручное возвращение виртуальных машин в строй. Это создаёт риски того, что в случае реальной масштабной аварии регламентированные показатели RTO не будут достигнуты из-за человеческого фактора и отсутствия натренированных процедур.

105 человек пришлось эвакуировать после того, как в сеульском дата-центре произошёл пожар. Возгорание случилось 29 сентября, в 11:55 по местному времени в районе Касан-дон (Gasan-dong) округа Кымчхон-гу (Geumcheon-gu), сообщает Datacenter Dynamics. К месту событий направили 80 пожарных и 14 пожарных машин, к 15:13 пожар был потушен.

Как сообщили представители пожарного управления Кымчхон-гу, в результате возгорания пострадавших нет. По предварительным данным, пожар начался с трансформаторов в зале с ИБП. Конкретный ЦОД не назван, но на видео с места происшествия виден объект Seoul 1, управляемый сингапурской STT GDC. Объект мощностью 30 МВт и площадью 40 тыс. м² был введён в эксплуатацию в июле.

Источник изображения: Lai Man Nung/unsplash.com

Хотя пожары в ЦОД — явление довольно редкое, в сентябре 2025 года сервисы правительства Южной Кореи серьёзно пострадали от пожара в ЦОД Национальной службы информационных ресурсов (NIRS), расположенном в городе Тэджон (Daejeon). Предполагается, что тогда было уничтожено 850 Тбайт государственных резервных копий, хранившихся на жёстких дисках. От пожара пострадала работа сотен государственных сервисов, обошлось без жертв. В октябре сообщалось, что полиция арестовала нескольких человек по подозрению в халатности.

В конце января 2026 года пожар случился в аккумуляторной лондонского ЦОД Global Switch, в мае пострадали государственные и частные компании в Амстердаме, а также облачный регион IBM Cloud Amsterdam 03. В июне пожар из-за литиевых АКБ в индийском ЦОД той же STT GDC нанёс масштабный ущерб Google и другим компаниям.

Amazon Web Services (AWS) заявила, что не может восстановить доступ к ресурсам и данным в некоторых зонах доступности на Ближнем Востоке после того, как дата-центрам был нанесён урон в ходе противостояния США, Израиля и Ирана, сообщает The Register. Тем не менее, компания намерена частично восстановить обслуживание пострадавших клиентов.

Облачный гигант подтвердил, что доступ к данным, хранившимся исключительно в бахрейнском регионе (me-south-1), не может быть восстановлен. По информации компании, урон инфраструктуре коснулся сразу нескольких зон доступности, который оказался сильнее, чем готовы были выдержать мультизональные системы. После «всесторонней оценки» компания пришла к выводу, что не может восстановить доступ к ресурсам и данным региона.

После того, как зона доступности mes1-az2 в Бахрейне была атакована в марте, AWS советовала клиентам перенести свои рабочие задачи в другие регионы. По данным Amazon, большинство клиентов так и поступило, пока новые атаки не повредили вторую зону доступности в апреле и привели к отключению всего облачного региона. Мартовская атака также повлияла на зоны доступности mec1-az2 и mec1-az3 в регионе me-central-1 в ОАЭ, тогда как mec1-az1 пострадала лишь частично. Теперь AWS заявила, что не может восстановить доступ к ресурсам и данным и в mec1-az2. Примечательно, что Иран грозил нанести удар и по строящемуся ЦОД Stargate в ОАЭ.

Источник изображения: Stephen Radford/unsplash.com

AWS заявляет, что продолжает работать над восстановлением ресурсов mec1-az1 и mec1-az3. По данным компании, большинство клиентов смогли возобновить операции в регионах AWS, воспользовавшись бэкапами или скопировав оставшиеся доступными данные. Компания подчёркивает, что её группы поддержки по-прежнему доступны клиентам для помощи в переносе приложений и нагрузок. Что касается региона me-south-1, то компания пообещала предоставить новую информацию о его судьбе в начале 2027 года. Вероятно, AWS не захочет его восстанавливать, поскольку летом Иран объявил, что вновь ударил по ЦОД в Бахрейне.

В терминологии AWS регион представляет собой географическую зону, в которой находятся многочисленные изолированные зоны доступности (AZ), каждая из которых состоит из одного или более отдельных ЦОД с независимым энергоснабжением, охлаждением и сетевой инфраструктурой. AWS рекомендует распределять приложения и ресурсы по нескольким зонам, чтобы успешно пережить возможное отключение одной из них. Но такой подход не может защитить от масштабного сбоя в работе целого региона.

AWS и некоторые другие технологические компании порекомендовали клиентам после первых ударов по ЦОД восстановить те ресурсы, которые возможно, и продублировать их в других регионах, лучше всего — в Европе, а не ждать, пока вернётся обслуживание на Ближнем Востоке. По данным Amazon, капитальные расходы компании должны составить в 2026 году $220 млрд, в основном они придутся на строительство новой инфраструктуры, в т.ч. ЦОД в США и за их пределами.

Использовавшийся для майнинга биткоинов дата-центр Athlon Blockchain Technology Corporation (Athlon BT) в городе Эль-Рино (El Reno, шт. Оклахома) пришлось закрыть после аварии водопровода на его территории. Последняя привела к утечке более 1,38 тыс. м3 воды, вызвав перебои с водоснабжением у местных жителей и учреждений, сообщает Datacenter Dynamics.

Утечка связана с неисправностью пожарного гидранта, расположенного на объекте, управляемом Athlon BT, которая занимается эксплуатацией дата-центров, а также созданием мобильных ЦОД для ИИ и майнинга. В результате утечки произошло падение давления в городском водопроводе, из-за чего пришлось временно прекратить водоснабжение некоторых районов и на два дня закрыть школы. После утечки объект был признан непригодным для эксплуатации, выдано предписание об устранении нарушений. Athlon BT не разрешат возобновить деятельность, пока не будет решён ряд связанных проблем.

Источник изображения: Keren Fedida/unsplash.com

Власти Эль-Рино выдали разрешение на строительство ЦОД в 2021 году, но в июне 2023 года город распорядился остановить работы после того, как проверки выявили многочисленные нарушения, угрожавшие жизни людей — от опасных конструкций до истёкших разрешений на строительные и электромонтажные работы, а также проблемы с водоотводом и отсутствие «окончательного сертификата» на эксплуатацию дата-центра. Всё это, по-видимому, не помешало компании достроить и запустить ЦОД. Впрочем, городские власти признают, что сами не проконтролировали исполнение предписания о прекращении работ, в том числе из-за текучки кадров и плохой внутренней коммуникации. По статистике Исследовательской службы Конгресса США (CRS), за 10 лет ЦОД США утроили потребление воды — а теперь ситуация может быть ещё хуже.

Athlon BT будет выставлен счёт за потерянные кубометры, сверхурочную работу аварийных и иных служб, использование оборудования, а также за прочие расходы, связанных с утечкой. По словам властей, утечка не была вызвана сбоем в системе охлаждения объекта или обычными тратами воды — авария случилась на частном водопроводе на территории ЦОД. Траты не коснутся местных жителей. Не так давно в штате представили законопроект, призванный защитить рядовых потребителей электричества от инфраструктурных расходов, связанных с ЦОД и майнинговыми объектами, добавляющими энергосистеме нагрузку в объёме по 75 МВт и более.

Google Cloud раскрыла довольно курьёзную причину частичного сбоя в регионе us-central1-b, который произошёл 1 сентября с 07:41 до 11:52 по тихоокеанскому времени (PT). Часть облака физически отключил от Сети инженер, обслуживавший оборудование, сообщает The Register. Это привело к «серьёзному ухудшению работы сети и изоляции ресурсов».

По данным Google, в разгар инцидента объём проходящего трафика в пострадавшей области облака «сократился на 100 %», из-за чего ряд инстансов оказался попросту недоступен пользователям, а потери пакетов ожидаемо выросли. Компания пояснила, что при проектировании облачных ЦОД занимается резервированием маршрутизаторов, но против человеческой «смекалки» ей противопоставить нечего. Система рассчитана на двойные и даже тройные отказы и использует раздельное питание оборудования и несколько ВОЛС. Тем не менее, как оказалось, все эти меры защиты можно обойти, просто выдернув кабели из гнёзд.

Сообщается, что непосредственной технической причиной сбоя стало отключение оптоволоконных кабелей в ходе стандартных работ по обслуживанию оборудования. Компания сообщила, что инженер последовательно отключил 100 % оптоволоконных соединений всего за 13 мин. Характер ошибки и высокая скорость работы «инициативного» сотрудника не позволили вовремя предупредить его о неправильных действиях до полного отключения.

Источник изображения: Jimmy Nilsson Masth/unsplash.com

После отключения маршрутизаторов ВМ в одной из зон доступности региона us-central1-b физически потеряли связь с внешним миром. Хотя их возможность обмена данными друг с другом сохранилась, пользователи не могли получить к ним доступ хотя бы для того, чтобы понять, что происходит. После того, как в Google выявили проблему, трафик был перенаправлен с маршрутизаторов, отключенных инженером, на «работоспособные мощности в других частях региона». Затем инженеры вернули кабели назад и восстановили исходную конфигурацию сети. Предполагается, что виноватый в сбое инженер нарушил базовое требование, предполагающее чтение инструкций до того, как браться за работу.

Человеческий фактор неоднократно становился причиной сбоев в США и за их пределами. Так, летом 2025 года австралийские военные по ошибке «положили» Wi-Fi и радио на побережье Новой Зеландии. В декабре 2025 года появилась новость, что лень и безалаберность инженеров Nokia и Optus в Австралии привели к смерти людей, которые не смогли дозвониться до скорой. Как отмечает Uptime Institute, сбои в дата-центрах стали реже, но значительнее.

Комитет Палаты представителей США по делам ветеранов (US House Committee for Veterans’ Affairs) единодушно решил получить показания от исполнительного председателя совета директоров и технического директора Oracle Ларри Эллисона (Larry Ellison), а также генерального директора компании Майка Сциллиа (Mike Sicilia). Представители американских налогоплательщиков желают узнать подробности о перерасходе средств в крупном проекте, связанном с созданием электронной медицинской картотеки, сообщает Computer Weekly.

На днях в ходе слушаний, посвящённых надзору за программой модернизации электронных медицинских карт (Electronic Health Record Modernisation, EHRM) возникли вопросы о том, почему так выросла стоимость системы. В августе комитет увеличил максимальную стоимость контракта с Oracle, ответственной за модернизацию EHRM, с $10 млрд до $27 млрд без проведеня тендера. Представители Конгресса потребовали, чтобы руководство компании под присягой поделилось подробностями об увеличении стоимости контракта, эффективности работы компании, а также о том, получают ли ветераны и налогоплательщики то, что им обещали.

Контракт на создание системы власти США заключили во время первого президентского срока Дональда Трампа (Donald Trump). Он обеспечивает связь между «ветеранскими» медицинскими учреждениями и Министерством войны, Береговой охраной США, Национальным управлением океанических и атмосферных исследований (NOAA) и поставщиками медицинской помощи, участвующими в программе. Предполагается, что система позволяет врачам централизованно получать доступ ко всем данным из истории болезни ветеранов.

Источник изображения: Dan Meyers/unsplash.com

Оказалось, что сроки реализации программы со временем пришлось увеличить, равно как и её бюджет. Ранее Счётная палата США (Government Accountability Office, GAO) уже выразила обеспокоенность ходом модернизации электронной картотеки. По состоянию на августв 2026 года Министерство по делам ветеранов США (U.S. Department of Veterans Affairs) не выполнило 14 из 18 рекомендаций палаты, связанных с оценкой стоимости, графиком реализации, принципами управления программой, освоением системой пользователями и др.

В комитете подчеркнули, что из 170 клиник, в которых министерство должно было внедрить систему, реализация проекта завершена только в 17, то есть только в десятой части от общего объёма, а ушло на это восемь лет. Проверяющие охарактеризовали ситуацию, как «безлимитный бюджет для Oracle». Возникли вопросы, почему министерство не наняло IT-Директора (CIO) до марта 2025 года, а также — не вернётся ли Oracle в Конгресс через два года, чтобы попросить ещё больше денег для завершения проекта?

При этом по некоторым данным Oracle якобы заявляла, что сама возьмёт на себя дополнительные расходы, но Ларри Эллисону решили выделить ещё $17 млрд. Стоит отметить, что Oracle не впервые оказывается в центре внимания в связи со скандальным перерасходом средств при внедрении своих систем. Один из наиболее громких — с внедрением системы Oracle Fusion для муниципалитета Бирмингема. Сообщалось, что общие потери уже превысили £216 млн.

Неисправность ЛЭП в Ашберне (Ashburn, Вирджиния) привела к крупнейшему падению нагрузки в истории американской энергосистемы. После того, как сбой заставил гиперскейлеров в «Аллее дата-центров» ненадолго включить резервные генераторы, нагрузка в сети PJM за считанные секунды упала на более чем 3 ГВт, сообщает Datacenter Knowledge. Это редкая возможность увидеть, как крупные ИИ-кампусы реагируют на неполадки в магистральной энергосистеме. Фактически изменение нагрузки инициировано не энергокомпанией, а системами защиты самих ЦОД.

По данным PJM, более 3 ГВт — это около 3 % потребностей энергосистемы на тот момент. Резкое отключение столь большой нагрузки вызвало заметно изменение частоты тока в сети, но общая надёжность энергосистемы не пострадала. Компания Dominion Energy, работающая в сети PJM, объявила, что события начались с автоматического отключения ЛЭП в Ашберне, работоспособность которой была восстановлена в течение нескольких минут. Сколько и какие именно объекты в результате этого сбоя были переведены на резервное питание, не разглашается.

Примечательно, что пару недель назад, во время рекордной жары, PJM впервые предупредила операторов ЦОД о том, что их могут попросить перейти на локальную генерацию, если состояние энергосети ухудшится, но подобных запросов так и не поступило. При этом сейчас PJM находится под давлением властей, которые упрекают её в недостаточной скорости обеспечения питанием новых ИИ ЦОД и грозятся разделить компанию. Однако у компании мало возможностей для манёвра — в «Аллее дата-центров», согласно данным Data Center Map, работают 278 дата-центров, а проектируются и строятся — ещё 121 ЦОД.

Источник изображения: Nhan Hoang/unspalsh.com

PJM пока не опубликовала никаких выводов, а причина неисправности ЛЭП, которых и так не хватает, не раскрыта. Нет данных и о том, связано ли падение нагрузки с одним крупных клиентом или несколькими кампусами. Однако это уже не первый инцидент в сети PJM и Dominion. Два года назад из-за миллисекундного сбоя ЛЭП сразу 60 ЦОД общей мощностью 1,5 ГВт разом отключились от энергосети, перейдя на резервные генераторы. Хуже того, автоматическое переключение на основное питание не произошло, так что ЦОД несколько часов были отключены от сети.

PJM разрабатывает новые протоколы действия в чрезвычайных ситуациях с перепадами нагрузок гигаваттного масштаба. Десятилетиями коммунальные компании и операторы энергосетей планировали действия на случай неожиданной потери крупных генерирующих мощностей. Теперь они должны готовиться и к внезапной потере нагрузки из-за ИИ ЦОД и столь же скоротечному восстановлению энергопотребления. По мнению экспертов, кампусы гиперскейл-уровня становятся достаточно значимыми для общей энергосистемы, чтобы выдвигать к ним специальные требования по устойчивости при кратковременных сбоях и корректному возврату в энергосистему — внезапное подключение 3 ГВт к сети ничем не лучше внезапного отключения.

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

Впрочем, уже сейчас дата-центры в Вирджинии негативно влияют на качество энергоснабжения обычных потребителей — риск возгораний становится всё выше. Более того, недавно китайские специалисты по кибербезопасности сообщили, что злоумышленники могут использовать облачные ЦОД как оружие для атаки на энергосети, удалённо управляя поведением энергоёмких ИИ-нагрузок.