Что такое Disaster Recovery
Любая ИТ-инфраструктура может пострадать из-за сбоя в работе серверов. В результате этого возникает простой в исполнении бизнес-задач, а часть критически важных данных – попросту утрачивается. В таких случаях многие компании прибегают к disaster recovery. Это – аварийное восстановление IT-системы, которое позволяет устранить последствия инцидента.
Многие облачные провайдеры сегодня предлагают такую меру как самостоятельную услугу или включают ее в состав основного тарифа. Решение предполагает комплекс мер для восстановления данных и программ и минимизации возможных последствий. Разберемся, в чем заключается суть процедуры и почему многие компании используют ее на практике.
Причины востребованности
Организации все чаще переносят все бизнес-задачи и процессы в IT-инфраструктуру. Это не удивительно, так как благодаря этому удается оптимизировать процессы, увеличить эффективность сотрудников и снизить издержки.
Однако на деле, чем активнее компания использует ресурсы такой инфраструктуры, тем сильнее зависит от ее работоспособности. Даже незначительные сбои могут привести к репутационным и финансовым потерям. Кроме этого, сбои также отражаются на эффективности сотрудников и приводят к серьезным затратам ресурсов.
Компании уделяют много внимания стабильности инфраструктуры, используя современное оборудование и программы для защиты информации. Однако даже в этом случае не удается на 100% исключить возможность непредвиденных ситуаций. Поэтому крайне важно не только не допустить сбои, но и мгновенно восстановить инфраструктуру в случае их наступления. Для этого и применяется комплекс аварийного восстановления.
Если говорить о том, что такое Disaster Recovery – то это, по сути, часть комплекса мер по поддержанию непрерывности бизнес-процессов. Главная идея заключается в поддержке работы компании вне зависимости от кибератак, внутренних сбоев и других инцидентов безопасности. В случае аварии комплекс мер позволяет не потерять критически важную информацию и быстро восстановить все процессы.
Условно аварийное восстановление делят на три уровня:
- Программы и приложения для выполнения бэкапа.
- План восстановления.
- Резервный сервер для размещения данных.
Для осуществления потребуется организация параллельно работающей IT-инфраструктуры, которая будет использована для размещения шаблонов ВМ и данных. Также параллельный сервис может выступать в качестве вспомогательного и брать на себя часть бизнес-задач во время сбоя.
Disaster Recovery обычно предлагают облачные поставщики услуг. Как правило, они могут предоставить необходимые мощности для размещения дополнительной информационной системы. Важно, что основная ИС находится в другом центре обработки данных, то есть системы не зависят друг от друга. Между ними обеспечиваются необходимые каналы связи, позволяющие обеспечить поступление данных и в основную, и в дополнительную ИС.
DRaaS, то есть «восстановление как сервис» существенно отличается от традиционного бэкапа. Основной целью резервного копирования является сохранность файлов во время аварийной ситуации. Аварийное восстановление же помогает сократить время простоя инфраструктуры. По сути резервная копия не позволяет организации продолжить работу на резервной площадке, пока не восстановлена работоспособность основной. Disaster Recovery, наоборот, позволяет применять резервную площадку, на которую будут перенесены все бизнес-процессы.
Основная цель решения – это наличие пошаговой инструкции для устранения любых последствий сбоя. С его помощью можно:
- Восстановить инфраструктуру любого размера и сложности.
- Сохранить все файлы и информацию.
- Гарантировать работу важных приложений во время сбоя в работе основной площадки.
Основные параметры
Disaster Recovery IT-систем подразумевает соблюдение двух критериев, которые влияют на стоимость инфраструктуры и возможную сумму ущерба в случае аварии:
- RTO (время восстановления). Этим показателем обозначается время, за которое инфраструктура должна полностью восстановиться. Например, если RTO составляет три часа, то система должна заработать не позднее этого срока. В том случае, если параметр составляет несколько секунд, то время простоя может остаться незамеченным для обычных пользователей. В общем важно, чтобы произошло автоматические перенаправление трафика на резервное оборудование. Такой подход позволяет избежать последствий сбоя и сделать их максимально незаметными для пользователей. Показатель определяется с учетом потребностей организации. Например, 4 часа простоя IT-системы практически не повредят малому бизнесу, а вот для крупного интернет-магазина это может принести огромные убытки и потерю репутации.
- RPO (точка восстановления). Показатель определяет тот период, за который сведения могут быть утеряны в результате инцидента. Например, при заявленном RPO в два часа могут быть потеряны данные, появившиеся не более чем за 2 часа до аварии. Если показатель составляет несколько секунд, то это означает что сохранится практически вся информация. Это может быть критически важным для организаций в финансовой сфере. Чем меньше показатели RPO, тем чаще будут создаваться копии инфраструктуры.
Аварийное восстановление данных будет обходиться компании дороже при меньших показателях RTO и RPO. Однако подбирать стоимость решения необходимо с учетом размера убытков в случае сбоя. Если стоимость восстановления больше, чем возможные потери, то стоит оптимизировать показатели RTO / RPO и уменьшить затраты.
Составление плана
Компании обязательно потребуется разработать DRP – Disaster Recovery Plan. Этот план должен включать в себя параметры воссоздания всех систем после происшествия. По сути, это отдельный документ, в котором описываются мероприятия по устранению последствий инцидента и воссозданию процессов. Важно указать, кто из сотрудников компании отвечает за отдельные задачи плана, а также донести информацию до каждого работника.
Возникает частый вопрос, когда требуется разработка DRP и всегда ли она нужна. План определенно потребуется организации в следующих ситуациях:
- Возможная остановка сервера или программ может привести к серьезным репутационным и финансовым потерям.
- В компании имеется собственный ИТ-отдел с отдельным бюджетом.
- Имеется бюджет для резервирования данных.
Например, бывают ситуации, когда простой баз данных даже в течение дня существенно не меняет ситуации и не несет серьезных финансовых потерь. В этом случае DRP может и не потребоваться.
План включает в себя несколько разделов. Сначала он потребует составления целей и списка критически важных сервисов. Затем – необходимо учесть возможные факторы риска.
Целями создания DRP может быть:
- Сохранение работоспособности системы. В этом случае основной упор делается на скорость восстановления инфраструктуры.
- Подготовка сотрудников к аварийным ситуациям. Это необходимо для того, чтобы работники действовали в соответствии с инструкциями.
- Соблюдение корпоративных правил. Спланированное аварийное восстановление ИТ-системы позволяет исключить нарушение корпоративных стандартов.
Факторы риска помогают понять, какие приложения потребуют основного внимания при восстановлении данных. В документе важно прописать все процедуры по устранению возможных рисков. К примеру, продумать резервные каналы связи, протестировать запасную инфраструктуру и проверить наличие необходимого оборудования.
Создание списка критических сервисов поможет определить, в какой последовательности будет выполняться восстановление. То есть, чем критичнее процесс, тем раньше его нужно запустить. Это позволит избежать длительного простоя даже при серьезном происшествии.
Как вы понимаете, не существует универсального способа аварийного восстановления сервисов. Для каждой компании потребуется индивидуальная разработка DRP и подбор технических параметров. Если вы хотите избежать потери данных и добиться постоянной работоспособности ИТ-инфраструктуры, то обращайтесь в нашу компанию Xelent. Мы подберем подходящее решение для вашего бизнеса!
