Обзор
В этой серии представлен пример того, как организация может разработать стратегию аварийного восстановления (DR) для корпоративной платформы данных Azure.
- Эта серия статей дополняет рекомендации, предоставляемые Microsoft Cloud Adoption Framework, Azure Well-Architected Framework и управление непрерывностью бизнес-процессов.
Azure предоставляет широкий спектр вариантов устойчивости, которые могут обеспечить непрерывность служб в случае аварии. Но более высокие уровни обслуживания могут привести к сложности и стоимости премиум. Компромисс между затратами и устойчивостью и сложностью является ключевым фактором принятия решений для большинства клиентов в отношении аварийного восстановления.
Хотя случайные сбои точки происходят на платформе Azure, центры обработки данных Microsoft Azure и службы Azure имеют несколько уровней избыточности. Любой сбой обычно ограничен в области и обычно устраняется в течение нескольких часов. Исторически это гораздо более вероятно, что ключевая служба, например управление удостоверениями, возникает проблема со службой, а не весь регион Azure в автономном режиме.
Следует также признать, что кибератаки, особенно программы-шантажисты, теперь представляют собой реальную угрозу для любой современной экосистемы данных и могут привести к сбою платформы данных. Хотя это не является областью действия для этой серии, клиентам рекомендуется реализовать средства управления такими атаками в рамках разработки безопасности и устойчивости любой платформы данных.
- Руководство майкрософт по защите от программ-шантажистов доступно в azure Cloud Fundamentals
Область
Область действия этой серии статей включает:
- Восстановление службы платформы данных Azure из физической аварии для иллюстрирующей персоны клиента. Этот иллюстрированный клиент:
- Средняя организация с определенной функцией операционной поддержки после методологии управления службами на основе библиотеки ит-технологий (ITIL).
- Не облачная среда, с основным предприятием, общими службами, такими как управление доступом и проверкой подлинности, а также управление инцидентами, оставшимися в локальной среде.
- На пути миграции в облако в Azure, включенную автоматизацией.
- Платформа данных Azure реализовала следующие проекты в клиенте в клиенте:
- Целевая зона предприятия — предоставление платформы, включая сети, мониторинг, безопасность и т. д.
- Платформа аналитики Azure. Предоставление компонентов данных, поддерживающих различные решения и продукты данных, предоставляемые службой.
- Процессы, описанные в этой статье, будут выполняться техническим ресурсом Azure, а не специалистом по вопросам субъекта Azure (SME). Таким образом, ресурсы должны иметь следующий уровень знаний и навыков:
- Основы Azure — рабочие знания о Azure, ее основных службах и компонентах данных.
- Рабочие знания о Azure DevOps. Возможность перемещаться по системе управления версиями и выполнять развертывания конвейеров.
- Эти процессы, описанные в этой статье, охватывают операции отработки отказа службы из основного в дополнительный регион.
Вне области
Для этой серии статей рассматриваются следующие элементы:
- Резервный процесс из дополнительного региона обратно в основной регион.
- Все приложения, компоненты или системы, отличные от Azure, включают в себя, но не ограничиваются локальными, другими поставщиками облачных служб, сторонними веб-службами и т. д.
- Восстановление всех вышестоящих служб, таких как локальные сети, шлюзы, корпоративные общие службы и другие, независимо от любых зависимостей от этих служб.
- Восстановление всех подчиненных служб, таких как локальные операционные системы, сторонние системы отчетности, моделирование данных или приложения для обработки и анализа данных, а также другие, независимо от любых зависимостей от этих служб.
- Сценарии потери данных, включая восстановление от программ-шантажистов или аналогичных инцидентов безопасности данных
- Стратегии резервного копирования данных и планы восстановления данных
- Установка первопричины события аварийного восстановления.
- Для инцидентов службы и компонентов Azure корпорация Майкрософт публикует "Анализ первопричин" на веб-странице "Состояние — журнал"
Ключевые предположения
Основные предположения для этого примера аварийного восстановления:
- Организация следует методологии управления службами на основе ITIL для операционной поддержки платформы данных Azure.
- Организация имеет существующий процесс аварийного восстановления в рамках платформы восстановления службы для ИТ-ресурсов.
- Инфраструктура как код (IaC) использовалась для развертывания платформы данных Azure, включенной службой автоматизации, например Azure DevOps или аналогичной.
- Каждое решение, размещенное платформой данных Azure, завершило оценку влияния на бизнес или аналогичное, предоставляя четкие требования к службе для целевой точки восстановления (RPO), целевой цели восстановления (RTO) и среднее время для восстановления метрик (MTTR).
Следующие шаги
Теперь, когда вы узнали о сценарии на высоком уровне, вы можете перейти к изучению архитектуры , предназначенной для варианта использования.