План аварийного восстановления (Disaster Recovery Plan, DRP) DWH — зачем он нужен и как работает

Корпоративное хранилище данных DWH – это масштабная система, которая проектируется в соответствии с требованиями к скорости обновления данных, глубине историчности, аналитическим сценариям и нагрузке.

Что такое DWH (Data warehouse, корпоративное хранилище данных) и как оно помогает бизнесу?

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

К сожалению, аварий в такой сложной системе невозможно избежать на 100%. Чтобы восстановление хранилища не превращалось в импровизацию и дополнительные затраты, необходимо заранее разработать план аварийного восстановления DWH (Disaster Recovery Plan, DRP).

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

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

• Понятие DR-плана
• DRP vs резервное копирование данных
• Когда одного бэкапа недостаточно

2.Почему DWH нуждается в аварийном восстановлении

• Бизнес-риски при отсутствии DR-плана
• Типичные сценарии отказов

3.Компоненты плана аварийного восстановления для DWH

• Анализ рисков и матрица приоритетов
• RTO, RPO и SLA для DWH
• Архитектура отказоустойчивости

4.Как разработать DR-план для DWH

5.Разработка плана аварийного восстановления от Qlever на примере ведущего регионального ритейлера

6.Как закрыть риски, связанные с потерей данных

7.Частые вопросы о DR-плане для DWH (FAQ)

Цель DRP – минимизировать простои и снизить финансовые и репутационные риски от потери данных, а также сделать процесс восстановления DWH управляемым и прозрачным как для ИТ-команды, так и для бизнеса.

В отличие от абстрактных рекомендаций, DRP отвечает на конкретные вопросы:

• Какие компоненты DWH являются критически важными и в каком порядке их восстанавливать
• Какие могут быть сценарии возможных аварий
• Какие команды выполняются при отказе (/failover) инструментов
• Кто ответственен за выполнение этапов восстановления
• Как часто нужно проверять целостность восстановления системы, тестировать и актуализировать план

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

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

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

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

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

При сбое в DWH бизнес теряет не просто средство обработки и хранения данных, а возможность принимать обоснованные решения на их основе.

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

Ключевые риски в таких условиях:

Аварии, требующие восстановления корпоративного хранилища, могут быть вызваны различными факторами:

• Программные – ошибки в СУБД, инструментах загрузки, репликации, оркестрации и их некорректные обновления
• Кибератаки - несанкционированный доступ, вредоносное ПО, шифрование и утечка данных
• Человеческий фактор – ошибочные изменения или удаление данных, запуск неверных процедур, неверные настройки компонентов
• Технические - сбои в работе ЦОД, серверного оборудования, сетевой инфраструктуры
• Техногенные - пожар, перебои электропитания, затопления, и другие физические повреждения инфраструктуры

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

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

• В рамках анализа рисков обычно рассматриваются:
• Критичность источников данных для бизнеса
• Влияние простоев на отчетность и управленческие процессы
• Допустимое время недоступности систем

• RTO (Recovery Time Objective) – целевое время восстановления системы после сбоя (время простоя до восстановления)

• RPO (Recovery Point Objective) - допустимый объем потери данных при аварии

• Оркестраторов (Airflow и аналоги);
• Сервисов управления метаданными
• Систем очередей и стриминга
• Балансировщиков нагрузки

• Горячая (hot standby) - полностью готовая к работе среда с актуальными данными. Переключение происходит быстро, но требует значительных ресурсов
• Теплая (warm standby) - инфраструктура развернута, но требует дополнительного запуска сервисов и синхронизации
• Холодная (cold standby) - резерв в виде бэкапов и шаблонов инфраструктуры, восстановление занимает больше времени

• Контрольные точки (checkpoints) загрузки данных для сохранения состояния ETL/ELT
• Хранение состояния выполнения задач
• Версионность данных
• Механизм повторного воспроизведения потоков

• Какие компоненты задействованы в сценарии
• Какой триггер запускает сценарий
• Как это отражается на доступности данных, аналитике и отчетности
• Какие действия требуются для восстановления в каждом сценарии
• Какие целевые значения RTO/RPO должны быть

• Последовательность восстановления компонентов
• Роли и зоны ответственности в процедурах восстановления
• Контрольные точки, позволяющие убедиться, что система восстановлена корректно

• AirFlow - оркестратора для выполнения задач ETL, трансформаций данных, а также других задач, связанных с обслуживанием данных и сервисов
• Arenadata Cluster Manager - инструмента управления кластером Arenadata
• Airbyte - системы потоковой загрузки данных из разных источников
• ClickHouse сервера
• GitLab репозитория кода и CI/CD
• OpenMetadata – платформы для управления данными
• Кластера Arenadata / Greenplum для распределенного хранения данных

• Развертывание и восстановление AirFlow
• Переключение кластера Greenplum на резервный мастер-хост
• Процедуры сброса репликации и перезапуска коннекторов
• Процедуры восстановления данных из snapshot/backup и переинициализация репликации