概述
本系列提供了一个组织如何为 Azure 企业数据平台设计灾难恢复 (DR) 策略的说明性示例。
Azure 提供了广泛的复原能力选项，可在发生灾难时提供服务连续性。 但更高的服务级别可能会带来复杂性和成本溢价。 涉及到 DR 时，成本、复原能力和复杂性之间的权衡是大多数客户的关键决策因素。
虽然 Azure 服务中偶尔会发生点故障，但应该注意的是，Microsoft 数据中心和 Azure 服务内置了多层冗余。 任何故障通常范围有限，常在几小时内恢复。 从历史上看，关键服务（如标识管理）遇到服务问题的可能性要远远超过整个 Azure 区域脱机的情况。
还应承认，网络攻击（尤其是勒索软件）现在对任何新式数据生态系统都构成了切实威胁，并可能导致数据平台中断。 虽然这不在本系列文章的讨论范围中，但建议客户在任何数据平台的安全性和复原能力设计过程中实施针对此类攻击的控制措施。
- Azure 云基础知识中提供了有关勒索软件防护的 Microsoft 指南
范围
本系列文章的范围包括：
- Azure 数据平台从物理灾难中的服务恢复，以客户为例。 此说明性客户是：
- 遵循基于信息技术基础结构库 (ITIL) 的服务管理方法，具有定义的运营支持功能的中型组织
- 不是云原生，其核心企业共享服务（如访问和身份验证管理以及事件管理）仍保留在本地
- 在云迁移到 Azure 的过程中，通过自动化实现
- Azure 数据平台已在客户的 Azure 租户中实现了以下设计
- 企业登陆区域 - 提供平台基础，包括网络、监视、安全性等。
- Azure 分析平台 - 提供支持服务提供的各种解决方案和数据产品的数据组件
- 此过程将由 Azure 技术资源而不是专业的 Azure 主题专家 (SME) 执行。 因此，这些资源应具备以下知识/技能水平
- Azure 基础知识 - Azure 及其核心服务和数据组件的实践知识
- Azure DevOps 的实践知识。 能够导航源代码管理并执行管道部署
- 此过程描述了从主要区域到次要区域的故障转移过程
超出范围
以下项目被视为不在本系列文章涵盖范围内：
- 从次要区域回退到主要区域的回退过程
- 任何非 Azure 应用程序、组件或系统 - 包括但不限于本地、其他云供应商、第三方 Web 服务等。
- 恢复任何上游服务，如本地网络、网关、企业共享服务等，这些都是该过程的先决条件
- 恢复任何下游服务，如本地操作系统、第三方报告系统、数据建模或数据科学应用程序等，这些服务都依赖于该流程来恢复自身的服务
- 数据丢失方案，包括从勒索软件或类似数据安全事件中恢复
- 数据备份策略和数据还原计划
- 确定 DR 事件的根本原因
- 对于 Azure 服务/组件事件，Microsoft 会在状态 - 历史记录网页中发布“根本原因分析”
关键假设
此 DR 工作示例的主要假设是
- 组织遵循基于 ITIL 的服务管理方法，为 Azure 数据平台提供运营支持
- 组织有一个现有的灾难恢复过程，作为 IT 资产服务还原框架的一部分
- 基础结构即代码 (IaC) 已用于部署由自动化服务（如 Azure DevOps 或类似服务）启用的 Azure 数据平台
- Azure 数据平台托管的每个解决方案都已完成业务影响评估或类似评估，为恢复点目标 (RPO)、恢复时间目标 (RTO) 和 MTO 提供了明确的服务要求
后续步骤
现在，你已大致了解了方案，接下来可以继续了解专为用例设计的体系结构。