Не все знают, с чего и когда начать воплощать планы по непрерывности бизнеса в жизнь. Я обычно говорю так: когда возможные потери выше затрат на противодействие угрозе — пора принимать меры, затраты на них будут адекватными. И наоборот. Если со стоимостью противодействия все более-менее понятно, то оценка потерь — задача нетривиальная. Я приглашаю вас за кулисы проекта по оценке влияния чрезвычайных ситуаций на бизнес (Business Impact Analysis — BIA) и разработке стратегии обеспечения непрерывности ИТ на примере крупного ритейлера. Итак, поехали.
Начало
Мы участвовали в проекте X5 Retail Group — крупнейшего ритейлера России. Компания управляет сетями «Пятерочка», «Карусель» и «Перекресток».
У нее уже была своя политика по управлению рисками прерывания деятельности, которая содержала в себе:
- страхование рисков;
- формирование антикризисного управления;
- минимизация рисков жизни и здоровью людей;
- контроль рисков управляемости бизнесом;
- подготовка планов восстановления ИТ-систем при чрезвычайных ситуациях.
В соответствии с этой политикой для централизованной ИТ-инфраструктуры необходимо было разработать планы непрерывности ИТ-сервисов и аварийного восстановления ИТ. Идеальным решением было бы построить резервный ЦОД, установить синхронную репликацию, настроить автоматизацию аварийного переезда и в час «Ч» смотреть на экране, как последовательно ИТ-системы переезжают в резервный ЦОД и загораются зеленые лампочки, сигнализируя, что опасности для бизнеса нет.
Но с учетом экономики процесса компания предположила, что адекватной мерой на случай чрезвычайной ситуации будет резервирование только самых критичных ИТ-систем, без которых магазины не смогут работать и в компании начнутся значительные финансовые потери. Возникает важный вопрос — какие именно системы и за какое время должны восстанавливаться?
ИТ-департамент заказчика определил классификацию ИТ-систем и допустимое время восстановления каждой системы. Однако позже было принято решение провести полноценную оценку влияния чрезвычайных ситуаций на бизнес компании (BIA) согласно ISO 22301 и лучшим практикам.
Объем и границы
Театр начинается с вешалки, а BIA — с определения объема работ. Для этого нужно обследовать бизнес-процессы компании, ее услуги, финансовую отчетность, взаимоотношения с партнерами, клиентами и контрагентами. Затем определить и согласовать те ключевые бизнес-процессы и услуги, которые войдут в границы проекта. От объема зависит продолжительность и стоимость BIA. При этом наш опыт подсказывает, что не стоит растягивать проект больше, чем на 9 месяцев.
В нашем случае заказчик уже определил границы, выбрав наиболее значимые для торговой деятельности бизнес-процессы.
Интервью
После того как зафиксированы границы и рамки BIA, определяется перечень заинтересованных лиц от бизнес- и других подразделений, с которыми требуется провести интервью. Очень важно собрать сведения от разных департаментов, чтобы получить объективную картину процессов в компании, понять, как они работают, получить оценку «а что будет, если…». На этом этапе мы получаем сведения, как именно бизнес-процессы зависят от ИТ и строим матрицу этих зависимостей. Также представители бизнеса и заинтересованные в бизнес-процессе стороны оценивают последствия, вероятный ущерб, возможные сценарии развития событий. Для этого мы разработали специальную анкету и опросили около 50 респондентов (представили 50 презентаций о самом проекте, провели, получили и обработали все заполненные анкеты).
Бизнес-процессы
Параллельно с интервьюированием мы описали бизнес-процессы, причем с учетом времени выполнения отдельных операций и глубиной проработки, достаточной для дальнейшего анализа. Разбиение процесса на более мелкие составляющие и конкретные операции необходимо для того, чтобы понять, как ИТ-система влияет на конкретный процесс в разное время суток и разное время года. На этом этапе важно понимать, что мы не описываем бизнес-процессы согласно ГОСТ или иной методологии. Мы не занимаемся оптимизацией бизнес-процессов и в целом не даем рекомендаций по улучшению бизнес-процессов, по крайней мере, в рамках BIA. Мы описываем бизнес-процессы в такой детализации, которая позволяет нам обосновать методику расчета потерь и оценить потери по нескольким критериям. Для графического описания использовали нотацию EPC, ARIS и MS Visio, как инструменты.
Пороги
Для того чтобы определить объективное целевое время восстановления, необходимо на берегу договориться о критериях, по которым будем оценивать ущерб, и об их пороговых значениях. При превышении данных порогов будем считать ущерб критичным, а временной интервал, при котором достигается пороговое значение, станет целевым временем восстановления. Было предложено два варианта:
- определить RTO по одному критерию — финансовые потери;
- определить RTO по трем критериям — финансовые потери, потеря репутации, потеря управляемости бизнес-процессов.
Первый вариант с одним критерием вроде бы предпочтительнее, так как любые потери условно можно перевести в деньги — главное, договориться о формуле пересчета. Но, как показывает практика, никто репутационные потери специально не пересчитывает в финансовые, и согласование такой формулы может занять неопределенное время. Было решено считать время восстановления по обоим вариантам, и на этапе презентации результатов заказчик сам определит, какой из них более объективно отражает действительность.
Забегая вперед, скажу, что при использовании первого варианта с одним критерием оказалось, что RTO по процессу «ценообразование», например, может достигать 10 дней. При расчете по второму варианту RTO не превышало 24 часов. В любом случае, управленческое решение — какие потери учитывать, а какие нет — остается за заказчиком.
Риски
Совместно с заказчиком определили перечень операционных рисков. То есть тех, которые влияют на ИТ, а те в свою очередь влияют на бизнес-процессы, которые… ну вы поняли. Этот этап важен, потому что чрезвычайная ситуация не рассматривается как сферический конь в вакууме, дескать, что же будет с Родиной и с нами, если мы потеряем ИТ. Риски разделили на глобальные и локальные. Для каждого из них определили сценарий развития и влияние на процессы компании с учетом результатов интервьюирования. Очевидно, что одна и та же ИТ-система при выходе из строя может затронуть несколько бизнес-процессов, но нас в рамках проекта жутко волновали только два процесса. Дальше мы провели оценку исков в соответствии со следующими параметрами:
- распространение угрозы;
- возможность оповещения;
- длительность воздействия;
- вероятность возникновения;
- оценочный ущерб.
По итогам нарисовали тепловую карту, где каждое приложение получило оценку того, насколько горячо бизнес мог бы обжечься во время его простоя. Допустим, за 4 часа простоя отдельных модулей SAP компания еще не получит серьезных проблем, но даже первые часы простоя кассового ПО на тепловой карте помечены огненно-красным цветом.
Нужно уточнить, что оценка рисков и дальнейшее ранжирование формируются с помощью группы экспертов и необходимы для того, чтобы определить наиболее критичные ситуации для заказчика.
Условный риск и сценарий. Пожар в ЦОД: полностью сгорела серверная комната, недоступен модуль SAP, задействованный в процессе «Пополнение». Это значит, что каждый день, пока сгоревший модуль SAP не будет восстановлен, товарный ассортимент уменьшается. В первую очередь это касается скоропортящихся продуктов, во вторую — продуктов, пользующихся массовым спросом (например, крупы и хлеб), в третью — бытовой химии. Очевидно, что такая ситуация приведет к снижению выручки в магазинах. А вот что не вполне очевидно: покупатель, который пришел за пивом и сигаретами, в случае отсутствия одного из товаров может с большой долей вероятности ничего не купить. Аналогично для процесса «Ценообразование». Если условный покупатель, который узнал о скидках в среду в 12:00, пополудни придет в магазин, а процесс «Ценообразование» не работает (то есть цены без скидок), то он:
А) не купит ничего (= финансовые потери);
Б) будет обвинять магазин в мошенничестве (= потеря репутации)
В) пожалуется регулятору (= штраф за недобросовестную рекламу).
Методика оценки потерь
Как вы, наверное, поняли из вышесказанного, чтобы посчитать даже финансовые убытки, необходимо разработать методику и формулы их подсчета, которые учитывают скидки, акции, время суток, высокий сезон (например, ажиотаж в конце декабря). Методика должна содержать описательную часть (что откуда берется и почему умножается на весовые коэффициенты), а также таблицы и графики для наглядности восприятия.
Также в методике описывается:
- как определяется время восстановления для бизнес-процесса;
- как время восстановления для бизнес-процесса транслируется в RTO/RPO для ИТ-систем;
- классы критичности и классы восстановления — зачем это нужно.
Едем дальше.
Расчет RTO
После того как проведены все интервью, описаны бизнес-процессы, оценены риски, определена и утверждена методика, производится расчет потерь. Так как бизнес «Пятерочки», «Карусели» и «Перекрестка» различается как минимум масштабами — для каждой сети мы разработали свои таблицы, свои графики и расчеты потерь.
Для бизнес-процесса в целом определяется время восстановления (см. методику), когда потери превышают пороговое значение (см. пороги). Это время восстановления присваивается тем ИТ-системам, которые участвуют в бизнес-процессе (см. интервью и матрица зависимостей). Казалось бы, параметры непрерывности определены — проект закончен (см. границы и рамки). Но недостаточно сказать «процесс должен восстанавливаться за 12 часов». Важно определить, как это работает сейчас. За сколько часов ИТ-систему удается реанимировать сегодня? И что делать, если текущее время восстановления больше или значительно больше целевого? Для тех, кто еще сохраняет рассудок и концентрацию, добро пожаловать в GAP!
GAP-анализ и план дальнейших действий
В результате предыдущих шагов мы определили состояние для процессов и систем «TO BE», то есть как должно быть в идеале. На текущем этапе, определяем состояние «AS IS». При этом мы в меньшей степени трогаем бизнес-процессы, а сосредотачиваемся на ИТ-составляющей. Для заказчика мы оценили его текущие решения с точки зрения восстановления после чрезвычайной ситуации. Причем в данном случае не пришлось проводить реальное восстановление с таймером. Достаточно было углубиться в подробности и хватило настольного тестирования, чтобы понять, что целевое RTO недостижимо.
После этого мы разработали ряд рекомендаций, как общего характера (по обеспечению непрерывности ИТ), так и касающиеся непосредственно ИТ-систем и их архитектуры. Это эскизы технических решений и грубая оценка стоимости их реализации. Фактически теперь есть основа для принятия решения. На одной чаше весов — потери, а на другой — стоимость мероприятий.
Если некоторые ИТ-системы не проходят GAP-анализ, а точнее, время их восстановления больше, чем целевое, мы делаем программу проектов по достижению целевого состояния или, если хотите, дорожную карту с обоснованием очередности выполнения проектов и промежуточной оценкой повышения устойчивости организации.
Помимо этого, для заказчика мы разработали методические материалы и шаблоны для формирования планов непрерывности и планов аварийного восстановления.
Стратегия
Подождите-подождите, я уже почти закончил.
По итогам BIA мы разработали стратегию обеспечения непрерывности ИТ. В стратегии непрерывности описали два ключевых момента.
- Какие ИТ-риски, влияющие на деятельность компании, принимаются во внимание, а какие — нет (то есть чего мы боимся и будем решать в рамках непрерывности, а чего не боимся и для этого у нас есть инцидент-менеджмент).
- Какими организационными, архитектурными, инфраструктурными и иными решениями мы будем защищаться от угроз.
Стратегией мы убиваем двух зайцев. Во-первых, все в компании понимают, как и от чего мы будем защищаться. Во-вторых, для неспециалистов в области ИТ (например, финансистов) более прозрачным выглядит процесс бюджетирования решений IT disaster recovery. И как бы пафосно это ни звучало, стратегия помогает принимать правильные управленческие решения (всегда есть вариант не тратить деньги на DR, и теперь мы точно знаем, как это повлияет на компанию в случае аварии).
Что дальше? Дальше реализация стратегии непрерывности и business impact analysis для других бизнес-процессов и ИТ-систем. Разработка планов непрерывности, периодическое тестирование этих планов, но это совсем другая история.
Игорь Тюкачев, Консультант Центра проектирования вычислительных комплексов «Инфосистемы Джет»
Автор: JetHabr
