什么是业务连续性、高可用性、灾难恢复？

本文介绍和说明通过高可用性和灾难恢复设计在风险管理方面实现的业务连续性和业务连续性规划。 虽然本文未提供有关如何满足自己的业务连续性需求的明确指导，但它有助于了解整个 Azure 可靠性指南中使用的概念。

业务连续性是企业在故障、中断或灾难期间可以继续运营的状态。 业务连续性需要主动规划、准备和实施可复原的系统和流程。

规划业务连续性需要识别、理解、分类和管理风险。 根据了解风险及其可能性，可以设计一个健康的业务连续性计划，以实现符合业务需求的高可用性（HA）和灾难恢复（DR）策略。

高可用性是指设计一个解决方案，以灵活应对日常问题，并满足业务需求的可用性。

灾难恢复是关于规划如何处理不常见的风险和可能导致的灾难性中断。

通常，云解决方案与业务运营直接绑定。 每当云解决方案不可用或遇到严重问题时，对业务运营的影响可能非常严重。 严重的影响可能会中断业务连续性。

对业务连续性的严重影响可能包括：

• 业务收入损失。
• 无法向用户提供重要服务。
• 违反对客户或其他方的承诺。

请务必了解业务期望以及失败的后果，并将它们传达给重要的利益干系人，包括那些设计、实施和操作工作负载的人员。 然后，这些利益干系人做出回应，分担满足这一愿景所涉及的成本。 通常会有一个根据预算和其他约束进行谈判和修订该愿景的过程。

若要控制或完全避免对业务连续性产生负面影响，请务必主动制定业务连续性计划。 业务连续性计划基于风险评估和开发通过各种方法控制这些风险的方法。 每个组织和工作负载的特定风险和缓解方法会有所不同。

业务连续性计划不仅要考虑云平台本身的复原功能，还要考虑应用程序的功能。 可靠的业务连续性计划还包含业务中支持的各个方面，包括人员、与业务相关的手动或自动流程以及其他技术。

业务连续性规划应包括以下按顺序的步骤：

1. 风险标识。 确定工作负载的可用性或功能的风险。 可能的风险包括网络问题、硬件故障、人为错误、区域中断等。了解每个风险的影响。

2. 风险分类。 将每个风险分类为常见风险（应纳入 HA 计划）或不常见风险（应为 DR 规划的一部分）。

3. 风险缓解。 为 HA 或 DR 设计缓解策略，以最大程度地减少或缓解风险，例如使用冗余、复制、故障转移和备份。 此外，请考虑非技术性和基于流程的缓解和控制。

业务连续性规划是一个过程，而不是一次性事件。 应定期审查和更新所创建的任何业务连续性计划，以确保它保持相关且有效，并支持当前的业务需求。

业务连续性规划的初始阶段是确定工作负载的可用性或功能的风险。 应分析每个风险，以了解其可能性及严重性。 严重性需要包含任何潜在的停机时间或数据丢失，以及解决方案设计其余部分的任何方面是否可以弥补负面影响。

下表是一个非详尽的风险列表，按可能性倒序排列：

业务连续性规划不仅仅关乎云平台和基础结构。 请务必考虑人为错误的风险。 此外，一些传统上可能被视为安全、性能或操作风险的风险也应被视为可靠性风险，因为它们会影响解决方案的可用性。

下面是一些示例：

故障模式分析 (FMA) 是确定工作负载或其组件可能失败的潜在方式以及解决方案在这些情况下的行为方式的过程。 若要了解详细信息，请参阅有关执行故障模式分析的建议。

业务连续性计划必须同时应对常见和不常见的风险。

• 常见风险是计划和预期内的。 例如，在云环境中，通常会出现暂时性故障，包括短暂的网络中断、因修补程序导致的设备重启、服务繁忙时超时等。 由于这些事件经常发生，因此工作负载需要具有弹性来应对。

  高可用性策略必须考虑和控制此类型的每种风险。

• 不常见风险通常是导致灾难性中断的不可预见事件（如自然灾害或重大网络攻击）造成的。

  灾难恢复过程负责应对这些罕见的风险。

高可用性和灾难恢复是相互关联的，因此必须共同规划这两者的策略。

请务必了解，风险分类取决于工作负载体系结构和业务需求，某些风险对于一个工作负载可以归类为 HA，而对于另一个工作负载则为 DR。 例如，Azure 区域完全中断通常被视为该区域工作负载的 DR 风险。 但是，对于在主动-主动配置中使用多个 Azure 区域并具有完整的复制、冗余和自动区域故障转移的工作负载，区域中断被归类为 HA 风险。

风险缓解包括为 HA 或 DR 制定策略，以最大程度地减少或缓解业务连续性的风险。 风险缓解可以是基于技术或基于人的。

基于技术的风险缓解使用基于工作负载实施和配置方式的风险控制，例如：

• 冗余
• 数据复制
• 故障转移
• 备份

在业务连续性计划上下文中，必须考虑基于技术的风险控制。

例如：

• 低故障时间要求。 由于严格的高可用性要求，某些业务连续性计划无法容忍任何形式的停机风险。 某些基于技术的控制可能需要一些时间才能通知相关人员，然后他们才能做出响应。 包含缓慢的手动流程的基于技术的风险控制可能不适合纳入其风险缓解策略。

• 对部分故障的容忍度。 某些业务连续性计划能够容忍处于降级状态的工作流。 当解决方案在降级状态下运行时，某些组件可能会被禁用或不可运行，但核心业务操作可以继续执行。 若要了解详细信息，请参阅有关自我修复和自我保护的建议。

基于人的风险缓解使用基于业务流程的风险控制，例如：

• 触发响应 playbook。
• 故障回复到手动操作。
• 培训和文化变动。

由于基于人的风险控制通常比基于技术的控制慢，而且更容易发生人为错误，因此良好的业务连续性计划应该包含一个正式的变更控制流程，针对会改变运行中的系统的状态的任何内容。 例如，请考虑实现以下流程：

• 根据工作负载关键性严格测试工作负载。 为了防止与变更相关的问题，请确保测试对工作负载所做的任何变更。
• 在工作负载的安全部署实践中引入战略质量检查点。 若要了解详细信息，请参阅安全部署实践的建议。
• 将临时性生产访问和数据操作正式化。 这些活动（无论多么微小）都可能具有导致可靠性事件的高风险。 此类过程可能包括与另一个工程师配对，使用清单，并在执行脚本或应用变更之前进行同行评审。

高可用性是特定工作负载可以日常维护其必要运行时间级别的状态，即使在暂时性故障和间歇性故障期间也是如此。 由于这些事件经常发生，因此，根据特定应用程序和客户期望的要求，为每个工作负载设计和配置高可用性非常重要。 每个工作负载的 HA 都有助于业务连续性计划。

由于 HA 因每个工作负载而异，因此在确定高可用性时必须了解要求和客户期望。 例如，组织用来订购办公用品的应用程序可能需要相对较低的运行时间，而关键财务应用程序可能需要更高的运行时间。 即使在工作负载中，不同的流也可能有不同的要求。 例如，在电子商务应用程序中，支持客户浏览和下单的流可能比订单履行和后台处理流更重要。 若要了解有关流的详细信息，请参阅有关对流进行标识和分级的建议。

通常，运行时间是根据运行时间百分比中的“九”的数量来衡量的。 运行时间百分比与给定时间段内允许的故障时间有关。 下面是一些示例：

• 99.9% 的运行时间要求（“3 个 9”）允许每月存在大约 43 分钟的故障时间。
• 99.95% 的运行时间要求（“3 个半 9”）则允许每月存在大约 21 分钟的故障时间。

运行时间要求越高，中断的容忍度就越小，需要完成越多的工作才能达到该可用性级别。 运行时间不是由单个组件（如节点）的运行时间来衡量的，而是通过整个工作负载的总体可用性来衡量。

为了满足 HA 要求，工作负载可以包含许多设计元素。 本节下面列出了一些常见元素。

许多 Azure 服务设计为高度可用，可用于生成高度可用的工作负载。 下面是一些示例：

• Azure 虚拟机规模集通过自动创建和管理 VM 实例并分发这些 VM 实例来降低基础结构故障的影响，从而为虚拟机 (VM) 提供高可用性。
• Azure 应用服务通过多种方法提供高可用性，包括自动将工作进程从不健康的节点迁移到健康的节点，并提供从多种常见故障类型自我修复的能力。

使用每个服务可靠性指南了解服务的功能，确定要使用的层，并确定要包含在高可用性策略中的功能。

查看每个服务的服务级别协议 (SLA)，以了解期望的可用性级别和需要满足的条件。 可能需要选择或避免特定的服务层来实现特定级别的可用性。 Azure 的一些服务是在默认不提供 SLA（例如开发层或基础层）或可能会从运行系统中回收资源（例如基于抢占式实例的产品）的前提下提供的。 此外，某些层还添加了可靠性功能，例如对可用性区域的支持。

容错是指在发生故障时，系统能够在某些定义的容量中继续运行。 例如，即使单个 Web 服务器发生故障，Web 应用程序也可能设计为继续运行。 容错可以通过冗余、故障转移、分区、正常降级和其他技术来实现。

容错还要求应用程序处理暂时性故障。 生成你自己的代码时，可能需要自行启用暂时性故障处理。 某些 Azure 服务为某些情况提供内置的暂时性故障处理。 例如，默认情况下，Azure 逻辑应用会自动重试对其他服务的失败请求。 若要了解详细信息，请参阅有关处理暂时性故障的建议。

冗余是复制实例或数据以提高工作负载可靠性的做法。

可以通过以下一种或所有方式分发副本或冗余实例来实现冗余：

• 数据中心内（本地冗余）
• 在区域内的可用性区域之间（区域冗余）
• 跨区域（异地冗余）。

下面是关于某些 Azure 服务如何提供冗余选项的一些示例：

• Azure 应用服务让你可以运行应用程序的多个实例，以确保即使一个实例失败，应用程序仍然可用。 如果启用区域冗余，这些实例将分布在你使用的 Azure 区域中的多个可用性区域。
• Azure 存储通过至少自动复制数据三次来提供高可用性。 可以通过启用区域冗余存储 (ZRS) 跨可用性区域分布这些副本，并且在许多区域中，还可以使用异地冗余存储 (GRS) 跨区域复制存储数据。
• Azure SQL 数据库有多个副本，以确保即使一个副本失败，数据仍可用。

若要详细了解冗余的工作原理，请参阅 冗余、复制和备份。 若要了解如何在解决方案中应用冗余，请参阅有关设计冗余的建议以及有关使用可用性区域和区域的建议。

可伸缩性和弹性是指系统通过添加和移除资源（可伸缩性）来处理增加的负载的能力，以及随着需求变化快速做到这一点的能力（弹性）。 可伸缩性和弹性有助于系统在高峰负载期间保持可用性。

许多 Azure 服务都支持可伸缩性。 下面是一些示例：

• Azure 虚拟机规模集、Azure API 管理和其他几项服务支持 Azure Monitor 自动缩放。 使用 Azure Monitor 自动缩放时，可以指定策略，例如“我的 CPU 持续超过 80% 时，添加另一个实例”。
• Azure Functions 可以动态预配实例来为请求提供服务。
• Azure Cosmos DB 支持自动缩放吞吐量，即服务可以根据你指定的策略自动管理分配给数据库的资源。

可伸缩性是部分或完全故障期间要考虑的一个关键因素。 如果副本或计算实例不可用，其余组件可能需要承担更多负载来处理以前由故障节点处理的负载。 如果系统无法快速缩放以处理负载的预期变化，请考虑超量预配。

有关如何设计可缩放和弹性系统的详细信息，请参阅有关设计可靠的缩放策略的建议。

部署和其他系统更改会带来严重的停机风险。 由于停机时间风险对高可用性要求提出了挑战，因此请务必使用零停机部署做法进行更新和配置更改，而无需停机。

零停机部署技术可包括：

• 一次更新一部分资源。
• 控制到达新部署的流量大小。
• 监视对用户或系统可能产生的任何影响。
• 快速修正问题，例如通过回滚到以前的已知良好部署。

若要详细了解零停机部署技术，请参阅安全部署做法。

Azure 本身对我们自己的服务使用零停机部署方法。 当你生成你自己的应用程序时，可以通过各种方法采用零停机部署，例如：

• Azure 容器应用提供应用程序的多个修订，可用于实现零停机部署。
• Azure Kubernetes 服务 (AKS) 支持各种零停机部署技术。

尽管零停机部署通常与应用程序部署相关联，但它们也应该用于配置更改。 下面是一些安全应用配置更改的方法：

• Azure 存储允许在多个阶段更改存储帐户访问密钥，从而防止密钥轮换操作期间停机。
• Azure 应用程序配置提供功能标志、快照和其他功能，可帮助你控制如何应用配置更改。

如果你决定不实现零停机部署，请确保定义维护时段，以便在用户期望进行系统更改时执行它们。

即使自动缓解措施发生，监视也会让你了解系统的运行状况。 监视对于了解解决方案的行为以及观察故障的早期信号（例如错误率增加或资源消耗过高）至关重要。 借助警报，你可以主动接收环境中的重要更改。

Azure 提供各种监视和警报功能，包括：

• Azure Monitor 会从 Azure 资源和应用程序收集日志和指标，它可以发送警报并在仪表板中显示数据。
• Azure Monitor Application Insights 提供对应用程序的详细监视。
• Azure 服务运行状况和 Azure 资源运行状况能够监视 Azure 平台和资源的运行状况。
• 预定事件告知虚拟机的维护计划时间。

有关详细信息，请参阅有关设计可靠的监视和警报策略的建议。

灾难是一种独特、不常见、重大的事件，其影响较大且持续较久，应用程序无法通过其设计的高可用性方面来缓解它。 灾难的例子包括：

• 自然灾害，如飓风、地震、洪水或火灾。
• 导致重大影响的人为错误，例如意外删除生产数据或配置不当的防火墙暴露了敏感数据。
• 重大安全事件，例如拒绝服务或勒索软件攻击，导致数据损坏、数据丢失或服务中断。

灾难恢复是关于规划如何响应这些类型的情况。

由于灾难事件的罕见性和严重性，DR 规划为你的应对带来了不同的预期。 许多组织都接受这样一个事实：在灾难场景中，一定程度的停机或数据丢失是不可避免的。 完整的 DR 计划必须为每个流指定以下关键业务要求：

• 恢复点目标 (RPO) 是在发生灾难时可接受的数据丢失的最长持续时间。 RPO 以时间单位度量，例如“30 分钟的数据”或“4 小时的数据”。

• 恢复时间目标 (RTO) 是在发生灾难时可接受的最长停机时间，其中“停机时间”由你的规范定义。 RTO 也以时间单位度量，例如“8 小时的停机时间”。

工作负载中的每个组件或流可能具有单独的 RPO 和 RTO 值。 在确定要求时，检查灾难场景风险和潜在的恢复策略。 指定 RPO 和 RTO 的过程可有效地为工作负载创建 DR 要求，因为存在独特的业务问题（成本、影响、数据丢失等）。

无论灾难原因如何，创建定义完善、可测试的 DR 计划非常重要。 该计划将用作基础结构和应用程序设计的一部分，以积极支持它。 可以针对不同类型的情况创建多个 DR 计划。 DR 计划通常依赖于流程控制和手动干预。

DR 不是 Azure 的自动功能。 但是，许多服务确实提供了可用于支持 DR 策略的特性和功能。 你应查看每项 Azure 服务的可靠性指南，以了解服务的工作原理及其功能，然后将这些功能映射到你的 DR 计划。

以下部分列出了灾难恢复计划的一些常见元素，并介绍了 Azure 如何帮助你实现它们。

某些灾难恢复计划涉及在另一个位置预配辅助部署。 如果灾难影响了解决方案的主要部署，则可以将流量故障转移到另一个站点。 故障转移需要仔细规划和实施。 Azure 提供多种服务来协助故障转移，例如：

• Azure Site Recovery 为 Azure 中的本地环境和虚拟机托管解决方案提供自动故障转移。
• Azure 流量管理器 支持在解决方案的不同部署（例如在不同区域）之间进行传入流量的自动故障转移。

故障转移过程通常需要一些时间来检测主要实例已失败并切换到辅助实例。 确保工作负载的 RTO 与故障转移时间保持一致。

考虑故障回复也很重要，这是在恢复主要区域后还原操作的过程。 故障回复的计划和执行可能会比较复杂。 例如，主要区域中的数据可能已在故障转移开始后被写入。 你需要对如何处理这些数据做出仔细的业务决策。

有关详细信息，请参阅故障转移和故障回复。

备份涉及获取数据的副本，并在定义的时间段内安全地存储它。 借助备份，可以在无法自动故障转移到另一个副本时或发生数据损坏时从灾难中恢复。

将备份用作灾难恢复计划的一部分时，请务必考虑以下事项：

• 存储位置。 使用备份作为灾难恢复计划的一部分时，应将其单独存储到主数据。 备份通常存储在另一个 Azure 区域中。

• 数据丢失。 由于备份通常不经常进行，因此备份还原通常涉及数据丢失。 因此，备份恢复应用作最后手段，灾难恢复计划应指定在从备份还原之前必须执行的步骤和恢复尝试的顺序。 请务必确保工作负载 RPO 与备份间隔保持一致。

• 恢复时间。 备份还原通常需要一段时间，因此测试备份和还原过程以验证其完整性并了解还原过程需要多长时间至关重要。 确保工作负载的 RTO 考虑到还原备份所需的时间。

许多 Azure 数据和存储服务都支持备份，例如：

• Azure 备份为虚拟机磁盘、存储帐户、AKS 和其他各种源提供自动备份。
• 许多 Azure 数据库服务（包括 Azure SQL 数据库和 Azure Cosmos DB）都具有数据库的自动备份功能。
• Azure Key Vault 提供备份机密、证书和密钥的功能。

若要在发生灾难时快速部署和配置所需的资源，请使用基础结构即代码 (IaC) 资产，例如 Bicep 文件、ARM 模板或 Terraform 配置文件。 与手动部署和配置资源相比，使用 IaC 可以减少恢复时间和出错的可能性。

定期验证和测试 DR 计划以及更广泛的可靠性策略至关重要。 在演练中包含所有人工流程，而不仅仅是专注于技术流程。

如果你尚未在灾难模拟中测试恢复流程，则你更有可能在实际灾难中使用它们时面临重大问题。 此外，通过测试 DR 计划和所需流程，可以验证 RTO 的可行性。

若要了解详细信息，请参阅有关设计可靠性测试策略的建议。

• 使用 Azure 服务可靠性指南了解每项 Azure 服务在其设计中如何支持可靠性，并了解可构建到 HA 和 DR 计划中的功能。
• 使用 Azure 架构良好的框架：可靠性支柱，详细了解如何在 Azure 上设计可靠的工作负载。
• 使用 Azure 服务的架构良好的框架视角，详细了解如何配置每项 Azure 服务，以满足可靠性以及架构良好的框架的其他支柱的要求。
• 若要详细了解灾难恢复规划，请参阅有关设计灾难恢复策略的建议。