概述
本系列提供了一个说明示例，说明组织如何为 Azure 企业数据平台设计灾难恢复（DR）策略。
Azure 提供了广泛的复原能力选项，可在发生灾难时提供服务连续性。 但更高的服务级别可能会带来复杂性和成本溢价。 涉及到 DR 时，成本、复原能力和复杂性之间的权衡是大多数客户的关键决策因素。
尽管偶尔在 Azure 平台上发生点故障，但Microsoft的 Azure 数据中心和 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）和平均恢复时间（MTTR）指标提供明确的服务要求。
后续步骤
现在，你已大致了解了方案，接下来可以继续了解专为用例设计的体系结构。