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

1. RTO и RPO наугад

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

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

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

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

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

Ну вы поняли

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

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

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

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

В стандарте 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-планы

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

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

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

В заключение

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

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

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

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

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