BCM: быть или не быть?

По данным совместного исследования IBM и журнала The Economist по проблемам рисков и устойчивости бизнеса, в мире только 37% крупных компаний имеют сегодня интегрированные решения и стратегию обеспечения устойчивости к внешним разрушающим факторам (управление непрерывностью бизнеса — Business Continuity Management, BCM). Что уж говорить об отечественной практике. По мнению специалистов компании «АйТи», в России можно насчитать не более 15–20 проектов по реализации стратегии обеспечения непрерывности бизнеса и внедрению соответствующих технологических решений, а свидетельств быстрой смерти компаний в отсутствие такой стратегии еще надо поискать.

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

ИТ сегодня — один из наиболее важных факторов, влияющих на непрерывность бизнеса. Это связано как с тем, что информационные технологии проникают практически во все области человеческой деятельности, так и с тем, что обеспечение восстановления бизнеса в значительной степени опирается на возможности и средства ИТ. И хотя BCM подразумевает решение множества организационных вопросов, без реализации соответствующей технологической платформы эти вопросы могут так и остаться без ответа.

Усиление зависимости бизнеса от ИТ и усложнение корпоративных ИТ-инфраструктур — основные факторы, которые определяют роль технологических составляющих в BCM. Среди респондентов исследования IBM и The Economist значительное число (40%) признают обеспечение непрерывности бизнеса прежде всего задачей ИТ. И большинство опрошенных признают, что руководители и сотрудники ИТ-департаментов являются ключевыми участниками реализации стратегии и планов BCM.

Понятия

Управление непрерывностью бизнеса — задача, которую в идеале каждая компания должна решать ежедневно, опираясь на хорошо продуманную стратегию и комплекс современных технологий. Непрерывность бизнеса нельзя отождествлять лишь с катастрофоустойчивостью информационной инфраструктуры, а следует говорить о комплексе корпоративных политик, организационных мероприятий и технологических решений, направленных на то, чтобы гарантировать постоянную доступность критически важных функций бизнеса его клиентам, поставщикам и регуляторам. Восстановление при катастрофах (disaster recovery) является только подмножеством общей корпоративной стратегии непрерывности бизнеса, которая строится исходя из международных стандартов и общепринятых рекомендаций, а также локальных законодательных и отраслевых норм и правил.

Все более тесная интеграция ИТ и бизнеса в решении задач управления непрерывностью бизнеса находит отражение и в частом объединении понятий BC (business continuity) и DR (disaster recovery). Последнее в большей степени относится именно к восстановлению технологической инфраструктуры и защите данных в случаях аварийных ситуаций с использованием средств надежного хранения, кластеризации, оптимизации сетевой инфраструктуры, инструментов резервного копирования и репликации данных.

Уже почти 20 лет консолидацией мирового опыта BCM, выработкой рекомендаций и развитием профессиональных компетенций в этой области занимается международная организация Business Continuity Institute (BCI), определяющая BCM как базовую структуру (фреймворк) для выявления потенциальных угроз организации и выстраивания организационных мер и средств их противодействия с целью защиты интересов ключевых акционеров, ее репутации, бренда и основных направлений деятельности. Угрозами могут служить не только аварийные ситуации вследствие сбоев оборудования, ошибок в ключевых бизнес-приложениях или природных стихийных бедствий, но и, например, болезнь или увольнение ключевых сотрудников, серьезные нарушения логистической цепочки или угрозы информационной безопасности.

Для BCM имеется стандарт, разработанный такой признанной организацией, как British Standard Institute (BSI ISO 25999), а на Западе действует ряд регулятивных норм (в частности, HIPAA в здравоохранении, Basel I, Basel II в финансовой сфере и др.), обязывающие организации гарантировать определенный уровень защиты данных и непрерывности бизнес-операций. В качестве примера такого регулирования для российского бизнеса можно привести положение Банка России о необходимости для кредитных организаций иметь планы действий на случай непредвиденных ситуаций.

Азы непрерывности

Программа BC/DR,безусловно, необходима для бизнеса, но на пути ее реализации имеется множество препятствий, в частности «методологический» хаос. Сегодня в области BCM существует около 20 международных стандартов и руководств и свыше 60 отечественных регулирующих документов. При этом подавляющее большинство такого рода документов носят стратегический характер и лишь 30% из них можно использовать для выстраивания конкретных операций в рамках BCM (в том числе ITIL и CoBit). Ближе всего к практике BC/DR оказались сегодня такие игроки ИТ, как IBM, HP, Oracle и EMC, однако и их рекомендации часто связаны со своими собственными технологическими платформами и могут оказаться бесполезными в условиях гетерогенной среды.

Как бы то ни было, имеется ряд общих шагов, которые должны входить в любой план обеспечения непрерывности бизнеса. Прежде всего, надо понимать, что реализация такого плана — мероприятие затратное и с точки зрения ИТ требующее дублирования компонентов инфраструктуры, развертывания резервных инфраструктур, поддержки надежной сетевой среды, внедрения программных инструментов резервного копирования данных и т. д. Поэтому в планировании действий по BC/DR очень важно расставить приоритеты, оценив, какие бизнес-активности и ИТ-сервисы наиболее важны для работоспособности организации; какие риски наиболее критичны, а с какими можно смириться; какие приложения и данные требуют незамедлительного восстановления, а какие могут пережить время простоя. Для получения исчерпывающих ответов на эти вопросы реализуются программы анализа влияния на бизнес (business impact analysis, BIA) и определяются основные метрики, характеризующие возможности восстановления. Исходя из этих данных выбираются и развертываются соответствующие технологии BC/DR — для обеспечения избыточности серверов, систем хранения и сетевой инфраструктуры, оптимизации хранения и передачи данных, резервирования/восстановления операционных систем, приложений, данных и серверных конфигураций. Сформулированная программа BCM требует постоянного тестирования, для того чтобы подтверждать свою эффективность и актуальность в меняющихся условиях.

Если организация практикует сервисный подход к управлению ИТ, ей проще проследить зависимости деятельности бизнеса от ИТ-сервисов и конкретных элементов ИТ-инфраструктуры и соответствующим образом расставить приоритеты восстановления — неслучайно положения ITIL, ISO 20000 и CoBit являются важными стандартами для выстраивания BCM.

В рамках анализа влияния на бизнес определяются различные категории приложений по уровню их критичности для бизнеса. Так, приложения, от которых напрямую зависят финансовые показатели, например банковские системы, должны иметь степень доступности «пять девяток» и, очевидно, будут отнесены к категории высококритичных (mission-critical). В зависимости от уровня критичности параметры восстановления приложений могут быть зафиксированы и контролироваться с помощью соглашений об уровне обслуживания для тех ИТ-сервисов, в реализации которых задействованы данные приложения.

Аналитики отмечают, что число приложений, которые организации считают критичными, имеет тенденцию к росту. По наблюдениям Forrester Research, сегодня все чаще компании относят к категории критичных системы электронной почты и совместной работы, что еще раз доказывает усиливающуюся зависимость от ИТ повседневных операций любого бизнеса. Кроме того, экосистема корпоративных приложений усложняется, что тоже влияет на оценку их критичности. Например, CRM, которую в компании могут считать критичной системой, зависит от надежности СУБД и устойчивой работы электронной почты, поэтому последние также попадут в категорию критичных для бизнеса систем. По данным опроса, проведенного аналитиками Forrester совместно с журналом Disaster Recovery Journal, компании в среднем относят к высококритичным 35% своих корпоративных приложений и к критичным — 34%. Согласно данным исследования Enterprise Strategy Group, 18% компаний не допускают ни минуты простоя для высококритичных приложений и данных без риска существенных финансовых потерь, для 35% компаний такие простои не могут превышать часа. Идентифицируя критичные для себя области ИТ-поддержки, бизнес тем не менее редко дает точные оценки стоимости простоев. Несложно вычислить, во что обойдутся потери производительности, нереализованные продажи или штрафы регулятивных органов, однако следствием простоев критичных бизнес-приложений и потерь данных могут быть отказы клиентов от продуктов или услуг компании, ущерб ее репутации и другие потери, которые трудно сразу выразить в конкретных показателях. По данным аналитиков Forrester, 55% компаний имеют инструменты расчета стоимости одного часа простоя, но только 18% смогли указать точные данные. Лишь 10% участников опроса аналитиков были в состоянии оценить, во сколько в целом обошлось им последнее по времени деструктивное событие. Тем не менее в среднем эти показатели выглядят удручающе — стоимость часа простоя составляет почти 350 тыс. долл., а потери от аварийной ситуации в целом в среднем достигают 10,8 млн долл.

На авось не надейся

Компания Acronis и независимый институт Ponemone Institute обнародовали результаты международного исследования готовности ИТ-инфраструктуры к аварийному восстановлению. В целом уровень уверенности организаций в своей готовности, возможностях и процедурах резервного копирования и аварийного восстановления за прошедший год вырос на 14%. Индекс составляется на основе оценок участников степени своего согласия с рядом контрольных утверждений, оценки варьируются от -5 до 5. Для большинства стран, которые второй раз приняли участие в опросе, индекс по сравнению с прошлым годом увеличился. Россия, впервые подключившаяся к исследованию, оказалась в аутсайдерах — более низкий показатель имеет только Бразилия (см. рисунок).

По данным исследования, 86% компаний сталкивались с простоями за последние 12 месяцев, в среднем длительность простоя составляет около двух дней, а убытки от них приближаются к 400 тыс. долл. в год. При этом четверть участников опроса не делают резервного копирования на удаленные площадки, а бюджеты на аварийное восстановление не меняются из года в год, составляя лишь 10% от всех ИТ-затрат. Почти половина опрошенных (47%) считают, что топ-менеджмент не оказывает должной поддержки задачам резервного копирования и восстановления, и по сравнению с данными прошлого года уровень поддержки руководства упал на 13%. Все это может в перспективе очень негативно отразиться на бизнесе.

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

По данным исследования, лишь 2% ИТ-менеджеров российских компаний высказали абсолютную уверенность в том, что их корпоративная инфраструктура выдержит любые испытания. Причины неуверенности те же, что и в остальном мире, но в еще более концентрированном числовом выражении: в российских компаниях среднего бизнеса на резервное копирование выделяется лишь 5% ИТ-бюджета, а 57% опрошенных жалуются на невнимание руководства к проблеме. Почти половина российских ИТ-менеджеров также сетуют на низкую квалификацию персонала, причем при объективно тревожной ситуации в России 30% опрошенных вообще не беспокоятся о возможных перебоях в ИТ-инфраструктуре, полагаясь на авось.

Индекс готовности ИТ-инфраструктуры к аварийному восстановлению

Инструменты восстановления

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

• RTO (recovery time objective, целевое время восстановления) — максимальное время, которое может быть отведено на восстановление данных;
• RPO (recovery point objective, целевая точка восстановления) — максимально допустимые объемы данных, которые компания может позволить себе потерять.

В организациях с выстроенной сервисной моделью управления ИТ эти метрики являются ключевыми в определении параметров BC/DR конкретного ИТ-сервиса с заданным для него SLA. С точки зрения технологий метрики RTO и RPO являются определяющими в выборе способов защиты данных и допустимых затрат на соответствующий инструментарий для различных бизнес-приложений (см. рисунок).

Соответствие между RTO, значимостью данных для бизнеса и стоимостью технологий

Традиционный подход к сохранению данных на магнитных лентах с их физическим перемещением на удаленные площадки или переносом данных на ленты средствами электронных коммуникаций (electronic tape vaulting) пригоден сегодня только для сервисов с минимальными требованиями к скорости восстановления. Обеспечить малое значение RPO в условиях большой скорости накопления данных резервирование на лентах тоже не сможет. Процесс сохранения данных на ленту, как правило, выполняется по определенному расписанию, часто в ночное время, а в случае аварии с лент будут восстанавливаться данные, возможно, суточной давности. Для критичных приложений потеря объемов данных, накопленных за день, обычно недопустима.

Сегодня на смену лентам в качестве инструмента защиты данных приходят технологии резервирования на диски, локальной и удаленной репликации данных. Резервное копирование на диски значительно ускоряет процессы резервирования и восстановления, и многие производители сегодня интегрируют в решения по дисковому резервированию инструменты дедупликации данных, позволяющие сохранять только уникальные данные, что сокращает дисковое пространство. Технологии «моментального снимка» (snapshot) данных позволяют проводить резервное копирование в рабочие часы без влияния на производительность продуктивных систем, благодаря чему становится возможным более частое, по сравнению с лентами, резервирование данных и, как следствие, достигаются более привлекательные для критичных приложений значения RPO. Однако слишком высокая частота таких снимков может потребовать неприемлемо больших объемов дискового пространства, поэтому компании должны идти на компромисс, сохраняя зазоры в резервировании в несколько часов, что может оказаться неприемлемым для высококритичных приложений и данных.

Максимальный уровень безопасности при восстановлении данных могут обеспечить технологии репликации, копирующие каждую очередную запись данных в продуктивной системе в систему хранения на локальной или удаленной резервной площадке. Два основных типа репликации — cинхронная и асинхронная — отвечают разным уровням критичности приложений. Синхронная репликация позволяет создать копию данных на вторичной системе хранения всякий раз, когда происходит операция записи в первичном источнике. Это означает, что показатель RPO при восстановлении данных будет равен нулю — никакие данные не будут потеряны, а работу бизнес-приложений на резервной площадке можно будет восстановить практически мгновенно. Платой за столь высокий уровень защиты становится невозможность реализовать синхронную репликацию на удаленных площадках. Технология создает большую нагрузку на сетевые соединения, кроме того, необходимость ожидать подтверждения повтора каждой записи на удаленной площадке создает задержки в передаче данных, влияющие на производительность приложений. Как правило, допустимый уровень таких задержек возможен только на расстояниях не более чем в несколько десятков километров между основной и резервной площадками.

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

Технологии репликации позволяют реализовать планы по BC/DR для наиболее критичных для бизнеса систем, но, так или иначе связанные с сетями, они могут быть эффективнее при их развертывании в связке с решениями по оптимизации передачи данных в глобальных сетях, включая интеграцию средств дедупликации и сжатия данных.

Решения для различных типов резервирования и репликации данных сегодня предлагают практически все ведущие поставщики систем хранения и сетевых инфраструктур: IBM, HP, EMC, Hitachi Data Systems, Teradata, NetApp. и др. Среди разработчиков технологий сетевой оптимизации можно выделить, например, компанию Riverbed, продукты которой обеспечивают сокращение объемов данных, передаваемых по сети в процессах резервирования или репликации, и тем самым позволяют снизить требования к пропускной способности глобальных сетевых соединений, а также приоритизируют сетевой трафик в зависимости от критичности резервируемых данных.

Облако спасения

По данным ESG, задача совершенствования программ BC/DR вошла в верхнюю десятку ИТ-приоритетов компаний в 2011 году. При этом аналитики отмечают, что другие ключевые направления ИТ часто оказывают непосредственное влияние на реализацию BC/DR. Так, первое место в этом списке приоритетов занимает расширение использования виртуализации. В ESG сообщают, что обеспечение непрерывности бизнеса — один из наиболее распространенных стимулов к развертыванию средств виртуализации. Действительно, создавая логический пул ресурсов, виртуализация помогает избежать возникновения единой точки сбоя и повышает устойчивость среды к уязвимостям. Однако одновременно виртуализация создает дополнительные сложности для обеспечения непрерывности — развертывание множества виртуальных машин на одном физическом ресурсе означает, что все они подвергаются риску выхода из строя в случае сбоя их физической платформы. И этот риск тем выше, чем выше степень консолидации виртуальных машин на физических серверах, к чему сегодня часто стремятся организации. К тому же большое количество виртуальных машин увеличивает нагрузку на сеть, что усложняет реализацию механизмов резервирования, репликации и восстановления данных. Помогая компаниям сокращать расходы и повышать эффективность использования ресурсов, консолидация центров данных за счет виртуализации одновременно повышает риски, которым подвергаются приложения и данные, сосредоточенные теперь на меньшем количестве, как правило, далеко разнесенных друг от друга площадок.

В ряде случаев компании создают не одну резервную площадку в рамках своих программ обеспечения непрерывности бизнеса, что дает дополнительную степень защиты данных и позволяет удовлетворить требования разных по степени критичности для бизнеса систем. Конфигурация с несколькими резервными центрами позволяет разместить один или два из них максимально близко к основной площадке, для того чтобы реализовать с его помощью синхронную репликацию данных для приложений, не терпящих никаких отлагательств по времени восстановления, например ключевых транзакционных систем. Еще один резервный центр размещается на удаленном расстоянии и обслуживает приложения с более низкими требованиями к RTO, поддерживая технологии асинхронной репликации и резервирования на диски и ленты на случай серьезных катастроф, затрагивающих не только основной ЦОД, но и целый город или даже регион, в котором он находится. Однако в Forrester отмечают, что за последние три года стала явной тенденция к консолидации не только основных, но и резервных площадок. Компании идут на это, как правило, под воздействием необходимости оптимизировать свои ИТ-расходы. По данным аналитиков, в 2007 году число организаций, имевших более одного резервного ЦОД, составляло 40%, а к 2010 году уменьшилось до 30%. Правда, аналитики отмечают, что это не всегда означает плохую стратегию BC/DR — во многих случаях необходимые компаниям показатели RTO и RPO вполне оправдывают наличие только одного резервного сайта, в том числе достаточно удаленного географически.

По мере все более активного обращения компаний к облакам они должны задумываться о том, какие изменения могут претерпеть их планы BC/DR. С другой стороны, наблюдается интерес к облаку как платформе для резервирования. В исследовании Forrester 2010 года отмечалось, что большинство компаний предпочитают использовать для создания резервных площадок выделенную среду — собственный ЦОД или инфраструктуру на хостинге у сервис-провайдера, но под полным собственным контролем. Лишь 9% опрошенных реализовали подход «IT recovery-as-a-service», 13% планировали такую реализацию, но 43% уже проявляли интерес. Среди причин обращения к облаку аналитики выделяют быстроту и незатратность развертывания инфраструктуры, гибкость выделения ресурсов и масштабирования, оплату в зависимости от объемов сохраняемых данных, а также удобство облака как платформы для тестирования задач BC/DR. Однако необходимо тщательно оценивать риски сохранения критичных данных в публичном облаке.

Сегодня рынок облачных предложений для BC/DR еще далек от зрелости, однако такие предложения, как, например, IBM SmartCloud Virtualized Server Recovery, свидетельствуют о появлении вполне надежных решений для облачного резервирования. Облачная платформа IBM для BC/DR может обеспечить разные характеристики RTO/RPO в зависимости от потребностей приложений, поддерживает резервирование виртуализированных сред, предоставляет гибкие возможности для тестирования программ BC/DR и позволяет клиентам управлять всеми процессами BC/DR в облаке с помощью специального портала.

Облако имеет потенциал стать эффективной средой для решения задач резервирования Больших Данных, представляющих серьезную проблему для программы BC/DR — колоссальная нагрузка на сеть, повышенные требования к масштабам резервных хранилищ в условиях необходимости быстрого сохранения на удаленных площадках и последующего восстановления для обеспечения нужных RTO и RPO. Самые современные на сегодня механизмы репликации, дедупликации и оптимизации сетевой передачи не в состоянии справиться с Большими Данными, и аналитики прогнозируют появление в 2012 году новых подходов в этой области.