Катастрофоустойчивость ИТ-инфраструктуры как залог непрерывности бизнес-процессов 

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

Рассказываем, что может стать причиной аварии, к каким рискам это может привести и как выстроить катастрофоустойчивую инфраструктуру.

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

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

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

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

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

Почему важна катастрофоустойчивость

Есть несколько факторов, которые могут привести к полному или частичному разрушению ИТ-инфраструктуры.

• Стихийное бедствие. Один из главных факторов риска — повреждение оборудования с данными во время пожара, землетрясения, наводнения, урагана или другого природного явления.
• Человеческая ошибка. По статистике Verizon, в 2023 году 74% инцидентов, которые нарушили безопасность информсистем, вызваны именно человеческим фактором.
• Сбой в ИТ-системе. К «катастрофам» относят аппаратные и сетевые сбои, ошибки на уровне программного обеспечения и перебои в энергоснабжении. 
• Вирусные атаки и киберпреступления. По данным Allianz Risk Barometer, в 2023 году киберинциденты возглавляют рейтинг главных бизнес-рисков. 

Отсутствие должной защиты от рисков чревато последствиями.

• Остановка бизнес-процессов. Если катастрофоустойчивость не обеспечена на достаточном уровне, даже небольшое бедствие может привести к простою, аварийной перезагрузке серверов, критической остановке ПО. 

Из-за этого в работе ИТ-инфраструктуры возникнет даунтайм. И чем сложнее инфраструктура, тем больше времени нужно на ее восстановление. На это время весь бизнес замрет. 
• Безвозвратная потеря данных. Аварийная остановка дата-центров, локальных серверов и хранилищ может привести к полной потере исторических (архивных) данных, а также невозможности сохранить данные, поступающие в момент недоступности оборудования. Во многих отраслях, например в финансовой сфере, такой сбой равносилен краху.
• Рост расходов. Нарушение штатной работы оборудования и бизнес-процессов неизбежно приводит к незапланированным расходам: для восстановления инфраструктуры нужно оборудование, дополнительные инструменты и специалисты.
• Репутационные издержки. В условиях высокой конкуренции даже краткосрочная вынужденная остановка бизнеса и сервисов может привести к потере клиентов и нарушению обязательств по SLA. Это особенно критично, если компания предоставляет бизнес-сервисы, для которых простой недопустим.

Как обеспечить катастрофоустойчивость

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

• Разработка плана аварийного восстановления (Disaster Recovery Plan). План аварийного восстановления — документ, в котором перечислены критически важные системы, описаны шаги по устранению последствий аварии и восстановлению данных, а также есть список ответственных сотрудников. Разработка такого гайда повышает шанс, что последствия катастрофы удастся устранить быстро и без критического нарушения бизнес-процессов.
• Дублирование основных систем и компонентов. Для катастрофоустойчивости важно, чтобы все активное оборудование было дублировано — например, серверы и хранилища. 

Также обязательно дублируют системы электроснабжения, каналы связи, трубопроводы охлаждения. Такие меры соответствуют требованиям к ЦОДу с уровнем надежности Tier III и гарантируют, что любой ремонт можно провести без остановки дата-центра.
• Кибербезопасность. Помимо физической защиты оборудования, нужно защитить ИТ-системы на программном уровне. В этом помогает распределение прав доступа, подключение IPS/IDS-систем, установка межсетевых экранов и антивирусного ПО. Важное значение имеет также регулярное резервное копирование данных.
• Геораспределение инфраструктуры. Один из ключевых способов защиты на случай катастроф — географическое распределение инфраструктуры. Данные реплицируются в удаленные друг от друга дата-центры — если в основном ЦОДе случается ЧП, можно сразу продолжить работу с ресурсами на вторичном. 

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

При построении катастрофоустойчивой инфраструктуры учитывают два параметра: RTO (Recovery Time Objective) и RPO (Recovery Point Objective). 

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

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

Варианты реализации: резервный ЦОД vs облако

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

В ситуации, когда команда работает со своим локальным ЦОДом, есть два подхода к реализации катастрофоустойчивой инфраструктуры: создать резервный физический ЦОД или дублировать основные системы в облако с подключением услуги Cloud Disaster Recovery (DRaaS).

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

Автоматизированные DR-решения

Есть специализированные DR-решения, например Hystax Acura Disaster Recovery. Они автоматизируют репликацию данных и управление резервной площадкой, что улучшает показатели RTO и RPO.

Принцип работы автоматизированных DR-решений прост.

1. На целевые виртуальные машины устанавливают агенты для синхронизации с Hystax Acura Disaster Recovery.
2. Для синхронизированных ВМ выполняется репликация данных. При необходимости настраивается расписание резервного копирования ВМ.
3. Создается план аварийного восстановления, в котором указывают описание инфраструктуры и набор инструкций по воссозданию бизнес-приложения в облаке. 
4. На основе плана создается резервная инфраструктура.
5. При возникновении аварийной ситуации резервная инфраструктура принимает на себя всю нагрузку.

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

Запуск failover происходит на резервной площадке, при запуске восстанавливается исходная ИТ-инфраструктура со всеми компонентами.

Основное по теме

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

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