你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
有关设计灾难恢复策略的建议
适用于此 Azure Well-Architected 框架可靠性清单建议：
| RE：09 | (与恢复目标一致的 BCDR) 计划实施结构化、测试和记录的业务连续性和灾难恢复。 计划必须涵盖所有组件和整个系统。 |
|---|
本指南介绍为工作负荷设计可靠的灾难恢复策略的建议。 若要满足内部服务级别目标 (SLO) 甚至服务级别协议（ (SLA) 已保证），必须具有可靠可靠的灾难恢复策略。 预计会出现故障和其他主要问题。 处理这些事件的准备工作决定了你的客户可以信任你的企业为他们可靠交付多少。 灾难恢复策略是重大事件准备的支柱。
定义
| 术语 | 定义 |
|---|---|
| 故障转移 | 自动和/或手动将生产工作负载流量从不可用区域转移到不受影响的地理区域。 |
| 故障回复 | 将生产工作负荷流量从故障转移区域自动和/或手动转移回主要区域。 |
关键设计策略
本指南假定你已在可靠性规划过程中执行以下任务：
可靠的灾难恢复 (DR) 策略建立在可靠的工作负载体系结构的基础之上。 在构建工作负载的每个阶段解决可靠性问题，确保在开始设计 DR 策略之前，已准备好优化恢复所需的部分。 此基础可确保工作负载的可靠性目标（如恢复时间目标 (RTO) 和恢复点目标 (RPO) ）是现实的且可实现的。
维护灾难恢复计划
工作负载的可靠 DR 策略的基础是 DR 计划。 你的计划应该是一个动态文档，随着环境的发展，定期审查和更新。 向相应的团队提交计划， (运营、技术领导和业务利益干系人) 每六个月定期 (，例如) 。 将其存储在高度可用、安全的数据存储中，例如OneDrive for Business。
按照以下建议制定 DR 计划：
明确定义什么是灾难，因此需要激活 DR 计划。
灾难是大规模问题。 它们可能是区域性服务中断、Microsoft Entra ID 或 Azure DNS 等服务中断，也可能是勒索软件攻击或 DDoS 攻击等严重恶意攻击。
确定不被视为灾难的故障模式，例如单个资源的故障，以便操作员不会错误地调用其 DR 升级。
在 FMA 文档中构建 DR 计划。 确保 DR 计划捕获定义为灾难的中断的故障模式和缓解策略。 并行更新 DR 计划和 FMA 文档，以便在环境更改或测试发现意外行为时准确无误。
- 是否为非生产环境制定 DR 计划取决于业务需求和成本影响。 例如，如果向某些客户提供质量保证 (QA) 环境进行预发行版测试，则可能需要将这些环境包含在 DR 规划中。
明确定义工作负载团队中的角色和职责，并了解组织内的任何相关外部角色。 角色应包括：
负责宣布灾难的一方。
负责宣布事件关闭的一方。
操作角色。
测试和验证角色。
内部和外部通信角色。
RCA) 主角 (追溯和根本原因分析。
定义工作负载团队必须遵循的升级路径，以确保将恢复状态传达给利益干系人。
捕获组件级恢复过程、数据资产级恢复和工作负载范围的恢复过程。 包括规定的操作顺序，以确保以影响最小的方式恢复组件。 例如，在恢复应用程序之前，先恢复和检查数据库。
作为分步指南，详细说明每个组件级恢复过程。 如果可能，请包含屏幕截图。
定义团队的责任与云托管提供商的责任。 例如，Microsoft 负责还原 PaaS (平台即服务) ，但你负责解除冻结数据并将配置应用于服务。
包括运行该过程的先决条件。 例如，列出需要收集的所需脚本或凭据。
在开始恢复之前，请捕获事件的根本原因并执行缓解措施。 例如，如果事件发生的原因是安全问题，请在故障转移环境中恢复受影响的系统之前缓解该问题。
根据工作负荷的 冗余设计 ，可能需要在故障转移后执行大量工作，然后才能再次向客户提供工作负载。 故障转移后的工作可能包括 DNS 更新、数据库连接字符串更新和流量路由更改。 捕获恢复过程中的所有故障转移后工作。
如果需要在故障转移环境中重新部署应用，请使用工具尽可能自动执行部署过程。 确保在故障转移环境中预先部署和配置 DevOps 管道，以便可以立即开始应用部署。 根据需要使用自动化端到端部署和手动审批入口，以确保部署过程一致且高效。 完整部署持续时间需要与恢复目标保持一致。
- 当部署过程的某个阶段需要手动干预时，请记录手动步骤。 明确定义角色和职责。
尽可能多地自动执行该过程。 在脚本中，使用声明性编程，因为它允许幂等性。 如果无法使用声明性编程，请注意开发和运行自定义代码。 使用重试逻辑和断路器逻辑，以避免在中断的任务上停滞的脚本上浪费时间。 由于仅在紧急情况下运行这些脚本，因此不希望错误开发的脚本造成更大的损害或减慢恢复过程。
注意
自动化会带来风险。 经过培训的操作员需要仔细监视自动化过程，并在任何进程遇到问题时进行干预。 若要最大程度地降低自动化对误报做出反应的风险，请在 DR 演练中彻底完成。 测试计划的所有阶段。 模拟检测以生成警报，然后完成整个恢复过程。
请记住，DR 演练应验证或通知对恢复目标指标的更新。 如果发现自动化容易出现误报，则可能需要提高故障转移阈值。
将故障回复计划与 DR 计划分开，以避免与 DR 过程产生潜在的混淆。 故障回复计划应遵循 DR 计划的所有开发和维护建议，并且应以相同的方式进行结构。 故障转移所需的任何手动步骤都应在故障回复计划中进行镜像。 故障回复可能在故障转移后快速发生，或者可能需要数天或数周的时间。 将故障回复视为独立于故障转移。
- 故障回复的需求是按情况决定的。 如果出于性能原因在区域之间路由流量，则故障回复最初位于故障转移区域中的负载非常重要。 在其他情况下，你可能已将工作负荷设计为完全正常运行，无论它位于哪个生产环境，它随时都可以运行。
进行灾难恢复演练
DR 测试实践与完善的 DR 计划一样重要。 许多行业都有合规性框架，要求定期执行指定数量的 DR 演练。 无论你的行业如何，定期的 DR 演练都对你的成功至关重要。
若要成功进行 DR 演练，请遵循以下建议：
每年至少执行一次生产 DR 演练。 桌面 (试运行) 演练或非生产演练有助于确保相关方熟悉其角色和职责。 这些演习还帮助操作员通过遵循恢复过程 (“肌肉记忆”) 建立熟悉度。 但只有生产演练才能真正测试 DR 计划以及 RTO 和 RPO 指标的有效性。 使用生产演练来计时组件和流的恢复过程，以确保可实现为工作负载定义的 RTO 和 RPO 目标。 对于无法控制的函数（如 DNS 传播），请确保涉及这些函数的流的 RTO 和 RPO 目标考虑到可能超出你控制范围的延迟。
使用桌面钻取不仅可让经验丰富的操作员熟悉，还可以让新操作员了解 DR 流程和过程。 高级操作员应花时间让新操作员执行其角色，并应watch改进机会。 如果新运算符对过程中的某个步骤犹豫不决或感到困惑，请查看该过程以确保它已写得很清楚。
注意事项
在生产环境中执行 DR 演练可能会导致意外的灾难性故障。 在初始部署期间，请务必在非生产环境中测试恢复过程。
在演练期间，为团队提供尽可能多的维护时间。 规划维护时间时，请使用 在测试 期间捕获的恢复指标作为 所需的最短时间 分配。
随着 DR 演练实践的成熟，你将了解哪些过程可以并行运行，哪些过程必须按顺序运行。 在演练的早期，假设每个过程都必须按顺序运行，并且每个步骤都需要额外的时间来处理意外的问题。
Azure 便利化
许多 Azure 产品都具有内置的故障转移功能。 熟悉这些功能，并将其包含在恢复过程中。
对于 IaaS (基础结构即服务) 系统，请使用 Azure Site Recovery自动执行故障转移和恢复。 有关常见 PaaS 产品，请参阅以下文章：
示例
有关为 DR 准备企业数据资产的指南，请参阅 适用于 Azure 数据平台的 DR 系列 。
相关链接
可靠性清单
请参阅完整的一组建议。