Цена сбоя
Современному бизнесу приходится функционировать в режиме real-time. Онлайн-покупки, онлайн-банкинг, отслеживание статуса доставки груза в режиме реального времени или движения продукции на производстве, мгновенный доступ к корпоративным базам данных для удаленного агента или к статистике спроса на товары для менеджера в офисе – эти и многие другие бизнес-процессы и задачи требуют непрерывной поддержки со стороны ИТ. И если вчера простой бизнес-процесса, скажем, в течение часа, мог пройти для организации относительно безболезненно, сегодня это чревато ощутимыми финансовыми потерями.
В 2014 г. корпорация EMC опросила 3,3 тыс. ИТ-руководителей из 24 стран мира о размере убытков от потерь данных и недоступности ИТ-сервисов. По данным исследования, компании с численностью сотрудников более 250 человек в 2013 г. потеряли $1,7 трлн из-за указанных причин.
Исследование Veeam за 2016 г. было направлено на выявление потерь от прерывания доступа к данным и приложениям. Согласно данным опроса лиц, принимающих решения в сфере ИТ, — 1140 человек из 24 стран, нарушения непрерывности в среднем могут обходиться компаниям в сумму до $16 млн ежегодно. Эта сумма на $6 млн больше, чем по результатам исследования 2014 г.
Что же лица, принимающие решение в сфере ИТ, считают нужным предпринять для предотвращения простоев? Почти все респонденты Veeam хотели бы расширить возможности корпоративных ЦОД. Больше половины из них заявили о стремлении к высокой скорости восстановления доступности серверов и приложений (не более чем за 15 минут) и предотвращению потерь данных (потери — менее чем за 15 минут). 71% опрошенных отметили, что стимулом к модернизации ЦОД является реализация концепции непрерывности бизнеса.
Что на практике?
Что касается ситуации на российском рынке, то необходимость обеспечения непрерывности бизнеса хорошо осознается в большинстве компаний. Для многих организаций обязанность управления непрерывностью деятельности предписывается законодательными или нормативными требованиями, но при этом соответствие требованиям не является ни единственным, ни главным мотивом для внедрения концепции непрерывности. Руководители заинтересованы не в формальной, а в реальной непрерывности деятельности компании как в факторе повышения доходности, конкурентоспособности, укрепления деловой репутации. Ключевая роль ИТ в этом процессе также хорошо осознается. К настоящему времени практически у всех крупных компаний ключевые ИТ-системы резервируются, в том числе на базе резервных ЦОД.
Однако на практике мы сталкиваемся с тем, что в компаниях, которые внедряют или, как они считают, уже внедрили концепцию непрерывности бизнеса, полноценного процесса обеспечения непрерывности деятельности нет! Почти ни у кого! Дорогостоящие и, казалось бы, правильно реализованные технические решения в критической ситуации оказываются неработоспособными. В чем причина?
Зачастую в организациях, где есть резервный дата-центр, в лучшем случае существуют инструкции по переезду ИТ-систем, но нет ни планов восстановления, ни политики обеспечения непрерывности, ни другой процессной документации.
У других с документацией все хорошо: процессы восстановления описаны подробно и правильно. Но для их реализации нет материальной базы: на какую площадку должны «переезжать» информационные системы, куда должны перемещаться люди, где в случае аварии будут находиться их рабочие места?
Нередки случаи, когда в организации есть и документы, и технические решения, но все это реализовано фрагментарно, и в случае нештатной ситуации никто не понимает четко, кому за что отвечать и что конкретно делать: куда эскалировать проблему, кому давать поручения, чьи указания выполнять и т.д.
И даже там, где есть проработанные планы восстановления и хорошие технические решения, практически никогда не проводится их периодическое тестирование. А ведь недоработки в планах существуют всегда, и без «обкатки» плана в боевом режиме их невозможно обнаружить. Равно как и удостовериться, что по прошествии некоторого времени план остался актуальным, а информационные системы и технические решения готовы к быстрому восстановлению.
Распространенными проблемами также являются отсутствие корпоративной культуры в области обеспечения непрерывности, стратегии обеспечения непрерывности и интеграции процесса обеспечения непрерывности в процесс управления изменениями в компании.
Но главная и самая распространенная проблема — отсутствие вовлеченности руководства в процесс обеспечения непрерывности бизнеса.
Решить все перечисленные проблемы одним махом, конечно, не получится. Но, отдавая себе отчет в том, что проблемы есть, можно, как минимум, определить для себя целевое состояние по обеспечению непрерывности и выработать стратегию поэтапного движения к идеальной картине.
Узнайте свои ИТ!
Непрерывность бизнеса подразумевает бесперебойную деятельность организации в целом, включая производственное оборудование, средства коммуникации, бизнес-процессы, персонал. Следовательно, обеспечение непрерывности требует синергии усилий ИТ- и бизнес-руководства. И это касается не только вопросов бюджетирования. Шансы реализовать концепцию непрерывности бизнеса значительно повышаются, если бизнес-руководитель понимает, как функционирует ИТ-служба, к каким последствиям ведут те или иные изменения в информационном ландшафте и способах предоставления ИТ-сервисов. Идеальной является ситуация, когда ИТ-руководитель выступает для бизнеса как партнер, хорошо понимающий специфику деятельности компании, риски и преимущества внедрения тех или иных технических решений для основной деятельности, когда ИТ-служба и бизнес одинаково понимают цели компании и совместно работают на конечный бизнес-результат. Но, к сожалению, такая ситуация пока существует далеко не во всех организациях, чаще ИТ-служба является для бизнеса обслуживающей инстанцией, причем иногда действующей по принципу «черного ящика», т.е. непрозрачно для бизнес-руководства.
Ниже приведен перечень вопросов, которые бизнес-руководитель должен задать ИТ-директору, чтобы понимать положение дел в части обеспечения непрерывности ИТ-сервисов в организации и готовности ИТ к поддержанию непрерывности бизнес-процессов. Оговоримся: мы исходим из того, что процесс обеспечения непрерывности бизнеса в компании либо уже внедрен, либо внедряется.
1. Кто и как часто проводит аудит процесса непрерывности бизнеса или ИТ-услуг в вашей компании?
Задача аудита — определить, какие фактические показатели восстановления могут обеспечить существующая инфраструктура и процессы, а также выявить потенциально проблемные зоны. Если вам требуется сертификация по требованиям международных стандартов, аудит будет выполнять специализированная консалтинговая компания; если нужна оценка соответствия корпоративным стандартам, это будет делать дирекция внутреннего аудита или аналогичная структура в рамках корпорации/холдинга. Но независимо от этого нужен периодический внутренний аудит (самооценка) — он необходим не просто для того, чтобы отчитаться перед внешними аудиторами, но и чтобы понять, насколько процесс обеспечения непрерывности отвечает тем целям, которые ставит бизнес, насколько декларируемые параметры ИТ-сервисов совпадают с реальными, что делает ИТ-служба, чтобы соблюсти заданные метрики, от каких рисков она защищает бизнес.
Кому поручить проведение внутреннего аудита — выбор бизнес-руководителя, главное, чтобы это была независимая оценка, т.е. аудиторами должны быть люди, непосредственно не вовлеченные в проверяемые процессы. Частота проведения аудита зависит от того, насколько часто происходят изменения в бизнес-процессах и в ИТ-ландшафте организации. Как правило, после выявления узких мест и возможных точек отказа разрабатывается пошаговый план их устранения.
2. Есть ли в вашем процессе обеспечения непрерывности внутренние KPI, по которым оценивается эффективность данного процесса?
KPI позволяют оценить, в правильном ли направлении действует служба ИТ и какова степень достижения поставленных задач по обеспечению непрерывности ИТ-сервисов. Например, если поставлена цель зарезервировать все mission critical-системы, в качестве KPI может быть определен процент систем, резервирование которых обеспечено в течение года. Для зарезервированных систем в качестве KPI может быть выбран процент успешных тестов на отказоустойчивость. Еще одна из возможных метрик — количество бизнес-подразделений, охваченных периодическим тестированием непрерывности деятельности. Какие KPI выбрать и какие показатели задать, зависит от стратегии и специфики бизнеса. Единых универсальных метрик не существует, их выбор — вопрос приоритетов конкретной компании.
3. Существует ли политика (регламент) процесса непрерывности бизнеса и описывает ли он входы и выходы из процесса?
Политика (регламент) непрерывности бизнеса описывает цели, которые организация преследует, внедряя процесс обеспечения непрерывности бизнеса, рамки этой деятельности, выделяемые для этого ресурсы. Это документ верхнего уровня, небольшой по объему, но важный, и его вполне можно разработать собственными силами. Важно, чтобы в политике были описаны все входы в процесс и все выходы из процесса. Например, чтобы любые запросы на изменения в ИТ (появление новой ИТ-услуги или изменение параметров существующей, внедрение новой технологии и пр.) фиксировались и служили триггерами для изменений в рамках процесса управления непрерывностью. Если, предположим, на «вход» этого процесса поступает запрос на внедрение новой системы, на «выходе» должны быть параметры ее доступности и отказоустойчивости, требования интеграции с другими системами и т.д.
Обычно регламент обеспечения непрерывности бизнеса подлежит актуализации не реже 1 раза в год либо в случае существенных изменений в организационно-штатной структуре или бизнес-процессах организации.
4. Разработана ли стратегия обеспечения непрерывности бизнеса?
Стратегия — более детальный документ, в котором описываются конкретные действия, совершаемые в целях обеспечения непрерывности деятельности организации. Цели должны быть описаны в измеримых метриках (показателях доступности инфраструктуры, доступности данных, доступности персонала и т.д.). Результаты действий, которые выполняет каждое вовлеченное подразделение на пути к цели, тоже должны поддаваться оценке. Иными словами, стратегия должна давать всем участникам процесса (руководству, ИТ-службе, бизнес-подразделениям) понимание того, «куда идти и как туда добраться».
5. Как часто и когда последний раз в компании проводились BIA (Business Impact Analysis) и RA (Risk Assessment)? Есть ли матрица зависимости бизнес-процессов/бизнес-услуг от ИТ-услуг/ИТ-систем/инфраструктуры?
Цель BIA – определение степени важности тех или иных ИТ-функций для бизнеса организации, их взаимного влияния, а также анализ последствий их нарушения. Сотрудники ИТ-подразделений, скорее всего, обладают этими знаниями, хотя, возможно, в неструктурированном и неформализованном виде. Составление матрицы зависимости бизнеса от ИТ поможет расставить приоритеты восстановления ИТ-функций в случае сбоя и правильно распределять усилия и ресурсы при планировании восстановительных мер. На первом этапе будет достаточно разработать только часть матрицы, описывающую хотя бы один важный бизнес-процесс.
Результатом оценки рисков (RA) должно стать определение вероятности наступления тех или иных событий, несущих угрозу для непрерывности бизнеса, и тяжести возможных последствий. Составляется реестр рисков, содержащий перечень кризисных ситуаций, защиту от которых планируется обеспечить в рамках процесса непрерывности бизнеса.
К сожалению, предсказать все возможные риски и полный объем их последствий — задача практически невыполнимая. Но не обязательно, особенно на первом этапе, создавать обширный исчерпывающий и детальный реестр. Можно даже начать с одного риска, серьезность которого очевидна и необходимость защиты от которого необходима. Даже если такой реестр рисков уже существует в организации, его не стоит сразу использовать целиком — лучше выбрать один риск и сосредоточиться на защите от него. Построив процесс защиты от одного риска, будет гораздо проще расширить процесс и на другие риски.
С какой частотой проводить BIA и RA, каждая компания должна решить для себя сама – ей лучше известно, как часто в ней происходят изменения: внедряются технологии, перестраиваются услуги, процессы. Рекомендуемая периодичность BIA – раз в год или, если процесс анализа занимает много времени, как это бывает в крупных организациях, раз в 2 года, но не реже. RA, как правило, проводится на постоянной основе, минимум раз в год с ежеквартальными сверками.
6. Представители каких бизнес-подразделений согласовывают результаты BIA и классификацию критичности бизнес-процессов (ИТ-услуг)?
Напомним: непрерывность деятельности — результат совместных усилий бизнес- и ИТ-подразделений. Задачи ИТ-подразделению ставит бизнес, и бизнес же оценивает результат. Поэтому ИТ-руководитель не может единолично согласовывать результаты BIA. В согласовании должны участвовать все структуры организации, непрерывность бизнес-процессов которых зависит от непрерывности ИТ-сервисов, а также все подразделения, которые давали информацию для проведения оценки допустимых потерь по разным показателям ущерба: финансисты, маркетологи, PR, HR и т.д. Если информация для BIA была получена на основании внутреннего аудита, аудиторы тоже должны быть привлечены к согласованию.
7. Вносились ли после этого изменения в стратегии обеспечения непрерывности?
Управление непрерывностью бизнеса компании — процесс циклический. Он должен постоянно совершенствоваться с учетом изменений в бизнесе, информационных технологиях, законодательстве и других областях, влияющих на деятельность компании. Актуализируется ли ваша стратегия обеспечения непрерывности после очередных процедур BIA и RA?
8. Может ли ИТ-руководитель показать график вложений по годам, CAPEX и OPEX на решения по обеспечению непрерывности и кривую уменьшения рисков (финансовую оценку) потери критичных ресурсов?
Есть ли у вас понимание, во имя чего необходимы инвестиции в программы поддержки непрерывности бизнеса, какой они дадут результат? Если расчетные данные у ИТ-службы действительно есть, они должны быть согласованы со всеми заинтересованными подразделениями и, в идеале, с финансовой службой.
9. Когда последний раз в вашей компании проводились тестирования BCP-планов, DRP-планов, планов антикризисного реагирования? Тестирование этих планов проводится ИТ-подразделением самостоятельно или с участием бизнес-подразделений?
Есть ли у вас стратегия тестирования элементов процесса непрерывности бизнеса с описанием того, каким образом проверяется работоспособность технических средств, процессов, регламентов, сотрудников? В этом документе должны быть указаны типы тестирования, рекомендуемая частота его проведения, лица, ответственные за подготовку, проведение и наблюдение за тестированием, приведены образцы протоколов тестирования. Тестирование — это главный метод, позволяющий вашей организации улучшать то, что уже сделано, и набираться опыта.
Подводя итог…
Хочется еще раз подчеркнуть, что обеспечение непрерывности — комплексная задача, и решить ее силами отдельных подразделений не получится. Кроме того, у всякой инициативы должен быть «спонсор».
Разовым выделением средств на «закрытие» того или иного риска вопросы непрерывности не решаются. Обеспечение непрерывности деятельности компании — процесс постоянный, и его финансирование должно быть постоянной статьей бюджета.
Комплексный подход к задаче обеспечения непрерывности бизнеса (т.е. участие в этом процессе всех подразделений) и регулярное финансирование могут существовать в организации только при условии вовлеченности руководства. В противном случае предпринятые усилия окажутся малоэффективными.
Следует также отметить, что обеспечение непрерывности бизнеса — процесс циклический. Анализ процессов организации, разработка мер защиты, внедрение этих мер, их тестирование — этот цикл должен непрерывно повторяться. И все сотрудники организации должны это понимать и быть к этому готовы. Иными словами, действия, направленные на обеспечение непрерывности бизнеса, должны стать частью корпоративной культуры.