通过

你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

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

  • 项目

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

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

规划业务连续性需要识别、理解、分类和管理风险。 根据风险及其可能性，为高可用性 (HA) 和灾难恢复 (DR) 进行设计。

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

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

业务连续性

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

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

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

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

业务连续性规划

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

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

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

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

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

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

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

风险识别

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

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

示例风险 说明 规律性（可能性）
暂时性的网络问题 网络堆栈组件中的临时故障，在短时间（通常是几秒钟或更少）后可恢复。 常规
虚拟机重启 你使用的虚拟机或者依赖服务使用的虚拟机重启。 可能会因为虚拟机崩溃或需要应用修补程序而重启。 常规
硬件失败 数据中心内组件的故障，例如硬件节点、机架或群集。 偶尔
数据中心中断 影响大多数或全部数据中心的中断，例如电源故障、网络连接问题或供热和冷却问题。 异常
区域中断 影响整个大都市区或更广泛地区的中断（如重大自然灾害）。 非常不寻常

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

以下是一些示例：

示例风险 说明
数据丢失或损坏 数据已因意外或安全漏洞（如勒索软件攻击）被删除、覆盖或受到其他损坏。
软件 bug 新代码或更新后的代码的部署引入了影响可用性或完整性的 bug，使工作负载处于故障状态。
失败的部署 新组件或版本的部署失败，使解决方案处于不一致状态。
拒绝服务攻击 系统遭到攻击，试图阻止解决方案的合法使用。
流氓管理员 具有管理权限的用户故意对系统执行破坏性操作。
意外流入应用程序的流量 流量激增使系统的资源不堪重负。

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

风险分类

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

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

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

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

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

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

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

风险缓解

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

基于技术的风险缓解

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

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

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

例如：

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

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

基于人的风险缓解

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

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

重要

设计、实施、操作和改进工作负载的个人应该称职，鼓励他们在担心的情况下发声，并对系统具有责任感。

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

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

高可用性

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

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

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

  • 99.9% 的运行时间要求（3 个 9）允许在一个月内大约 43 分钟的停机时间。
  • 99.95% 的运行时间要求（3.5 个 9）允许在一个月内大约 21 分钟的停机时间。

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

重要

不要为了达到不合理的更高可靠性而过度设计你的解决方案。 使用业务需求来指导你的决策。

高可用性设计元素

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

注意

某些工作负载是任务关键型的，这意味着任何停机都可能导致人员生命和安全的严重后果或重大财务损失。 如果要设计任务关键型工作负载，在设计解决方案和管理业务连续性时，需要考虑一些具体事项。 有关详细信息，请参阅 Azure 架构良好的框架：任务关键型工作负载。

支持高可用性的 Azure 服务和层

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

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

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

查看每个服务的服务级别协议 (SLA)，以了解期望的可用性级别和需要满足的条件。 可能需要选择或避免特定的服务层来实现特定级别的可用性。 Microsoft 提供的某些服务不提供 SLA，如开发层或基本层，或者可以从运行系统中回收资源，如基于现成机器的服务。 此外，某些层还添加了可靠性功能，例如对可用性区域的支持。

容错

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

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

冗余

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

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

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

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

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

若要了解有关冗余的详细信息，请参阅有关设计冗余的建议以及有关使用可用性区域和 Azure 区域的建议。

可伸缩性和弹性

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

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

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

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

零停机部署技术

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

零停机部署技术可包括：

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

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

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

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

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

自动测试

测试解决方案对于你认为属于 HA 范围内的中断和故障的承受能力非常重要。 其中许多故障可以在测试环境中模拟。 测试解决方案自动容忍或从各种故障类型中恢复的能力的过程被称为混沌工程。 混沌工程对于具有严格 HA 标准的成熟组织至关重要。 Azure Chaos Studio 是一个混沌工程工具，可以模拟一些常见的故障类型。

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

监视和警报

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

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

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

灾难恢复

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

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

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

注意

你应遵循解决方案中的建议做法，以最大程度地减少这些事件的可能性。 不过，即使经过了精心的主动规划，还是应该谨慎地计划一下如果出现这些情况时该如何应对。

灾难恢复要求

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

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

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

RTO 和 RPO 持续时间（以小时为单位）的屏幕截图。

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

注意

虽然试图实现零 RTO 和 RPO（在发生灾难时不会出现停机和数据丢失）具有吸引力，但实际上实现它很难且成本高昂。 技术和业务利益干系人必须共同讨论这些要求，并确定实际的要求。 有关详细信息，请参阅有关定义可靠性目标的建议。

灾难恢复计划

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

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

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

故障转移和故障回复

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

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

考虑故障回复也很重要，这是恢复主要区域后还原其中的操作的过程。 故障回复在规划和实施方面可能非常复杂。 例如，主要区域中的数据可能在故障转移开始后被写入。 你需要对如何处理这些数据做出仔细的业务决策。

备份

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

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

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

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

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

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

自动部署

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

测试和演练

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

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

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

相关内容