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