Как сохранить данные и восстановить работу сервисов, когда ЦОД недоступен

В 2024 году серьезные инциденты, затронувшие критичные бизнес-процессы, пережили 93% российских организаций. Средний простой вырос до четырех часов, а один значимый сбой обошелся компаниям в среднем в два миллиона рублей. Уже в первом квартале 2025 года число масштабных инцидентов выросло еще на 25%, и больше половины из них затронули критически значимые бизнес-процессы. Тенденция устойчива, и объясняется она системной неподготовленностью: большинство компаний строят резервирование, которое выглядит убедительно на бумаге, но не выдерживает проверки реальным отказом. О том, как это исправить, рассказывает Виктор Виноградов, директор по информационной безопасности mt cloud.

С чего начинается настоящая отказоустойчивость

Любая работа по отказоустойчивости начинается с двух вопросов к бизнесу: как долго компания может не работать и сколько данных готова потерять. Ответы на них задают два ключевых показателя резервирования. Первый из них, RTO (Recovery Time Objective), фиксирует допустимое время простоя. Второй, RPO (Recovery Point Objective), определяет допустимый объем потери данных. Вместе они задают требования ко всей архитектуре, и без них нельзя обоснованно выбирать ни технологии, ни провайдеров, ни конфигурацию резервных площадок.

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

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

Резервная копия не спасет, если ЦОД упал

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

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

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

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

Ранее Виктор Виноградов объяснял журналу RUБЕЖ, почему одного правила резервного копирования 3-2-1 уже недостаточно для защиты от современных угроз.

Три фактора, которые срывают восстановление

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

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

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

Третья причина: отсутствие доступов. Учетные записи, сертификаты, ключи, профили удаленного подключения должны быть доступны независимо от основной инфраструктуры и заранее розданы тем, кто будет восстанавливать систему. Запрашивать доступы в момент инцидента означает терять критичное время там, где каждые 15 минут стоят денег.

Когда переключаться на резервный ЦОД, а когда ждать

Вопрос, который редко проговаривается заранее: в какой момент переключаться на резервный ЦОД? Иногда дождаться локального восстановления быстрее, иногда нет. Принимать это решение под давлением инцидента не рекомендую: в кризисе люди склонны либо к панической активности, либо к полному бездействию, и то и другое удлиняет простой. 

Критерии переключения и предельное время ожидания должны быть определены заранее и зафиксированы в регламенте. Логика здесь простая: если основная площадка не восстанавливается за N минут, принимается решение о переключении. Значение N определяется исходя из RTO конкретных систем, с учетом времени, которое само переключение занимает.

Как понять, что план восстановления работает

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

Довольно распространенная ошибка при тестировании состоит в том, что проверяют только факт восстановления файлов. Файлы поднялись, контрольные суммы совпали, тест засчитан, но проверить таким способом работоспособность системы невозможно.

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

Почему учения важнее любого регламента

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

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

Результаты учений должны видеть не только технические команды, но и руководство. Им нужны конкретные цифры: сколько времени заняло восстановление и насколько оно соответствует требованиям бизнеса. Только тогда у компании появляются основания инвестировать в резервирование осознанно, а не по принципу «у нас же есть бэкапы».