BCP & DRP

Есть два понятия, которые довольно часто люди путают.
BCPBusiness Continuity Planning — план работ по предотвращению возникновения и исправлению последствий в случае возникновения ситуаций, негативно влияющих на работу компании.
DRPDisaster Recovery Plan — план восстановления инфраструктуры компании после возникновения аварии.

При этом, как правило, ИТ служба вовлечена в оба плана. А так как зачастую ИТ дистанцировано от непосредственно бизнеса, то понятия и путают.

Итак, что это за планы, и с чем их курят?


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

BCP должен постоянно развиваться вместе с компанией: риски и их влияние должны пересматриваться; мероприятия по предотвращению проводится в жизнь, а мероприятия по выходу из кризисной ситуации тестироваться; все новые сервисы и бизнес-процессы учитываться, добавляться в план.

DRP — как правило должен входить в состав BCP, однако может существовать и сам по себе, в случае отсутствия последнего (хотя это и не есть хорошо).
Этот план призван описать порядок действий по борьбе с последствиями аварий, влияющих на техническое состояние активов компании. Проще говоря, работу офисов, прочих помещений компании, инфраструктуры компании, включая инфраструктуру ИТ.
DRP не только техническое решение, это и административные действия, и определенные процедуры, и состав антикризисного комитета. Но так как наиболее сложная часть компании — инфраструктура ИТ, то и большая часть плана посвящается построению решения по защите этой инфраструктуры.
DRP тоже должен развивается, и желательно в рамках общего BCP. 


Рассказать про BCP и DRP можно очень много, но это несколько уводит от тематики блога, так как лежит в пространстве бизнес-аналитики; да и потребует больших усилий.

Пожалуй немного еще скажу про DRP.
Из компаний, которые испытали на себе катастрофы с потерей большой части своих данных:— 43% никогда больше не открылись;— 51% закрывались в течении последующих 2х лет

Наиболее часто применяемым решением по защите от катастроф — построение резервного ЦОДа (центра обработки данных). Резервный ЦОД, или, как еще называют, резервная площадка, предназначен для содержания копии сервисов, и данные, без которых компания не сможет существовать дальше. Таким образом, при выходе из строя первого ЦОДа, должен работать второй.
В западной терминологии резервный ЦОД называют DR Site (Disaster Recovery Site)
Есть несколько вариантов построения такого решения: резервный “законсервированный” ЦОД, два взаимозащищающих друг друга ЦОДа, один резервный защищающий множество других и т.д.

Основные этапы соотносятся с задачами, которые необходимо решить (и периодически пересматривать) при построении решения защиты от катастроф:

  1. Что дублировать, без каких сервисов компания не сможет продолжать работать?
  2. Здесь определяются не только сами сервисы/приложения, но и параметры RTO/RPO для каждого. А также очень немаловажный параметр — стоимость простоя.
  3. Как переносить данные с основной площадки на резервную для поддержания резерва в актуальном состоянии?
  4. Многое зависит от показателей RTO/RPO, объема данных, удаленности резервной площадки, каналов связи. Здесь непосредственно и выбирается оптимальное решение для DR, с учетом стоимости простоев.
  5. Построение процедур восстановления, в случае наступления часа Х (аварии) — непосредственно разработка самого плана.


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

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



Адрес статьи

Комментариев нет:

Отправить комментарий