План аварийного восстановления (DR)

Что такое план аварийного восстановления и зачем он нужен

Disaster Recovery Plan — документ с последовательным описанием согласованных процедур, ролей и обязанностей персонала в аварийной ситуации.

В первую очередь, план определяет критически важные объекты IT-инфраструктуры и степень риска при отказе каждого из них. Уровень риска оценивается по методу BIA (business impact analysis). Это не единственный, но один из самых доступных методов анализа для ранжирования факторов риска и определения степени влияния события на ключевые бизнес-процессы. По методу BIA удобно определять взаимосвязь между процессами, устанавливать максимально допустимый период их простоя и рассчитывать целевое время для восстановления.

Также в DR-плане обязательно учитываются ресурсы (персонал и объекты инфраструктуры), задействованные в восстановлении. Ранжируется очередность устранения последствий. Определяются технологии Disaster Recovery и данные, чью безопасность нужно обеспечить в первую очередь.

• С практической точки зрения план аварийного восстановления (DR) решает четыре задачи бизнеса:
• Сохранить доступность критичных сервисов при сбое на основной площадке.
• Как можно быстрее восстановить стабильную работу IT-инфраструктуры, чтобы минимизировать убытки.
• Добиться прозрачности и предсказуемости процесса восстановления, сократив влияние человеческого фактора.
• Исключить или свести к минимуму потери важных данных. 

Как определить, нужен ли компании план аварийного восстановления

Говорить, что любому бизнесу нужен план аварийного восстановления — не совсем верно. Disaster Recovery Plan нужен компаниям, для которых остановка сервера оборачивается реальными финансовыми убытками, кибератака на базы данных чревата репутационными потерями, а сбой сайта или приложения нарушает операционный денежный поток.

Если потеря данных за 6-12 часов ничего в бизнес-процессах не меняет, компания может обойтись без детально прописанного DRP и ограничиться несложным планом восстановления из резервных копий. Пусть и не полноценный Disaster Recovery Plan, такой документ тоже полезен. Он помогает определиться с объектами копирования, расписанием и графиком бэкапов, видом, политикой хранения и регламентом восстановления резервных копий.

Как разработать план аварийного восстановления

План аварийного восстановления разрабатывает IT-отдел компании или архитекторы облачного провайдера. В нашем случае план разрабатывается архитекторами и параллельно с выбором DR-решения:

1. Проводится аудит инфраструктуры и объектов защиты при аварийных инцидентах. По каждому объекту формируются ссылки на документацию.

2. Распределяются роли персонала, обязанности внешних подрядчиков с фиксацией KPI по процессу реализации (время реагирования, RTO). Взаимодействие между сотрудниками и аутсорсером удобно иллюстрировать схемой.

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

4. Определяется порядок поддержания актуальности плана аварийного восстановления. Устанавливается частота аудита и тестирования, необходимые для проверки корректности DRP.

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

У плана аварийного восстановления нет формализованной структуры. Он может быть шире и объемней вышеприведенного шаблона. Главное, чтобы документ выстраивал четкую последовательность шагов при потенциальном сбое, помогал оценить масштаб аварии и среагировать адекватно угрозе. Кроме того, DR-план не статичен. Его нужно регулярно актуализировать, адаптируя под меняющуюся IT-инфраструктуру, новые направления деятельности и приоритеты бизнеса.

Чтобы понимать, насколько эффективен новый или скорректированный план восстановления, DRP тестируют. На базовом уровне достаточно проверить, понимает ли команда цель и значение DR-плана, знает ли каждый из сотрудников свои задачи, сроки реагирования. Для полноценного тестирования в компании моделируют аварийную ситуацию, не прерывая работу IT-систем: имитируют отказ оборудования и ПО, отслеживают реакцию персонала, проверяют эффективность коммуникаций, отклик резервных систем. Самый показательный, но и самый сложный вариант тестирования — проверка в рабочем режиме. Здесь все по-настоящему: провайдер отключает IT-инфраструктуру основной площадки, а компания проходит процедуры DR-плана в условиях реального отказа.

Глобальные тенденции к цифровизации постепенно подводят нас к тому, что Disaster Recovery Plan становится неотъемлемой частью планирования непрерывности бизнеса (Business Continuity). Как один из инструментов антикризисного менеджмента, он берет на себя поддержание доступности и восстановление IT-процессов, чтобы компания продолжала работать, несмотря на геополитические угрозы, инсайдерские атаки, стихийные бедствия и саботаж.