Сбои после атак на дата-центры Яндекса. Как обеспечить отказоустойчивость сервисов?

8 октября работа дата-центра «Яндекса» в Сасово Рязанской области была остановлена после серьезного инцидента и пожара. 9 октября пострадал еще один дата-центр «Яндекса», уже в Калуге.

Одновременно Yandex Cloud сообщил о проблемах с электропитанием в зоне доступности ru-central1-b. Часть облачной инфраструктуры оказалась недоступна, а клиентам рекомендовали по возможности переносить нагрузку в другие зоны.Основные продукты «Яндекса» продолжили работать, но часть клиентов (особенно в регионах) жаловались на недоступность почты и других сервисов компании.

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

Можно резервировать электропитание, каналы связи и оборудование, устанавливать системы пожаротушения и дублировать критические узлы, но предусмотреть вообще все внешние события невозможно. Теперь отказоустойчивость должна отвечать на вопрос, что произойдет с данными и сервисами, если площадка станет недоступна?

Если вся критическая инфраструктура находится в одном дата-центре, вместе с площадкой компания потенциально теряет доступ сразу ко всему: серверам, хранилищу и части сетевой инфраструктуры. И помочь здесь может географическое резервирование.

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

Недавний инцидент с «Яндексом» не единственный подобный пример. В марте 2026 года в результате ударов была повреждена инфраструктура Amazon Web Services на Ближнем Востоке. AWS также пришлось восстанавливать работу сервисов и перераспределять нагрузку. Так что масштаб компаний здесь не имеет никакого значения.

Устойчивость к серьезным авариям обычно строится сразу на нескольких уровнях:

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

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

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

С 2014 года PlatformCraft работает с медиапроектами, для которых даже непродолжительная недоступность файлов быстро становится заметной конечным пользователям, поэтому облачная инфраструктура PlatformCraft распределена между тремя географически независимыми дата-центрами в РФ (SLA 99,99%).

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

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

Подобную архитектуру мы используем не только в собственном облаке. В корпоративных проектах DEPOT может быть развернут как распределенное объектное хранилище в нескольких географически независимых дата-центрах заказчика, что позволит компании полностью контролировать данные без единой точки отказа.

Авария в крупном дата-центре — это повод проверить собственную.

Где физически находятся ваши данные? Сколько их копий существует? Находятся ли они действительно на независимых площадках? Что произойдет, если один дата-центр будет полностью недоступен несколько часов или несколько дней? Есть ли отдельная резервная копия? И проверялось ли когда-нибудь восстановление из нее?

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