В данном контексте речь идет о форс-мажоре такой силы, когда возникает существенный риск прерывания деятельности организации. Примерами таких реализовавшихся рисков могут стать атака террористов (например, авиатараны на башни-близнецы в США), блэкаут (авария в энергосистеме в 2005 году и ледяной дождь в 2010 году в Москве), землетрясение или цунами (так называемое Великое землетрясение Восточной Японии в 2011 году, ураган «Катрина» в США в 2005 году и т.д.). Понятно, что масштабы бедствий бывают разными, для относительно небольших компаний критичными могут стать и проблемы гораздо меньших масштабов: пожары в офисе или ЦОДе, экскаватор строителей, повредивший кабель связи, или, к примеру, митинги валютных ипотечников у входа в офис банка, парализовавшие работу всей кредитной организации.
Что делать с IT-инфраструктурой во время инцидента?
С одной стороны, понятно, что надо иметь планы на случай нештатных ситуаций. И они, действительно, у многих есть: на случай пожара, например, проводятся учения и тренировки персонала. Но вот беда: если сейф из бухгалтерии по плану с трудом, но вынести можно, то что делать с IT-инфраструктурой? Проблема заключается в том, что современный бизнес — это во многом и есть IT: например, банковские платежные системы или сервисы ДБО. И даже если эта инфраструктура территориально распределена, нет гарантии, что резервные узлы выдержат резко увеличившуюся нагрузку и не выйдут из строя.
Наверное, важность вопроса, до какой степени IT-инфраструктура стала критичной для непрерывности банковского бизнеса, впервые стал понятен после атаки на башни-близнецы в Нью-Йорке, в которых было довольно много офисов финансовых организаций. Часть из них сумели восстановить свои сервисы довольно оперативно благодаря резервным площадкам, налаженным технологиям управления непрерывностью бизнеса (Business Continuity Management, BCM) и грамотным планам восстановления IT-систем (Disaster Recovery Plan, DRP).
Как следствие события 11 сентября 2001 года дали мощный импульс к обязательному наличию BCM в финансовой сфере США. Страны Азии, где природные катаклизмы — не редкость, также активно включились в эти процессы.
Надеетесь на авось — получите стандарты
Но вот прошло 15 лет. Появились совершенно новые риски, например атаки киберкриминала. Что же изменилось? Насколько нам интересны чужие ошибки? Согласно совместному исследованию IBM и журнала Economist, посвященному проблемам рисков и устойчивости бизнеса, в мире только 37% большого бизнеса имеет налаженные BCM и DRP. А что касается России, то показателен в этом плане пример блэкаута в Санкт-Петербурге в 2010 году. Казалось бы, наученные горьким московским опытом банкиры и многие другие службы, тем не менее показали себя плохо подготовленными: банкоматы не работали, многие отделения банков не были открыты и т.д. Почему? Все хотят сэкономить и надеются на авось.
Так каким образом банк может противостоять такого рода воздействиям или, по крайней мере, минимизировать возможный ущерб для бизнеса? При этом в условиях текущей финансовой турбулентности критично важно найти бюджетные пути. Где их искать?
Для начала необходимо обратиться к нормативным актам и лучшим мировым практикам в этой сфере, собранным, например, международной организацией Business Continuity Institute (BCI), которая определяет BCM и значительно расширяет список привычных угроз, вплоть до действий внутренних инсайдеров и взломов информационных систем хакерами. Кроме того, часть методологий содержится в CobiT (Control Objectives for Information and Related Technologies, «Задачи управления для информационных и смежных технологий»), ITIL (IT Infrastructure Library — библиотека инфраструктуры информационных технологий).
Довольно много можно почерпнуть в ISO 27001 — международном стандарте по информационной безопасности. Самого пристального внимания заслуживает стандарт ISO 22301, посвященный практикам BCM. Что касается России, то ЦБ довольно плотно регулирует описываемые практики в Положении 242-П, стандартах безопасности СТО БР ИББС-1.0-2006, ГОСТ Р ИСО/МЭК 27001-2006 и некоторых других.
С больной головы на IT
Анализируя требования к BCМ и DRP, приходим к тому, что BCМ направлен на поддержку бизнес-активности и бизнес-функций, в то время как DRP — на поддержание бесперебойной работы информационных систем и сохранности данных. В то же время BCМ ориентирован на предупреждение проблем, а DRP — на их решение; BCМ охватывает вопросы восстановления бизнеса, а DRP направлен на восстановление IT-инфраструктуры после сбоев.
Кроме того, становится понятно, почему соответствие нормативным актам обходится банкам все дороже: это усиление зависимости бизнеса от информационных технологий, а также усложнение собственных корпоративных IT-инфраструктур. Неудивительно, что в упомянутом исследовании IBM говорится о том, что сегодня уже в 40% случаев обеспечение непрерывности бизнеса «сваливают» на IT-службы банков, забывая при этом о лучших практиках, которые говорят о том, что BCM — комплексный подход, затрагивающий буквально все процессы, происходящие в современном банке.
Таким образом, все чаще можно наблюдать тенденцию, когда инициатива внедрения процессов непрерывности бизнеса от топ-менеджмента переходит к IT. К сожалению, в России всего несколько банков с практически неограниченным IT-бюджетом, остальным же приходится серьезно экономить. Понятно, что люди из IT имеют гораздо более объемное представление о том, какие существуют зависимости между теми или иными бизнес-процессами и приложениями, их обслуживающими, нежели высшие руководители. Обладая этими весьма ценными знаниями, можно попытаться добиться соответствия (как на бумаге, так и реального), сэкономив при этом и так небольшой бюджет. Так какие есть варианты действий?
Экономить за счет оптимизации
Как показывает практика, на текущее время процесс обеспечения непрерывности в банках колеблется от «лишь написанных планов BCM и DRP для ЦБ» до «практически все есть, но нет ресурсов регулярно обновлять перечень угроз и рисков. Часто забываем включить процесс в культуру организации (управление изменениями)».
Это показывает, что полный процесс включает в себя несколько шагов, на каждом из них можно сэкономить вплоть до игнорирования работ по какому-то пункту. Но чем ближе к высшему уровню максимального соответствия, тем бесполезнее окажутся инвестиции в предыдущие.
«Какие мероприятия действительно нужны, зависит от того, как сам банк оценивает свою стратегию поведения в чрезвычайных ситуациях (в рамках нормативов регулятора), — рассказывает Роман Лукин, руководитель группы IT-аудита и консалтинга компании “Инфосистемы Джет”. — Причем нужно знать, как эта стратегия будет эволюционировать, что в ней должно появиться (или не появиться) в будущем. Имея этот документ на руках, можно на уровне руководства банка строить всеобъемлющую концепцию управления конкретными рисками, а не вкладывать деньги в то, в чем нет необходимости. Кроме того, здесь самое время заняться командой, которая будет решать текущие задачи».
Понятно, что параллельно или чуть раньше необходимо озаботиться аудитом ресурсов, поддерживающих бизнес-процессы организации. Требуется определиться с угрозами, от которых BCM будет защищать на данном шаге внедрения. Например, учитываем только IT-приложения, но не трогаем персонал, работающий с ними.
После этой работы начинается «творческий процесс», а именно выбор того, как именно будут обеспечены BCM и DRP с точки зрения технических решений. Будет ли построен для этого резервный ЦОД или операционный центр для персонала? А может, идти в ногу со временем и использовать виртуальные ЦОДы или облака, а также арендовать в подходящем технопарке временный офис, пока центральная площадка непригодна для работы?
«Не углубляясь в технические подробности, можно сконцентрироваться только на аспекте DRP, что позволит не строить дорогостоящие решения по синхронному резервному копированию, — отмечает Роман Лукин. — Кто-то допускает некоторый уровень потерь информации и(или) уменьшение скорости восстановления. Все зависит от стратегии и уже имеющихся решений. На этом этапе есть масса возможностей для оптимизации — нужно найти свою золотую середину».
Немного бумажной работы, тестов и изменений в корпоративной культуре
Обычно на этом, четвертом, этапе эксперты рекомендуют определиться с политикой непрерывности бизнеса, созданием реестра ролей и должностных обязанностей, концепцией управления процессом непрерывности, реестром рисков, матрицей зависимостей бизнеса от IT, таблицей потерь, планами управления инцидентами, стратегией непрерывности деятельности бизнес-подразделений, планами аварийного восстановления и тестирования. Правда, мало кто в состоянии осилить этот неполный список, но люди сидят и пишут…
Лучшие практики заключаются в том, что все эти бумаги не обязаны появляться одновременно! Первой должна быть разработана небольшая по объему, но «краеугольная» по значению политика непрерывности бизнеса. А вот реестр ролей и должностных обязанностей, служащий для собственного понимания организацией, какие специалисты требуется и что им предстоит делать, может постепенно дополняться по мере необходимости. Концепция управления процессом непрерывности, отвечающая за порядок расширения и сужения рамок BCM, разрабатывается банком с учетом того, что организация может ответить на вопросы самостоятельно, не затрачивая большого количества времени и сил.
Что касается реестра рисков, специалисты советуют выбирать какой-то конкретный риск, а не брать сразу весь их спектр. Построив процесс управления непрерывностью для защиты от него, будет гораздо проще расширить процесс и на другие риски. Аналогичный подход применим и для построении матрицы зависимости бизнеса от IT. На первых порах достаточно разработать только часть матрицы, описывающую один бизнес-процесс.
Не будем углубляться во всю эту бумажную бюрократию, а отметим, что не надо идти «на ура, до победного конца», а стоит использовать народную мудрость «умный в гору не пойдет»: так вот, умный обратится к экспертам-консультантам и «обойдет гору». Иными словами, можно и нужно подготовку документов распределить по этапам и изменять их полноту, минимизируя затраты на их подготовку.
Для того чтобы убедиться в том, что все сделано правильно, существует этап тестирования. Наиболее ресурсоемким видом тестов является «настольный». Он очень полезен для проверки полноты существующих документов, вовлечения сотрудников и руководителей в тематику BCM и DRP, для приобретения драгоценного опыта и выработки практических навыков в нештатных ситуациях.
На «настольных» тестах экономить, как правило, — себе дороже. Но вот совместить проведение тестирования процедур DRP с регулярными регламентными работами, например с установкой обновлений ПО или со сменой версий, можно. Такой вариант выгоден с экономической точки зрения, а навредить бизнесу тестами в это время трудно.
Завершается цикл создания BCM внедрением процессов управления изменениями и непрерывностью в культуру организации. Это не ресурсоемкий этап, но его сложность заключается в том, что данный шаг не может быть единовременным. Усилия по внедрению должны предприниматься на регулярной основе. В рамках процесса должны возникнуть новые должностные обязанности, возложить которые резонно на людей, управляющих рисками, или CIO. Последнее выгодно с той точки зрения, что информационные процессы обычно наиболее полно описаны, кроме того, как ни крути, они являются составной частью бизнес-процессов и их придется включать в процесс управления непрерывностью. Так почему с них не начать?
Делая выводы, необходимо отметить, что внедрение BCM и DRP, безусловно, вещь полезная. К сожалению, автоматизация бизнеса вызывает зависимость от IT, но никому не хочется при любом сбое систем вне зависимости от причины останавливать бизнес-процессы на определенное время с непредсказуемыми эксцессами и потерями данных после восстановления. Стимулируют внедрение и регуляторы рынка.
Да, необходим бюджет. Однако, как показывают лучшие мировые и отечественные практики в виде международных стандартов и положений, есть разные варианты оптимизации расходов при получении достойного результата. Но получить экономию можно только в том случае, когда есть знание, что и как делать, а также при непрерывном, как того и требуют стандарты, цикле работ. Отдельный вопрос: делать ли все самим на свой страх и риск или объединить усилия с независимыми консультантами.
Начать дискуссию