适用于此 Azure Well-Architected 框架可靠性清单建议：
| RE：09 | 实现结构化、测试和记录的业务连续性和灾难恢复（BCDR）计划，这些计划符合恢复目标。 计划必须涵盖所有组件和整个系统。 |
|---|
本指南介绍为工作负荷设计可靠的灾难恢复策略的建议。 若要满足为客户保证的内部服务级别目标（SLA），甚至服务级别协议（SLA），必须制定可靠可靠的灾难恢复策略。 预计会出现故障和其他主要问题。 你应对这些事件的准备工作决定了客户对你的业务能够可靠交付的信任程度。 灾难恢复策略是准备重大事件的骨干。
定义
| 术语 | 定义 |
|---|---|
| 故障转移 | 将生产工作负荷流量从不可用区域自动和/或手动转移到不受影响的地理区域。 |
| 故障回复 | 将生产工作负荷流量从故障转移区域自动和/或手动转移到主要区域。 |
关键设计策略
本指南假定你已执行以下任务作为可靠性规划的一部分：
可靠的灾难恢复（DR）策略建立在可靠的工作负荷体系结构的基础之上。 在构建工作负荷的每个阶段都解决可靠性问题，确保在开始设计 DR 策略之前，已准备好优化恢复所需的部分。 此基础可确保工作负荷的可靠性目标（如恢复时间目标（RTO）和恢复点目标（RPO）是现实可行的且可实现的。
维护灾难恢复计划
工作负荷可靠 DR 策略的基石是 DR 计划。 你的计划应该是一个活生生的文档，随着环境的发展，定期审查和更新。 定期向相应的团队（运营、技术领导和业务利益干系人）（例如，每六个月）提出计划。 将其存储在高度可用的安全数据存储（如 OneDrive for Business）中。
按照这些建议制定灾难恢复（DR）计划：
明确定义构成灾难的内容，因此需要激活 DR 计划。
灾难是大规模问题。 它们可能是区域性服务中断、Microsoft Entra ID 或 Azure DNS 等服务中断，或者勒索软件攻击或 DDoS 攻击等严重恶意攻击。
确定不被视为灾难的故障模式，例如单个资源的故障，以便操作员不会错误地触发其 DR（灾难恢复）升级。 可以通过对问题进行故障排除、重新部署失败的资源或使用备份计划来解决这些故障模式
根据 FMA 文档构建 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 演练可能会导致意外的灾难性故障。 在初始部署期间，请务必在非生产环境中测试恢复过程。
在演练期间，为团队提供尽可能多的维护时间。 规划维护时间时，请使用 在测试 期间捕获的恢复指标作为 所需的最低时间 分配。
随着 DR 演练实践的成熟，你将了解可以并行运行哪些过程，以及必须按顺序运行的过程。 在演练实践的早期，假设每个过程都必须按顺序运行，并且需要在每个步骤中额外时间来处理意外的问题。
为关键流中的资源定义和维护备份计划
备份是整个恢复过程的重要组成部分。 通常，这只是需要恢复的环境的一部分。 DR 计划通常在应用程序范围内，或者甚至在区域范围内。 意外或恶意删除数据、文件损坏、恶意软件和目标勒索软件攻击都可能会影响工作负荷的可用性。 为环境的每个部分制定可靠的备份计划与制定有效的 DR 计划一样重要，因为 DR 计划取决于可靠的备份计划才能有效。 与 DR 计划一样，备份计划还需要由适当的管理级别达成一致，定期重新访问可能的更新，并在高度可用的安全数据存储中记录。
为属于工作负荷中关键路径的不同 Azure 服务确定适当的备份解决方案。
为每个不同的服务定义所需的保留期。
了解一个工具可能不适用于所有情况。 Azure 备份工具可以涵盖许多资源类型，但并非所有资源类型。
有时，还原某些类型的对象的最佳选择是从某种级别的高可用性存储库重新部署。 （Azure DevOps、GitHub 或其他）
数据服务的要求与应用程序相关对象不同。
请务必考虑备份数据的多区域存储策略，以创建跨区域可恢复性。
定期运行备份数据的计划测试还原，以确保服务按预期工作。
Azure DR 便利化
许多 Azure 产品具有内置的故障转移功能。 熟悉这些功能，并将其包含在恢复过程中。
对于 IaaS（基础结构即服务）系统，请使用 Azure Site Recovery 自动执行故障转移和恢复。 有关常见 PaaS 产品，请参阅以下文章：
示例
有关为 DR 准备企业数据资产的指导，请参阅适用于 Azure 数据平台系列的 DR。
Azure 备份便利化
许多 Azure 产品具有内置的备份功能。 熟悉这些功能，并将其包含在恢复过程中。
对于 IaaS（基础结构即服务）系统，请使用 Azure 备份 来帮助备份 VM 和 VM 相关服务和某些数据服务。 有关常见产品，请参阅以下文章：
相关链接
可靠性清单
请参阅完整的建议集。