disaster recovery что такое

BCP и DRP. Разница иногда не очевидна

Привет, хабр! Это скорее не статья-разъяснение, а статья-рассуждение о непрерывности и самая мякотка, надеюсь, будет в комментариях.

В силу того, что business continuity превратился в модный тренд, что-то вроде нанотехнологий, инноваций и импортозамещения, самое время определиться, что такое BCP и что такое DRP, в чем их разница и почему BCP и DRP как в том анекдоте «не муж и жена, а четыре совершенно разных человека».

BCP (business continuity plan) – план обеспечения непрерывности бизнеса. Содержит детальный план, что необходимо сделать для восстановления бизнес процессов.

DRP (disaster recovery plan) – план восстановления после катастрофы. Содержит детальный план по восстановлению инфраструктуры. Обычно имеется ввиду ИТ инфраструктура, но это могут быть самые разные механизмы, автотранспорт и здания.

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

DRP – это план про восстановление. Если сгорел склад, то есть запасной склад на такой случай. Если в ЦОД пришли маски-шоу, есть резервный ЦОД. Если сломался автомобиль – есть запасные части для ремонта. Или резервный автомобиль. В зависимости от требований бизнеса, о которых мы поговорим в другой статье.

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

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

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

BCP создается и тестируется совместно с представителями бизнеса. DRP создается и тестируется внутри ИТ подразделения.

Очень интересует мнение практиков, которые забороли путаницу в терминологии в непрерывности.

— * — требования бизнеса – это именно требования от бизнеса, а не размышления внутри ИТ департамента, как могли бы выглядеть бизнес требования.​

Источник

Disaster Recovery: облака и аварийное восстановление IT-инфраструктуры

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

По прогнозам компании Grand View Research, к 2025 году объем мирового рынка решений для аварийного восстановления достигнет 26,23 млрд долларов США. Спрос растет из-за того, что IT-системы становятся сложнее, поэтому увеличивается число случаев отказа инфраструктуры вследствие внешних и внутренних угроз.

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

Что такое Disaster Recovery

Disaster Recovery (DR) или катастрофоустойчивость — способность IT-инфраструктуры восстановиться после катастрофы.

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

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

Экономика Disaster Recovery: время восстановления и точка восстановления

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

Чем меньше RTO и RPO, тем дороже решение: систему, которая моментально восстанавливается после сбоя и не теряет данные, организовать сложнее.

Зависимость стоимости от величины RTO/RPO

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

Выбор оптимального решения

Что лучше для Disaster Recovery: резервный ЦОД или облако

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

Вместо того, чтобы создавать собственную резервную площадку, компания может перейти на Cloud DRaaS — облачные сервисы для быстрого аварийного восстановления IT-инфраструктуры. Disaster Recovery в этом случае предоставляется облачным провайдером как услуга.

Это дешевле и проще, чем строить вторую IT-инфраструктуру. Сравним Cloud DRaaS с классическим вариантом — собственным резервным ЦОД,

Организация

Резервный ЦОД. Его сложно организовать. Дублирующая инфраструктура большую часть времени простаивает, однако, нужно закупить или арендовать оборудование, настроить, обслуживать, ремонтировать и обновлять его. Нужен обслуживающий персонал, важно настроить репликации, переключение доменов и DNS-записей, чтобы система заработала в случае аварии. Не всегда можно совместить с нужными платформами.

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

Стоимость

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

Cloud DRaaS. Стоимость зависит от модели, которую использует компания, есть разные решения, отличающиеся по цене. Однако облачные технологии всегда дешевле собственного резервного ЦОД, так как не надо платить за машинные залы, их обслуживание и работу инженеров. При размещении инфраструктуры в облаке часто используют модель Pay-As-You-Go, когда оплата идет за фактически использованные ресурсы — если система не используется, бизнес платит меньше.

Три модели облачных решений Disaster Recovery

В зависимости от масштаба бизнеса и желаемого RTO/RPO можно выбрать три варианта аварийного восстановления в облаке.

Решение для резервного копирования и восстановления (Backup & Restore Solution). Информация копируется и восстанавливается по заданному расписанию, например, раз в сутки или несколько часов. Скопированная IT-инфраструктура помещается в надежное облачное хранилище, например, облачное решение для «горячего хранения» данных Hotbox. Когда наступает катастрофа, клиент восстанавливает информационные системы из облака. Если катастрофа происходит между копированиями, то данные, которые не были сохранены, потеряются.

RTO и RPO у этого облачного решения самые высокие — от 2-3 часов, зато оно экономично и подходит малому бизнесу, которому не критична непрерывная работа инфраструктуры.

Решение можно сравнить с поломкой автомобиля во время поездки. Например, лопнула шина или порвался ремень генератора, а у водителя нет запасных. Теперь нужно ждать эвакуатор, тратить время на ремонт в автосервисе или шиномонтаж. Чем больше повреждения, тем дольше автомобиль никуда не поедет.

Копии инфраструктуры делают периодически и хранят в облачном хранилище

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

Решение для быстрого восстановления (Quick Recovery Solution). Информационная система содержится в облаке в минимально рабочей конфигурации. Рабочая и резервная базы данных непрерывно синхронизируются в инкрементальном режиме — то есть сначала делают полную копию системы, а потом копируют только новую информацию. В облаке содержатся готовые к запуску шаблоны виртуальных машин и приложений. После сбоя IT-инфраструктуру можно запустить одной кнопкой.

После аварии время нужно только на запуск приложений, в облаке хранится актуальная копия информационной системы, поэтому данные не теряются. Этот вариант дороже первого, так как он подразумевает платное агентское решение, клиент платит за использование ресурсов и образов, организацию непрерывного копирования и систему восстановления «по одной кнопке». Зато RTO/RPO решения меньше: до получаса/несколько минут. Оно универсально и подходит большинству компаний, в том числе интернет-магазинам, где важно не терять данные о заказах и транзакциях. Кроме того, хранение инфраструктуры в «спящем режиме» дешевле, чем организовать и обслуживать вторую боевую инфраструктуру, находящуюся в рабочем состоянии.

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

В облаке содержится актуальная копия рабочей IT-инфраструктуры

Синхронность записи данных зависит от системы, есть два варианта с учетом нужной точки восстановления (RPO):

Переключение трафика на резервную инфраструктуру может быть ручным или автоматическим. В таком варианте простоя после аварии практически не будет, но решение подходит не для всех IT-инфраструктур.

Параллельная активная инфраструктура подходит компаниям, где работа информационных систем критична для бизнеса: не должно быть сбоев, потеря данных недопустима. Например, финансовые компании и банки, госуслуги, крупные IT-компании. В этом решении RTO/RPO минимальны: несколько минут/несколько секунд. Оно самое дорогое из облачных вариантов Disaster Recovery, но его стоимость меньше, чем стоимость резервного дата-центра.

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

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

При отключении основной инфраструктуры трафик можно переключить на резервную

Есть похожие решения, в которых облачная инфраструктура не стоит «в резерве», а также ставится под нагрузку и представляет собой «второе плечо» инфраструктуры. При этом выполняется балансировка нагрузки с равномерным распределением запросов между инфраструктурами. Строго говоря, это решение не относится к классу DRS, но позволяет на сходной с DRS архитектуре организовать высокодоступный геораспределенный сервис (high availability).

Два плеча инфраструктуры с балансировкой нагрузки

Источник

Как избежать убытков от ИТ-сбоя: план по аварийному восстановлению

Об эксперте: Евгений Колбин, вице-президент «Сбера», генеральный директор SberCloud.

Ключевая практика борьбы с последствиями ИТ-сбоев — разработка и внедрение планов по аварийному восстановлению (Disaster Recovery Plan, DR-план), которые являются частью планов непрерывности бизнеса.

Хорошо продуманный DR-план позволяет предусмотреть и снизить последствия большинства ИТ-сбоев, включая:

При разработке DR-плана надо определить цели бизнеса, а затем понять, какие сервисы для каких процессов критичны и в какой последовательности они должны быть восстановлены. Только после проведения такого анализа, который называют Business Impact Analysis, есть смысл выбирать конкретные инструменты для аварийного восстановления.

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

Как и почему меняется Disaster Recovery сегодня

Основных причин изменения Disaster Recovery в сторону оптимизации самого процесса две:

DR становится дешевле

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

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

Экономия не сказывается на вопросах надежности и безопасности: облака обеспечивают более высокий уровень устойчивости ИТ-инфраструктуры и бизнес-приложений, чем корпоративные On-Premise системы.

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

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

DR становится быстрее

При критических сбоях компаниям необходимо действовать быстро. Сегодня рынок предлагает большое количество сервисов автоматизированного восстановления. Это высвобождает важные ресурсы (например, время сотрудников), которые можно направить на более приоритетные проекты. Облачные DR-системы также увеличивают скорость аварийного восстановления — с помощью облачного резервного ЦОДа можно не только в течение нескольких минут восстановить утерянные данные, но и развернуть на его мощностях резервную ИТ-инфраструктуру.

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

DR становится проще

Еще несколько лет назад российских провайдеров DR-решений можно было пересчитать по пальцам одной руки. При интеграции их продуктов приходилось учитывать сотни нюансов — по сути, рынок только учился полноценно работать с DR. Сегодня Disaster Recovery — это больше не сакральное знание, для реализации которого нужно прочитать десятки книг или пройти специальные курсы. И со стороны провайдеров, и со стороны заказчиков разработаны четкие инструкции реализации надежных DR-решений. Все идет в сторону минимизации набора необходимых действий и сокращения возможности ошибки на каком-либо этапе.

Самая критичная часть реализации DR-решения — это организация сетевого взаимодействия между резервной и основной площадкой.

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

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

Если сравнивать российские предприятия с западными, то отечественные компании только учатся непрерывности бизнеса. Закон о хранении персональных данных подстегнул российский рынок: сначала — хостинга, затем — облачных провайдеров. Провайдеры, в свою очередь, ринулись разрабатывать и внедрять как можно больше удобных решений и моделей работы для заказчиков. Такая сильная конкуренция за растущий рынок на руку клиентам: они получают разнообразные надежные сервисы по выгодной стоимости. Это касается и решений для Disaster Recovery, которые, будучи важной частью индустрии Cloud, продолжат развиваться и становиться удобнее.

Подписывайтесь также на Telegram-канал РБК Тренды и будьте в курсе актуальных тенденций и прогнозов о будущем технологий, эко-номики, образования и инноваций.

Источник

Как разработать план аварийного восстановления (Disaster Recovery Plan)

Отказы и сбои IT-инфраструктуры нельзя исключить полностью. После катастрофы работу сервисов нужно восстановить как можно быстрее — тогда убытки бизнеса будут минимальны. Чтобы сотрудники знали, как действовать, и нужные меры были приняты вовремя, разрабатывают план аварийного восстановления (DRP): выбирают технологии Disaster Recovery с учетом потребностей бизнеса и бюджета, назначают ответственных, прописывают порядок действий для предупреждения катастрофы и устранения ее последствий.

Мы составили руководство по разработке плана аварийного восстановления с общими рекомендациями по восстановлению IT-инфраструктуры.

Что такое план аварийного восстановления

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

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

Чтобы обеспечить катастрофоустойчивость бизнеса и непрерывность его работы, компания может дублировать IT-сервисы в собственный дата-центр или использовать облачные сервисы, когда Disaster Recovery предоставляется провайдером как услуга.

Что должно быть в плане аварийного восстановления (Disaster Recovery Plan)

Цели плана аварийного восстановления

В качестве целей DRP могут быть указаны:

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

Факторы риска

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

Такие мероприятия, как правило, проводят регулярно для оценки состояния IT-инфраструктуры и ее готовности к процедурам аварийного восстановления в случае катастрофы. Это могут быть:

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

Так может выглядеть список потенциальных угроз для IT-инфраструктуры в DRP

Список критически важных сервисов

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

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

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

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

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

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

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

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

Распределение ролей и обязанностей между сотрудниками

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

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

Процесс реализации плана и реагирования на технический сбой

В плане DRP нужно прописать действия команды для восстановления IT-инфраструктуры после катастрофы. Сотрудники должны заниматься восстановлением работы сервисов, оповестить о случившемся нужных членов команды, добиться запуска системы в нужное время.

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

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

Каждая задача должна быть максимально конкретной, то есть состоять из точных команд или действий. Например, не просто позвонить ответственному, а позвонить менеджеру Юлии по телефону 8-965-123-45-64 в течение трех минут.

Типовая схема действий после катастрофы

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

Готовый план аварийного восстановления тестируют, чтобы выяснить, сработает он в реальной ситуации аварии или нет.

Существуют различные типы тестов:

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

Источник