План аварийного восстановления или как Disaster Recovery Plan защищает критически важные сервисы

Для успеха бизнеса важна не только безопасность, но и непрерывность. Однако никто не защищен от аварийных ситуаций, которые несут угрозу этой самой непрерывности. Текущие реалии меняются динамично, и угроза вашему бизнесу может прийти откуда вы ее не ждете – от природных катастроф до социальных изменений. Обезопасить себя от наступления катастрофы в некоторых случаях возможно. Например, мы как-то рассказывали про то, как мы разрабатываем отказоустойчивые сервисы. Но лучше заранее позаботиться о минимизации возможных последствий. В этом вам поможет план, а точнее Disaster Recovery Plan. 

Начнем с теории

Disaster Recovery Plan (он же DRP, он же «план аварийного восстановления») — это заранее разработанный и документально оформленный набор действий и процедур, которые организация должна выполнить для восстановления критически важных IT-систем и инфраструктуры в случае возникновения чрезвычайной ситуации. Такими чрезвычайными ситуациями может стать та или иная авария в дата-центре (ДЦ), на котором расположены основные сервисы компании. DRP направлен на минимизацию времени простоя, предотвращение потери данных и обеспечение непрерывности бизнес-процессов. Сам план аварийного восстановления включает в себя стратегии резервирования данных, аварийного переключения на резервные системы (failover), а также регулярное тестирование и обновление процедур для поддержания их актуальности и эффективности.

Все схемы DRP можно принципиально поделить на два вида:

1) В первом случае наше приложение работает одновременно в двух (или больше) дата-центрах, обеспечивая «горячий» резерв. Примером такого приложения, например, является сервис для продажи авиабилетов и услуг, который мы разрабатывали для нашего заказчика – два экземпляра приложения одновременно работают в двух дата-центрах, расположенных в разных городах. При нормальной работе трафик балансируется между дата-центрами, а при аварии один из дата-центров автоматически выключается из балансировки и остаётся работать только второй.

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

У этих схем есть как очевидные плюсы, так и некоторые «подводные камни». К очевидным плюсам «горячего резерва» можно отнести то, что в случае аварии полная работоспособность восстанавливается в течение нескольких секунд (эти несколько секунд нужны балансировщику, чтобы понять, что одно из окружений упало, и перестать отправлять на него запросы), а также то, что в нормальном режиме мы получаем распределение нагрузки. Основной же плюс «холодного» резерва в том, что он дешевле – не нужно держать поднятой (и оплачивать) всю инфраструктуру во втором дата-центре, она появляется только в случае аварии. За эту дешевизну мы платим, соответственно, временем, которое требуется на развёртывание.

Кроме очевидных различий есть ещё одно очень важное сходство – при работе одновременно в двух дата-центрах приложение должно иметь консистентные интеграционные сервисы – в первую очередь это база данных (БД) и очереди сообщений RabbitMQ/Kafka (про очереди, кстати, мы рассказывали в отдельной статье).

В данный момент на схеме одновременной работы в двух ДЦ («горячий резерв») у нас работают три приложения заказчика. И у каждого из приложений своя схема работы с базами данных.

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

Другой наш продукт - финансовый модуль использует базу данных MySQL, и в этом случае мы применили решение на базе групп доступности AlwaysOn. DelegationService же в качестве базы данных использует ScyllaDB, изначально поддерживающую геораспределённый формат работы.

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

Примером «холодного» резерва в ближайшее время станут две учетные системы – прямо сейчас мы ведем работы над реализацией плана аварийного восстановления на данных проектах. В случае с ними при согласовании с владельцами продуктов решили, что внедрять новую схему работы с базами данных будет слишком трудозатратно. Наиболее оптимальной будет схема, при которой у нас есть реплики базы данных, есть кластер RabbitMQ в другом ДЦ с федерациями для нужных очередей, есть подготовленные пайплайны для развёртывания, но само приложение работает только в одном экземпляре. В случае же аварии мы будем разворачивать второй экземпляр на месте. И сами сервисы в данный момент используют базы данных, расположенные в DBaaS, поэтому репликация и переключение БД – это уже понятный и отработанный механизм.

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

• сам кластер OpenShift
• VCS / CI-CD (GitLab)
• Harbor
• S3
• WSO2
• ELK
• интеграционные сервисы
• и другие (тут у каждого приложения будет свой список необходимого).

Это все теория, а в качестве практической части хотим поделиться основными этапами внедрения плана аварийного восстановления:

1) Оценка рисков и уязвимостей

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

2) Определение критически важных систем и данных

• Определите критически важные приложения, системы и данные, которые необходимо восстановить в первую очередь
• Установите цели времени восстановления (RTO) и цели точки восстановления (RPO) для каждой системы

3) Разработка стратегии восстановления

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

4) Создание плана аварийного восстановления

• Документируйте пошаговые процедуры восстановления для каждой критически важной системы 
• Определите ответственных лиц и команды для выполнения плана 
• Разработайте план коммуникаций для информирования сотрудников и клиентов в случае катастрофы

5) Разработка плана тестирования и обучения

• Установите регулярный график тестирования плана аварийного восстановления для проверки его эффективности 
• Обучите сотрудников и команды действиям в случае возникновения катастрофы

6) Обеспечение актуальности и поддержки плана аварийного восстановления

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

7) Интеграция с общими бизнес-стратегиями

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

8) Оценка и улучшение

• Проведите анализ после реализации DRP для выявления недостатков и возможностей для улучшения 
• Внедрите рекомендации и улучшения на основе опыта и отзывов участников 

Что мы имеем в итоге?

На наш взгляд для обеспечения безопасности важны превентивные меры. Например, выбор надежного метода авторизации или подготовка уже знакомого нам DRP.

Однако «подстелить соломку» на случай непредвиденных проблем или нет – выбор сугубо индивидуальный. Кому-то достаточно иметь бэкап, но мы придерживаемся идеи, что надежный план по ликвидации последствий обязательно должен быть, ведь один небольшой сбой в IT-инфраструктуре может привести к колоссальным финансовым и репутационным потерям. Поэтому активно внедряем план аварийного восстановления на продуктах наших заказчиков.