Что такое business continuity plan

Disaster Recovery vs High Availability

Business continuity (непрерывность выполнения бизнес-задач) — один из самых популярных запросов при построении инфраструктуры. Для того, чтобы ее обеспечить, используются два основных подхода: High Availability и Disaster Recovery. Мы постарались рассмотреть оба подхода и показать преимущества и контекст применения каждого.

Отказоустойчивость (High Availability) позволяет продолжать выполнение бизнес-задач при выходе из строя какого-либо компонента инфраструктуры.

Катастрофоустойчивость (Disaster Recovery) же позволяет продолжать выполнение бизнес-задач при выходе из строя ЦОД целиком, например, из-за отключения электричества на длительное время, пожара или любого иного масштабного природного явления.

Итоговый выбор зависит от типа задач, с которыми нужно будет работать.

Рассмотрим основные моменты:

Услуги по обеспечению непрерывности весьма востребованы, так как в любых технически сложных системах аварии неизбежны.

В финансовом секторе и промышленном производстве к высокому спросу подталкивают требования обеспечения непрерывности бизнеса, накладываемые регуляторами. В остальных сегментах, например, для торговых сетей, построение отказоустойчивых инфраструктур или их аренда (как в ЦОД, так и облачных провайдеров) объясняется растущей конкуренцией.

Для обеспечения непрерывности бизнеса (Business Continuity) необходимо подготовить два плана:

При выходе из строя офисного здания, сгорания склада или поломки автомобиля DRP будет описывать как оперативно запустить новое офисное здание, открыть запасной склад или использовать запасные части для ремонта автомобиля.

BCP же будет описывать, как организовать удаленную работу сотрудников, перенаправить поступающие товары на новый склад или вызвать такси.

Оба плана должны разрабатываться, исходя из требований бизнеса, и использоваться сразу после возникновения аварии. В них должны содержаться протестированные наборы инструкций и список ответственных, которые эти инструкции должны выполнить.

Технологии резервирования

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

Выделяют три вида резервов:

Холодный резерв

Некое серверное помещение с запасным оборудованием. В «сценарии катастрофы» может планироваться закупка либо хранение оборудования на складе.

Следует помнить, что большая часть оборудования поставляется под заказ и оперативно ввести в работу десятки единиц серверов, СХД, коммутаторов представляется маловероятным.

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

Теплый резерв

Существующая функционирующая дополнительная площадка, для которой настроены интернет и WAN-каналы, базовая телекоммуникационная и вычислительная инфраструктура. Основное оборудование должно быть подключено и всегда готово к переводу нагрузки.

Такая площадка «слабее» основной по вычислительным мощностям, некоторое оборудование может отсутствовать, но важно, чтобы на площадке всегда была актуальная резервная копия данных. Для запуска такой системы требуется не более одного дня. Данный вариант в настоящее время является весьма популярным решением из-за соотношения цена-качество, а также приемлемого времени ввода в эксплуатацию.

Горячий резерв

Серверная площадка с оборудованием, производительность которого соответствует оборудованию основной площадки, а все данные основной площадки регулярно реплицируются. Такая площадка с готовой инфраструктура, настроенными каналами и актуальными версиями программного обеспечения запускается в пределах установленного RTO.

Минус как горячего, так и теплого резерва – простой оборудования. Одним из решений может стать решение использовать две площадки равномерно – большинство приложений могут работать как на одной, так и на другой. При использовании мощности всего оборудования можно обеспечить балансировку нагрузки, например, на одно из приложений при ожидаемом пике.

Отказоустойчивость

Под «Отказоустойчивостью» понимается свойство системы сохранять работоспособность в случае случайного выхода из строя или сбоя отдельных компонентов. Критерий надежности может определятся количеством «девяток после запятой»:

Как измеряется High Availability

Процент доступности рассчитывается следующим образом:

доступность = (минуты в месяце — минуты простоя) * 100 / минут в месяц

Поставщик услуг обычно предоставляет показатели доступности в своих соглашениях об уровне обслуживания (SLA). При этом обслуживание системы и запланированное время простоя являются неотъемлемой частью этого соглашения. Если в SLA заявлено 99,999%, конечный пользователь может ожидать, что услуга будет недоступна в течение следующих промежутков времени:

Если провайдер услуг придерживается стандарта «три девятки» (99,9%), то это означает, что в течение одного года допустимо около 8 часов и 45 минут простоя системы.

Как обеспечить High Availability

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

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

Инфраструктура, настроенная для обеспечения непрерывной доступности, должна иметь дополнительное (избыточное) аппаратное и программное обеспечение, благодаря которому в случае сбоя система останется работоспособной.

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

Катастрофоустойчивость

Под катастрофоустойчивостью подразумевается способность системы сохранить критически важные данные и продолжить выполнять свои функции после массового (возможно, целенаправленного) уничтожения его компонентов в результате различных форс-мажорных ситуаций. Этому определению точно соответствует англоязычный термин «Disaster Tolerance» (DT), однако в общем случае термин «Disaster Recovery» (DR) (дословно «Восстановление после катастрофы») можно также переводить как «катастрофоустойчивость». Отличие DR от DT состоит в том, что DR концентрирует внимание на сохранности данных (при строго контролируемых потерях, если они неизбежны).

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

Для защиты от природных, техногенных катастроф или терактов и обеспечения непрерывности бизнес-процессов необходимо резервирование основных систем хранения и обработки данных. В случае катастрофы может пострадать здание центра обработки данных, поэтому создание территориально удаленной площадки – резервного дата-центра – необходимо. Когда уровня надежности Tier III не хватает, географически распределенная катастрофоустойчивая инфраструктура ЦОД способна гарантировать доступность четыре и даже пять девяток.

Непрерывность работы виртуальных дата-центров

Облако на базе VMware представляет собой облачную инфраструктуру (IaaS) на базе платформы VMware vSphere® и VMware vCloud Director® и предназначено для получения вычислительных ресурсов с удаленным доступом на базе облачной платформы VMware Cloud.

Совокупность виртуальных облачных вычислительных ресурсов (процессоры, память, место на диске, сети) называется виртуальным дата-центром.

При построении отказоустойчивой облачной инфраструктуры необходимо создавать одновременно основной и резервный дата-центры, расположенные в разных локациях, которые могут находится в одном физическом здании ЦОД.

При построении катастрофоустойчивой облачной инфраструктуры необходимо создавать одновременно основной и резервный дата-центры, которые будут располагаться в разных регионах, то есть в географически удаленных друг от друга физических ЦОД.

Все изменения системы в основном виртуальном дата-центре в реальном времени должны резервироваться и добавляться в резервный виртуальный дата-центр, благодаря чему выход из строя любого компонента системы не повлияет на выполнение бизнес-задач. При аварии вместо основного дата-центра подключается резервный во временных рамках, обозначенных RPO и RTO.

Вместо заключения

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

Чтобы обеспечить функционирование своих информационных систем современные бизнесы стремятся повысить отказоустойчивость, например, за счет избыточности входящих в нее компонентов и обращают особое внимание на условия эксплуатации поддерживающего ее IT-оборудования:

Желаем успеха в построении надежных IT-инфраструктур и будем рады поделиться нашей собственной экспертизой. Задавайте любые интересующие вопросы в комментариях, а также наших социальных сетях: ВКонтакте, Фейсбуке и Твиттере.

Полезные статьи и материалы по теме:

Источник

Есть ли у вас план?!

Понятие «планирование непрерывности бизнеса» (Business Continuity Planning, BCP) появилось сравнительно недавно и сегодня вызывает большой интерес у топ-менеджеров отечественных компаний.

Понятие «планирование непрерывности бизнеса» (Business Continuity Planning, BCP) появилось сравнительно недавно и сегодня вызывает большой интерес у топ-менеджеров отечественных компаний. Насколько методики и технологии обеспечения непрерывности бизнеса могут быть полезны?

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

Сегодня известно довольно много угроз и разрушающих факторов, неблагоприятно влияющих на деятельность коммерческих и федеральных структур и организаций. Например, перевод на два и более часа корпоративной информационной системы в состояние «отказ в обслуживании» по причине инфицирования ранее неизвестными вирусами или враждебными апплетами может нанести серьезный ущерб бизнесу компании. Для парирования возникающих угроз любому предприятию жизненно важно разработать и поддерживать в актуальном состоянии план восстановления бизнеса в чрезвычайных ситуациях.

Планирование восстановления после происшествия

Сегодня в России стремительно растут объемы передаваемой и обрабатываемой информации в корпоративных информационных системах. В этих условиях ИТ-службы отечественных компаний так заняты освоением новых технологий, что у них не хватает времени на обеспечение бесперебойной работы и безопасности систем. Это обычная проблема в циклах постоянного освоения новых технологий. Однако по мере «взросления» компаний и их систем все большее значение приобретают такие процессы, как резервное копирование данных и способность поддержания непрерывного доступа клиентов к приложениям.

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

План восстановления после происшествия (Disaster Recovery Plan, DRP) является частью плана непрерывности бизнеса и позволяет определить необходимые процедуры восстановления в случае возникновения инцидентов.

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

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

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

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

Для качественного выполнения плана восстановления необходимо знать допустимое время восстановления (Recovery Time Objective), а также конечные цели восстановления (Recovery Point Objective). Стратегия технического восстановления после инцидента основывается на комбинации этих требований.

Процедура восстановления после происшествия состоит из определенных правил, процессов и дисциплин, гарантирующих, что критичные бизнес-процессы продолжат функционирование даже в случае, если произойдет сбой одного или более телекоммуникационных ресурсов или ресурсов обработки информации, от которых зависят операции. К ключевым элементам плана восстановления после происшествия относятся: формирование группы планирования; оценка рисков и аудит; определение приоритетов для приложений и сетей; разработка стратегии восстановления; подготовка оборудования и документирование плана; разработка критериев и процедур верификации; реализация плана.

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

Анализ рисков и их воздействий на бизнес должен включать в себя анализ по крайней мере десяти «наихудших» потенциальных происшествий. Затем каждому бизнес-процессу и приложению/системе должен быть присвоен определенный уровень приоритетности. Цель создания такого списка — обеспечение жизнеспособного, эффективного и экономически целесообразного процесса восстановления во всех технологических областях. Важно поддерживать этот список актуальным, проводить полную инвентаризацию оборудования, помещений, поставщиков и контактных точек. Таблица 1, составленная согласно рекомендациям международного стандарта ISO 17799:2, может использоваться для классификации приложений и/или систем организации.

Классификация приложений/систем

В настоящее время подготовлено более десятка различных стандартов и спецификаций управления безопасностью, детально регламентирующих процедуры планирования и поддержки непрерывности бизнеса, среди которых наибольшую известность приобрели международные и национальные спецификации и стандарты, такие как ISO 17799-2002 (BS 7799), NIST, COOP, HIPAA Gramm-Leach-Bliley, The Expedited Funds Availability, SAS 78/94.

Определение приоритетов восстановления приложений

Приложения классифицируются как критически важные, критичные, существенные или некритичные — в соответствии с классификацией поддерживаемых ими бизнес-процессов. Кроме того, для названных приложений определяются показатели допустимого времени и цели восстановления.

Системное время восстановления

Для оценки общего времени восстановления отдельного бизнес-процесса определяется системное время восстановления (System Recovery Time). С тем чтобы гарантировать восстановление бизнес-процесса в течение допустимого времени, необходимо планировать порядок приоритетов, в соответствии с которым и будет производиться восстановление аппаратных средств и компонентов систем. Например, согласно плану восстановления после происшествия, гарантированное восстановление хостов системы и соответствующих приложений должно начинаться в течение 15 минут. Хост-системы и связанные компоненты выполняют приложения, которые представляют бизнес-процессы. Должны быть определены компоненты инфраструктуры аппаратных средств, необходимые прикладным системам и данным, поддерживающим соответствующие бизнес-процессы. Также необходимо идентифицировать все прикладные зависимости, компоненты сетевой инфраструктуры и поддерживающий персонал.

Существует несколько способов определения системного времени восстановления. Для того чтобы обеспечить допустимое время восстановления бизнес-процесса, рассматривается несколько сценариев восстановления и выбирается лучший из них. В целом для успешного определения системного времени восстановления необходимо выбрать критичные для компании бизнес-процессы; определить допустимое время и конечную цель восстановления. Это же необходимо предлагать и в отношении всех приложений, поддерживающих выбранные бизнес-процессы, хост-систем приложений и времени восстановления для хост-систем и приложений.

Использование резервного копирования

Достижение конечной цели восстановления происходит как в штатных, так и во внештатных ситуациях. Если в случае происшествия программы и данные потеряны, то следует обратиться к архиву для их восстановления. Для этого необходимо выполнить процедуру резервного копирования.

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

Тестирование плана

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

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

Применение плана восстановления после происшествия

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

Таким образом, план непрерывности бизнеса возобновляет бизнес-процессы в целом, а план восстановления после происшествия восстанавливает работоспособность ИТ-систем. Задача планирования восстановления после происшествия заключается в том, чтобы максимально оперативно возобновить работоспособность систем, поддерживающих как критичные бизнес-процессы, так и обычные операции.

Программа реагирования на инциденты

Для успешного восстановления непрерывности бизнеса необходимо разработать программу реагирования на инциденты (Incident Response Program). Под инцидентом безопасности понимается неблагоприятное событие в информационной системе и/или сети или угроза того, что такое событие может произойти. Инцидентами могут быть: неавторизованный доступ, атаки злоумышленников, вирусные атаки и пр. Независимо от вероятности инцидента важно, чтобы все шаги, предложенные программой, были осуществимы.

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

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

Инструментальные средства обеспечения непрерывности бизнеса

Сегодня на рынке представлен достаточно широкий спектр программного обеспечения для автоматизации процессов планирования и управления непрерывностью бизнеса. Такое программное обеспечение позволяет использовать универсальные архитектуры баз данных для упрощения процедур анализа рисков и развития планов по восстановлению и непрерывности бизнеса.

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

В целом программное обеспечение планирования и управления непрерывностью бизнеса можно условно разделить на следующие категории.

В табл. 2 рассмотрены характерные особенности некоторых программных продуктов.

Так, например, RSM McGladrey основное внимание уделяет решениям по обеспечению непрерывности бизнеса в области бухгалтерской деятельности, а SunGard рассматривает вопросы планирования и управления непрерывностью бизнеса в контексте решений и услуг по обработке финансовой информации в корпоративных информационных системах. Типичные особенности программных продуктов обеспечения непрерывности бизнеса следующие:

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

Таким образом, целесообразность планирования непрерывности бизнеса в каждой отечественной компании сегодня уже не вызывает сомнений.

Сергей Петренко — эксперт управления профессионального сервиса компании «АйТи», SPetrenko@it.ru
Ольга Ремизова — консультант управления профессионального сервиса компании «АйТи», info@it.ru

Поставщики решений и услуг

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

Состав работ

Стандартная схема планирования непрерывности бизнеса компании может включать в себя следующие работы:

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

Тщательно составленный документированный план обеспечения непрерывности бизнеса показывает, какие цели и задачи компании являются приоритетными в чрезвычайных ситуациях.

Пример плана обеспечения непрерывности бизнеса

Основные положения плана обеспечения непрерывности бизнеса (актуальность, основные цели и задачи, способы решения).

Оценка воздействия на бизнес:

Деятельность компании в чрезвычайной ситуации:

Поддержание готовности к обеспечению непрерывности бизнеса:

Организационное обеспечение, состав и функции групп, ответственных за поддержку непрерывности бизнеса в случае происшествия. Формируются следующие группы:

Поделитесь материалом с коллегами и друзьями

Источник