为多区域部署制定灾难恢复计划

作为云解决方案架构师，您在确保恢复计划、设计和记录广泛范围故障为灾难恢复（DR）计划方面发挥重要作用。 如果失败，该计划的质量会影响事件是暂时挫折还是成为声誉和金融危机。

该计划应基于业务优先级指导的策略，并受可衡量目标的约束。 本文指导你制定实际的灾难恢复（DR）计划，首先从恢复服务的基础实践开始，然后转向思维方式的转变，以便在压力下维护业务连续性。

术语

在开始制定计划之前，建议熟悉常用词汇。 将这些术语确定为共享语言，以便在激活 DR 计划时启用明确的通信和协调决策。

什么是灾难恢复？

灾难恢复（DR）是一种在发生重大故障事件后还原系统或关键部分的战略和有条不紊的方法。

在云环境中，临时故障是正常的。 这些短暂的中断（通常称为 闪烁 或 暂时性故障）可能会导致隔离组件不可用或性能意外下降。 它们通常通过平台复原功能和内置的自我修复机制来解决，无需人工干预。

但是，灾难是另一类事件。 它们范围广泛，同时影响多个系统或服务，并可能使系统停止。 这些事件需要外部干预和专用角色，由定义完善的 DR 计划指导，当系统的内置自我修复复原能力不足时，可以激活该计划。 一些示例包括：

• 完整的区域性中断

• 失去控制平面访问或服务管理功能

• 恶意活动或严重配置错误导致生产环境损坏

• 影响系统的多层严重基础结构故障

• 自然灾害或地缘政治事件导致服务长时间不可用

无人注意的小故障可能会升级为全面灾难。 尽管高级监视和运行状况建模有助于尽早检测和缓解这些问题，但本主题超出了本文的范围。 有关详细信息，请参阅 健康建模。

DR 的最终目标是在定义的定量指标内保持业务连续性。 将该计划视为一项协调工作，需要预定义的程序、明确的通信协议和执行级别的决策。

选择关键性等级

并非所有工作负荷（或部分工作负荷）都需要一个英勇的恢复计划。 恢复应反映其关键性。

过度工程的低影响服务浪费资源。高影响的服务如果准备不足，会带来严重后果。 关键是根据业务影响调整恢复策略的大小。 使用以下分类层作为起点来评估关键性并相应地调整灾难恢复投资。

量化层的一种常见方法是通过服务级别目标（SLO），通常表示为“五九”（99.999%）、“四九”（99.99%），等等。 这些百分位广泛表示给定工作负荷所需的可用性级别。

DR 策略中最重要的指标是恢复时间目标（RTO）和恢复点目标（RPO），这两个指标都限定为时间单位。 RTO 定义在中断后必须恢复系统的时间。 它表示组织的停机时间容忍度。 RPO 定义可接受的数据丢失量，并反映必须备份数据的频率。

本文假设 SLO 和恢复指标已定义，并且不会介绍如何计算它们。 如果需要有关建立有意义的 SLO 的指导，请参阅 可靠性指标。

第 0 层：任务关键

任务关键层包括整个工作负荷或特定组件，其中停机时间不是一个选项，成本节省是次要的连续性。 这些系统是组织的基础，直接推动收入，保护客户信任或影响生命。 常见示例包括金融平台、医疗保健系统和安全基础结构。

此层要求 SLO 超过 99.99%，RTO 以秒为单位测量，RPO 接近零。 为了满足这些要求，通常需要主动-主动、多区域部署，能够实现瞬时恢复，不影响用户体验。

当任务关键型系统发生故障时，后果是立即和重大的：收入损失、信誉损害或监管风险。

第 1 层：业务关键

业务关键型系统对于日常运营和客户体验至关重要，但与任务关键型系统不同，它们可以容忍短暂的中断期，只要恢复速度很快且数据丢失最少。 这些系统通常由收入激励驱动，例如电子商务平台、面向客户的应用程序和合作伙伴门户。

它们通常需要 99.95 左右的 SLO%，RTO 和 RPO 以分钟为单位。 主动-主动或热备用部署的组合通常用于平衡复原能力与成本。

虽然短暂的中断可能可以忍受，但在此层的延长停机时间会直接影响收入、用户满意度和品牌信誉。 可预测性和恢复速度至关重要。

第 2 层：业务运营

业务运营系统支持内部团队和流程。 虽然并非直接面向客户，但它们对于生产力和运营连续性至关重要。 典型示例包括报告平台、内部仪表板和管理工具。

这些系统通常以大约 99.9%为目标的 SLO，RTO 和 RPO 以小时为单位。 通常采用主动-被动部署策略，并结合暖/冷部署，次要环境在需要时才激活，从而优化成本而非恢复速度。

此层中的中断可能不会立即影响客户，但更长的中断可能会降低业务速度。 及时恢复很重要，即使它不是立即恢复。

第 3 层：管理

管理系统是支持后台操作和提供低优先级用例的非关键工作负荷。 它们通常包括存档平台、沙盒环境、培训门户或批处理工具，其中可用性不区分时间。

由于 SLO 低于 99.9%，这些系统可以容忍更长的恢复时段，RTO 范围从小时到天不等，RPO 以小时为单位。 此处最经济高效的方法是备份和还原，最大程度地降低正在进行的基础结构成本，同时仍保持可恢复性。

虽然此层中的延迟通常可以接受，但数据完整性仍必须受到保护。 如果这些系统发生故障，这些系统可能不会停止业务，但完全失去这些系统仍可能导致合规性风险或知识差距随时间推移。

对工作负荷进行分类

在启动 DR 策略之前，请根据实际业务影响和恢复要求对工作负荷进行分类。

首先列出工作负荷中的每个用户流。 记录它的功能、依赖它的人以及如果它故障会产生什么影响。 同一工作负荷中的不同流可能需要不同的灾难恢复策略，具体取决于其各个业务影响和关键性。

请与业务利益相关者合作，获取他们对这些分类的批准。 根据实际业务后果确认 RTO 和 RPO 目标，而不仅仅是技术意见。 他们的承诺将建立基础，DR 策略建立在这一基础之上。 如果不对业务风险保持一致，技术响应就缺乏方向。

定期查看这些分类。 随着业务需求的发展，请相应地更新 DR 计划。

注意这些摩擦点

以下是你应该谨慎的一些关键摩擦点，否则 DR 规划可能会变成成本高昂的练习，而没有正确的结果。

• 预期与预算不匹配。 妥善管理预期，以便让利益相关者不会期望冷备用预算能提供热备用性能。 RTO/RPO 承诺与预算之间的差距可能导致风险和失望。

• 共享服务依赖项可能会中断链。 灾难恢复 (DR) 计划的有效性取决于其最薄弱的环节。 如果工作负荷依赖于共享资源或第三方资源（缺少适当的故障转移策略），则它可以在灾难期间创建漏洞。

• DR 激活标准必须清晰。 责任列表中列出的每个人都必须对标准清楚。 如果没有此情况，可能会犹豫启动恢复，这可能会导致不必要的延迟。

• 故障恢复与故障转移一样重要。 虽然许多人专注于将故障转移视为切换，但有时故障回复是一种可行的选项。 但是，将操作返回到主站点通常更为复杂。 请务必规划和测试故障恢复过程。 一个很好的准则是，在通过有控制的过程管理故障恢复的同时自动执行故障转移。

优化恢复成本

灾难恢复的成本随工作负荷的关键性而增加。

• 第 0 层（任务关键型） 具有最高的成本，这是预期的。 双活部署和冗余基础设施会显著增加支出，以确保几乎零停机时间。 在成本优化方面，最佳选项是标准做法，例如预留实例或 Azure 混合权益（如果适用）。

  努力实现设计中的简单性。 超出明确要求的设计过度会导致隐藏成本的悄然积累。 请记住，基础结构即代码、自动化部署和测试等基础做法引入了前期工程工作。 虽然这种努力可能与提供新功能的目标竞争，但减少对充足运营的投资绝非一种选择。

• 第 1 层（业务关键） 提供平衡，通常使用降低成本的热备用环境。

  在次要区域中以部分规模部署计算资源，从而在热备用状态下降低基线容量，同时仅在需要时通过自动扩展增加容量。 此方法可避免为全容量 24/7 付费。

  将手动触发的故障转移过程与协调的 Runbook 配合使用，以减少与完全自动化故障转移相比的复杂性和持续运营成本。 常规故障转移测试有助于识别效率不足，

• 第 2 层（业务运营） 侧重于使用冷备用设置和即用即付选项（如现成实例和消耗定价）来优化成本。 仅当需要避免为空闲资源付费时，才在次要区域中自动预配 PaaS 计算。 定义明确的灾难条件和故障转移过程，以防止不必要的故障转移。 定期测试可确保满足恢复目标，并重点介绍削减成本的区域。

• 第 3 层（管理） 通过依靠具有较长恢复时段的备份和存档存储来确定成本节省的优先级。 使用次要区域中复制的 Azure 备份保管库来保护持久性数据，而无需运行备用基础结构。 定期测试还原过程，以确保可靠性，同时将费用保持在最低水平。

无论您所在的层级如何，请使用合适的工具来审查成本。 使用Microsoft成本管理和 Azure 顾问等工具监视、预测和优化所有层的支出。 标记资源并设置预算阈值，使责任和退款模型更易于跟踪。有关Microsoft建议标记的信息，请参阅 标记任务关键型工作负荷。

制定您的 DR 计划

强大的灾难恢复（DR）计划将战略转化为决定性的行动。 激活从自动警报和人工监督的组合开始。 可观测性工具会标记性能放缓等潜在问题，并触发运营团队要调查的警报。 他们查看仪表板中的异常情况并评估情况。 如果问题看起来更为广泛或更严重，则会升级，并可能涉及其他团队。 在有足够的证据后，DR 领导正式宣布了灾难，启动结构化故障转移过程，以保持系统连续性。

为了使这一点成为可能，每个 DR 计划都应包括三个基本组件：一个明确的 Runbook、一个定义完善的通信计划和一个结构化的升级路径。

DR 通信计划

通信计划可确保在中断期间，于正确的时间将正确的信息传达给正确的人。 它支持协调、减少混乱，并使利益干系人在整个恢复过程中得到通知。 计划应涵盖以下方面：

• 激活条件和审批。 确定哪些内容定义为 DR 事件。 确定谁有权触发 DR 过程。 文档升级路径和决策检查点。

• 角色和职责。 定义谁负责沟通，以及与谁通信。

• 关键利益干系人。 确定关键内部和外部受众，例如员工、领导、合作伙伴和客户。

• 通信通道。 建立电子邮件、短信等主要和备份方法。 此外，还应确定这些渠道的更新频率。

• 通知和模板。 概述何时为电子邮件、状态页和事件通道发送更新和准备预先批准的消息模板。

• 升级和连续性。 请确保在某人不可用或情况变化迅速时，有一种结构化的方式来升级问题。 通信计划必须通过适当的详细信息和频率以及单独的渠道解决内部和外部利益干系人的问题。 内部通信为执行领导和业务用户提供定期更新，侧重于业务影响、时间线和资源需求。 外部沟通与客户、合作伙伴和监管机构进行协调，包括当前状态和现实的恢复时间框架。

灾难恢复手册

强大的 Runbook 将抽象策略替换为结构，并允许团队在压力下做出响应。 明确，使其实用，并确保它有效。 从简单的大纲开始，逐步构建。 与业务、安全和运营进行协作，确保全面覆盖。

• 文档故障转移和故障回复过程。 编写启动故障转移的分步技术说明。 可用来执行的参考工具和脚本（附链接或参考文献）。 建立启动故障回复和协调直接转换步骤的条件。

  为执行故障转移开发分步骤流程。

  Action	所有者	条件
  1. 检测故障	监控与运维	事件由警报或用户报告触发。
  2. 评估严重性	事件管理器	使用事件分类表确定严重性级别。
  3.宣布中断（如果需要）	高级 Ops/BCDR 主管	仅对高严重性和紧急严重性事件宣布中断。
  4. 通知利益干系人	通信主管	遵循已建立的通知通信计划。
  5. 启动“Runbook”执行	运营团队	启动灾难恢复手册的执行，包括自动化手册和手动步骤。
  6. 准备辅助基础结构	运营团队	在备用环境中部署、扩展和验证基础设施配置。
  7. 确保数据完整性	运营团队	根据需要从备份还原数据，并验证数据完整性和遵守 RPO。
  8.恢复应用程序	Ops/QA 团队	根据需要部署应用程序，并在备用环境中激活应用程序。 验证正确操作及所有依赖项
  9. 流量切换	运营团队	将用户迁移至次要环境。 如有必要，请更新 DNS 记录
  10. 关闭事件并记录	事件管理器	进行事后验尸和更新事件记录。

  同样，创建故障回复决策和执行过程（主要区域可用）：

  Action	所有者	条件/决策点
  1. 监控主区域健康状况	运营/云计算团队	验证主区域是否通过所有健康检查并完全正常运行。 使用自动化监视工具和手动验证来确认就绪情况。
  2. 评估业务影响	应用程序所有者/业务连续性	确认故障回复的业务准备情况，包括低流量窗口和所需的审批。 与利益干系人协调，确保时间与业务需求保持一致。
  3.查看数据同步	数据库/基础结构团队	确保次要区域中的数据与主要区域同步并满足 RPO/RTO 要求。 使用复制状态仪表板验证数据一致性。
  4. 沟通故障回复计划	事件管理器	告知利益干系人计划的故障恢复切换，包括时间线和潜在影响。 使用电子邮件、Teams 或事件管理工具进行通信。
  5. 准备主要区域	Infra/Cloud 团队	验证基础结构、安全性和应用程序组件是否已在主要区域中准备就绪。 运行回退前检查清单，以确保完全准备就绪。
  6. 启动故障回切	运营/云团队	仅在满足所有条件时执行已批准的更改请求。 开始将流量和工作负荷重定向到主要区域。
  7. 监视故障回复进度	运营/云团队	监视转换过程中的错误、延迟或数据丢失。 使用仪表板和警报系统跟踪进度。
  8. 验证应用程序功能	应用程序所有者/QA	确认应用程序和服务在主要区域中完全正常运行。 运行冒烟测试和回归测试来验证功能。
  9. 完成和关闭事件	事件管理器	确保所有系统都稳定，告知利益干系人，并更新文档。 完成事后分析并总结所吸取的教训。

• 建立健康验证和准备情况检查。 定义在故障转移后验证服务功能的方式。 包括应用程序级别、基础结构和数据完整性检查。

• 规划恢复和后续评审。 概述清理临时环境的步骤。 文档数据对帐（如果适用）。 计划根本原因分析和灾难恢复总结。

DR 升级计划

在灾难恢复期间，速度和清晰度都是一切。 升级计划可确保当事情不按计划进行时，正确人员会快速发出警报。

• 升级触发器。 确切地定义何时需要采取升级措施，无论是错过恢复进度的里程碑、关键系统故障还是供应商无响应。

• 命令链。 在标识的角色和联系人列表中，按要联系的顺序进行布局。 也就是说，如何依次向主要、辅助和备份人员上报问题。 还包括响应时间预期。 例如，在 15 分钟内在电话或紧急通信平台上拨打 DR 管理器。

• 事件严重性级别。 按影响对事件进行分类，使次要问题不会堵塞系统，主要问题立即引起领导层的注意。

下面是一个示例模板：

定期测试并改进计划

灾难恢复是一项操作学科。 从未测试过的 DR 计划始终是理论性的和未经证实的。

• 定期排练运行手册，以模拟场景并阐明团队角色。

• 计划完整或部分故障转移演练，以验证实际恢复步骤和时间。 计划的故障转移通过模拟区域性中断来练习如何顺利进行系统转换。 Azure Chaos Studio 等工具用于测试计划外故障，并了解系统如何响应。

• 每次测试后，检查数据以确认没有任何丢失或损坏。 捕获任何发现的问题或漏洞，然后及时更新你的体系结构和运行手册。

恢复策略：备份和还原

备份和还原策略必须是所有恢复策略的一部分。

建议操作

将此用作所有层级的基础。 每个步骤都应包括一个明确的目标和验证其有效性的方法。

主动-被动（冷备用）的恢复策略

主动-被动冷备用部署将次要区域的计算资源保持停止，直到需要为止。 此方法非常适合第 2 层或第 3 层工作负荷，其中 RTO 可以容忍更长的延迟，但恢复仍必须可靠且可重复。

主要区域处理所有生产流量，而次要区域在运行资源最少的情况下保持基础结构就绪状态，需要在灾难方案中手动激活。

建议操作

基于 备份和还原的恢复策略 ，并涵盖这些点。 根据需要进行扩展。

主动-被动（热备用）的恢复策略

主动-被动暖备用部署通过维护可在故障事件期间快速缩放的最小预配辅助环境来平衡成本和复原能力。 此方法可减少停机时间，同时避免跨区域始终保持冗余的全部成本。

主要区域在正常情况下处理所有生产流量，而次要区域以最少的资源运行，并且仅在为灾难恢复激活时才纵向扩展。

建议操作

基于 主动-被动（冷备用）的恢复策略 ，并涵盖这些点。 根据需要进行扩展。

主动-主动部署的恢复策略

主动-主动部署通过跨区域运行多个工作负荷实例来最大化服务可用性，每个实例都主动处理生产流量。 此设计可消除停机时间并启用即时故障转移，但也需要精确规划来管理分布式系统的一致性、路由和成本。

选择两种部署方法之一：

• 双活（满载容量）：两个或多个区域中的镜像部署实例，其中每个区域处理生产负载的一部分，并且能够扩展以吸收区域故障期间的全部负载。

• 主动-主动（过度预配）：在两个或更多区域中的镜像部署印记。每个区域始终以满负荷运行，独立处理 100% 的流量。

建议操作

基于 主动-被动（热备用）的恢复策略。 根据需要进行扩展。

后续步骤

• RE：09 用于设计灾难恢复策略的体系结构策略

• RE：05 用于设计冗余的体系结构策略