У Яндекса атаковали три дата-центра. Насколько мы близки к «всё, рунета больше нет»?
После атак на дата-центры Яндекса начались разговоры о том, что ещё немного и Рунет закончится. Когда одновременно не вызывается такси, не проходит оплата и не открывается рабочая почта, поверить в это довольно легко. Особенно если рядом уже объясняют, сколько серверов осталось до цифрового средневековья.
Я решил разобраться, что действительно произошло, сколько у Яндекса дата-центров и почему наличие резервных копий не спасает от всех неприятностей. Получилась история серьёзнее, чем «ничего страшного, сейчас перезагрузят», но оснований объявлять скорые похороны всего рунета я тоже не нашёл.
Начнём с того, что подтверждено. В ночь с 7 на 8 октября был повреждён дата-центр в Сасово, его работу полностью остановили. 9 октября пострадала площадка в Калуге, где вышла из строя часть инфраструктуры. 11 октября Яндекс сообщил об остановке дата-центра во Владимире после новой атаки. По сообщениям компании, сотрудники этих площадок не пострадали.
Здесь уже есть существенная поправка к пересказам: три атакованные площадки не означают три полностью уничтоженных дата-центра. Работа может остановиться из-за повреждения электроснабжения, охлаждения или связи, даже если часть серверов сохранилась. И наоборот, внешне целое здание ещё ничего не говорит о работоспособности оборудования внутри. Полной публичной картины повреждений пока нет.
При этом последствия вполне реальные. Yandex Cloud, облачная платформа компании, прямо назвала режим работы аварийным и рекомендовала клиентам задействовать альтернативные площадки для восстановления. В опубликованных 13 октября рекомендациях компания всё ещё не называла сроки полного восстановления сервисов. Так что рассказывать, будто всё происходящее существует только в панических заголовках, тоже было бы странно.
Почему проблемы одной компании ощущаются как проблемы всего интернета? Потому что Яндекс давно обслуживает гораздо больше, чем собственный поиск.
Дата-центр представляет собой комплекс с серверами, системами хранения, электропитанием, охлаждением и связью. На этих серверах работают программы, которые принимают ваши заказы, показывают документы, рассчитывают маршруты и проводят другие операции. Часть оборудования Яндекс использует для своих сервисов, а часть предоставляет другим компаниям через Yandex Cloud. Бизнес арендует вычислительные ресурсы вместо того, чтобы покупать и обслуживать собственные серверы.
По итогам первого полугодия 2026 года у Yandex Cloud было около 64 тысяч клиентов. Это не значит, что все они одновременно перестали работать. Но масштаб зависимости становится понятнее: проблемы облака могут затронуть множество компаний, на вывесках которых вообще нет слова «Яндекс».
Допустим, интернет-магазин хранит в таком облаке базу заказов. Его главная страница может открываться, фотографии товаров могут загружаться, а оформить покупку уже не получится. У другого сервиса работает всё, кроме входа через стороннюю систему авторизации. Третий не может обратиться к нужному хранилищу. Пользователь видит несколько сломавшихся приложений подряд и вполне естественно говорит: «Что-то интернет сегодня не работает».
Технически связь при этом может сохраняться. Провайдер продолжает передавать данные, другие сайты доступны, сообщения доходят. Но человеку, который не может получить заказ или воспользоваться рабочим сервисом, от этого разграничения не сильно легче.
А сколько у Яндекса вообще дата-центров? Здесь даже с подсчётом есть нюанс. В новостях часто встречается цифра пять. Она действительно фигурирует в публичных описаниях инфраструктуры компании. Однако в марте 2026 года Яндекс объявил о вводе новой зоны доступности на базе ещё одного полноценного дата-центра. Если учитывать этот комплекс отдельно от прежних пяти, по опубликованным сообщениям получается шесть.
При этом количество дата-центров всей компании и количество зон её облачной платформы считать одним и тем же нельзя. Зона доступности описывает отдельную часть облачной инфраструктуры, в которой клиент размещает свои ресурсы. Это не универсальная единица измерения всего хозяйства Яндекса.
Но даже точная цифра не позволит посчитать ущерб простым делением. Шесть дата-центров не обязательно дают шесть одинаковых долей мощности. У площадок могут различаться размер, оборудование, фактическая загрузка и задачи. Потерять половину зданий не обязательно означает потерять половину вычислений. А сохранение половины вычислений ещё не гарантирует, что на них можно немедленно запустить всё остальное.
Удобная арифметика «три из пяти, значит, осталось 40% Яндекса» заканчивается примерно там, где начинается устройство настоящей системы.
Но ведь у них должны быть резервы. Почему тогда вообще что-то падает? Резервирование всегда рассчитывают на определённые неисправности. Сервер может пережить отказ диска, приложение может пережить отказ сервера, а распределённая система может пережить недоступность целой площадки. Это разные уровни защиты.
Яндекс публично рассказывал о принципе «минус один дата-центр»: собственные сервисы распределяют так, чтобы они сохраняли работоспособность при потере одной площадки. Для проверки проводят учения с отключением дата-центров от внешнего мира. Но способность пережить одну такую аварию не означает возможность без последствий пережить несколько подряд.
Вот условный пример, который не описывает реальные мощности Яндекса. Есть три одинаковые площадки, каждая загружена на 60%. Одна отключилась, её работу поровну распределили между двумя оставшимися. Теперь они загружены примерно на 90%. Система продолжает работать, но свободного места почти не осталось. Если до восстановления первой площадки отключается ещё одна, последней достаётся нагрузка на 180% её возможностей. Отправить её туда технически можно. Убедить оборудование обработать её целиком уже сложнее.
Именно поэтому после первого сбоя система может выглядеть почти здоровой, хотя запас прочности уже потрачен. Следующая авария происходит в гораздо менее благоприятных условиях.
Есть ещё одна тонкость. Некоторые распределённые базы данных должны согласовывать изменения между несколькими копиями. Если доступных участников становится недостаточно, система может остановить запись, чтобы не получить противоречивые данные. Поэтому ситуация «информация сохранилась, но пользоваться сервисом полностью нельзя» вполне возможна.
Например, увидеть остаток на счёте и безопасно провести новую операцию для программы представляют собой разные задачи. Наличие читаемой копии ещё не решает вторую.
А резервная копия почему не помогает всё быстро включить? Она помогает восстановиться, но сама по себе работающим сервисом не является.
Полезно различать три вещи. Реплика хранит актуальную копию данных и получает изменения по мере работы системы. Бэкап сохраняет состояние на определённый момент, к которому можно вернуться после повреждения или удаления информации. А запас вычислительной мощности позволяет где-то запустить программы, которые будут с этими данными работать.
Можно иметь хорошую резервную копию и не иметь свободного сервера нужного размера. Можно иметь сервер, но ещё несколько часов переносить на него данные. Можно перенести данные и обнаружить, что для запуска приложения нужны дополнительные настройки, доступы и другие сервисы. А после запуска ещё требуется проверить, что система работает правильно.
К тому же реплика и бэкап защищают от разных неприятностей. Если программа ошибочно удалила записи, реплика может послушно повторить удаление. Тогда пригодится сохранённая версия до ошибки. Если пропала площадка, полезна доступная копия в другом месте. Слово «резервирование» одно, а задач под ним довольно много.
Поэтому фраза «ну у них же есть бэкап» примерно так же описывает восстановление бизнеса, как «у меня есть чемодан» описывает готовность к переезду. Важная часть действительно имеется. Остальное ещё предстоит организовать.
Что в такой ситуации делают инженеры? Восстановление идёт одновременно по нескольким направлениям.
На повреждённой площадке сначала нужно обеспечить безопасность, оценить состояние инженерных систем и оборудования. Подать питание обратно недостаточно: необходимо понимать, что его можно подавать, что охлаждение работает и что повторное включение не создаст новых проблем.
Параллельно команды сервисов используют сохранившиеся ресурсы. Где-то переключают работу на готовые копии, где-то разворачивают системы из резервных данных. Проверяют согласованность информации, восстанавливают связи между компонентами и постепенно возвращают нагрузку. Часть функций при этом может временно оставаться отключённой.
Это объясняет, почему сервисы возвращаются не одновременно. Один уже открывается, другой позволяет только посмотреть данные, третий работает медленно, четвёртый пока недоступен. Даже у одного приложения разные действия могут восстанавливаться в разное время.
В текущей ситуации Yandex Cloud ограничивала выделение дополнительных ресурсов и рекомендовала использовать внешние площадки. В рекомендациях есть способы переноса данных и восстановления систем. Это хороший пример того, что «облачные мощности» в конце концов упираются в вполне физические компьютеры. Кнопка создания сервера не производит процессоры.
Причём возвращение приложения в строй и восстановление повреждённого дата-центра могут происходить в совершенно разные сроки. Сервис можно запустить на другой площадке раньше окончания ремонта. А потом ещё потребуется вернуть ему нормальную производительность и резервирование. Сообщение «всё снова открывается» не обязательно означает, что система уже вернулась к прежней устойчивости.
Можно ли из всего этого сделать вывод, что пользовательские данные потеряны? Нет, по одной недоступности сервиса такой вывод сделать нельзя. Но и обещать сохранность абсолютно всей информации всех клиентов без результатов проверок было бы нечестно.
Для разных данных используются разные способы хранения и защиты. Например, 11 октября руководство финтех-направления Яндекса сообщило, что записи о счетах хранятся в нескольких копиях на разных площадках, их целостность проверили и потерь записей не обнаружили. Это заявление относится к конкретным данным конкретного направления. Автоматически распространять его на каждый файл, каждую базу и каждый клиентский проект нельзя.
У клиентов облака многое зависит ещё и от того, как они построили свои системы. Если компания разместила приложение только в одной зоне и не подготовила восстановление, сам факт аренды ресурсов у крупного провайдера не создаёт ей автоматически вторую работающую копию бизнеса.
Теперь к главному: сколько дата-центров должно отключиться, чтобы «лёг Рунет»? Такого универсального числа нет.
Рунет не хранится целиком у Яндекса. Интернет состоит из множества соединённых сетей разных операторов. Поверх них работают сайты, приложения и облачные платформы. Поэтому серьёзный сбой одного провайдера вычислений может нарушить работу огромного количества сервисов, но из этого не следует автоматическое отключение всех остальных сетей и ресурсов.
Для оценки действительно масштабной потери связи важны работа операторов, доступность маршрутов передачи данных, электроснабжение, системы доменных имён и наличие альтернативных соединений. Массовые перебои возможны из-за крупных аварий, ошибок программного обеспечения, неправильных настроек или административных ограничений. Считать их вероятность по числу повреждённых серверных зданий бессмысленно.
У нас уже был наглядный пример. 30 января 2024 года множество пользователей столкнулось с недоступностью сайтов в зоне .ru. Координационный центр связал произошедшее со сбоем в механизме DNSSEC, который защищает систему доменных имён. Если совсем просто, возникла проблема с проверкой адресов сайтов. Для столь заметного сбоя не потребовалось физического уничтожения дата-центров.
Обратная ситуация тоже возможна: связь между сетями сохраняется, но многие привычные сервисы недоступны из-за проблем с их вычислительной инфраструктурой. В повседневной речи обе ситуации назовут «интернет упал», хотя причины, последствия и способы восстановления будут разными.
Распределённость интернета помогает переживать неисправности. Но она не делает его неуязвимым. Если много компаний пользуется одной и той же платформой, её проблемы расходятся далеко за пределы её собственного приложения. Чем больше таких общих зависимостей, тем заметнее последствия одного крупного инцидента.
Поэтому я бы не подписывался ни под «Рунету конец», ни под «обычный сбой, чего вы переживаете». Для Яндекса и части его клиентов это серьёзный кризис: потеря доступных мощностей, простой, расходы на восстановление и работа с уменьшенным резервом. Для людей за этим стоят вполне конкретные сорванные заказы, недоступные документы и остановившиеся рабочие процессы.
А вот прогноз о скором исчезновении всего российского интернета требует совсем других доказательств. Их нельзя заменить подсчётом дата-центров.
Больше разборов про технологии и то, как они влияют на нашу жизнь, в «Пост Завтра». Подписывайтесь пожааалуйста
Источники и подробности
«Коммерсантъ»: что известно об атаке на дата-центр во Владимире. Хронология событий, сообщения компании и последствия для сервисов.
РБК: постепенное восстановление сервисов Яндекса. Какие функции возвращались к работе и почему ограничения сохранялись.
«Коммерсантъ»: последствия атак для облачного рынка. Нехватка вычислительных мощностей, перенос клиентских систем и сложности восстановления.
РБК: последствия сбоев для бизнеса и самозанятых. Пример того, как проблемы инфраструктуры затрагивают сторонние рабочие процессы.
РБК: причина массового сбоя Рунета 30 января 2024 года. Тот самый случай с DNSSEC, когда массовая недоступность сайтов возникла без уничтожения дата-центров.
