Атаки на дата-центры «Яндекса»

• серверы,
• системы хранения,
• линии связи,
• электроснабжение,
• работа инженерных команд.

Когда повреждается один из её крупных узлов, последствия могут почувствовать люди за сотни километров.

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

Материал основан на сведениях, доступных утром 12 октября 2026 года. Окончательная оценка повреждений и общая стоимость восстановления на этот момент в проверенных источниках не опубликованы.

У облака есть физическая основа

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

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

У облака есть физическая основа. Доступность цифровых услуг зависит от зданий, электроэнергии, связи и оборудования.

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

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

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

Три атаки и разные последствия

В ночь с 7 на 8 октября был атакован дата-центр в Сасове Рязанской области. «Яндекс» подтвердил пожар, повреждение части инфраструктуры и полную остановку объекта. Утром 9 октября атака затронула площадку в Калуге, где, по сообщению компании, из строя вышла часть инфраструктуры. В официальном обращении «Яндекс» сообщил, что сотрудники на обеих площадках не пострадали.

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

11 октября «Яндекс» сообщил о повреждении инфраструктуры и остановке дата-центра во Владимире. Платформа Yandex Cloud предупредила клиентов об аварийном режиме и рекомендовала использовать альтернативные планы восстановления. По сообщению компании, пострадавших не было.

Остановка объекта не равна уничтожению. Недоступность дата-центра сама по себе не доказывает гибель серверов или безвозвратную потерю данных.

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

Именно такую неопределённость зафиксировал Reuters вечером 8 октября: компания ещё не могла подтвердить возможность восстановления оборудования в Сасове. Судьба находившихся там суперкомпьютеров также оставалась неустановленной публично.

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

Какие вычислительные площадки оказались затронуты

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

Сасовский дата-центр начал работу в 2014 году. Согласно опубликованным сведениям, он разместился в части бывших помещений завода «Саста». В дальнейшем площадка стала местом размещения крупных вычислительных систем «Яндекса». История объекта показывает, как промышленная территория может получить новую технологическую функцию.

Калужский проект анонсировался с мощностью 63 мегаватта и вместимостью более 3 800 серверных стоек. В описании предусматривалась нагрузка до 15 киловатт на стойку. Это проектные характеристики, опубликованные до атак: они показывают масштаб комплекса, но не количество установленной или повреждённой техники.

Для исходного владимирского объекта генподрядчик указывает строительство первой очереди с апреля 2016 по март 2017 года, территорию 14,48 гектара и проектную вместимость всех очередей 2 880 стоек. Выделенная мощность составляла 50 мегаватт, а предусмотренная масштабируемость нагрузки вычислительного оборудования — от 4 до 40 мегаватт. Эти показатели описывают разные части энергетического баланса.

Рядом с действующим владимирским объектом «Яндекс» развивал ещё одну площадку. В официальном анонсе сентября 2025 года говорилось о мощности более 40 мегаватт, задержке связи с соседней зоной менее миллисекунды и высокой энергоэффективности. В отчётности за первое полугодие 2026 года ввод новой зоны доступности уже назван состоявшимся.

Различать эти объекты принципиально. Сообщение об атаке во Владимире не даёт оснований автоматически переносить повреждения на все расположенные поблизости мощности. Точность описания защищает от завышенных оценок и позволяет увидеть реальную картину восстановления.

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

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

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

Масштаб этой связи отражает отчётность Yandex Cloud. За первое полугодие 2026 года платформа сообщила о 64 тысячах клиентов и выручке 16,7 миллиарда рублей. На крупный бизнес приходилось 50% потребления, на средний — 29%, на малый и массовый сегмент — 21%. Это размер клиентской базы, а не число пострадавших от атак организаций.

Последствия распространяются по цепочкам зависимостей. Инцидент у инфраструктурного поставщика затрагивает компании и пользователей далеко от места атаки.

Для Подмосковья показателен транспортный эпизод. 8 октября областной Минтранс сообщил о недоступности онлайн-покупки автобусных билетов в связи с остановкой обеспечивавшего её дата-центра. Цифровая услуга оказалась зависимой от инфраструктуры за пределами региона.

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

«Циан» связал сбой с инцидентом у инфраструктурного партнёра и сообщил о восстановлении основного функционала после переноса части систем на другие мощности и использования резервных копий. Группа «Астрал» предупреждала о возможных перебоях в электронной отчётности и документообороте. Эти примеры показывают разнообразие последствий для внешнего бизнеса.

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

Как работает резервирование и почему ему нужен запас

Устойчивую систему проектируют с учётом того, что отдельные компоненты будут отказывать. Сервер может сломаться, линия связи — отключиться, программное обновление — вызвать ошибку. Резервирование ресурсов позволяет сохранить обслуживание, пока неисправный компонент ремонтируется или заменяется.

В облаке одной из единиц такого разделения служит зона доступности. Документация Yandex Cloud различает зональные ресурсы, например виртуальные машины и диски, и глобальные, например облачную сеть и бакеты объектного хранения. Размещение приложения в нескольких зонах снижает зависимость от отдельной площадки, но результат определяется устройством самого приложения.

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

Представим условную систему из трёх одинаковых площадок. Каждая способна обработать 100 единиц нагрузки, а общая потребность составляет 180. После потери одной площадки остаётся мощность 200 единиц — обслуживание теоретически можно сохранить. При потере второй остаётся только 100. Даже исправная автоматика не создаст недостающие вычисления.

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

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

Официальное руководство Yandex Cloud по отказоустойчивости рассматривает, в частности, кратковременный выход одной зоны из строя и частичный отказ программных интерфейсов. В нём отдельно отмечено, что после зонального отказа свободные ресурсы других зон исчерпываются быстрее. Границы сценария имеют значение: рекомендация для одного типа сбоя не является гарантией на любой масштаб происшествия.

Публичный опыт компании содержит и более ранний пример. После аварии энергоснабжения 30 марта 2025 года «Яндекс» описывал принцип сохранения работы собственных сервисов при потере одного дата-центра. При этом приложения клиентов, размещённые только в затронутой зоне, могли оставаться недоступными на протяжении восстановления. Разбор аварии был опубликован 7 апреля.

Следующий уровень защиты — резервные копии. Реплика базы помогает продолжить работу при отказе узла, а копия позволяет вернуться к сохранённому состоянию данных. Эти механизмы решают связанные, но разные задачи. Для бизнеса важна проверенная процедура: откуда получить данные, где запустить систему и кто имеет необходимые права.

Резервную копию нужно уметь восстановить. Её наличие недостаточно, если недоступны средства получения данных или площадка для запуска системы.

Именно поэтому учения полезнее формальной отметки «резервирование настроено». Команда должна проверить полный путь восстановления: доступ к копии, её пригодность, запуск приложения, соединение компонентов и выполнение критической операции пользователем.

В конструктивном смысле это вполне управляемая работа. Её можно разделить на небольшие проверки, измерить время выполнения и постепенно устранить слабые места. Инженерная дисциплина превращает абстрактное обещание надёжности в наблюдаемый результат.

Суперкомпьютеры и искусственный интеллект: важность без преувеличения

Отдельное внимание к атакованным площадкам связано с размещением суперкомпьютеров. По официальной публикации «Яндекса» 2021 года, «Червоненкис» и «Ляпунов» находились в Сасове, а «Галушкин» — во Владимире. Для них были опубликованы результаты теста Linpack: 21,53, 12,81 и 16,02 петафлопса соответственно. Эти исторические показатели характеризуют производительность систем в определённом испытании.

Один петафлопс соответствует квадриллиону операций с плавающей точкой в секунду. Число выглядит впечатляюще, но его смысл зависит от вида операций и метода измерения. Результат Linpack нельзя напрямую перевести в количество ответов голосового помощника или скорость обучения любой нейросети.

Сумма трёх опубликованных результатов составляет 50,36 петафлопса. Однако это не подтверждённая величина потерь и не измерение всей современной вычислительной инфраструктуры компании. Арифметическая сумма остаётся суммой паспортных показателей, пока нет сведений о фактическом состоянии оборудования.

Ущерб ИИ нельзя измерить одними паспортами суперкомпьютеров. Нужны подтверждённые сведения о повреждениях и роли оборудования в текущих вычислениях.

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

Конкретные последствия лучше устанавливать по сообщениям команд продуктов. 9 октября команда «Алисы» предупреждала о недоступности части функций чата, более долгих ответах, паузах на Станциях и нестабильной работе некоторых устройств умного дома. Это подтверждённые ограничения, которые можно обсуждать без предположений о гибели всех вычислительных систем.

История размещения оборудования также проверяется разными источниками. Например, отчёт Объединённого института ядерных исследований подтверждает, что во время посещения владимирского дата-центра 28 июня 2025 года делегации показали «Галушкина». Но даже независимое подтверждение его присутствия тогда не устанавливает состояние машины после октябрьской атаки.

Сдержанность здесь помогает точнее оценить значение события. Обсуждение устойчивости искусственного интеллекта становится полезнее, когда разделены доступность услуги, запас вычислений, сохранность моделей и ремонт оборудования.

Восстановление начинается с возвращения полезных функций

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

Возвращение сервиса и ремонт дата-центра — разные процессы. Приложение может заработать на альтернативных мощностях раньше восстановления исходного объекта.

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

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

Значимым шагом стало объявленное 9 октября сотрудничество с Selectel, К2Cloud и VK Cloud. По сообщению «Яндекса», провайдеры предложили ускоренное размещение инфраструктуры пострадавших клиентов, дополнительные команды, упрощённое подключение и гибкие финансовые условия. Отраслевая кооперация расширяет возможности восстановления за пределы ресурсов одной компании.

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

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

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

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

Экономическая цена: оборудование, время и доверие

Стоимость повреждённой техники — только одна часть последствий. Для облачного провайдера важны восстановительные работы и доступность услуг, для его клиента — способность продолжать собственный бизнес. Цена простоя зависит от того, какая операция остановилась и насколько быстро её можно заменить.

Цена инцидента шире стоимости техники. Она включает простой, восстановление, миграцию и возможную потерю клиентов; биржевое падение не заменяет этот расчёт.

Корректная оценка должна отдельно учитывать несколько составляющих:

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

Рынок акций реагирует быстрее, чем появляется полноценная оценка. Утром 12 октября «Коммерсантъ» сообщал о снижении бумаг «Яндекса» до 3 250 рублей, или на 5,79% к закрытию 9 октября, с последующим сокращением падения. Внутридневная котировка отражает ожидания участников рынка, а не бухгалтерскую стоимость повреждений.

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

Компания объяснила изменения унификацией положений, уже предусмотренных законодательством и условиями ряда сервисов. Однако общее пользовательское соглашение не заменяет анализ конкретного корпоративного договора. Условия обслуживания, гарантии доступности и порядок компенсаций необходимо рассматривать применительно к каждой услуге.

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

Российские и зарубежные источники: как сохранить точность

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

Reuters, например, приводит конкретный клиентский случай: владелец приложения Pulse с восемью тысячами пользователей сообщал о недоступности сервиса и проблемах доступа к резервной базе. При этом потерю данных он не подтверждал. Такой клиентский опыт показывает тяжесть неопределённости, не превращая опасение в установленный ущерб.

Отраслевое издание Data Center Dynamics рассматривало события на фоне повреждений украинской цифровой инфраструктуры. В публикации о Dream Line сообщалось, что, по заявлению оператора, данные и услуги перенесли на резервные площадки. Это важный для обеих сторон инженерный опыт: восстановление обслуживания может происходить раньше восстановления исходного объекта.

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

Технические метрики требуют точного прочтения. Автоматизированный трафик нельзя приравнивать к пропаганде, а количество жалоб — к числу уникальных пострадавших.

Особенно показательно обсуждение падения бот-трафика сети «Яндекса». В зарубежных публикациях эта динамика связывалась с гораздо более широкими выводами о российских ботах. Однако документация Cloudflare определяет соответствующую категорию через вероятность автоматизированного происхождения запроса. Назначение автоматизации такая метрика само по себе не устанавливает.

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

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

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

Что этот опыт меняет для цифрового бизнеса

История «Яндекса» объединяет разные классы угроз. В 2021 году совместное исследование компании и Qrator Labs описало атаки ботнета Mēris, достигавшие 21,8 миллиона запросов в секунду. Это была нагрузка на сетевые и программные механизмы. Октябрьские события 2026 года связаны с физическим повреждением инфраструктуры и требуют других способов восстановления.

Из этого не следует, что облачные технологии перестают быть полезными. Они предоставляют бизнесу ресурсы и инструменты, которые трудно воспроизвести самостоятельно. Но выбор облака должен сопровождаться пониманием распределения ответственности: что обеспечивает платформа, что настраивает заказчик и какие процедуры выполняются совместно.

Устойчивость доказывается восстановлением. Решающий показатель — способность вернуть критические функции и данные в проверенный срок при отказе привычной инфраструктуры.

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

Следующий шаг — определить допустимый перерыв и допустимую потерю последних изменений. Если данные копируются раз в сутки, восстановление может вернуть систему к состоянию предыдущего дня. Если резерв запускается вручную, понадобятся люди и время. Измеримые требования позволяют увидеть эти ограничения заранее.

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

Наконец, восстановление требует понятного взаимодействия с пользователями. Им нужны сведения о доступных функциях, временных способах работы и следующем обновлении статуса. Регулярная коммуникация уменьшает неопределённость и позволяет людям принимать собственные решения.

Уже подтверждённые действия — переключение нагрузки, возвращение массовых сервисов, использование резервных копий и привлечение других провайдеров — показывают, что у отрасли есть рабочие механизмы восстановления. Их развитие может сделать цифровые услуги устойчивее, если выводы будут закреплены в архитектуре, договорах и регулярных учениях.

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

Справочный раздел

Основные определения

• Дата-центр — комплекс для размещения вычислительного оборудования с системами электроснабжения, охлаждения, связи, контроля и обслуживания.
• Зона доступности — выделенная инфраструктурная область облачной платформы, используемая для размещения ресурсов и разделения отказов.
• Облачная платформа — среда, предоставляющая вычисления, хранение, сетевые и программные услуги по запросу.
• Репликация данных — поддержание копий данных на нескольких узлах с определённым способом и скоростью синхронизации.
• Резервная копия — сохранённое состояние данных, предназначенное для последующего восстановления.
• Аварийное восстановление — согласованный набор технических и организационных действий для возвращения системы к работе после серьёзного отказа.
• Допустимый простой — период, в течение которого отсутствие критической функции остаётся приемлемым для бизнеса.
• Допустимая потеря данных — объём последних изменений, которым организация готова пожертвовать при восстановлении.
• Соглашение об обслуживании — документ с параметрами предоставления услуги, условиями оценки её качества и предусмотренными последствиями нарушений.
• Коэффициент энергоэффективности — отношение полного энергопотребления дата-центра к потреблению вычислительного оборудования; обычно обозначается как PUE.
• Производительность Linpack — результат вычислительного теста, который используется при сравнении суперкомпьютеров.
• Автоматизированный трафик — запросы, создаваемые программами; эта характеристика сама по себе не определяет их полезность, вредоносность или политическое назначение.

Ключевые даты

• 2014 год — начало работы дата-центра в Сасове, по опубликованным сведениям.
• Апрель 2016 — март 2017 года — период строительства первой очереди исходного владимирского объекта по данным генподрядчика.
• Декабрь 2020 года — ввод «Ляпунова».
• Июнь 2021 года — ввод «Червоненкиса» и «Галушкина».
• 5 сентября 2021 года — атака Mēris на «Яндекс» с опубликованным пиком 21,8 миллиона запросов в секунду.
• 30 марта 2025 года — авария энергоснабжения одного из дата-центров; её не следует включать в число подтверждённых атак.
• 24 сентября 2025 года — анонс новой зоны доступности на базе соседней владимирской площадки.
• 8 октября 2026 года — атака на Сасово.
• 9 октября 2026 года — атака на Калугу и объявление о помощи других облачных провайдеров.
• 10 октября 2026 года — публикация новой редакции пользовательского соглашения.
• 11 октября 2026 года — атака на Владимир; вечером компания сообщила о постепенном восстановлении массовых сервисов.

Характеристики площадок

• Калужский проект: 63 мегаватта, более 3 800 серверных стоек, до 15 киловатт на стойку — исторические проектные параметры.
• Исходный Владимир: 14,48 гектара территории, 10 130 квадратных метров зданий первой очереди, вместимость всех очередей 2 880 стоек.
• Электрическая мощность исходного владимирского объекта: 50 мегаватт выделенной мощности; предусмотренная вычислительная нагрузка — до 40 мегаватт.
• Новая площадка рядом с Владимиром: в анонсе 2025 года указаны мощность более 40 мегаватт, задержка между соседними зонами менее миллисекунды и ёмкость межзонового канала 25,6 терабита в секунду.

Суперкомпьютеры

• «Червоненкис», Сасово: опубликованный результат Linpack — 21,53 петафлопса.
• «Ляпунов», Сасово: 12,81 петафлопса.
• «Галушкин», Владимир: 16,02 петафлопса.
• Общий показатель трёх исторических результатов — 50,36 петафлопса. Он не является оценкой уничтоженных мощностей.
• Состояние оборудования после атак: подтверждённой публичной оценки повреждений каждой из трёх систем в использованных источниках нет.

Масштаб облачного бизнеса

• Клиентская база: 64 тысячи клиентов Yandex Cloud по итогам первого полугодия 2026 года.
• Выручка платформы: 16,7 миллиарда рублей за полугодие, рост на 30% год к году.
• Структура потребления: крупный бизнес — 50%, средний — 29%, малый и массовый сегмент — 21%.
• Использование ИИ: соответствующие сервисы применяли 37% крупных клиентов.
• Граница интерпретации: эти показатели описывают бизнес до атак и не устанавливают число пострадавших организаций.

Что ещё предстоит установить

• Фактический ущерб: количество повреждённых модулей, серверов, накопителей и другого оборудования.
• Сохранность данных: подтверждённые случаи безвозвратной потери и их масштаб.
• Сроки восстановления: отдельно для пользовательских функций, клиентских систем и физических площадок.
• Экономические последствия: расходы на ремонт и миграцию, потерянная выручка, компенсации и страховое возмещение.
• Результаты миграции: число клиентов, которым удалось восстановить работу на альтернативной инфраструктуре.

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