有关设计灾难恢复策略的建议
适用于此 Power Platform Well-Architected 可靠性检查表建议：
| 回复：07 | 实施与恢复目标一致的结构化、测试和记录的业务连续性和灾难恢复 (BCDR) 计划。 计划必须涵盖所有组件和整个系统。 |
|---|
本指南介绍为工作负责设计可靠的灾难恢复策略的建议。 若要满足内部服务级别目标 (SLO) 甚至是向客户保证的服务级别协议 (SLA)，必须具有强大可靠的灾难恢复策略。 预计会出现故障和其他主要问题。 处理这些事件的准备工作决定了您的客户对您的企业为他们提供可靠服务的信任程度。 灾难恢复策略是重大事件准备的支柱。
定义
| 术语 | 定义 |
|---|---|
| 故障转移 | 动和/或手动将生产工作负载流量从不可用区域转移到不受影响的区域。 |
| 故障恢复 | 将生产工作负责流量从故障转移区域自动和/或手动转移回主要区域。 |
关键设计策略
本指南假定您已在可靠性规划过程中执行以下任务：
确定关键和非关键流。
为流执行故障模式分析 (FMA)。
确定可靠性目标。
设计稳健的测试策略。
可靠的灾难恢复 (DR) 策略建立在可靠的工作负载体系结构的基础之上。 在构建工作负载的每个阶段考虑可靠性问题，确保在开始设计 DR 策略之前，已准备好高效恢复所需的部分。 此基础可确保工作负载的可靠性目标（如恢复时间目标 (RTO) 和恢复点目标 (RPO)）是现实的且可实现的。
维护灾难恢复计划
工作负载的可靠 DR 策略的关键是 DR 计划。 您的计划应该是一个动态文档，随着环境的发展，定期审查和更新。 定期（例如，每六个月）与相关团队（运营、技术领导和业务利益相关者）分享该计划。 将其存储在高度可用、安全的数据存储中，如 OneDrive。
按照以下建议制定 DR 计划：
明确定义什么是灾难，因此需要激活 DR 计划。
灾难是大规模问题。 它们可能是区域性中断、服务中断（如 Microsoft Entra ID 或 Azure DNS）或严重的恶意攻击（如勒索软件攻击或 DDoS 攻击）。
在灾难恢复计划中明确不被视为灾难的故障模式示例，例如单个资源的不可用或故障，以便操作员不会错误地调用其灾难恢复升级。
在 FMA 文档中构建 DR 计划。 确保 DR 计划捕获定义为灾难的中断的故障模式和缓解策略。 如果需要更新，并行更新 DR 计划和 FMA 文档，以便在环境更改或测试发现意外行为时准确无误。
明确定义工作负载团队中的角色和职责，并了解组织中任何相关的外部角色。 如果灾难是由外部服务（如 Microsoft Entra ID）中断引起的，请确保定义负责与外部方通信并可以与工作负载团队共享更新的角色。 角色应包括：
- 负责宣布灾难的一方
- 负责宣布事件关闭的一方
- 操作角色
- 测试和验证角色
- 内部和外部通信角色
- 追溯和根本原因分析 (RCA) 领导角色
定义工作负载团队必须遵循的上报路径，以确保将恢复状态传达给利益干系人。
载明规定的顺序，以确保以影响最小的方式恢复工作负载组件。 例如，在恢复应用程序之前，恢复数据库并重启云端流。
作为分步指南，详细说明每个组件级恢复过程。 如果可能的话，包括屏幕截图和运行该过程的先决条件。 例如，列出需要收集的脚本或凭据。
定义团队的职责和云托管提供商的职责。 例如， Microsoft 负责还原 PaaS（平台即服务），但您负责解除冻结数据并将配置应用于服务。
在开始恢复之前，捕获事件的根本原因并执行缓解措施。 例如，如果事件发生的原因是安全问题，请在故障转移环境中恢复受影响的系统之前缓解该问题。
如果需要在故障转移环境中重新部署应用，请使用工具尽可能自动执行部署过程。 确保在故障转移环境中预先部署和配置 Azure 管道，以便可以立即开始应用部署。 根据需要使用自动化端到端部署和手动审批入口，以确保部署过程一致且高效。 当部署过程的某个阶段需要手动干预时，请记录手动步骤。 明确定义角色和职责。
尽可能多地自动执行该过程。 使用重试逻辑和断路器逻辑，以避免在中断的任务的停滞脚本上浪费时间。 由于仅在紧急情况下运行这些脚本，因此不希望错误开发的脚本造成更大的损害或减慢恢复过程。
备注
自动化会带来风险。 经过培训的操作员需要仔细监视自动化过程，并在任何进程遇到问题时进行干预。 若要最大程度地降低自动化对误报做出反应的风险，请在 DR 演练中彻底完成。 测试计划的所有阶段。 模拟检测以生成警报，然后完成整个恢复过程。
进行灾难恢复演练
DR 测试实践对于良好的 DR 计划至关重要。 许多行业都有合规性框架，要求定期执行指定数量的 DR 演练。 无论您属于哪个行业，定期的 DR 演练都对您的成功至关重要。
若要成功进行 DR 演练，请遵循以下建议：
每年至少执行一次生产 DR 演练。 试运行演练或非生产演练有助于确保相关方熟悉其角色和职责。 这些演练也有助于操作员通过遵循恢复流程来建立熟悉度。 但只有生产演练才能真正测试 DR 计划以及 RTO 和 RPO 指标的有效性。 使用生产演练来计时组件和流的恢复过程，以确保可实现为工作负载定义的 RTO 和 RPO 目标。 对于无法控制的函数（如 Microsoft Entra ID 中断），请确保涉及这些函数的流的 RTO 和 RPO 目标考虑到可能超出您控制范围的延迟。
使用试运行演练可以让新操作员了解 DR 流程和过程。 资深操作员应该花时间让新操作员履行其职责，并应寻找改进机会。 如果一名新操作员对程序中的某个步骤感到犹豫或困惑，请检查该程序以确保其内容写得很清楚。
注意事项
在生产环境中执行 DR 演练可能会导致意外的灾难性故障。 在初始部署期间，请务必在非生产环境中测试恢复过程。
在演练期间，为团队提供尽可能多的维护时间。 规划维护时间时，请使用在测试过程中获得的恢复指标作为所需的最短时间分配。
随着 DR 演练实践的成熟，您将了解哪些过程可以并行运行，哪些过程必须按顺序运行。 在演练的早期，假设每个程序都必须按顺序运行，并且每个步骤都需要额外的时间来处理意外问题。
故障转移功能
Microsoft 业务应用程序为 Dynamics 365 中的所有生产 Power Platform 环境和软件即服务（SAAS）应用程序提供业务连续性和灾难恢复（BCDR）功能。 Microsoft 了解如何确保您的生产数据在区域性中断期间具有弹性。
可靠性清单
请参考整套建议。