Сбой дата-центра у облачного провайдера: что делать сайту, боту и CRM

Что известно на 10 октября 2026 года

Страницу статуса Yandex Cloud мой запрос не открыл, её закрывает проверка на робота. Поэтому формулировки компании беру из новости Хабра, где цитируются официальное обращение Яндекса и канал Yandex Cloud Alerts. Это пересказ, не первоисточник. Причины событий не обсуждаю: по сообщению компании, повреждены дата-центры.

• Ночью на 8 октября в дата-центре в Сасово (Рязанская область) начался инцидент. Зона ru-central1-b недоступна, остальные зоны доступности работают.
• Яндекс пишет, что по текущим оценкам возобновить работу зоны в ближайшее время не удастся. Клиентам рекомендовано по возможности задействовать альтернативные планы, в том числе выделенные физические серверы Bare Metal.
• 9 октября компания сообщила о повреждении части инфраструктуры дата-центра в Калуге: несколько модулей выведены из строя, часть сервисов Яндекса может работать с перебоями, полный масштаб оценивается. Пострадавших нет.
• Яндекс договорился с Selectel, К2Cloud и VK Cloud об ускоренном размещении и резервировании ресурсов клиентов на их площадках. Обращаться можно к ним напрямую, в техподдержку или к аккаунт-менеджеру Яндекса.
• «Циан» сообщил о сбое сайта и приложения из-за инцидента на объекте инфраструктурного партнёра. Партнёр в этом сообщении не назван, цитату я видел в пересказе СМИ.

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

Первые два часа

Сначала разберитесь, что именно не работает.

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

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

Первые сутки

Главный вопрос дня: есть ли свежая резервная копия вне этой зоны и вне этого провайдера. Копия в том же облаке, в той же зоне, ничего не стоит, когда лежит зона. Второй вопрос: когда вы последний раз проверяли, что копия восстанавливается. Как собрать копии на отдельное хранилище, есть в разборе Duplicati.

Затем DNS. Посмотрите, у кого размещён домен и какой TTL у записей. Если TTL сутки, переключить сайт на другой адрес быстро не получится. Поставьте 300 секунд заранее, до аварии.

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

Первый месяц

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

Регулярный тест восстановления: раз в квартал разворачивайте копию на пустой машине и засекайте время. Мониторинг должен стоять вне вашего провайдера, иначе он замолчит вместе с сервисом. Пример настройки в статье про Uptime Kuma. И документ «кто что делает»: кто решает, что авария, кто пишет клиентам, кто восстанавливает, чей телефон и где лежат пароли.

Что даёт мультизонная схема и чего не даёт

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

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

Поэтому полезна инвентаризация: выпишите всё, на чём держится бизнес, включая то, что вы не администрируете. Рядом с каждой строкой ответ на вопрос «что делаем, если этого нет». Для части строк ответ «ждём и предупреждаем клиентов» нормален, если записан заранее.

Что можно сделать уже сегодня вечером

Возьмите таблицу и заполните её на час-два. Пустые клетки показывают, где риск.

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

Если нужна помощь, я делаю аудит зависимостей и план восстановления в рамках DevOps, резервного копирования и плана восстановления.

Частые вопросы

Нужно ли срочно переезжать к другому провайдеру?

Срочный переезд посреди аварии повышает риск потерять данные и сделать ошибку. Сначала стабилизируйте работу: заглушка, ручной режим, копия. О втором провайдере решайте по таблице из раздела выше. Условия переноса у Selectel, К2Cloud и VK Cloud уточняйте у них, я их не проверял.

Как понять, в какой зоне стоят мои ресурсы?

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

Хватит ли резервной копии, если она лежит у того же провайдера?

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

Коротко о главном

На 10 октября 2026 года зона ru-central1-b в Yandex Cloud, по сообщениям компании, недоступна, остальные зоны работают, сроки восстановления не названы. Что спасает бизнес при любом сбое дата-центра: готовый шаблон сообщения клиентам, копия вне зоны и вне провайдера, заглушка, проверенное восстановление и записанный план.

Если хотите, чтобы я провёл аудит зависимостей вашего сайта, бота или CRM и составил план восстановления, напишите мне в Telegram кодовое слово «ЗОНА».