Аварийное восстановление для платформы данных Azure

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

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

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

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

Дополнительные сведения см. в разделе "Резервное копирование и восстановление" для защиты от программ-шантажистов.

Scope

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

  • Организация среднего или крупного размера, имеющая выделенную функцию операционной поддержки, которая следует методологии управления ИТ-услугами ITIL.

  • Не облачно-нативное. Основные корпоративные общие службы, такие как управление удостоверениями и управление инцидентами, остаются локальными.

  • Миграция на Azure с помощью развертываний с поддержкой автоматизации.

Платформа данных реализует следующие архитектурные решения в среде Azure заказчика:

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

  • Платформа аналитики Azure, которая предоставляет компоненты данных для различных решений и продуктов данных

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

  • Рабочие знания о Azure, основных службах и компонентах данных. Дополнительные сведения см. в статье "Основы Azure".

  • Практическое знание Azure DevOps, включая навигацию по системе контроля версий и запуск конвейеров.

Вне сферы действия

Эта серия не охватывает следующее:

  • Переключение с вторичного региона на основной регион.

  • Не Azure приложения, компоненты или системы, такие как локальные системы, другие поставщики облачных служб и внешние веб-службы.

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

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

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

  • Стратегии резервного копирования данных и планы восстановления данных.

  • Анализ первопричин (RCA) для события аварийного восстановления. Для инцидентов службы Azure Microsoft публикует отчеты RCA на странице журнала состояния Azure.

Ключевые предположения

В этом примере предполагается, что:

  • Организация следует методологии управления службами на основе ITIL для оперативной поддержки платформы данных Azure.

  • У организации есть существующий процесс аварийного восстановления в рамках своей системы восстановления ИТ-сервисов.

  • Организация использует инфраструктуру в качестве кода (IaC) для развертывания платформы данных Azure через службу автоматизации, например Azure DevOps.

  • Организация проводит оценку воздействия на бизнес для каждого решения на платформе данных с определёнными метриками: целевая точка восстановления (RPO), целевое время восстановления (RTO) и среднее время восстановления (MTTR).

Следующий шаг

После просмотра сценария ознакомьтесь с архитектурой этого варианта использования.

  • Last updated on