disaster recovery что такое

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

Об эксперте: Евгений Колбин, вице-президент «Сбера», генеральный директор 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-канал РБК Тренды и будьте в курсе актуальных тенденций и прогнозов о будущем технологий, эко-номики, образования и инноваций.

Источник

Готовим DRP — не забудьте учесть метеорит

Даже во время катастрофы всегда есть время на чашку чая

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

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

В этом посте я хочу поделиться рекомендациями, как надо писать DRP и что он должен содержать. А еще мы рассмотрим следующие штуки:

Для каких компаний это может быть полезно

Очень сложно провести границу, когда IT-подразделение начинает нуждаться в подобных вещах. Я бы сказал что DRP вам гарантированно нужно, если:

Документация важна

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

После того, как у вас на руках есть хорошее описание компонентов сервиса, поднимите статистику по авариям. Почти наверняка они будут совершенно типовые. Например, у вас время от времени переполняется диск, что приводит к отказу ноды до ее ручной очистки. Или становится недоступен клиентский сервис из-за того, что кто-то опять забыл продлить сертификат, а Let’s Encrypt настроить не смог или не захотел.

Мысли как диверсант

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

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

После того, как типовые проблемы записаны, наливаем еще кофе и начинаем рассматривать самые странные сценарии, когда какие-то параметры начинают сильно выходить за пределы нормы. Например:

Что такое этот ваш DRP?!

Итак вы определили модель угроз. Учли и местных жителей, которые режут оптоволоконные кабели в поисках меди, и военный радар, который роняет радиорелейную линию строго по пятницам в 16:46. Теперь надо понять, что с этим всем делать.

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

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

Хороший DRP состоит из нескольких простых блоков:

Как правильно тестировать

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

Неправильно — «Зайдите на виртуализацию и ребутните мертвую ноду»
Правильно — «Подключитесь через веб-интерфейс к virt.example.com, в разделе ноды выполните перезагрузку ноды, которая вызывает ошибку».

Не допускайте двусмысленностей. Помните про испуганного стажера.

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

Ключевые пункты

Источник

Как разработать план аварийного восстановления (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-инфраструктуры в облаке. Если вы разрабатываете план аварийного восстановления самостоятельно, можете воспользоваться нашим шаблоном.

Источник

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

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

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

Причины востребованности

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

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

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

Если говорить о том, что такое Disaster Recovery – то это, по сути, часть комплекса мер по поддержанию непрерывности бизнес-процессов. Главная идея заключается в поддержке работы компании вне зависимости от кибератак, внутренних сбоев и других инцидентов безопасности. В случае аварии комплекс мер позволяет не потерять критически важную информацию и быстро восстановить все процессы.

Условно аварийное восстановление делят на три уровня:

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

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

DRaaS, то есть «восстановление как сервис» существенно отличается от традиционного бэкапа. Основной целью резервного копирования является сохранность файлов во время аварийной ситуации. Аварийное восстановление же помогает сократить время простоя инфраструктуры. По сути резервная копия не позволяет организации продолжить работу на резервной площадке, пока не восстановлена работоспособность основной. Disaster Recovery, наоборот, позволяет применять резервную площадку, на которую будут перенесены все бизнес-процессы.

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

Основные параметры

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

Аварийное восстановление данных будет обходиться компании дороже при меньших показателях RTO и RPO. Однако подбирать стоимость решения необходимо с учетом размера убытков в случае сбоя. Если стоимость восстановления больше, чем возможные потери, то стоит оптимизировать показатели RTO / RPO и уменьшить затраты.

Составление плана

Компании обязательно потребуется разработать DRP – Disaster Recovery Plan. Этот план должен включать в себя параметры воссоздания всех систем после происшествия. По сути, это отдельный документ, в котором описываются мероприятия по устранению последствий инцидента и воссозданию процессов. Важно указать, кто из сотрудников компании отвечает за отдельные задачи плана, а также донести информацию до каждого работника.

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

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

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

Целями создания DRP может быть:

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

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

Как вы понимаете, не существует универсального способа аварийного восстановления сервисов. Для каждой компании потребуется индивидуальная разработка DRP и подбор технических параметров. Если вы хотите избежать потери данных и добиться постоянной работоспособности ИТ-инфраструктуры, то обращайтесь в нашу компанию Xelent. Мы подберем подходящее решение для вашего бизнеса!

Источник