Атака на дата-центр Яндекса в Сасово: чем сбой опасен для бизнеса и как защитить сайт

8 октября 2026 года беспилотники атаковали дата-центр Яндекса в Сасовском районе Рязанской области. На объекте начался пожар, работу площадки остановили. Пострадавших, по официальным данным, нет. Но для тысяч компаний этот день стал наглядным уроком: сайт может перестать работать, даже если ваш хостинг находится в другом городе, а сами вы с Яндексом напрямую не связаны.

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

Что произошло 8 октября

Губернатор Рязанской области Павел Малков сообщил о двух сбитых беспилотниках и возгорании кровли на одном из предприятий Сасовского района. Позже стало понятно, что речь идёт о дата-центре Яндекса.

• Yandex Cloud. В зоне доступности ru-central1-b начались перебои с электропитанием. Создание новых ресурсов в ней ограничили, нагрузку стали переводить на другие площадки.
• Яндекс Почта. С утра пользователи жаловались на ошибки; за несколько часов работу восстановили.
• Состояние площадки. К вечеру компания ещё оценивала ущерб, и было неясно, удастся ли вернуть оборудование в Сасово в строй.

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

Кого задело: не только Яндекс

Самое показательное в этой истории — компании, которые узнали о своей зависимости от конкретного дата-центра только в момент аварии.

• ЦИАН сообщил о сбое сайта и приложения из-за инцидента у инфраструктурного партнёра. Основные функции вернули, часть инфраструктуры перевели на резервные мощности, а затронутые данные восстановили из копий.
• Сервис продажи билетов на автобусы Подмосковья приостановил онлайн-продажи: остановился ЦОД, на котором он работал.
• «Астрал» предупредил клиентов о возможных перебоях в электронном документообороте и сдаче отчётности.
• У ряда СМИ в течение дня медленно открывались страницы. Здесь важно не делать поспешных выводов: у каждого такого случая могут быть свои причины.

Вывод простой: облако — это не абстракция, а конкретные здания, линии питания и стойки. Если все ваши сервисы стоят в одной зоне доступности, авария в этой зоне выключает бизнес целиком.

Почему сайт падает, даже если он «ни при чём»

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

• Платёжный виджет. Каталог открывается, а оплата зависает на последнем шаге — клиент уходит к конкуренту.
• Карты и онлайн-чат. Если скрипт карты загружается синхронно, он может «подвесить» всю страницу.
• Аналитика. В Метрике появляются провалы, и потом сложно понять, какие рекламные кампании работали.
• Реклама. Директ продолжает тратить бюджет и вести трафик на сайт, который в этот момент не принимает заказы.
• Почта. Формы отправляют заявки на ящик, который не работает. Письма теряются, а вы даже не знаете, что клиенты писали.
• Облачные CRM, кассы, ЭДО. Отделу продаж нечем работать, даже если сам сайт жив.

Поэтому вопрос «где лежит мой сайт» — только половина картины. Вторая половина — «от каких чужих серверов он зависит».

Сколько стоит час простоя

Посчитать собственные потери проще, чем кажется. Возьмите среднее число заявок в час в рабочее время, умножьте на конверсию в продажу и средний чек. Добавьте рекламный бюджет, который ушёл впустую за время простоя. Для интернет-магазина с 10 заказами в час и чеком 3 000 ₽ четыре часа простоя — это около 120 000 ₽ выручки, не считая клиентов, которые больше не вернутся.

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

Чек-лист: 7 вопросов к своему сайту до аварии

Ответьте на них сейчас, пока всё работает. Если на какой-то вопрос ответа нет — это и есть ваша зона риска.

1. Где физически размещён сайт и есть ли у хостинга резервная площадка в вашем тарифе?
2. Как часто делаются резервные копии, где они хранятся и проверяли ли вы хоть раз восстановление из них?
3. Сколько займёт восстановление, кто им займётся и сколько это будет стоить?
4. Какие внешние сервисы встроены в сайт и куда писать в поддержку каждого из них?
5. Сохраняются ли заявки в админке или CRM, если почта перестанет работать?
6. Кто узнает о падении сайта первым и следит ли мониторинг не только за главной, но и за формами и оплатой?
7. Кто предупредит клиентов и кто заменит этого человека, если он в отпуске?

Технические меры, которые реально помогают

• Бэкапы на другой площадке. Копия в том же дата-центре, что и сайт, при пожаре сгорит вместе с ним. Храните копии минимум в двух местах — например, у хостера и в отдельном облачном хранилище.
• Разнесение по зонам доступности. Для серьёзных проектов — сервера в разных зонах или у разных провайдеров, с возможностью быстро переключить DNS.
• Резерв, рассчитанный на реальную нагрузку. Запасной сервер, который падает под обычным трафиком, бесполезен. Его нужно хотя бы раз нагрузить тестом.
• Асинхронная загрузка виджетов. Сайт должен открываться и принимать заявки, даже если чат, карта или аналитика не ответили.
• Текстовый адрес вместо одной лишь карты. Если карта не загрузится, клиент всё равно поймёт, куда ехать.
• Заявки в базу, а не только на почту. Каждая заявка с формы должна сохраняться в админке сайта или CRM.
• Внешний мониторинг. Проверка каждые 1–5 минут с уведомлением в Telegram — вы узнаете о проблеме раньше клиентов.

Что делать, если сайт уже лежит

1. Убедитесь, что проблема не у вас. Откройте сайт с мобильного интернета, а не с офисного Wi-Fi. Сделайте скриншот ошибки и запишите время.
2. Напишите хостеру. Укажите адрес сайта, время начала сбоя и приложите скриншот — так ответ придёт быстрее.
3. Приостановите рекламу, если сбой затягивается: нет смысла платить за клики на неработающую страницу.
4. Предупредите клиентов. Короткий пост в соцсетях или рассылка с телефоном и мессенджером для связи.
5. Принимайте заказы вручную. По телефону и в мессенджерах, обязательно записывая контакты и состав заказа. Прежде чем подтверждать, уточните наличие товара и статус оплаты.
6. Ведите журнал. Когда началось, что не работало, какие заказы приняли вручную, какие отменили.
7. После восстановления проверьте всё. Отправьте тестовую заявку, пройдите оплату, сверьте записи менеджеров с данными сайта, чтобы не было дублей.

Главное

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

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

Источники: сообщения губернатора Рязанской области, официальные заявления компаний, обзор Мегагрупп.