"Построение комплексной системы управления непрерывностью бизнеса"

АЛЕКСАНДР ШАБАЛИН,
группа компаний 4х4

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

Часто компании ограничиваются разработкой планов аварийного восстановления или непрерывности бизнеса (disaster recovery и business continuity). Такие планы могут использоваться как шпаргалки при наступлении чрезвычайных ситуаций, будут полезны при прохождении проверок или аудитов, но не позволят быстро и эффективно восстановить бизнес функции компании.

Построение комплексной системы управления непрерывностью бизнеса требует большой подготовительной работы, в основном со стороны бизнес-подразделений компании. В первую очередь нужно определиться с перечнем ключевых процессов, причем желательно при создании такого перечня принимать во внимание не только текущую ситуацию, но и перспективную, основанную на стратегии развития компании. Полученные бизнес-процессы ранжируются по степени их критичности для компании (финансовые, репетиционные потери, упущенная выгода и т. д.), и для каждого из процессов определяются:
• RTO (recovery time objective) – время, за которое необходимо восстановить процесс,
• RPO (recovery point objective) – максимальный период, за который может быть потеряна информация при восстановлении,
• MTPoD (maximum tolerable period of disruption) – максимальное время простоя бизнес-процесса, которое не повлечет за собой неприемлемых для компании последствий,
• минимальный уровень сервиса (ИТ и люди), необходимый для функционирования бизнес-процесса.

Такие параметры, как RTO, RPO, MTPoD, и минимальный уровень сервиса лучше всего смогут определить люди, ответственные непосредственно за определенный бизнес-процесс. А вот ранжировать бизнес-процессы по значимости для компаний лучше всего сможет ее руководитель, поэтому желательна его вовлеченность в процесс. Нормальная ситуация, что при определении этих параметров каждый ответственный за определенный бизнеспроцесс будет стараться «перетянуть одеяло на себя» и доказать, что его процесс самый важный, восстановить его надо в полном объеме, очень быстро и потеря данных при этом неприемлема. Но искать компромисс в любом случае придется, так как зависимость финансовых вложений от RTO/RPO не линейная, а скорее экспоненциальная.

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

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

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

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

Как было сказано выше, «все и сразу» зарезервировать очень дорого и зачастую нереализуемо. Поэтому необходимо на начальных этапах совместно с представителями бизнес-подразделений определить вектор движения создаваемой системы управления непрерывностью бизнеса – а именно что и как реально нужно резервировать, исходя из стоимости этих решений и вероятных последствий отказа.

Часто повторяющаяся ошибка – при определении причин вероятного прерывания бизнес-процесса все внимание сосредотачивается на сбоях ИТ-инфраструктуры. Да, это наиболее вероятная причина прерывания бизнеса, но далеко не единственная. Не нужно забывать о людях, внезапное отсутствие которых может остановить бизнес-процесс (забастовка, недовольство персонала). Для некоторых регионов актуальными могут быть природные катаклизмы или техногенные катастрофы. Вероятен конфликт с собственником здания, в результате которого доступ сотрудников в офис может быть попросту заблокирован. Эти и другие источники проблем, а также вероятные последствия от их реализации необходимо учитывать при построении системы управления непрерывностью, чтобы быть готовым не только к инфраструктурному сбою.

В завершение хочется сделать акцент на слове «управление» в названистатьи. Управление подразумевает то, что по мере изменения бизнеса компании, следом за ним должна корректироваться и система обеспечения его непрерывности. Для описания процесса управления нашей системой лучше всего подходит цикл Деминга (P-D-C-A).

Периодически (например, раз в полгода), а также после каждого изменения в системе она должна тестироваться в условиях, максимально приближенных к реальным. И корректироваться на основе этих тестов. Вряд ли владельцы бизнеса разрешат раз в полгода «дергать рубильник», чтобы реально прерывать бизнес-процессы и репетировать их восстановление. В этом случае частично теряется смысл создания такой системы – мы строим ее для того, чтобы обеспечить непрерывность бизнеса, а сами вместо этого регулярно требуем его прерывания. Но другой стороной этой медали является то, что персонал, ответственный за восстановление бизнес-функции должен точно понимать свою роль в процессе и знать, что и в какой последовательности он должен делать. Надо находить компромисс, так как поверхностное тестирование не всегда показывает все недостатки в алгоритме восстановления.

В планах-алгоритмах восстановления не должно быть отсылок «в никуда», и у каждой роли должен быть дублер. Например, для восстановления бизнес-функции нам нужен исходный файл программы, месторасположение которого, как выясняется в ходе тестирования, знает только один человек, который сейчас в отпуске/болеет/уволился – одним словом оперативно недоступен. Согласитесь, гораздо лучше об этом узнать во время тестирования, чем во время реального сбоя, когда каждая минута простоя может стоить компании больших денег. Регулярные тестирования процесса восстановления позволяют выявить, в том числе, и эти нюансы.

Итак, процесс построения комплексной системы управления непрерывностью бизнеса должен проходить через всю компанию, а не ограничиваться участием подразделений ИТ и ИБ. Этот процесс не должен останавливаться – создаваемая система должна постоянно совершенствоваться и изменяться вслед за изменениями в компании, и тогда она поможет сэкономить гораздо больше, чем было в нее вложено. По сути, она как огнетушитель – реальная необходимость очевидна, когда нужно что-то потушить.