Зависимость от технологий
Зависимость бизнес-процессов компаний от информационных технологий во всех сферах экономической деятельности в последние десятилетия постоянно возрастает. Как показывает практика, даже для компаний среднего и малого бизнеса ИТ-системы — включающие в себя такие, например, средства, как система взаимодействия с клиентами, электронная почта, IP-телефония, автоматизация бухгалтерии или интернет-портал, являются фактором выживания. Подобные инструменты дают высокую степень управляемости бизнесом, позволяя без промедления реагировать на изменения рыночной ситуации и добиваться успеха в условиях жесткой конкуренции. Для больших компаний ИТ-инфраструктура, как правило, оказывается критическим элементом бизнес-модели, и выход из строя ее критических элементов даже на короткое время приводит к остановке бизнес-процессов и большим потерям.
При этом современные ИТ-инфраструктуры бизнес-инфосистем всех форм предприятий довольно часто находятся под угрозой незапланированных, непредсказуемых событий, таких как сбои в работе оборудования и его выход из строя, появление программных ошибок, сбои в работе сети, человеческие ошибки, стихийные бедствия и разного рода другие внешние угрозы. Поэтому в любой организации потеря или прекращение предоставления бизнес-функций из-за аварий или катастроф может привести к утрате клиентов, репутационным издержками.
К примеру, несложно представить ситуацию, когда в результате стихийного бедствия или хакерской атаки банк приостанавливает выполнение банковских операций (включая операции по депозитам, перевод денег и т. п.). В результате многие клиенты могут запаниковать или, как минимум, задуматься о надежности своего банка и озаботиться поисками более стабильного. В результате гипотетической масштабной аварии электросети простой более одного часа биллинговой системы крупного регионального оператора связи не позволит принять оплату на сумму более одного миллиона долларов. Тем, кто полагает, что такая ситуация маловероятна, достаточно вспомнить наводнение в Альпах в 2005 году. Тогда в Швейцарии из соображений безопасности пришлось останавливать электростанции и отключать линии электропередач. Целому ряду предприятий, где не были предприняты специальные меры безопасности, был нанесен серьезный ущерб. Аналогичный печальный опыт приобрели и жители Дрездена во время наводнения на Эльбе в 2002 году.
На сегодняшний день многие ИТ-руководители и собственники компаний начали выдвигать более высокие требования к вопросу обеспечения непрерывности работы бизнеса. Однако существующее множество организационных и технологических решений не всегда эффективно обеспечивает необходимый результат из-за ряда особенностей их внедрения и использования в различных сегментах рынка.
Ненадежная надежность
Малые и средние компании стремятся экономить, ведь они тратят на автоматизацию ограниченные свободные средства, которые могли бы быть направлены на развитие. Поэтому инвестирование в резервные компоненты ИТ-инфраструктуры в таких компаниях часто может рассматриваться как избыточное. К тому же рынок СМБ часто использует не специализированные, а «бытовые» решения, предназначенные для домашних пользователей. Для таких ИТ-решений производители в большинстве случаев не указывают параметры надежности, в частности — среднее время наработки на отказ. Добавим к этому отсутствие базы знаний возможных аварийных событий, а также отсутствие понимания руководителями предприятий, не имеющих специальных технических знаний, взаимосвязи функций ИТ-систем с бизнес-процессами, — и мы получим наиболее благоприятные условия для появления аварийных ситуаций.
Немного иначе дела обстоят у крупных компаний. При выборе того или иного ИT-продукта крупные компании менее ограничены в бюджетных средствах, поэтому могут позволить себе уделять необходимое внимание качеству.
Нам нужна стратегия
Шаг первый: Business Impact Analysis
Определение четких методик и создание конкретных планов может позволить найти баланс усилий и вложений для наиболее эффективной защиты ИТ-инфраструктуры.
С чего начать подготовку планов? Например, продуктивным первым шагом может быть проведение BIA (Business Impact Analysis) — анализа воздействия на бизнес последствий, вызываемых нарушением функций компании в результате бедствий различных типов, и последующего восстановления.
BIA позволяет оценить влияние разнообразных процессов на критически важные бизнес-функции и понять, как потенциальное нарушение этих функций — например оперативных или финансовых — может сказаться на организации. Если говорить простым языком, данный анализ позволяет определить, что может понадобиться восстановить и как быстро.
Анализ влияния на бизнес является одной из лучших процедур планирования, который преследует следующие цели:
- определение наиболее важных функций и систем;
- определение финансовых, операционных, юридических и репутационных издержек в случае отказа этих систем;
- выбор RPO и RTO (об этом — далее);
- установление требований для восстановления;
- проведение тестирования;
- анализ слабых мест и уязвимостей.
Для проведения анализа BIA необходимо выполнить определенную подготовку, а именно:
- получить данные и информацию о влиянии рисков на бизнес-операции посредством интервью, опрашивая людей с глубокими знаниями и опытом в отношении анализируемых бизнес-функций;
- провести определение угроз (обычно в соответствии с ISO 31000:2018, документом, который описывает принципы, структуру и процесс управления рисками).
В отдельных случаях опрос BIA можно провести в автоматизированном режиме, к примеру, используя программный продукт BIA Professional от Sungard Availability Services, который позволяет оперативно получать проанализированную обобщенную информацию.
Готовые шаблоны BIA также могут помочь в планировании, но важно понимать, подходит ли выбранный шаблон именно для вашей организации. При этом можно ориентироваться на ISO/TS 22317:2015 — руководство по созданию, внедрению и поддержке формализованного и документированного процесса BIA.
Шаг второй: Business Continuity and Disaster Recovery (BC/DR)
После завершения BIA и выявления потенциальных рисков для бизнеса и вероятности их возникновения, организация может составить подробные планы Business Continuity и Disaster Recovery (BC/DR). Как можно понять из названия план BC/DR состоит из двух концепций: BC — непрерывность бизнеса и DR — аварийное восстановление.
Непрерывность бизнеса обычно представляет собой процессы и процедуры, которые организация должна внедрить, чтобы обеспечить выполнение критически важных функций. План BC должен указать основные функции бизнеса, определить список ответственных должностных лиц, установить, какие системы и процессы должны быть устойчивыми, и подробно указать, как их поддерживать.
План аварийного восстановления (DRP) включает в себя оперативные шаги, которые организация должна предпринять, чтобы за наименьшее время возобновить работу после аварии.
Эксперт в сфере управления повышением устойчивости функционирования предприятия Пол Кирван описывает, что конкретно должно содержаться в плане обеспечения непрерывности бизнеса и аварийного восстановления. В частности стратегия BC/DR должна включать:
- контактную информацию лиц, которые должны первыми реагировать на чрезвычайную ситуацию;
- процедуры управления изменениями, описывающие перераспределение полномочий, средств, ресурсов и обязанностей между ответственными лицами в случае невозможности выполнения изначально оговоренных обязанностей;
- рекомендации по использованию плана, определяющие, какие именно ситуации являются достаточно чрезвычайными для того, чтобы задействовать план BC/DR. Действия, которые должны быть выполнены независимо от способности организации применить план BC/DR;
- пошаговые процедуры, описывающие набор мероприятий, направленных на выявление возможных критических уязвимостей ИТ-систем и конкретных мер для их восстановления;
- график проверки, тестирования и обновления, описывающий меры, направленные на обновления оборудования и программного обеспечения, переквалификацию сотрудников и проверку боеготовности плана в целом, и их последовательность.
Рассмотрев ключевые этапы плана обеспечения непрерывности бизнеса BC/DR можно отметить, что непрерывность бизнеса BC и аварийное восстановление DR это тесно связанные практики, которые поддерживают способность организации оставаться в рабочем состоянии после неблагоприятных событий. Главные отличия между этими планами заключаются в том, что BC обычно сосредотачивается на организации в целом, а DR — на технологической инфраструктуре.
Определение RPO и RTO
Существует целый спектр подходов к организации восстановления после аварии. Как правило, решения, обеспечивающие более надежное и быстрое восстановление, оказываются более дорогими, поэтому важно понять, какой именно вариант окажется оптимальным в каждом конкретном случае.
Одним из распространенных способов выбора наиболее подходящего варианта DR будет оценка рентабельности инвестиций в данное решение (Return on Investment, ROI). Для этого необходимо рассчитать совокупную стоимость владения (Total Cost of Ownership, TCO), включающую все затраты, такие как приобретение, внедрение и поддержка ИТ-системы/оборудования, а также обучение и поддержка персонала в течение срока полезного использования выбранного решения. После этого сравнить полученную стоимость с экономией, возникающей в результате внедрения данного решения. Помочь решить такую задачу может ранее проведенный анализ влияния на бизнес (BIA), который учитывает допустимые объемы потери данных, а также расходы включающие упущенную выгоду, потерю репутации, снижение рыночной капитализации и так далее.
Для того чтобы определиться с требованиями к DR-решению, можно ориентироваться на такие показатели, как целевая точка восстановления (Recovery Point Objective, RPO) и целевое время восстановления (Recovery Time Objective, RTO).
Целевая точка восстановления (RPO) — это точка на шкале времени относительно сбоя, до которой требуется сохранить данные. Изменения данных, предшествующие сбою или аварии на интервал, не меньший этого периода, должны быть сохранены процедурой восстановления.
Целевое время восстановления (RTO) — это максимально допустимый интервал времени, в течение которого компьютер, система, сеть или приложение могут быть недоступны после сбоя или аварии. Данный параметр по сути представляет собой максимальное допустимое время простоя ИТ-системы.
Когда организация планирует свои RPO и RTO, она должна рассчитать их конкретные значения для различных бизнес-процессов.
Тестирование
Однако время не стоит на месте и каждое изменение в организации несомненно повлияет на существующий план BC/DR. Необходимо все время убеждаться, что план актуален, что ответственные лица, участвующие в восстановлении, знают что делать в случае аварии, что приложения имеют актуальные обновления и что необходимое резервное ИТ-оборудование будет своевременно предоставлено или уже есть в наличии.
Чтобы убедиться, что компания сможет восстановить данные и критически важные бизнес-приложения и продолжать работу после прерывания обслуживания, следует регулярно проводить тестирование.
Существует три основных типа тестирования аварийного восстановления. Они включают обзор плана DR, настольный тест и симуляционный тест.
- Обзор плана. Владелец плана DR и другие члены команды, стоящие за его разработкой и реализацией, детально исследуют его, чтобы найти любые несоответствия и недостающие элементы.
- Настольный тест. Упражнения, с помощью которых заинтересованные стороны могут шаг за шагом пройтись по всем компонентам плана аварийного восстановления. Это помогает определить, все ли знают, что должны делать в чрезвычайной ситуации. Также выявляются любые несоответствия, недостающая информация или ошибки.
- Моделирование. Моделирование сценариев аварийных ситуаций — хороший способ увидеть, проводятся ли необходимые процедуры и выделяются ли ресурсы, включая системы резервного копирования и площадки восстановления, для аварийного восстановления и обеспечения непрерывности бизнеса в ситуации, максимально приближенной к реальной. Моделирование обычно подразумевает создание «тестовой» аварии с последующим выполнением плана DR и оценкой результатов.
При тестировании проверяется множество сценариев аварий, чтобы увидеть, могут ли команды, вовлеченные в процесс аварийного восстановления, своевременно перезапустить технологии и бизнес-операции. Это помогает определить, достаточно ли людей в штате, чтобы выполнить работу по аварийному восстановлению должным образом. Подробнее о том, что представляет собой DRP (план восстановления после аварии) и как его подготовить, мы напишем в наших будущих публикациях.
DRaaS
Большинство организаций используют самостоятельно построенные и поддерживаемые решения по аварийному восстановлению, поскольку считают, что такой вариант дешевле, чем покупка решения у DR-провайдера. Впрочем, качественные, самостоятельно разработанные решения (гарантирующие высокую надежность и скорость восстановления) также обходятся недешево и предъявляют высокие требования к ИТ-персоналу организации. Альтернативой тут могут быть решения DRaaS (восстановление после аварии как сервис), которые позволяют снизить нагрузку на персонал, обеспечить экономию на закупках аппаратного обеспечения и передать задачу восстановления после аварии провайдеру услуги DRaaS. Следите за обновлениями блога, чтобы узнать больше о модели DRaaS и ее преимуществах по сравнению с другими подходами к восстановлению после аварии.
