Обеспечение непрерывности бизнеса и восстановление после сбоев
Сегодня многие компании начинают задумываться о планировании непрерывности бизнеса (Business Continuity Planning) и восстановлении после сбоев (Disaster Recovery Planning). Эффективная система управления непрерывностью бизнеса позволит минимизировать денежные потери в случае реализации угрозы прерывания бизнеса. Банковским же организациям необходимо выполнять требования Положения 242-П «Об организации внутреннего контроля». В настоящей заметке я рассмотрю основные этапы создания эффективной системы управления непрерывностью бизнеса и ее организационную структуру.
Как создается система управления непрерывностью бизнеса?
У каждой компании свой путь к эффективной системы управления непрерывностью бизнеса, который зависит от вида деятельности, размера организации, корпоративной культуры и многих других факторов. Рассмотрим основные шаги проекта по внедрению
полноценной системы управления непрерывностью бизнеса.
Шаг 1. Оценка рисков
Первым шагом на пути к обеспечению непрерывности бизнеса является создание в компании процесса по идентификации угроз, которые могут оказать столь негативное влияние на бизнес компании.
Перечень угроз для каждой компании будет индивидуальным, но некоторые угрозы будут актуальны для многих компаний.
Приведу примеры некоторых угроз:
- недоступность офиса;
- недоступность датацентра;
- массовое отравление персонала;
- и т.д.
После идентификации угроз, проводится оценка рисков (как правило, с помощью наиболее понятного и удобного способа и в результате мы получаем ТОП N рисков, с которыми нужно бороться в первую очередь.
Шаг 2. Оценка влияния прерываний на бизнес и определение требований
На этом шаге решается несколько задач, но разбивать его на отдельные шаги, как правило, нецелесообразно.
Задачами данного этапа являются:
- определение последствий прерывания процессов;
- выявление критичных бизнес-процессов;
- выявление взаимозависимости процессов;
- определение информационных систем, поддерживающих критичные бизнес-процессы;
- определение требований бизнеса к целевому времени восстановления системы (RTO – Recovery Time Objective) и целевой точки восстановления (RPO – Recovery Point Objective);
- определение требований к ресурсам, необходимым для минимального поддержания функционирования процессов (персонал, рабочие станции).
Замечание из практики
Очень часто руководители бизнес-подразделений пытаются завысить критичность процессов своего подразделения. Для того чтобы получить адекватную оценку критичности бизнес-процессов необходимо получить подтверждения оценок от руководителей более высокого уровня.
Также в ходе данного этапа формируются списки критичных сотрудников (20% тех, кто делает 80% работы), что также сталкивается с сопротивлением со стороны руководителей подразделений по понятным причинам.
Шаг 3. Оценка текущего состояния
После того, как мы поняли, какие бизнес-процессы для нас являются критичными и определили требования к информационным системам, необходимо определить, насколько эти требования выполнимы в текущих условиях.
На данном шаге мы получаем информацию о существующих проблемах, что позволит нам в ходе непосредственного планирования определить, какие решения нужно принять для выполнения требований бизнеса.
Шаг 4. Разработка нормативной документации системы управления непрерыностью бизнеса
Для того чтобы наша система управления непрерывностью бизнеса заработала, необходима разработка ряда нормативных документов. На мой взгляд, набор документации по BCP для крупной компании должен содержать:
- Политику обеспечения непрерывности бизнеса;
- План действий антикризисного комитета;
- План PR-отдела по реагированию на кризис;
- План HR-отдела по реагированию на кризис;
- Планы обеспечения непрерывности деятельности бизнес-подразделений;
- План восстановления ИТ после сбоев;
- Инструкции по восстановлению информационных систем;
- Общий план обеспечения непрерывности бизнеса и восстановления после сбоев;
- Схемы рассадки персонала
Детально содержание данных документов я рассмотрю в одной из следующих своих заметок.
Шаг 5. Внедрение контрмер
>
Для повышения устойчивости компании принимают различные решения:
- договариваются с соседями по бизнес-центру о предоставлении площадей в случае кризисной ситуации;
- территориально разносят подразделения;
- выбирают один из офисов в качестве резервной площадки;
- строят или арендуют резервные датацентры;
- и т.д и т.д.
В зависимости от требований к целевому времени восстановления может появиться необходимость внедрения различных технических решений, либо настройки существующих в соответствии с требованиями бизнеса.
Обеспечить необходимый уровень устойчивости к сбоям и скорейшее восстановление нам помогут:
- кластерные решения;
- виртуализация;
- системы резервного копирования;
- сети хранения данных;
- территориальное разнесение серверов;
- резервные каналы связи.
Сотрудники должны изучить разработанные планы и знать, что им делать в случае кризисной ситуации.
Шаг 6. Тестирование
После того, как мы определились с угрозами прерывания нашего бизнеса и приняли и внедрили в жизнь соответствующие контрмеры, нам необходимо проверить, насколько все то что мы создали, позволит нам противостоять угрозам в действительности. Для этого необходимо тестирование эффективности принятых мер.
Бывают различные виды тестирования. Можно тестировать только планы, тогда сотрудники собираются в одном помещении и имитируют выполнение действий, которые они бы предприняли в соответствии с планами, а можно устроить боевое тестирование – отозвать партию продукции, остановить работу “боевого” сервера и т.п. Объем и вид тестирования выбираются, исходя из необходимости проверить работоспособность решения/плана и не нанести ущерб бизнесу.
Организационная структура
Для того, чтобы непрерывность бизнеса обеспечивалась, необходимо иметь соответствующую организационную структуру.
В ходе обычного функционирования компании, как правило, выделяется человек (очень редко отдел), который отвечает за поддержание работоспособности системы управления непрерывностью бизнеса (обновление документации, результатов анализа рисков и т.п.). Такого человека часто называют менеджером по обеспечению непрерывности бизнеса. В каждом критичном бизнес-подразделении также назначается координатор, ответственный за поддержание актуальными планов подразделений.
В случае возникновения кризисной ситуации созывается антикризисный комитет, который берет управление компанией на себя для сокращения времени реакции. Для восстановления деятельности создаются специальные команды восстановления, которые и подчиняются антикризисному комитету.
Замечание из практики
Цель создания антикризисного комитета понятна: в случае кризисной ситуации очень важна малая скорость реакции, и поэтому необходимо сосредоточивание власти у довольно малой группы руководителей. Таким образом, если обычно компания управляется десятью директорами, то в случае кризисной ситуации, управление может осуществляться 2-3-мя топ-менеджерами. Понятно, что здесь появляются политические вопросы, в которые консультанты не любят вмешиваться, и иногда антикризисный комитет просто полностью дублирует исполнительный орган управления компании, что, на мой взгляд, не оправдано.
Продолжение следует.
в целом все правильно, Анализ рисков->Создание->Тестирование…по поводу риск менеджмента:>> массовое отравление персонала;особо улыбнуло:)
А отчего, кстати, BIA после RA? У BCI и BSI наоборот.(Во я шифровку написал!)
to Dmitry: Ну если смущает отравление, то его можно заменить на какой-нибудь вид гриппа. 😉 to Ригель: Все просто: первоначальный анализ рисков позволит определить наиболее вероятные сценарии, ведущие к прерыванию бизнеса. Эти сценарии зададут тон всему планированию. В ходе же 2-го шага (его уже нельзя назвать BIA в чистом виде) определяются и более детальные угрозы, способные прервать конкретный критичный бизнес-процесс, для того, чтобы в ходе разработки планов для бизнес-подразделений учесть не только глобальные катастрофы, но и локальные неприятности.
Не понял: Вы теперь хотите два раза анализ рисков (шаг 1) проделывать и отказываетесь от оценки влияния на бизнес (шаг 2)?
Не совсем, на первом шаге проводится анализ рисков достаточно высокого уровня (например, риск потери датацентра, риск потери офиса и т.п.), а в ходе второго этапа идет анализ более низкоуровневых рисков (например, риск недоступности определенного канала связи, риск недоступности аутсорсера). То есть, в ходе второго этапа анализ рисков продолжается, но уже более детальный. Шаг 2 не является в чистом виде BIA, он его просто включает. Это делается для того, чтобы не отрывать от бизнеса руководителей подразделений по несколько раз (для BIA, сбора требований к ИТ и резервной площадке, идентификации рисков для критичных процессов).
Александр, при BIA должны (внимание!) времена оцениваться, в этом и суть его. Вы же ведь описание-то правильное привели (из BCIного гайдбука, видимо).
Да, Ригель, Вы совершенно правы. Одной из задач второго шага является "выявление критичных бизнес-процессов". Это происходит следующим образом:Определяются градации критичности процессов (например, "критичный" — максимальное время прерывания процесса — 1 или 3 дня при "серьезном" воздействии прерывания на бизнес день и т.д.). Воздействие может оцениваться по различным его видам (финансовые потери, ущерб имиджу, проблемы с регуляторами и т.д.) Таким образом мы определяем критичность процесса по допустимому времени прерывания и тяжести последствий прерывания.Затем для информационных систем, поддерживающих критичные процессы определяем RTO и RPO.Все это намешано во втором шаге, так как позволяет минимизировать затраты. Можно подготовить одну анкету со взаимосвязанными вопросами по RA, BIA, требованиям к ИТ и ресурсам и т.д. и собрать всю важную информацию за одну встречу.Таким образом и методологии (GPG и BS25999) соблюдаются и время сотрудников расходуется разумно.
BIA надо делать на первом этапе, иначе анализ рисков ИБ вполне может стать огромной и затянутой задачей.
to Nikita: cмотря, как его делать. Очень трудоемко делать BIA для всех процессов или подразделений. Поэтому сначала проводится высокоуровневый анализ рисков, а вместе с BIA уже более детальный.