Azure 数据平台的 DR - 建议
经验
确保所有参与方都了解高可用性（HA）与灾难恢复（DR）之间的差异。 混淆这些概念可能会导致解决方案不匹配。
若要定义恢复点目标（RPO）和恢复时间目标（RTO），请与业务利益干系人讨论他们对以下因素的期望：
可以容忍的停机时间。 请记住，更快的恢复通常会产生更高的成本。
利益干系人需要保护的事件类型及其发生的可能性。 例如，服务器故障比影响区域中所有数据中心的自然灾害更有可能发生。
系统不可用对其业务的影响。
长期解决方案的运营费用（OPEX）预算。
考虑最终用户可以接受哪些降级的服务选项。 这些选项可能包括：
访问可视化仪表板，即使数据未 up-to-date 也是如此。 在这种情况下，即使引入管道失败，最终用户也可以查看其数据。
没有写入功能的读取访问权限。
目标 RTO 和 RPO 指标确定选择实现的 DR 策略。 这些策略包括主动/主动/被动和主动/重新部署灾难。 考虑自己的 复合服务级别目标 ，以考虑可容忍的停机时间。
确保了解可能影响系统可用性的所有组件，例如：
标识管理。
网络拓扑。
机密管理和密钥管理。
数据源。
自动化和作业计划。
源存储库和部署管道，如 GitHub 和 Azure DevOps。
及早检测到中断也可以显著降低 RTO 和 RPO 值。 包括以下关键因素：
根据Microsoft定义服务中断的定义及其映射方式。 Microsoft 定义可在产品或服务级别的 Azure 服务级别协议 (SLA) 页面获取。
使用负责的团队实施高效的监视和警报系统，以便及时查看指标和警报以支持目标。
对于订阅设计，DR 的额外基础结构可以存储在原始订阅中。 平台即服务服务（如 Azure Data Lake Storage 和 Azure 数据工厂）通常包括本机故障转移功能。 这些功能允许其他区域中的辅助实例，同时保留原始订阅。 为了优化成本，某些组织可能会选择专门为 DR 相关资源分配专用资源组。
订阅限制 可能会在此方法中引入约束。
其他约束可能包括设计复杂性和管理控制，以确保 DR 资源组不用于照常业务工作流。
根据解决方案的关键性和依赖项设计 DR 工作流。 例如，不要尝试在数据仓库正常运行之前重新生成 Azure Analysis Services 实例，因为它会触发错误。 请留出开发实验室，以便稍后完成此过程，并首先恢复核心企业解决方案。
确定可跨解决方案并行化的恢复任务。 此方法可减少 RTO 总数。
如果在解决方案中使用 Azure 数据工厂，请不要忘记在作用域中包含自承载集成运行时。 Azure Site Recovery 非常适合这些计算机。
尽可能自动执行手动作，以防止人为错误，尤其是在压力不足时。 建议：
通过 Bicep、Azure 资源管理器模板或 PowerShell 脚本采用资源预配。
采用源代码和资源配置的版本控制。
使用持续集成和持续交付发布管道，而不是选择作。
由于有故障转移计划，因此应考虑回退到主实例的过程。
定义明确的指示器和指标，以验证故障转移是否成功，以及解决方案是否正常运行。 确认性能恢复正常，也称为 主要功能。
确定故障转移后 SLA 是否应保持不变，或者是否允许暂时降低服务质量。 此决策在很大程度上取决于支持的业务流程。 例如，房间预订系统的故障转移与核心作系统大相径庭。
基于特定用户方案而不是基础结构级别的 RTO 或 RPO 定义。 此方法在如何确定在中断或灾难期间应优先进行恢复的流程和组件方面提供了更大的粒度。
在继续故障转移之前，请确保在目标区域中执行容量检查。 在重大灾难中，许多客户可能尝试同时故障转移到同一配对区域。 此方案可能会导致资源预配出现延迟或争用。 如果这些风险不可接受，请考虑主动/主动或主动/被动 DR 策略。
必须创建和维护 DR 计划才能记录恢复过程和作所有者。 请记住，某些团队成员可能正在休假，并确保包含辅助联系人。
执行常规 DR 演练来验证 DR 计划工作流，确保它满足所需的 RTO 和 RPO 要求，并培训负责任的团队。 定期测试数据和配置备份，以确保它们 适合其用途，这意味着它们适合其预期用途且有效。 此过程可确保它们能够支持恢复活动。
与负责网络、标识和资源预配的团队进行早期协作有助于就最佳解决方案达成一致，以了解如何：
将用户和流量从主站点重定向到辅助站点。 可以评估域名系统重定向等概念，或者使用 Azure 流量管理器 等特定工具。
以及时且安全的方式提供对辅助站点的访问权限和权限。
在灾难中，有关各方之间的有效沟通是计划高效快速实施的关键。 Teams 可能包括：
- 决策者。
- 事件响应团队。
- 受影响的内部用户和团队。
- 外部团队。
在正确的时间协调不同资源可确保 DR 计划实施的效率。
注意事项
反模式
复制/粘贴本文系列
本文系列为寻求更深入地了解特定于 Azure 的 DR 过程的客户提供了指导。 它基于通用Microsoft知识产权和参考体系结构，而不是任何特定于客户的 Azure 实现。
此内容提供了强有力的基础理解。 但是，客户必须考虑到其独特的上下文、实施和要求来制定适合用途的 DR 策略和流程来定制其方法。
将 DR 视为仅限技术的过程
业务利益干系人对于定义 DR 的要求和完成确认服务恢复所需的业务验证步骤至关重要。
确保所有 DR 活动都参与业务利益干系人提供了一个符合目的的 DR 流程，表示业务价值，并且可实现。
“设置和忘记”DR 计划
Azure 不断发展，各个客户使用各种组件和服务的方式也一样。 适合用途的 DR 过程必须随它们一起发展。
客户应定期通过软件开发生命周期或定期评审重新评估其 DR 计划。 此策略使服务恢复计划有效，并正确解决组件、服务或解决方案之间的任何更改。
基于纸张的评估
DR 事件的端到端模拟在现代数据生态系统中难以执行。 但是，应努力尽可能接近受影响组件的完整模拟。
定期计划的演练有助于组织制定自信地实施 DR 计划的本能能力。
依靠Microsoft来做到这一切
在 Microsoft Azure 服务中，有明确的 责任划分，由使用的云服务层锚定。
即使使用完整的 软件即服务堆栈 ，客户仍有责任确保帐户、标识和数据正确且 up-to日期，以及用于与 Azure 服务交互的设备。
事件范围和策略
灾难事件范围
不同的事件具有不同的影响范围，需要不同的响应。 下图说明了灾难事件的影响和响应范围。
灾难策略选项
DR 策略有四个高级选项：
等待Microsoft
顾名思义，解决方案处于脱机状态，直到通过Microsoft完全恢复受影响区域中的服务。 恢复后，客户会验证解决方案，然后对其进行更新，以帮助确保服务恢复。
在灾难时重新部署
在发生灾难事件后，解决方案将手动重新部署为新的部署到可用区域。
暖备用（主动/被动）
在备用区域中创建辅助托管解决方案，并部署组件以确保最小容量。 但是，组件不会接收生产流量。
备用区域中的辅助服务可能会 关闭，或者在发生 DR 事件之前以较低的性能级别运行。
热备用（主动/主动）
该解决方案托管在多个区域的主动/主动设置中。 辅助托管解决方案接收、处理数据并将其作为较大系统的一部分提供服务。
DR 策略效果
服务复原能力较高级别的运营成本在 DR 策略 的关键设计决策 中通常起着主要作用，但还应考虑其他重要因素。
注意
成本优化 是 Azure Well-Architected 框架中体系结构卓越五大支柱之一。 其目标是减少不必要的开支并提高运营效率。
此工作示例的 DR 方案是一个完整的 Azure 区域中断，直接影响托管 Contoso 数据平台的主要区域。
下表是选项之间的比较。 具有绿色指示器的策略比具有橙色或红色指示器的策略更适合该分类。
分类键
对于此中断方案，对四种高级 DR 策略的相对影响基于以下因素：
RTO： 从灾难事件到平台服务恢复的预期运行时间。
要执行的复杂性： 组织执行恢复活动的复杂性。
实现的复杂性： 组织实施 DR 策略的复杂性。
客户影响： 从 DR 策略对数据平台服务的客户产生直接影响。
在线 OPEX 成本： 实施此策略所需的额外成本，例如 Azure 的每月计费增加，用于支持额外组件和额外资源。