Хабрахабр

ТОП-11 ошибок при разработке BCP

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

1. RTO и RPO наугад

Самая важная ошибка из тех, которые мне встречались, заключается в том, что время восстановления (RTO) берётся с потолка. Ну как с потолка – например, есть некие цифры двухлетней давности из SLA, который кто-то принес с предыдущего места работы. Почему так делают? Ведь по всем методикам нужно сначала проанализировать последствия для бизнес-процессов, и на основе этого анализа вычислить целевое время восстановления и допустимую потерю данных. Но делать такой анализ иногда долго, иногда затратно, иногда не очень понятно, как, — нужное подчеркнуть. И первое, что многим приходит в голову: «Мы же все взрослые люди и понимаем, как работает бизнес. Не будем напрасно тратить время и деньги! Давай возьмём плюс-минус, как это должно быть. Из головы, используя пролетарскую смекалку! Пусть RTO будет равно двум часам».

Когда приходишь к руководству за деньгами на мероприятия по обеспечению требуемых RTO/RPO с некими цифрами, оно всегда требует обоснования. К чему это приводит? А ответить-то и нечего. Если обоснования нет, то возникает вопрос: откуда вы ее взяли? В итоге доверие к вашей работе теряется.

И обоснование длительности RTO — вопрос денег, причём очень больших. Кроме того, иногда эти два часа восстановления работоспособности стоят миллион долларов.

И если вы не можете внятно это объяснить, то и у них не будет доверия ни к вам, ни к вашему документу. И наконец, когда вы придёте со своим BCP и/или DR-планом к исполнителям (которые непосредственно будут бегать и размахивать руками в момент аварии), они зададут аналогичный вопрос: откуда взялись эти два часа?

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


Ну вы поняли

2. Лекарство от всего

Некоторые считают, что план BCP разрабатывается для защиты всех бизнес процессов от любых угроз. Недавно на вопрос «От чего мы хотим защищаться?» я услышал ответ: «От всего и побольше».

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

Например, огромный Х5 Retail Group начал заниматься обеспечением непрерывности с двух ключевых бизнес-процессов (мы писали об этом здесь). Нельзя защитить одним BCP всю компанию целиком, особенно большую. А огородить всю компанию одним планом просто нереально, это из разряда «коллективной ответственности», когда ответственны все и не ответственен никто.

В ней описывается, что мы будем защищать и от чего. В стандарте ISO 22301 есть понятие политики, с которой, собственно, и начинается процесс непрерывности в компании. Если прибегают люди и просят добавить того-сего, например:

— А давайте добавим в BCP риск того, что нас хакнут?

Или

— Вот у нас недавно во время дождя залило последний этаж – давайте добавим сценарий, что делать на случай затопления?

То сразу отсылайте их к этой политике и говорите, что мы защищаем конкретные активы компании и только от конкретных, заранее согласованных угроз, потому что именно они сейчас находятся в приоритете.

Потому что защита компании — это немалые деньги. И даже если предложения об изменениях действительно целесообразны, то предлагайте учесть их в следующей версии политики. Мы рекомендуем пересматривать политику непрерывности бизнеса компании один раз в год или сразу после значительных изменений структуры компании или внешней конъюнктуры (да простят меня читатели за такие слова). Так что все изменения BCP плана должны проходить через бюджетный комитет и планирование.

3. Фантазии и реальность

Очень часто бывает, что при составлении плана BCP авторы описывают некую идеальную картину мира. Например, «у нас нет второго ЦОД, но мы напишем план так, как будто он у нас есть». Или у бизнеса пока нет какой-то части инфраструктуры, но сотрудники все равно внесут ее в план в надежде, что в будущем она появится. А затем компания будет натягивать реальность на план: строить второй ЦОД, описывать прочие изменения.


Слева — инфраструктура, соответствующая BCP, справа — реальная инфраструктура

Написать план BCP — это означает потратить деньги. Всё это ошибка. По нему невозможно восстановиться, его невозможно протестировать. Если вы напишете план, который не будет работать прямо сейчас, то вы заплатите за очень дорогую бумагу. На это может уйти не один год. Получается работа ради работы.
Написать план можно довольно быстро, а построить резервную инфраструктуру, потратить деньги на все решения по защите — это долго и дорого. Зачем нужен такой план? И может оказаться так, что план у вас уже есть, а инфраструктура под него появится через два года. От чего он вас защитит?

Получается из разряда: «увидев в тайге медведя, необходимо развернуться в противоположную от медведя сторону и бежать со скоростью, превышающей скорость медведя. Еще из разряда фантазий, когда рабочая команда по разработке BCP начинает додумывать за экспертов, что они должны делать и за какое время. В зимние месяцы необходимо заметать следы».

4. Вершки и корешки

Четвертая по важности ошибка заключается в том, что план делают либо слишком поверхностным, либо слишком подробным. Нужна золотая середина. План не должен быть слишком подробным, для идиотов, но и не должен быть слишком общим, чтобы не получилось нечто такое:


На изи вообще

5. Кесарю — кесарево, слесарю — слесарево

Следующая ошибка проистекает из предыдущей: в один план нельзя вместить все действия для всех уровней управления. BCP планы разрабатываются обычно для крупных компаний с большими финансовыми потоками (кстати, согласно нашему исследованию, в среднем 48% крупных российских компаний сталкивались с нештатными ситуациями, влекущими за собой значительные финансовые потери) и многоуровневой системой управления. Для таких компаний не стоит пытаться вместить все в один документ. Если компания большая и структурированная, то план должен иметь три отдельных уровня:

  • стратегический уровень — для высшего руководства;
  • тактический уровень — для управленцев среднего звена;
  • и операционный уровень — для непосредственных исполнителей на местах.

Например, если речь идёт о восстановлении упавшей инфраструктуры, то на стратегическом уровне принимается решение об активации плана восстановления, на тактическом уровне могут быть описаны процедуры процесса, а на операционном — инструкции по вводу в строй конкретных элементов оборудования.


BCP без бюджета

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

6. Ролевые игры

Ещё одна ошибка при составлении плана BCP: не нужно прописывать в плане конкретные фамилии, адреса почты и прочие контактные данные. В тексте самого документа нужно указывать лишь обезличенные роли, а присваивать этим ролям фамилии ответственных за конкретные задачи и перечислять их контакты нужно в приложении к плану.

Почему?

И если всех ответственных и их контакты вы пропишете в тексте плана, то его придётся постоянно менять. Сегодня большинство людей каждые два-три года меняют работу. А в крупных компаниях, и тем более государственных, каждое изменение любого документа требует кучи согласований.

Не говоря уже о том, что если произойдёт ЧП, и вам придется судорожно листать план и искать нужный контакт, то потеряется драгоценное время.

Еще одна подсказка: можете использовать системы автоматизации обновления плана. Лайфхак: при изменении приложения часто даже не требуется его утверждать.

7. Отсутствие версионности

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


Никому уже не разобраться

8. С кого спрашивать?

Часто в компаниях нет ответственного за план BCP и нет отдельного подразделения, которое отвечает за непрерывность бизнеса. Эта почетная обязанность возлагается на ИТ-директора, его заместителя или по принципу «ты же занимаешься информационной безопасностью, вот тебе еще и BCP вдобавок». В результате план разрабатывают, согласуют и утверждают все подряд, сверху донизу.

Такого могут и не назначить. А кто отвечает за хранение плана, обновление, и пересмотр информации в нем? Брать для этого отдельного сотрудника — расточительно, а нагрузить дополнительной обязанностью одного из имеющихся — можно, конечно, потому что все сейчас стремятся к эффективности: «Давайте на него ещё фонарь повесим, чтобы он и ночью мог косить», но надо ли?

Ищем ответственных за BCP через два года после его создания

Никто его не тестирует, не поддерживает его актуальность. Поэтому часто бывает так: план разработали и положили в долгий ящик покрываться пылью. Самый частая фраза, которую я слышу, когда прихожу к заказчику: «План есть, но разработан давно, тестировался ли — неизвестно, есть подозрение, что не работает».

9. Слишком много воды

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


Когда пытаешься дочитать до момента, что же все-таки делать при затоплении дата-центра

Сам план должен быть предельно конкретным: ответственный за эту задачу делает то-то, и так далее. Всю корпоративную «воду» выносите в отдельный документ.

10. За чей счет банкет?

Часто у создателей плана нет поддержки от высшего руководства компании. Но есть поддержка от руководства среднего звена, которое не управляет или не обладает необходимым бюджетом и ресурсами для организации непрерывности бизнеса. Например, ИТ-департамент создает свой план BCP в рамках своего бюджета, но ИТ-директор не видит картину в компании целиком. Мой любимый пример — это видеоконференцсвязь. Когда у генерального не работает видеоконференцсвязь, кого он выпотрошит? ИТ-директора, который «не обеспечил». Поэтому с точки зрения ИТ-директора что самое важное в компании? То, за что его постоянно «любят»: видеоконференцсвязь, которая сразу превращается в систему business-critical. А с точки зрения бизнеса — ну нет ВКС, подумаешь, поговорим по телефону, как при Брежневе…

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

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


Так выглядит ситуация, когда только у ИТ-департамента есть DR-планы

10. Без тестирования

Если есть план, его надо тестировать. Для тех, кто не знаком со стандартами, это совершенно неочевидно. К примеру, у вас везде висят таблички «аварийный выход». Но скажите мне, где у вас находится противопожарное ведро, багор, лопата? Где находится пожарный гидрант? Где должен стоять огнетушитель? А ведь все должны это знать. Нам совершенно не кажется логичным при входе в офис найти глазами огнетушитель.

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

В заключение

Некоторые компании могут проанализировать свою историю с целью понять, какие неприятности и с какой вероятностью могут произойти. Исследования и опыт говорят о том, что мы не сможем защититься от всего. Shit, рано или поздно, happens с любой компанией. Другое дело, насколько вы к этой или похожей ситуации будете подготовлены и сможете ли вовремя восстановить свой бизнес.

Нет, речь о том, что риски реализуются, а мы к этому будем готовы. Некоторые думают, что непрерывность — это про то, как устранить всевозможные риски, чтобы они не реализовались. То же самое и с планом BCP: он позволит вам восстановить бизнес настолько быстро, насколько это возможно необходимо. Солдаты тренируются для того, чтобы в бою не думать, а действовать.


Единственное оборудование, не требующее BCP

Игорь Тюкачев,
Консультант по непрерывности бизнеса
Центра проектирования вычислительных комплексов
«Инфосистемы Джет»

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть