В ночь на 8 октября в Yandex Cloud потеряла электропитание зона доступности ru-central1-b — один из ключевых дата-центров облака. К утру компания сообщила, что работа дата-центра полностью остановлена. Жалобы на сбои начали поступать от пользователей самых разных сервисов: сайтов объявлений вроде «Авито» и «ЦИАН», банков, транспортных порталов, ритейла и других. Утром 9 октября были полностью выведены из строя несколько модулей ещё одного дата-центра Яндекса, в Калуге. На момент подготовки статьи срок восстановления оборудования не назван.

Для инженеров это повод ответить на неудобный вопрос: что будет, если площадка, где расположен прод, внезапно выйдет из строя на неопределённое время? Под катом разберём сценарии отказов инфраструктуры, архитектуру восстановления на независимой площадке и посчитаем RPO и RTO на модельном примере из 40 ВМ.

Что произошло в этот раз

За полтора года зона ru-central1-b выпала целиком уже второй раз, и теперь площадка не просто обесточена, а повреждена. А на следующий день пострадал ещё один дата-центр Яндекса, в Калуге. Хронология по публичным сообщениям Яндекса, Yandex Cloud и СМИ:

Часть компаний прямо связала свои проблемы с инцидентом у инфраструктурного партнёра: так сделал, например, «ЦИАН». Мострансавто объяснило недоступность онлайн-продажи билетов остановкой дата-центра и оценило восстановление в срок до 24 часов. Сбои части банков и СМИ днём 8 октября, по данным «Коммерсанта», были связаны также с ошибкой у поставщика защиты от DDoS-атак Curator.

Прецедент уже был. 30 марта 2025 года та же ru-central1-b осталась без питания: на опорной подстанции одновременно отключились обе линии 110 кВ. Полное восстановление заняло около 10 часов, и всё это время приложения, развёрнутые только в этой зоне, были недоступны. В опубликованном разборе инцидента Яндекс пообещал включить двойные отказы в регулярные учения.

Отметим, что 8 октября платформа отработала в соответствии с регламентом: нагрузка, распределённая по нескольким зонам, переехала. Пострадали те, чьи приложения были развёрнуты только в одной зоне. Но за двое суток были повреждены две площадки одного провайдера, а сам Яндекс помогает клиентам Yandex Cloud ускоренно разместить данные и сервисы у других облачных провайдеров. Не буду гадать, как часто подобное будет повторяться. Важно другое: сценарий «площадка недоступна целиком, сроков восстановления нет» уже нельзя считать маловероятным риском.

Почему второй зоны у того же провайдера может не хватить

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

Но схема с распределением нагрузки по нескольким зонам одного и того же провайдера имеет ограничения, которые стоит заранее учесть в DR-плане:

• Ёмкость. Когда падает одна зона, все её клиенты одновременно идут создавать ВМ в оставшихся зонах, и свободных ресурсов может не хватить. 8 октября Yandex Cloud сам предупредил, что создание новых ресурсов может быть ограничено. DR-план, который предусматривает только создание ВМ в соседней зоне того же провайдера, изначально обрекает на конкуренцию за ресурсы в случае масштабного инцидента.

• Управление. Консоль, API, учётные записи и доступы, квоты и биллинг у всех зон одного провайдера общие. Если сбой затронет их, управлять ресурсами не получится ни в одной зоне.

• География. Зоны одного региона расположены относительно близко друг к другу или внутри одного датацентра. Событие, которое бьёт по местности целиком, например авария в региональной энергосистеме, может задеть несколько зон сразу.

• Архитектура приложения. Дополнительные зоны распределения нагрузки спасают, только если приложение умеет в них работать: сервисы не хранят состояние локально, у базы данных есть реплики в разных зонах, перед ними стоит балансировщик. Многие корпоративные системы устроены иначе: это монолиты и ВМ, которые перенесли в облако из собственного ЦОДа без переделки. Они работают в одной зоне, и чтобы распределить их по нескольким, их придётся перепроектировать. Поэтому совет «просто разверните всё в нескольких зонах» подходит не всем.

Мультизональность и DR (аварийное восстановление) на независимую площадку — разные уровни защиты. Мультизональность спасает от отказа одной зоны, но с ограничениями, о которых я рассказывал выше. DR — это реплика инфраструктуры у другого провайдера, в другом регионе или в собственном ЦОДе, которую запускают при аварии. Аварийное восстановление нужно, когда проблема шире одной зоны или когда архитектура приложения не позволяет распределить его работу по нескольким зонам.

Похожий принцип давно известен в резервном копировании — правило 3-2-1-1-0: три копии данных на двух разных типах носителей, одна из них вне основной площадки, одна неизменяемая или изолированная, и ноль ошибок при проверке восстановления. Для DR на случай потери ЦОДа из этого правила главное — копия вне основной площадки, причём сегодня это требование разумно читать строже: такая копия должна храниться вне основного провайдера или хотя бы вне основного региона, а сервисы из неё должны запускаться быстро, по готовому плану.

Сценарии отказов: от одной ВМ до площадки целиком

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

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

• Резервное копирование (бэкап) — это набор копий данных за разные моменты времени, например за каждый день последнего месяца, которые хранятся отдельно от рабочих систем. Если данные в рабочих системах удалили, испортили или зашифровали, их восстанавливают из копии, сделанной до инцидента. Бэкап обеспечивает сохранность данных, но не резервирует вычислительные ресурсы и сетевую инфраструктуру: при отказе основной площадки восстановить из него серверы и приложения можно только после того, как будет подготовлена новая площадка.

• Аварийное восстановление (Disaster Recovery, DR) — это готовая к работе копия всей инфраструктуры на другой площадке: серверов, приложений и данных. Данные туда постоянно реплицируются, а сети и порядок запуска настроены заранее. Если основная площадка выходит из строя, серверы и приложения быстро запускаются на резервной. Но реплика повторяет все изменения, в том числе заражение вредоносным ПО и порчу данных, поэтому если на резервной площадке хранится только последняя копия, от таких угроз она не защитит.

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

Как устроен DR в Хайстекс Акура

Хайстекс Акура по заданному расписанию обновляет реплику инфраструктуры на резервной площадке, а при аварии запускает из неё серверы и приложения по заранее настроенному плану. Основные компоненты и возможности:

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

• Контроллер. Центральный компонент управления. В нём настраиваются расписания репликации и хранения точек восстановления и составляются DR-планы, а при аварии контроллер запускает переключение на резервную площадку (failover) и возврат обратно (failback). Контроллер можно развернуть в отказоустойчивом режиме, чтобы управление восстановлением не зависело от одного сервера.

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

• Резервный контур. Так в Хайстекс Акура называется рабочее окружение на резервной площадке: серверы и приложения, запускаемые из выбранной точки восстановления. Запуск идёт по DR-плану: серверы стартуют в нужном порядке с учётом зависимостей между ними, а сети и IP-адреса заданы заранее, поэтому после переключения не нужно вручную перенастраивать сеть.

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

• Множественные хранилища точек восстановления. Ключевая возможность для защиты от потери площадки: Хайстекс Акура записывает каждую точку восстановления сразу в несколько хранилищ, и число таких хранилищ не ограничено. Это могут быть блочные хранилища для быстрого запуска и объектные S3-хранилища для хранения истории — на разных площадках, у разных провайдеров или в собственных ЦОДах. Если одна из площадок выйдет из строя, восстановиться можно из копии на любой другой. Подробнее — в следующем разделе. 

• Прямая копия ВМ. Режим, в котором Хайстекс Акура записывает данные напрямую на диски заранее созданных ВМ на резервной площадке, не обращаясь к API платформы. Благодаря этому резервной площадкой может стать любая платформа виртуализации или облако, где можно заранее создать ВМ нужной конфигурации, даже если у них нет API, с которым интегрирована Хайстекс Акура. Такая функциональность Хайстекс Акура позволяет реализовать DR практически на любых площадках, включая собственные ЦОДы «на земле», нишевые и «самописные» облака, а также закрытые контуры с жёсткими требованиями безопасности. Для российского рынка это редкая возможность: большинство DR-решений работают только с теми платформами, с API которых они интегрированы. С прямой копией ВМ схему DR можно построить под конкретные задачи, требования безопасности, внутренние регламенты и бюджет: от недорогой резервной площадки в собственном ЦОДе до нескольких площадок у разных провайдеров и в разных регионах.

Практическое правило: контроллер не должен жить на той площадке, которую защищает. Иначе в момент аварии управлять восстановлением будет нечем.

Множественные хранилища: копии на любом числе площадок

С функцией «Множественные хранилища точек восстановления» Хайстекс Акура записывает каждую точку сразу в несколько хранилищ, и число таких хранилищ не ограничено. Блочные копии можно держать на одной или нескольких резервных площадках, а объектные — в одном или нескольких S3-хранилищах. И те и другие стоит размещать вне основного провайдера, причём минимум на двух независимых площадках: у разных провайдеров или в собственных ЦОДах. Именно распределённое размещение копий делает схему устойчивой к потере основной, а иногда и одной из резервных площадок: остаются готовые к работе запасные варианты — независимая DR-площадка либо резервная копия в объектном хранилище и ресурсы для восстановления из неё.

• Блочные хранилища. Используются на резервных площадках для быстрого запуска: Хайстекс Акура хранит в них заданное число последних точек восстановления в виде облачных снапшотов. Из снапшота ВМ запускается за минуты: не нужно сначала загружать и распаковывать данные.

• Объектные хранилища S3. Используются для хранения всей истории точек восстановления. Подходят любые S3-совместимые хранилища: облачные или собственные, например на базе MinIO. Глубокая история обходится здесь недорого: данные дедуплицируются, а в облачных S3 оплачивается только фактически занятый объём. Дополнительно можно включить S3 Object Lock (неизменяемые точки восстановления): тогда точку нельзя изменить или удалить, пока не истечёт срок хранения.

Политика хранения настраивается отдельно для блочных и объектных хранилищ: например, сколько последних точек держать в блочном хранилище и за какой период хранить историю в объектном. Хайстекс Акура применяет её автоматически, а при необходимости политику можно изменить.

При потере основной площадки каждая копия становится отдельным вариантом восстановления, и RPO у всех вариантов практически одинаковый: каждая точка попадает во все хранилища. На схеме ниже — минимальная конфигурация с двумя копиями.

Порядок цифр я приводил в прошлом материале: подъём ВМ из снапшота в блочном хранилище — 6–8 минут, из S3-архива — около 40 минут. Отдельный случай — логическая порча данных или шифровальщик. Реплика повторит эти изменения, поэтому восстанавливаться придётся из точки, сделанной до инцидента. Для этого в Хайстекс Акура есть глубокая история точек в S3, неизменяемые точки восстановления (S3 Object Lock), которые нельзя изменить или удалить до окончания срока хранения, и раннее выявление аномальных изменений данных, которое помогает вовремя заметить атаку и выбрать чистую точку для восстановления.

Считаем на примере: RPO и RTO при потере площадки

Хотя сам запуск серверов из снапшотов Хайстекс Акура выполняет за считанные минуты, на практике восстановление занимает больше времени: нужно учесть человеческий фактор и дополнительные проверки, а при восстановлении из S3 — ещё и загрузку данных. Возьмём для расчёта реалистичный вариант с запасом по времени, где ядро сервиса возвращается примерно через 45 минут при запуске на площадке B и примерно через 2,5 часа при восстановлении из S3, а RPO критичного тира в обоих случаях — около 16 минут. Это расчёт на допущениях, а не бенчмарк: на реальном проекте каждую величину нужно замерить на пилоте.

Исходные данные

Условный онлайн-сервис, прод в одной зоне провайдера или в собственном ЦОДе:

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

RPO: сколько данных можно потерять

Худший случай — авария происходит за мгновение до того, как очередная точка восстановления полностью дошла до резервной площадки. Тогда эта точка теряется, и восстанавливаться придётся из предыдущей. Потеря равна длительности интервала плюс время доставки инкремента (его объём мы берём для пиковой интенсивности изменений данных):

Из расчёта выше видно, что основной вклад в RPO вносит длительность интервала между точками, а не время доставки инкремента: даже в пик инкремент тира 1 доходит до резервной площадки меньше чем за минуту. Значит, RPO можно уменьшить, если делать точки чаще, и канал это позволяет: в среднем за сутки в нашем примере репликация передаёт около 22 Мбит/с (360 ГБ изменений в сутки по всем тирам, после сжатия в 1,5 раза — 240 ГБ, или 1 920 Гбит, делим на 86 400 секунд в сутках) — это примерно 3% пропускной способности канала. Интервал для тира 1 можно сокращать, пока инкремент успевает дойти до резервной площадки до создания следующей точки. Во все хранилища попадают одни и те же точки восстановления, поэтому RPO почти не зависит от того, из какой копии восстанавливаемся: различаться может только время доставки точки до каждого хранилища. А вот RTO у вариантов разный: на площадке B серверы запускаются из снапшотов за минуты, а при восстановлении из S3 данные сначала нужно передать на площадку D. Рассмотрим RTO подробнее.

RTO: когда сервис снова обслуживает клиентов

Сценарий A: прод потерян, площадка B жива, ВМ поднимаются из блочных снапшотов волнами по DR-плану. Сценарий B: недоступны и прод, и площадка B (или на ней не хватает ресурсов), данные загружаются из S3 на заранее подготовленную площадку D. Восстанавливаем по приоритету: сначала тир 1, потом остальное.

В сценарии A больше половины времени (25 минут из 45) уходит на работу людей: заметить аварию, эскалировать её и принять решение о переключении. Сократить это время помогает не более мощное оборудование, а чёткий регламент: заранее утверждённый триггер вроде «нет прогноза восстановления через 15 минут — переключаемся» и отрепетированный план. В сценарии B всё упирается в скорость загрузки: при наших допущениях это около 22 минут на каждый терабайт исходных данных, поэтому разбиение на тиры здесь важнее всего.

Сравнение схем защиты для ядра сервиса (тир 1) из нашего примера

Что проверить прямо сейчас, пока прод ещё доступен

Рассчитанный нами RTO достижим, только если всё из этого списка подготовлено заранее, а не тогда, когда основная площадка уже недоступна из-за серьёзного инцидента:

• Размещение контроллера. Контроллер Хайстекс Акура должен работать не на той площадке, которую он защищает, иначе при аварии он также будет недоступен и не сможет управлять восстановлением. Регламент переключения и контакты ответственных тоже храните вне основной площадки: если они лежат только во внутренней вики или почте, при аварии их не открыть.

• Ресурсы на резервной площадке. Вычислительные ресурсы для тира 1 нужно зарезервировать заранее, а не рассчитывать, что их удастся выделить в момент аварии. Хайстекс Акура перед каждым действием проверяет, хватает ли облачных квот на тома, сетевые порты, IP-адреса, ВМ и снапшоты, и предупреждает, если их недостаточно. Но увеличить квоты или зарезервировать мощности у провайдера нужно заранее, по договорённости с ним.

• Сеть. Адресацию на резервной площадке, VPN, правила межсетевых экранов и сертификаты нужно настроить и заложить в DR-план заранее. Для публичных DNS-записей стоит задать короткое время жизни (TTL), чтобы после переключения пользователи быстро начали попадать на резервную площадку.

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

• Регулярные тестовые переключения. Хайстекс Акура проводит их в изолированной сети, не затрагивая работу основной площадки. Во время тестов замеряйте фактический RTO и используйте в планировании свои цифры вместо модельных.

• Триггер переключения. Заранее определите, кто и при наступлении каких условий объявляет аварию и запускает переключение на резервную площадку (failover). Это самый эффективный способ сократить RTO: в нашем расчёте больше половины времени в сценарии A уходит на работу людей.

• Защита копий. Площадка может стать недоступной не только из-за аварии, но и из-за атаки. Злоумышленник часто пытается удалить или зашифровать резервные копии и реплики, чтобы восстанавливаться было не из чего. Поэтому храните резервные копии на отдельной площадке и включите для S3-хранилища неизменяемые точки восстановления (Object Lock). Для доступа к хранилищам используйте отдельные учётные данные, не связанные с основной площадкой, а чтобы вовремя заметить атаку, включите раннее выявление аномальных изменений данных.

• Failback. Заранее определите, как и когда возвращать работу на основную площадку и сколько займёт обратная синхронизация данных. Без плана возврата «временная» резервная площадка рискует стать постоянной.

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

Вместо вывода

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

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