你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
适用于此 Azure Well-Architected 框架可靠性清单建议：
| RE：09 | 实现结构化、测试和记录的灾难恢复（DR）计划，这些计划符合恢复目标。 计划必须涵盖所有组件和整个系统。 |
|---|
灾难是需要工作负荷和运营团队仔细规划和主动准备的重大事件。
本文概述了灾难恢复的关键策略，强调可复原的工作负荷设计、数据完整性以及明确定义的故障转移和恢复目标。 它侧重于 DR 的用途和指导原则，而不是分步过程。 有关详细的实施指南，包括分步流程和手册，请参阅配套文章：为多区域部署制定灾难恢复计划。
定义
| 术语 | 定义 |
|---|---|
| 主动-被动冷备 | 一种 DR 部署模式，其中次要区域在发生灾难之前运行最少或没有基础结构，需要在故障转移期间进行完整部署。 |
| 主动-被动热备用 | 一种 DR 部署模式，其中次要区域的基础设施已预部署并以降低的容量运行，从而实现比冷备用更快的故障转移。 |
| 备份 | 与主系统分开存储的数据的副本，以便在发生丢失、损坏或灾难时启用数据恢复 |
| 业务关键性 | 工作负荷或组件的分类，具体取决于其对业务运营的重要性，影响恢复优先级和投资级别。 |
| DR 激活条件 | 预定义的阈值和条件，用于确定何时声明灾难和触发恢复过程。 |
| DR 演练 | 一个计划练习，用于测试灾难恢复过程，并在受控条件下验证恢复功能。 |
| 故障回复 | 将生产工作负荷流量从故障转移区域自动和/或手动转移到主要区域。 |
| 故障转移 | 将生产工作负荷流量从不可用区域自动和/或手动转移到不受影响的地理区域。 |
| 时间点还原 | 将数据还原到特定时间点的功能，通常用于从数据损坏或意外更改中恢复。 |
| 恢复点目标 （RPO） | 时间测量的最大可接受数据丢失量，定义企业在灾难期间可承受的数据量。 |
| 恢复时间目标 （RTO） | 发生灾难后恢复业务运营的可接受的最长时间。 |
| 同步复制 | 数据复制中，变更被同时写入多个位置，确保零数据丢失，但延迟可能更高。 |
| 异步复制 | 数据复制在这种方式中，变更首先被写入主位置，然后再复制到次要位置，以容忍某些数据丢失为代价，降低延迟。 |
| 作战室 | 一个集中的位置或通信渠道，关键人员在灾难恢复操作期间协调。 |
按业务影响确定优先级
按组织定义的关键性层对工作负荷进行分类，例如任务关键、业务关键型、业务运营等。 认识到每个层需要不同级别的投资、复原和恢复排序。 如果工作负荷包含多个具有不同关键性的流或组件，请记录每个流的恢复方法，以避免在事件期间出现歧义。
这些关键层会影响适当的恢复目标。 较高的关键性组件需要更快的恢复和更频繁的数据保护，而较低的关键性组件可以容忍较慢的还原。 从这些要求 中，派生明确的 RTO 和 RPO 目标，这些目标直接与业务价值保持一致。
定义灾难阈值
确保团队和业务利益干系人确切地了解什么是灾难和什么不算。 你的策略必须区分完全灾难、重大中断和可以快速修复的小问题。 不要仅基于可能会出故障的组件来下决定。 相反，考虑问题对用户和整个企业的影响程度。
定义将次要事件与真实 DR 情况分开的阈值后，将它们构建到 运行状况模型中。 这样，监视可以发现预警信号，并触发适当的恢复过程。
建立通信协议
如果没有明确的通信，即使是设计最佳的灾难恢复计划也可以分解。 构建明确的通信策略，用于定义谁做出决策、谁获得通知，以及信息在 DR 事件期间如何流动。
首先在任务团队中概述角色和职责，以及涉及的任何外部团队。 其中包括负责声明灾难、关闭事件、运行操作任务、执行测试和验证、管理内部和外部沟通，以及领导回顾或根本原因分析的所有者。
提供分步说明、列出所有先决条件（例如脚本、凭据和配置），并定义团队与云提供商之间的职责。 在恢复开始防止重复失败之前，请确保解决根本原因问题。
建立跨职能作战室，确保合适的人员能够快速协调，并提前准备沟通渠道和消息模板，以便团队不会在压力下即兴进行。
定义工作负荷团队必须遵循的升级路径，以确保将恢复状态传达给利益干系人。
设计恢复感知体系结构
灾难恢复过程应反映工作负荷的设计方式，相反，恢复要求应从一开始就影响体系结构决策。 在设计系统时，请考虑在灾难期间如何恢复，并选择支持恢复要求的 主动-被动冷备用 或 主动-被动热备用等模式。
对于数据恢复，请使用基于 RPO 目标的复制策略。 例如，跨可用性区域同步用于高优先级数据，跨区域异步用于低优先级数据。 确保一致性模型支持恢复、实现频繁的完整备份和时间点恢复、考虑数据存储之间的依赖关系，并在恢复期间自动执行完整性检查。
注释
设计工作负载，使其具有包容性和隔离性，以允许单个组件部分故障迁移。 这样可以降低复杂性、成本和RTO，并且无需声明全面灾难就能保持部分可用性。 单独测试部分故障转移，并记录何时应触发这些故障转移。
准备基础结构和恢复过程
提前准备次要区域。 生成清单，以便团队在事件发生时准备就绪，例如：
- 计算层：对于暖态的主动/被动工作负载，提前部署最少量的计算资源以支持快速故障转移。
- 网络基础结构：复制拓扑，包括 VNet、子网、路由、防火墙和安全组，并确认所有配置。
- 标识与访问管理：重复账户设置、角色访问控制（RBAC）权限和策略，确保安全基线与生产环境保持一致。
- 监视：部署监视基础结构，并配置警报和仪表板，以增强监控的清晰度。
对恢复过程进行分层。 组件级别、数据资产级别和工作负荷级别的结构过程。 定义适当的顺序以最大程度地减少影响。 例如，应该在依赖数据库的应用程序之前还原数据库。 根据业务影响定义范围。 确定哪些环境、生产和（如有必要）非生产环境需要 DR 覆盖范围，考虑客户的影响和成本。
使故障回复机制与故障转移策略分开。
风险： 故障回复需求的依据取决于情况：例如，如果流量在区域之间由于性能原因被重新路由，则将其恢复到原始区域非常重要。 在其他情况下，无论哪个环境处于活动状态，工作负荷都可以完全正常运行。 如果未将故障回复视为独立于故障转移的不同明确定义的过程，团队可能会遇到混淆、导致未完成还原或长时间停机的情况。
若要缓解该风险，请创建故障回复计划，使用与 DR 计划相同的原则生成和维护故障回复计划，包括镜像故障转移中的任何手动步骤。 故障恢复可能立即发生，或者在几天或几周内发生，但应将其视为单独的过程。
规划故障转移后的工作。 捕获故障转移后所需的所有任务，例如 DNS 更新、流量路由和连接字符串调整，以确保工作负载完全恢复上线。
实施可靠的备份策略
选择针对每个 Azure 服务定制的备份解决方案，定义保留期，并识别没有任何工具涵盖所有内容。 考虑使用多区域存储实现跨区域可恢复性，对于某些资源，请使用从高度可用的存储库重新部署。 定期测试还原以验证备份，并定期查看和更新计划，安全地存储这些备份并使其可供相关团队访问。
进行常规练习
DR 计划仅在实际条件下验证时才有意义。 测试多个方案，包括边缘案例，并将计划的演练与惊喜游戏日相结合，了解系统和团队在压力下的反应。
在灾难恢复 (DR) 计划中，包括桌面推演的过程和节奏、非生产环境中的模拟运行和生产级别演练。 桌面演练可帮助团队练习其角色、提高熟悉度并训练新成员，同时生产演练是验证计划在实际条件下是否满足 RTO 和 RPO 目标的唯一方法。 对于控制外部的进程（如 DNS 传播），请在评估恢复时间时验证潜在的延迟。
制定一个将测试结果视为输入以改进总体 DR 状况的过程。 例如，如果新操作员有所犹豫，请查看该流程以确保其书写清晰。
测试和验证整体和组件级别的 RTO 和 RPO，分开进行，而不是依赖完整的灾难恢复演练。 包括跨区域移动数据或从冷存储还原等方案，以确保实现目标。
使计划保持更新且可执行
将 DR 计划视为活文档。 随着环境的变化，你的计划应随着环境的变化而发展，并且应定期与所有相关团队、运营、技术领导和业务利益干系人一起审查，最好每六个月审查一次。
保持灾难恢复计划与故障模式分析文档一致，记录系统在灾难期间的行为和响应措施。 发现新的故障案例时，通过测试、监视或实际事件更新计划以包括这些情况。 每当环境发生更改或测试发现意外行为时，请确保更新 DR 计划和 FMA 文档。
随着时间的推移优化过程。 在 DR 实践的早期，假设每个过程必须按顺序运行，并允许为意外问题留出额外的时间。 随着 DR 实践的成熟，请确定哪些步骤可以安全地并行运行。 优化还应捕获体系结构更改。 每当工作负荷体系结构发生更改时，请更新 DR 计划，明确定义对激活条件或恢复过程的任何调整。
规划实际恢复时间。 在计划演练时，使用测试中的指标作为恢复步骤所需的最短时间。
确保在中断期间可访问性
仅当计划和执行所需的工具在所有故障条件下都可用时，灾难恢复才成功。
将灾难恢复文档、脚本和恢复组件存储在高度可用、安全的位置，以便即使在区域性中断期间仍可访问这些组件。 保护所有 DR 资产，包括计划、凭据、证书和脚本，并跨区域复制它们。 保留脱机副本或打印副本，以备不时之需。 在每个区域预部署 CI/CD 管道，以便它们在需要时可立即运行。
安全地自动执行恢复过程
尽可能自动执行故障转移环境中的部署和恢复过程，确保它们满足 RTO 目标。 使用声明性脚本和幂等脚本以提高可靠性，并为任何自定义代码构建例如重试和断路器逻辑的保护措施。 预先部署和配置 DevOps 管道，以便部署可以立即启动，仅在需要时才使用具有手动审批入口的自动化端到端流程。 确保部署时间线与恢复目标保持一致。
必要时应用手动审批，以平衡速度与控制。 需要手动步骤时，请明确记录这些步骤并定义角色和职责。
Azure 协助
许多 Azure 产品具有内置的故障转移功能。 熟悉这些功能，并将其包含在恢复过程中。 有关为 DR 准备企业数据资产的指导，请参阅适用于 Azure 数据平台系列的 DR。
对于 IaaS（基础结构即服务）系统，请使用 Azure Site Recovery 自动执行故障转移和恢复。 有关常见 PaaS 产品，请参阅以下文章：
许多 Azure 产品具有内置的备份功能。 熟悉这些功能，并将其包含在恢复过程中。
对于 IaaS（基础结构即服务）系统，请使用 Azure 备份 来帮助备份 VM 和 VM 相关服务和某些数据服务。 有关常见产品，请参阅以下文章：
相关链接
可靠性清单
请参阅完整的建议集。