Привет, хабр! Это скорее не статья-разъяснение, а статья-рассуждение о непрерывности и самая мякотка, надеюсь, будет в комментариях.

В силу того, что business continuity превратился в модный тренд, что-то вроде нанотехнологий, инноваций и импортозамещения, самое время определиться, что такое BCP и что такое DRP, в чем их разница и почему BCP и DRP как в том анекдоте «не муж и жена, а четыре совершенно разных человека».

BCP (business continuity plan) – план обеспечения непрерывности бизнеса. Содержит детальный план, что необходимо сделать для восстановления бизнес процессов.

DRP (disaster recovery plan) – план восстановления после катастрофы. Содержит детальный план по восстановлению инфраструктуры. Обычно имеется ввиду ИТ инфраструктура, но это могут быть самые разные механизмы, автотранспорт и здания.

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

DRP – это план про восстановление. Если сгорел склад, то есть запасной склад на такой случай. Если в ЦОД пришли маски-шоу, есть резервный ЦОД. Если сломался автомобиль – есть запасные части для ремонта. Или резервный автомобиль. В зависимости от требований бизнеса, о которых мы поговорим в другой статье.

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

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

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

BCP создается и тестируется совместно с представителями бизнеса. DRP создается и тестируется внутри ИТ подразделения.

Очень интересует мнение практиков, которые забороли путаницу в терминологии в непрерывности.

— * — требования бизнеса – это именно требования от бизнеса, а не размышления внутри ИТ департамента, как могли бы выглядеть бизнес требования.?
Поделиться с друзьями
-->

Комментарии (4)


  1. it_manager
    13.10.2016 17:04

    Немного не понял, что хотел донести многоуважаемый автор до аудитории и что конкретно спросить?


    1. igor2706
      14.10.2016 14:37

      Ага, внятно вопрос не сформулировал. (проведу работу над ошибками)
      Вопрос в том, сталкивался кто-нибудь с тем, что вопрос управления непрерывностью бизнеса идет изнутри IT и при этом плохо воспринимается у представителей бизнеса.


  1. aczkasow
    14.10.2016 14:34

    Я, навнедряв и отаудировав десятки компаний, склонился к позиции, что BCP, DRP, и ICM (incident management) это всё части BCM.


  1. latonita
    14.10.2016 14:34

    Мне не понятно, какая цель у данной публикации. Я абсолютно не согласен с тем, что BC или DRP стал модным трендом.
    Все зависит от целей/требований бизнеса. Полагаю, что большинство людей не сталкивалось с ними ни разу, а кто-то много лет их создает и имплементирует. И связано это скорее всего с размерами и серьезностью клиентов )
    Мы — сервисная компания по разработке ПО. Первый раз я такой план рисовал лет 10 назад.
    Есть план для нашего бизнеса, есть планы для центров разработки, которые мы создаем для клиентов. Причем у клиентов требования к планам достаточно разные.

    Далее что-то наподобие средней температуры по больнице =) список полезных пунктов, которые не хотелось бы оставить за бортом

    + overview, objectives, assumptions, disaster recovery task forces — who/where/what
    + plan of disaster
    ++ disaster classification на классы
    +++ самая крупная разбивка L1-L4 (asset,site,city, country)
    ++++ complete/partial/localized
    +++++ конкретные проблемы, степень их влияния на бизнес, и ответственные команды
    ++ кто определяет класс проблемы, схемы оповещения call tree, кого/когда (до/после)
    ++ knowledge management plan impact — важно понимать, как мы не потеряем какие-то важные знания/информацию в случае проблем
    ++ recovery strategy
    +++ для каждой проблемы детальные инструкции, fallback планы
    ++ планы тренингов, проверок поддержания обороноспособности
    ++ планы ревью и обновления планов )
    + по странам/городам/офисам — описание рисков, опять же разных уровней — начиная с политической обстановки, рисков природных катаклизмов, расписания сезонных эпидемий, и до asset уровня по необходимости
    + списки офисов, ответственных в каждом офисе, кол-во рабочих мест (с техникой/без техники)
    + списки бэкап оборудования в офисах, возможность их перемещения между офисами

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