Есть два понятия, которые довольно часто люди путают.
BCP — Business Continuity Planning — план работ по предотвращению возникновения и исправлению последствий в случае возникновения ситуаций, негативно влияющих на работу компании.
DRP — Disaster Recovery Plan — план восстановления инфраструктуры компании после возникновения аварии.
При этом, как правило, ИТ служба вовлечена в оба плана. А так как зачастую ИТ дистанцировано от непосредственно бизнеса, то понятия и путают.
Итак, что это за планы, и с чем их курят?
BCP — более общий, и глобальный план. Для его построения определяют все риски, способные негативно повлиять на работу компании, не только связанные с ИТ. Далее, план состоит из работ по каждому риску: списки вовлеченных сотрудников, внешних служб; мер по предотвращению риска; последовательности действий по уменьшения воздействия и выхода из кризисной ситуации.
Повторюсь, это не обязательно может быть связано с ИТ (вернее — должно покрывать не только ИТ). Так, например, репутиционные риски закрываются работой по ним администрации и юристов компании.
BCP должен постоянно развиваться вместе с компанией: риски и их влияние должны пересматриваться; мероприятия по предотвращению проводится в жизнь, а мероприятия по выходу из кризисной ситуации тестироваться; все новые сервисы и бизнес-процессы учитываться, добавляться в план.
DRP — как правило должен входить в состав BCP, однако может существовать и сам по себе, в случае отсутствия последнего (хотя это и не есть хорошо).
Этот план призван описать порядок действий по борьбе с последствиями аварий, влияющих на техническое состояние активов компании. Проще говоря, работу офисов, прочих помещений компании, инфраструктуры компании, включая инфраструктуру ИТ.
DRP не только техническое решение, это и административные действия, и определенные процедуры, и состав антикризисного комитета. Но так как наиболее сложная часть компании — инфраструктура ИТ, то и большая часть плана посвящается построению решения по защите этой инфраструктуры.
DRP тоже должен развивается, и желательно в рамках общего BCP.
Рассказать про BCP и DRP можно очень много, но это несколько уводит от тематики блога, так как лежит в пространстве бизнес-аналитики; да и потребует больших усилий.
Пожалуй немного еще скажу про DRP.
Наиболее часто применяемым решением по защите от катастроф — построение резервного ЦОДа (центра обработки данных). Резервный ЦОД, или, как еще называют, резервная площадка, предназначен для содержания копии сервисов, и данные, без которых компания не сможет существовать дальше. Таким образом, при выходе из строя первого ЦОДа, должен работать второй.
В западной терминологии резервный ЦОД называют DR Site (Disaster Recovery Site)
Есть несколько вариантов построения такого решения: резервный “законсервированный” ЦОД, два взаимозащищающих друг друга ЦОДа, один резервный защищающий множество других и т.д.
Основные этапы соотносятся с задачами, которые необходимо решить (и периодически пересматривать) при построении решения защиты от катастроф:
Обычно решения по защите такого рода обходятся не дешево. И иногда бывает (сейчас это происходит все реже) и так, что порог входа (минимальная стоимость решения) значительно выше стоимости потерь — то есть смысла стоит резервную площадку просто нет.
Ну и, конечно же, с виртуализацией внедрять системы восстановления в случае катастроф намного проще. Например, SRM.
Адрес статьи
BCP — Business Continuity Planning — план работ по предотвращению возникновения и исправлению последствий в случае возникновения ситуаций, негативно влияющих на работу компании.
DRP — Disaster Recovery Plan — план восстановления инфраструктуры компании после возникновения аварии.
При этом, как правило, ИТ служба вовлечена в оба плана. А так как зачастую ИТ дистанцировано от непосредственно бизнеса, то понятия и путают.
Итак, что это за планы, и с чем их курят?
BCP — более общий, и глобальный план. Для его построения определяют все риски, способные негативно повлиять на работу компании, не только связанные с ИТ. Далее, план состоит из работ по каждому риску: списки вовлеченных сотрудников, внешних служб; мер по предотвращению риска; последовательности действий по уменьшения воздействия и выхода из кризисной ситуации.
Повторюсь, это не обязательно может быть связано с ИТ (вернее — должно покрывать не только ИТ). Так, например, репутиционные риски закрываются работой по ним администрации и юристов компании.
BCP должен постоянно развиваться вместе с компанией: риски и их влияние должны пересматриваться; мероприятия по предотвращению проводится в жизнь, а мероприятия по выходу из кризисной ситуации тестироваться; все новые сервисы и бизнес-процессы учитываться, добавляться в план.
DRP — как правило должен входить в состав BCP, однако может существовать и сам по себе, в случае отсутствия последнего (хотя это и не есть хорошо).
Этот план призван описать порядок действий по борьбе с последствиями аварий, влияющих на техническое состояние активов компании. Проще говоря, работу офисов, прочих помещений компании, инфраструктуры компании, включая инфраструктуру ИТ.
DRP не только техническое решение, это и административные действия, и определенные процедуры, и состав антикризисного комитета. Но так как наиболее сложная часть компании — инфраструктура ИТ, то и большая часть плана посвящается построению решения по защите этой инфраструктуры.
DRP тоже должен развивается, и желательно в рамках общего BCP.
Рассказать про BCP и DRP можно очень много, но это несколько уводит от тематики блога, так как лежит в пространстве бизнес-аналитики; да и потребует больших усилий.
Пожалуй немного еще скажу про DRP.
Из компаний, которые испытали на себе катастрофы с потерей большой части своих данных:— 43% никогда больше не открылись;— 51% закрывались в течении последующих 2х лет
Наиболее часто применяемым решением по защите от катастроф — построение резервного ЦОДа (центра обработки данных). Резервный ЦОД, или, как еще называют, резервная площадка, предназначен для содержания копии сервисов, и данные, без которых компания не сможет существовать дальше. Таким образом, при выходе из строя первого ЦОДа, должен работать второй.
В западной терминологии резервный ЦОД называют DR Site (Disaster Recovery Site)
Есть несколько вариантов построения такого решения: резервный “законсервированный” ЦОД, два взаимозащищающих друг друга ЦОДа, один резервный защищающий множество других и т.д.
Основные этапы соотносятся с задачами, которые необходимо решить (и периодически пересматривать) при построении решения защиты от катастроф:
- Что дублировать, без каких сервисов компания не сможет продолжать работать? Здесь определяются не только сами сервисы/приложения, но и параметры RTO/RPO для каждого. А также очень немаловажный параметр — стоимость простоя.
- Как переносить данные с основной площадки на резервную для поддержания резерва в актуальном состоянии? Многое зависит от показателей RTO/RPO, объема данных, удаленности резервной площадки, каналов связи. Здесь непосредственно и выбирается оптимальное решение для DR, с учетом стоимости простоев.
- Построение процедур восстановления, в случае наступления часа Х (аварии) — непосредственно разработка самого плана.
Обычно решения по защите такого рода обходятся не дешево. И иногда бывает (сейчас это происходит все реже) и так, что порог входа (минимальная стоимость решения) значительно выше стоимости потерь — то есть смысла стоит резервную площадку просто нет.
Ну и, конечно же, с виртуализацией внедрять системы восстановления в случае катастроф намного проще. Например, SRM.
Адрес статьи
Vint Ceramic Art | TITNIA & TECHNOLOGY
ОтветитьУдалитьExplore an all new “Vint Ceramic Art” dental implants project on communitykhabar TITNIA & 바카라사이트 TECHNOLOGY. Our team https://vannienailor4166blog.blogspot.com/ of sculptors and artists have created new and ventureberg.com/