Утром 9 октября 2026 года беспилотники повредили крупнейший по проектной мощности дата-центр «Яндекса» в Калуге. Несколько модулей полностью вышли из строя, компания предупредила о возможных перебоях в работе сервисов. Удар пришёлся не по рядовой серверной, а по вычислительному комплексу, рассчитанному на 63 МВт электрической мощности и более 3800 серверных стоек. Всего за сутки до калужского инцидента из-за другой атаки полностью остановился дата-центр компании в Сасово.
Я решил разобраться, что представляет собой калужский ЦОД, насколько велик его реальный масштаб, как устроены питание и охлаждение, какие задачи выполняет площадка и почему даже резервирование не гарантирует непрерывной работы облака. Заодно отделю проектные характеристики от подтверждённых эксплуатационных показателей. Между красивыми цифрами при строительстве и фактической работой дата-центра есть существенная разница.
Как устроен дата-центр «Яндекса» в Калуге
Строительство комплекса началось в 2022 году на территории индустриального парка «Грабцево». Проект сразу создавался как одна из крупнейших вычислительных площадок страны. Калужский объект должен был обслуживать собственные сервисы «Яндекса» и предоставлять вычислительные ресурсы клиентам Yandex Cloud.
В первоначальной спецификации проекта компания назвала следующие характеристики.
- 63 МВт общей проектной электрической мощности.
- Более 3800 стоек для серверов и сетевого оборудования.
- 15 кВт расчётной нагрузки на одну стойку.
- Около 58 МВт предполагаемого энергопотребления IT-оборудования.
- 130 000 м² площади земельного участка.
- PUE 1,07–1,09 в качестве первоначального целевого показателя энергоэффективности.
Самое интересное начинается при анализе цифр. Умножив 3800 стоек на 15 кВт, получаем приблизительно 57 МВт серверной нагрузки. Остальная энергия требуется вентиляции, оборудованию электроснабжения, освещению и другим инженерным системам. Но 63 МВт не означает, что дата-центр постоянно потребляет именно такую мощность или что все проектные стойки уже установлены.
Распространённая ошибка касается и площади. Многие публикации называют 130 тысяч квадратных метров площадью самого здания. В действительности градостроительная документация относит указанную величину к земельному участку. Проект предусматривает четыре основных серверных корпуса, административные и технические здания. Планируемая доля застройки участка составляет 30%, то есть площадь застройки значительно меньше площади территории.
Комплекс возводили поэтапно. Первая очередь получила разрешение на ввод в конце декабря 2023 года. В дальнейшем строительство и оснащение продолжились. Публичных подтверждений, что к октябрю 2026 года все 3800 стоек были заполнены и постоянно работали, я не нашёл.
Поэтому оценивать повреждения после атаки как долю от полной проектной мощности преждевременно. Неизвестно даже, сколько серверов находилось в пострадавших модулях.
Электроснабжение, охлаждение и реальная энергоэффективность
Крупный ЦОД потребляет электричество в масштабах промышленного предприятия. Обычного городского подключения для десятков мегаватт недостаточно, поэтому калужский комплекс получил отдельную высоковольтную инфраструктуру.
В октябре 2024 года Системный оператор ЕЭС сообщил о вводе подстанции напряжением 110 кВ для калужского объекта. На площадке установили два силовых трансформатора по 63 МВА. При технологическом присоединении указывалась максимальная потребляемая мощность 49 МВт.
Здесь важно не путать три величины. Проектные 63 МВт описывают заявленный масштаб комплекса, 49 МВт относятся к оформленному на тот момент технологическому присоединению, а 63 МВА характеризуют полную электрическую мощность каждого трансформатора. Переводить МВА непосредственно в МВт без учёта коэффициента мощности нельзя.
Вторая инженерная особенность заключается в системе охлаждения. Серверное оборудование преобразует почти всю потребляемую электроэнергию в тепло. При нагрузке в десятки мегаватт отвод тепла становится одной из главных задач.
«Яндекс» использует фрикулинг, то есть охлаждение наружным воздухом. Воздух проходит фильтрацию, поступает в помещения с серверными стойками, забирает тепло и выводится наружу. Специально разработанные серверы рассчитаны на эксплуатацию при повышенной температуре, что уменьшает потребность в традиционных холодильных машинах.
Эффективность принято измерять коэффициентом PUE. Формула достаточно простая.
PUE = общее энергопотребление ЦОД / энергопотребление IT-оборудования
При PUE 1,10 на каждые 100 кВт, которые получают серверы, приходится ещё 10 кВт для вспомогательной инфраструктуры. Чем ближе показатель к единице, тем меньше энергии расходуется вне вычислительного оборудования.
Именно здесь обнаруживается разница между рекламным проектом и практикой. При строительстве «Яндекс» прогнозировал PUE 1,07–1,09. Однако в отчёте компании об устойчивом развитии за 2024 год для Калуги указан фактический среднегодовой PUE 1,17.
Результат по-прежнему хороший для крупного дата-центра, но заметно отличается от первоначального обещания. На каждые 100 кВт серверной нагрузки приходилось в среднем около 17 кВт дополнительных расходов энергии, а не 7–9 кВт. Фактический показатель за 2025 год отдельно для калужского комплекса в изученных материалах установить не удалось.
Есть и другая тонкость. Низкий PUE говорит об энергетической эффективности, а не о защищённости здания, сохранности данных или способности пережить физическое разрушение. Смешивать энергоэффективность с отказоустойчивостью нельзя.
Что произошло после атаки и почему резервирование не спасает от всех аварий
В ночь с 7 на 8 октября был серьёзно повреждён дата-центр «Яндекса» в Сасово Рязанской области. На площадке возник пожар, работа объекта полностью остановилась. Утром 9 октября беспилотники атаковали калужский комплекс.
Компания подтвердила выход из строя части оборудования Калуги, включая несколько модулей. В официальном заявлении «Яндекс» сообщил, что сотрудники на обоих объектах не пострадали. Сроки восстановления оборудования пока определить невозможно.
При этом остаются неизвестными количество повреждённых серверов, объём потерянной вычислительной мощности, состояние систем хранения и распределение пострадавших ресурсов между конкретными сервисами.
Слово «модуль» тоже нельзя автоматически приравнивать к серверному корпусу. В архитектуре ЦОД модулем может называться отдельный инженерный или вычислительный блок со своим оборудованием. Без опубликованной схемы невозможно понять, какая часть объекта потеряна.
Почему авария вообще влияет на пользователей, если крупный облачный оператор строит несколько независимых площадок?
В Yandex Cloud используется архитектура зон доступности. Вычислительные ресурсы распределяются между дата-центрами, которые должны быть изолированы от локальных технических отказов. Клиент может размещать несколько копий приложения в разных зонах и направлять запросы на оставшиеся работающие узлы при аварии.
Но такая защита зависит от конкретной архитектуры приложения. Одна виртуальная машина в одной зоне не становится отказоустойчивой только потому, что провайдер владеет несколькими дата-центрами.
Даже две работающие копии приложения не гарантируют доступность, если обе зависят от одной базы данных, общей системы управления или единственной точки сетевого входа. Дополнительная проблема возникает при последовательном повреждении нескольких площадок, когда свободных ресурсов может не хватить для быстрого переноса всей нагрузки.
Существуют и последствия, которые резервирование серверов не устраняет. После повреждения оборудования необходимо оценить состояние электрической инфраструктуры, восстановить сети, заменить серверы и проверить целостность данных. Простая установка нового компьютера вместо сгоревшего не означает немедленного возвращения сервиса.
Технический разбор опирается на общедоступные сведения и касается надёжности информационных систем. Конфигурации физической защиты, потенциальные точки проникновения и другие сведения, способные облегчить повторные атаки на инфраструктуру, здесь не рассматриваются.
Как проверить собственные ресурсы и подготовиться к отказу ЦОД
Для клиентов Yandex Cloud главный вопрос заключается не в количестве повреждённых зданий, а в том, где размещены виртуальные машины, базы данных и резервные копии. Проверить необходимо также зависимости между сервисами.
Начать можно с состояния облака. Страница показывает опубликованные оператором сообщения о неисправностях и состоянии сервисов. Однако общий статус облака не заменяет проверку работоспособности собственного приложения.
Если установлен и настроен интерфейс командной строки Yandex Cloud CLI, список виртуальных машин в выбранном каталоге можно получить командой.
yc compute instance list
В результате отображаются идентификаторы машин, состояния и зоны размещения в колонке ZONE ID. Для дисков предусмотрена отдельная команда.
yc compute disk list
Я бы проверил не только распределение серверов, но и способность восстановить приложение после полной потери площадки. Для такой проверки нужны четыре вещи.
- Независимые зоны. Критически важные компоненты должны иметь работающие копии за пределами одной площадки.
- Резервные копии. Хранить их следует отдельно от основных систем, желательно с независимыми учётными данными и в другом контуре инфраструктуры.
- Проверенный сценарий восстановления. Нужно знать, за сколько времени удастся развернуть приложение на другой площадке и какой объём последних изменений допустимо потерять.
- Контроль внешних зависимостей. DNS, система авторизации, балансировщик и средства управления не должны превращаться в единственные точки отказа.
В профессиональной практике два последних требования описываются показателями RTO и RPO. Первый задаёт допустимое время восстановления сервиса, второй определяет максимально допустимую потерю данных во времени. Например, резервное копирование раз в сутки не обеспечивает RPO в пять минут.
Проверить готовность можно только реальным тестом. Создайте резервную среду, восстановите туда данные, запустите приложение и убедитесь, что пользователи могут выполнить основные операции. Работоспособность резервных копий нельзя считать доказанной, пока из них ничего не восстанавливали.
Для особенно критичных проектов разумно рассмотреть второго облачного провайдера. Но переносимость приложений между облаками нужно подготовить заранее. Несовместимые управляемые базы данных, уникальные API и зависимость от конкретного хранилища способны превратить аварийную миграцию в отдельный технический проект.
Частые вопросы
Можно ли определить, находятся ли мои файлы Яндекс Диска в Калуге?
Обычный пользователь не видит физическое расположение конкретных данных. Нельзя определить место хранения файла по адресу сервиса, скорости соединения или географическому положению пользователя. Публичной информации для точного сопоставления отдельных файлов с калужским ЦОД нет.
Сколько серверов пострадало при атаке?
Подтверждён выход из строя нескольких модулей, но количество находившихся в них серверов не раскрыто. Оценить число повреждённых машин по общей проектной вместимости комплекса невозможно.
Используется ли калужский дата-центр для обучения нейросетей?
Калужская инфраструктура рассчитана на разные вычислительные задачи, включая облачные сервисы. Однако подтверждённого перечня ускорителей, размещённых именно на повреждённых модулях, нет. Нельзя автоматически переносить сведения о суперкомпьютерах других ЦОД «Яндекса» на Калугу.
Почему RAID не гарантирует сохранность данных после разрушения здания?
RAID помогает пережить отказ отдельных накопителей, но не обеспечивает защиту от потери всего серверного помещения. Для подобных сценариев нужны географически независимые копии данных и проверенная процедура восстановления.
Имеет ли дата-центр «Яндекса» в Калуге сертификат Tier IV?
Достоверного публичного подтверждения действующей сертификации калужского объекта по Tier IV в изученных материалах нет. Высокий показатель доступности или низкий PUE сами по себе не доказывают соответствие определённому уровню Tier.
Можно ли восстановить дата-центр, если повреждены серверные корпуса?
Технически восстановление возможно, но сроки зависят от состояния конструкций, энергетического оборудования, сетей и серверов. Если часть инфраструктуры разрушена физически, восстановление может потребовать полной замены оборудования и повторной проверки инженерных систем.
Может ли атака на калужский ЦОД отключить домашний интернет?
Повреждение дата-центра не означает автоматического отключения доступа в интернет. Однако могут перестать открываться отдельные сайты, приложения и сервисы, использующие повреждённую инфраструктуру. Снаружи такой сбой иногда выглядит как проблема с интернет-соединением.
Вывод
Калужский дата-центр «Яндекса» представляет собой действительно крупный инженерный комплекс с промышленным электроснабжением, собственными системами охлаждения и проектной мощностью 63 МВт. При этом красивые характеристики первоначального проекта нельзя принимать за подтверждённый масштаб работающего оборудования. Фактическая загрузка, количество действующих стоек и объём повреждений остаются неизвестными.
На мой взгляд, главное в истории с Калугой не само разрушение нескольких серверных модулей. Атаки 8 и 9 октября продемонстрировали предел традиционного представления о надёжности облаков. Избыточное питание, эффективное охлаждение и резервные зоны защищают от многих технических неисправностей, но не устраняют риск одновременной потери нескольких физических площадок.
Для бизнеса вывод вполне практический. Необходимо проверять не обещания о доступности инфраструктуры, а способность собственного сервиса пережить полную потерю дата-центра. Начать следует с инвентаризации размещённых ресурсов и пробного восстановления из независимой резервной копии. Только успешный тест покажет, сколько действительно стоит отказоустойчивость, за которую компания платит облачному провайдеру.
