Расшифровка аббревиатур
| Сокращение | Полное название | Что это на практике |
|---|---|---|
| BCM | Business Continuity Management, управление непрерывностью бизнеса | Система, а не документ. Процессы, роли, планы, тестирования и отчетность, которые вместе обеспечивают продолжение работы при сбоях |
| BCP | Business Continuity Plan, план непрерывности бизнеса | Документ, описывающий, как компания продолжает обслуживать клиентов, пока что-то не работает |
| DRP | Disaster Recovery Plan, план аварийного восстановления | Документ, описывающий, как техническая служба восстанавливает информационные системы и данные |
| BIA | Business Impact Analysis, анализ воздействия на бизнес | Расчет, показывающий, какие процессы критичны и сколько стоит их простой. Из него берутся все целевые сроки |
| RTO | Recovery Time Objective, целевое время восстановления | За сколько процесс или система должны вернуться в работу |
| RPO | Recovery Point Objective, целевая точка восстановления | Какой объем данных допустимо потерять, измеряется во времени |
| ПОНиВД | План обеспечения непрерывности и восстановления деятельности | Название BCP в терминологии Банка России для поднадзорных организаций |
Как они связаны, вложенные уровни
Это не конкурирующие подходы, а вложенные друг в друга контуры. Каждый следующий уже предыдущего и решает более узкую задачу.
- Управление рисками — самый широкий контур. Выявляет и снижает любые риски компании, от валютного до репутационного.
- BCM — часть управления рисками, отвечающая на один вопрос: как продолжать работать, когда что-то уже случилось.
- BCP — главный документ внутри BCM. Про бизнес целиком, процессы, людей, поставщиков, клиентов и коммуникации.
- DRP — техническая часть, чаще всего оформленная приложением к BCP. Про серверы, каналы связи, базы данных и резервные копии.
Таблица сравнения
| Параметр | BCP, план непрерывности | DRP, план аварийного восстановления |
|---|---|---|
| Объект | Бизнес-процессы и обязательства перед клиентами | Информационные системы, инфраструктура и данные |
| Главный вопрос | Как продолжать оказывать услуги, пока идет восстановление | Как вернуть системы в рабочее состояние |
| Владелец | Бизнес, руководитель уровня правления или директор по операциям | Служба информационных технологий |
| Кто исполняет | Все подразделения, задействованные в критичных процессах | Администраторы систем, сети, баз данных, подрядчики |
| Ключевые метрики | RTO процессов, MTPD, MBCO, стоимость часа простоя | RTO и RPO систем, время переключения на резервную площадку |
| Что входит | Сценарии, обходные схемы работы, коммуникации, резервные площадки, порядок активации, роли кризисного штаба | Схемы восстановления, порядок переключения, резервное копирование, проверка целостности данных |
| Типичный объем | Основной документ плюс карты действий по сценариям | Технические регламенты по каждой критичной системе |
| Что происходит без него | Системы подняли, но никто не знает, как обслуживать клиентов и что им говорить | Решение принято, но технически восстановить нечем и не из чего |
| Как тестируется | Настольные разборы сценариев, учения кризисного штаба | Натурное переключение на резервную площадку, контрольное восстановление из копии |
BCP и DRP, где проходит граница
Граница проходит там, где заканчивается техника и начинаются обязательства перед клиентом. Проще всего это увидеть на трех проверочных вопросах.
Вопрос первый. Что делает компания в те часы, пока системы восстанавливаются? Если ответа нет, у вас есть DRP и нет BCP. Восстановление даже по самому оптимистичному сценарию занимает часы, и все это время бизнес должен как-то работать: принимать заявки на бумаге, обслуживать клиентов в резервном контуре, переводить нагрузку в другой офис.
Вопрос второй. Кто и что говорит клиентам, сотрудникам и регулятору? Коммуникации в кризисе целиком лежат в BCP. Ни один технический регламент этого не описывает, а именно здесь чаще всего происходит второй, репутационный, ущерб.
Вопрос третий. Что делать, если ИТ вообще ни при чем? Пожар на складе, недоступность офиса, уход ключевого сотрудника, отказ единственного поставщика, блокировка платежей контрагенту. DRP на такие сценарии не отвечает по определению, а на них приходится существенная часть реальных нарушений непрерывности.
Обратная ситуация встречается реже, но тоже бывает: компания написала красивый BCP с процессами и коммуникациями, а в нем нет ни одного технического норматива. При инциденте выясняется, что бизнес ждет восстановления за два часа, а резервное копирование настроено раз в сутки и физически не позволяет уложиться. Поэтому оба документа делаются в связке, и целевые сроки в них должны совпадать.
Один инцидент, разложенный по ролям
Пятница, 19:40. Шифровальщик поражает файловые серверы и часть прикладных систем компании. Смотрим, какой документ работает в каждый момент.
| Время | Что происходит | Какой документ работает |
|---|---|---|
| 19:40 | Мониторинг фиксирует аномалию, дежурный администратор видит недоступность систем | Регламент мониторинга, затем DRP |
| 19:55 | Подтверждено шифрование. Принимается решение изолировать сегменты сети | DRP и план реагирования на инциденты информационной безопасности |
| 20:10 | Активируется план непрерывности, собирается кризисный штаб, назначается руководитель реагирования | BCP, раздел порядка активации |
| 20:30 | Критичные процессы переводятся на обходные схемы: прием заявок по телефону и в бумажной форме, ручная сверка | BCP, карты действий по сценариям |
| 21:00 | Клиентам и партнерам уходит первое сообщение, готовится позиция для СМИ, уведомляется регулятор | BCP, раздел коммуникаций |
| Ночь | Восстановление систем из резервных копий, проверка целостности данных, оценка глубины потери | DRP |
| Суббота | Поэтапный возврат процессов в штатный режим, сверка данных, введенных в обходном режиме | BCP, раздел возврата к нормальной работе |
| Понедельник | Разбор инцидента, фиксация фактического времени простоя и потерь, обновление обоих планов | BCM как система |
Обратите внимание, что DRP работает первым и последним, а всю середину, когда компания фактически живет без систем, держит BCP. Именно этой середины обычно и нет в компаниях, где непрерывностью занимается только служба информационных технологий.
RTO, RPO, MTPD и MBCO
Четыре метрики, из-за которых чаще всего расходятся ожидания бизнеса и возможности техники.
RTO, целевое время восстановления. За сколько процесс или система должны вернуться в работу. Ставится бизнесом на основании расчета, а не техническими специалистами по остаточному принципу.
RPO, целевая точка восстановления. Какой объем данных допустимо потерять. Измеряется во времени: RPO в четыре часа означает, что при аварии компания готова потерять данные за последние четыре часа работы. Эта метрика напрямую определяет частоту резервного копирования и стоимость решения.
MTPD, максимально допустимый период нарушения. Срок, после которого ущерб становится неприемлемым, например компания теряет лицензию или ключевого клиента. RTO всегда должен быть меньше MTPD, иначе план бессмысленен.
MBCO, минимально допустимый уровень услуг. Не «работаем или нет», а какой объем услуг компания обязуется поддерживать в кризисном режиме. Например, обслуживание не менее сорока процентов обычного потока платежей. Именно эта метрика превращает план из бинарного в управляемый.
Кто за что отвечает
| Роль | BCP | DRP |
|---|---|---|
| Правление, совет директоров | Утверждает план и допустимый уровень риска, выделяет ресурсы | Утверждает бюджет на резервирование |
| Владелец процесса | Задает RTO и MBCO, описывает обходные схемы, принимает решение об активации | Формулирует требования к системам |
| Служба непрерывности или управления рисками | Методология, координация, BIA, тестирования, отчетность | Проверяет согласованность технических сроков с бизнесовыми |
| Информационные технологии | Участвует как исполнитель | Полный владелец документа и процедур восстановления |
| Информационная безопасность | Сценарии атак, требования к изоляции и восстановлению | Проверка целостности данных и отсутствия повторного заражения |
| Коммуникации и связи с общественностью | Шаблоны сообщений, работа со СМИ и клиентами | Не участвует |
| Внутренний аудит | Проверяет, что план тестируется и обновляется | Проверяет фактические восстановления из копий |
Российские названия, ПОНиВД и план ОНиВД
В российской регуляторной практике те же документы называются иначе. Банк России использует термин ОНиВД, обеспечение непрерывности и восстановления деятельности, а главный документ называется ПОНиВД. По содержанию это тот же BCP, но с обязательным составом разделов, привязкой к технологическим процессам с заданными пороговыми значениями и надзорной отчетностью.
Практическое следствие простое. Если компания поднадзорна Банку России, действующий BCP обычно не переписывают с нуля, а достраивают до требований положения: добавляют перечень технологических процессов, целевые показатели операционной надежности, порядок фиксации инцидентов и программу тестирований. Подробный разбор требований и структуры — в материале ОНиВД и ПОНиВД, требования Банка России.
Встречается и обратная путаница: подрядчики банка получают в договоре требование «предоставить ПОНиВД» и не понимают, что от них хотят, хотя у них уже есть работающий план непрерывности под другим названием.
Пять частых ошибок
Считать DRP достаточным. Самая распространенная. Компания заказывает план аварийного восстановления, закрывает вопрос «у нас есть план» и обнаруживает пробел только во время реального инцидента.
Ставить RTO без расчета. Цифра берется из общих соображений, а не из анализа воздействия на бизнес. В результате либо компания переплачивает за резервирование процессов, простой которых терпим, либо не резервирует то, что действительно критично.
Разные сроки в BCP и DRP. Бизнес записал два часа, техника обеспечивает восемь. Расхождение обнаруживается на первом же тестировании, если тестирование вообще проводится.
Забыть про неинформационные сценарии. Недоступность помещения, потеря ключевого сотрудника, отказ поставщика. Эти сценарии не имеют технического решения и требуют организационных договоренностей, подготовленных заранее.
План без владельца. Документ есть, но у него нет конкретного ответственного лица, поэтому он не обновляется и устаревает за год.
Частые вопросы
BCP и DRP — это одно и то же? Нет. BCP описывает, как компания продолжает работать в целом: процессы, люди, поставщики, коммуникации с клиентами. DRP описывает восстановление информационных систем и данных. DRP обычно входит в BCP как техническая часть.
Как расшифровывается BCP? Business Continuity Plan, план непрерывности бизнеса. В терминологии Банка России тот же документ называется ПОНиВД.
Как расшифровывается DRP? Disaster Recovery Plan, план аварийного восстановления. Иногда встречается написание DR-план.
Что такое BCM простыми словами? Управление непрерывностью бизнеса. Это система, которая заранее определяет, какие процессы нельзя останавливать, сколько времени компания может без них прожить и что конкретно делают люди, когда процесс встал.
Что делать раньше, BCP или DRP? Сначала анализ воздействия на бизнес, из него становятся понятны критичные процессы и допустимые сроки. Затем BCP, задающий требования. DRP пишется под уже известные требования, иначе технические сроки берутся с потолка.
Как BCM связан с информационной безопасностью? Информационная безопасность предотвращает и обнаруживает атаку, BCM обеспечивает работу компании, если атака удалась. Это соседние функции с общими сценариями, подробнее в материале BCM и защита данных.
Нужен ли BCP небольшой компании? Нужен, но в объеме нескольких страниц. Критичных процессов у малого бизнеса немного, и план по ним пишется за один рабочий день. Отсутствие плана обходится дороже.
Что такое планы BCP/DRP? Это пара документов: план непрерывности бизнеса описывает, как компания продолжает обслуживать клиентов во время сбоя, план аварийного восстановления — как возвращаются к жизни системы и данные. В зрелой системе второй входит в первый отдельным разделом.
DRP это часть BCP? Да, в большинстве методологий именно так. План восстановления решает техническую задачу внутри более широкой задачи непрерывности. Обратное неверно: восстановив серверы, компания еще не обязательно обслуживает клиентов.
Что такое стресс-тест BCP? Проверка плана в условиях, близких к предельным: одновременно отказывают несколько зависимостей, часть людей недоступна, время ограничено. Цель не пройти проверку, а найти место, где план ломается.
С чего начать непрерывность бизнеса
13 вопросов и 5 минут покажут уровень готовности. Дальше два пути: разобраться самому в программе или построить систему с нами.
