Логотип
Хижина
Летучего
Мыша
Логин:
Баланс:

Disaster Recovery Plan (DRP) — как составить и что в него включить

Disaster Recovery plan (DRP) — это системный подход, который последовательно описывает действия по восстановлению работоспособности IT-инфраструктуры организации в случае аварийной ситуации. Disaster Recovery, как правило, включает в себя резервную площадку для хранения информации, программные решения для восстановления и план действий. Компания может иметь как физические серверы, так и использовать облачные технологии, применять виртуальные машины. При любом варианте IT-инфраструктуры требуется разработать план восстановления для каждого способа хранения информации. Так риски потери данных и остановки рабочих процессов будут сведены к минимуму.

Для составления плана в организации проводится анализ бизнес-процессов и формулируются цели Disaster Recovery.

Типы аварий

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

Природные бедствия

  • Пожары.
  • Наводнения.
  • Землетрясения.
  • Пандемия.

Инфраструктурные катастрофы

  • Отключение электричества.
  • Пожар или прорыв водопровода.
  • Обрушение здания.
  • Проникновение злоумышленников на объект и нанесение физического ущерба.

Технологические аварии

  • Авария сервера.
  • Сбой ПО на локальном сервере.
  • Сбой SaaS-приложения в облаке.
  • Потеря данных из-за сбоя или вируса.
  • Сбой сетевой инфраструктуры.
  • Выход из строя инфраструктуры интернет-провайдера.

Стратегии DRP

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

Локальное восстановление

Так как приложения, системы и данные развернуты on-premise, стратегия восстановления должна предусматривать потерю одного или нескольких компонентов системы.

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

Аварийное восстановление в облаке провайдера

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

Аварийное восстановление как услуга (DRaaS)

Облачные провайдеры предлагают Disaster Recovery как услугу. По сути, она является горячей резервной площадкой для аварийного восстановления ресурсов. DRaaS использует облако для предоставления пользователям копий приложений из корпоративного дата-центра. За счет этого организации быстрее реагируют и восстанавливают критически важные приложения.

Аварийное восстановление за счет виртуализации ресурсов

Виртуализация позволяет быстро развернуть копию виртуальной машины из облака или резервного сервера.

Что включить в Disaster Recovery Plan

Он должен содержать несколько разделов:

  • описание и цели DRP;
  • периодичность тестирования на резервных ресурсах;
  • процедуры восстановления и перечень персонала, ответственного за реализацию плана.

Цели и параметры плана аварийного восстановления

Цель DRP — свести к минимуму негативное влияние аварии на работу организации. План может предусматривать как восстановление только базовых параметров, так и полное восстановление работоспособности.

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

RTO (целевое время восстановления) задает период, в течение которого система недоступна после аварии. Он указывается в минутах, часах или сутках. RTO относится к допустимому времени простоя от сбоя до восстановления. Например, организация должна вернуться к работе в течение 4 часов, чтобы избежать ущерба.

Для определения RTO нужно ответить на вопрос: «Сколько времени займет восстановление после сообщения о сбое бизнес-процесса?»

RPO (целевая точка восстановления) определяет максимальный период, за который данные могут быть утеряны. Например, RPO допускает потерю данных в пределах одного часа. Для достижения этой цели резервное копирование должно выполняться не реже одного раза в час.

Для определения RPO нужно ответить на вопрос: «Какой объем данных может быть потерян без существенного негативного влияния на бизнес организации?»

Затем разрабатываются стратегии восстановления приложений и данных.

Персонал

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

IT-оборудование

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

Кроме того, все прошлые аварии необходимо задокументировать и описать, как они устранялись.

Процедуры резервного копирования и восстановления

В DRP указывается, как создается резервная копия каждого ресурса данных — где именно, на каких устройствах и в каких папках, а также как IT-отдел должен восстанавливать их из резервных копий.

Размещение ресурсов для аварийного восстановления

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

Тестирование плана

Мало составить план — его надо протестировать, чтобы подтвердить соответствие заданным параметрам RTO и RPO, выявить и исправить возможные недостатки. Тестирование необходимо проводить с определенной периодичностью.

Существуют следующие типы тестирования:

  • кабинетные учения;
  • проверка отказоустойчивости приложений;
  • проверка отказоустойчивости инфраструктуры;
  • симуляция нарушения работы в тестовой среде;
  • симуляция нарушения работы в среде продакшн.

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

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

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

При этом, решение DRaaS (аварийное восстановление как услуга) отличается от услуги резервного копирования данных (бэкапа).

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

Этапы аварийного восстановления системы в общем виде выглядят следующим образом...

1. Определение спектра систем, подлежащих восстановлению, расчет параметров BIA, RA, RTO и RPO.

Именно расчет BIA, RA, RTO и RPO позволяет определить оптимальную стратегию восстановления для каждого элемента IT-системы компании.

RTO (Recovery Time Objective) – это допустимое время восстановления системы после аварии. Этот параметр определяет период времени, в течение которого необходимо восстановить определенную систему. К примеру, если RTO составляет 12 часов, то система должна быть восстановлена не позднее, чем через 12 часов. В некоторых случаях, при автоматическом переключении трафика на резервную систему, RTO может составлять всего несколько секунд.

Для крупного бизнеса большой RTO может привести к значительным убыткам.

RPO (Recovery Point Objective) – это допустимая потеря данных или допустимая точка восстановления. Параметр отражает период времени, за который данные могут быть утеряны в результате сбоя. Например, RPO, равный 1 часу, означает, что будет потеряна информация, созданная не более чем за 1 час до сбоя. Чем меньше значение RPO, тем чаще необходимо выполнять резервное копирование данных.

Для некоторых компаний, например, банков, критически важно не потерять данные даже за минуту до аварии, поэтому для них RPO обычно имеет минимальные значения. BIA (Business Impact Analysis) – это анализ воздействия на бизнес. Параметр оценивает ущерб для бизнеса в результате аварии. Расчет BIA учитывает важность систем для бизнеса и распределение средств на их защиту. Все убытки выражаются в денежном эквиваленте и сравниваются со стоимостью мер защиты. Например, привлечение упущенного количества клиентов может обойтись вдвое дороже, чем услуга резервного копирования данных.

Параметр помогает принять решение о приобретении услуги Disaster Recovery и выбрать приоритетные системы для защиты.

RA (Risk Analysis) – это анализ рисков. Параметр отражает потенциальные проблемы, которые могут негативно повлиять на бизнес-процессы предприятия в случае аварий. Зная потенциальные риски, легче найти оптимальные способы их предотвращения или смягчения. RA также помогает определить, какие воздействия будут наиболее серьезными для компании и с какими системами они могут быть связаны.

Расчет параметров RA, BIA, RTO и RPO позволяет определить, какие системы нуждаются в наибольшей защите, и какие инструменты для этого будут наиболее эффективными и выгодными.

2. Разработка Disaster Recovery Plan и его наполнение.

Disaster Recovery Plan – это документ, описывающий процесс восстановления после аварии, и включающий в себя:

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

На этом этапе также могут разрабатываться такие документы, как SLA (Service-Level Agreement, соглашение об уровне услуг между компанией и клиентом) и RumBook (пошаговая инструкция для каждого сотрудника в момент сбоя).

3. Внедрение DRP и другой документации по аварийному восстановлению системы, их обсуждение и разбор с командой.

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

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