什么是恢复时间目标（RTO）？

恢复时间目标（RTO）是指在中断后恢复系统的最长允许时间，以确保对业务运营的影响最小。设定 RTO 可以帮助组织更快地从事件中恢复，满足客户期望和合规目标，并最大限度地减少对运营和声誉的影响。系统的复杂性和依赖项会影响恢复时间，并且可以根据系统重要性为 RTO 设置分层系统级别。使用恢复时间目标可以帮助组织制定可靠的恢复计划，以应对系统事件。

恢复时间目标、恢复点目标（RPO）和平均恢复时间（MTTR）是灾难恢复和规划中常用的三个指标。尽管这些指标重叠，但组织应了解其独特的定义和目的。

恢复点目标（RPO）

恢复点目标是您可以容忍的最大数据丢失量，以时间段来表示。RPO 表示如果发生某种数据丢失事件或灾难，贵公司可以接受多少数据丢失。例如，如果您将 RPO 定义为一小时，则在发生灾难时，您的组织能够容忍丢失一小时的数据变更。

对于贵公司的不同系统，恢复点目标通常是不同的。关键工作负载的 RPO 可能极低，接近于零。记录或归档未经审计的信息的不太重要的系统对业务来说不那么重要，这意味着它可以安全地将 RPO 延长到几天或更长时间。

虽然零时 RPO 是理想的，但 RPO 越短，创建和更新备份过程中的组织压力就越大。确定 RPO 是备份频率和资源消耗之间的平衡。

恢复时间目标（RTO）

恢复时间目标是您的企业在中断后将系统恢复到正常运行状态应花费多长时间。RTO 时间范围是根据您的企业开始因中断而遭受不可接受的损失或影响之前必须经过多少时间来计算的。

RTO 还为灾难恢复专家提供了一个在发生停机或数据灾难时必须努力满足的时间表。

平均恢复时间（MTTR）

平均恢复时间是企业从系统中断中恢复所花费的实际总时间。平均而言，该测量值代表不同事件场景中多个不同时间的平均值。与 RPO 和 RTO 不同，MTTR 是基于数据的事实时间，而不是预期的估算值或目标。

通常将平均恢复时间指标与恢复时间目标进行比较，因为差异可能代表为改善灾难恢复流程而需要做的工作。

计算恢复时间目标涉及多个步骤，允许您全面设计考虑到停机成本、可容忍的停机时间和恢复能力的 RTO。

以下是计算 RTO 的方法。

进行业务影响分析

首先，您的企业应进行业务影响分析，旨在识别和量化灾难事件和系统停机可能对您的运营产生的任何潜在影响。以下是您应该考虑的几个类别：

• 收入损失：计算预期收入损失总额，同时考虑您在一段时间内预期的销售额、暂停的交易总数，以及服务中断给您和您的客户造成的成本等项目。
• 工作效率影响：如果系统中断或事件使员工无法访问内部系统，他们将无法工作。包括估算的员工停机成本，例如因未推进内部或客户项目而造成的潜在损失。
• 声誉损失：特别是如果您的停机是由网络安全事件造成的，您的客户可能会对您的品牌保持数据安全的能力失去信心。声誉损失可能会降低您的品牌权威性，对未来的销售产生负面影响，甚至促使客户取消合同。
• 监管处罚：如果灾难事件是应报告的事件，您可能会因在特定时间范围内不遵守报告要求而受到监管处罚。

为每个类别分配一个货币价值，然后将它们相加，得出最终的业务影响数字。

确定可容忍的最长停机时间

您的组织可容忍的最长停机时间可能取决于哪些系统出现故障。例如，与很少使用的辅助系统相比，关键系统可能需要更快的 RTO。为了帮助解决这个问题，请根据系统对组织的重要程度定义多个 RTO 等级。

第 1 级系统优先级最高，需要尽可能短的 RTO，而第 3 级系统能在 24 小时甚至更长时间内都不需要修复。

评测当前的恢复能力

在确定了最长可容忍停机时间之后，您将估算出特定系统的理想 RTO。接下来，您需要根据现有的恢复目标架构确定这些 RTO 目标是否现实。

灾难恢复计划的核心支柱应该是对现有恢复能力进行基准检查。规划现有的数据备份系统、您的业务连续性计划以及任何其他可用的策略。初步调查将有助于揭示您的 RTO 数字是否现实。

设计符合 RTO 目标的恢复架构

设计和实施帮助符合 RTO 目标的其他恢复架构。实施方法将包括添加失效转移机制、冗余系统、持续监控和配置管理系统。这些额外的架构系统有助于缩短响应时间，使您总体上可以缩短 RTO。

根据需要灾难恢复过程的特定系统层级，您采用的确切机制和使用的工具将有所不同。以下是根据不同的 RTO 要求，在不同的灾难恢复场景中使用的一些策略和工具。

备份和恢复（RTO：数小时到数天）

备份和恢复策略是最常见且易于实施的灾难恢复策略之一。该策略涉及经常运行备份来存储您的业务数据。每当发生影响系统的事件时，您只需恢复备份数据即可使系统重新启动并运行。

虽然这确实可以促进业务连续性，但也意味着您必须提前定义任务关键型应用程序的 RPO。较低的 RPO 可能会导致需要频繁进行增量备份，才能持续存储数据。

Pilot light（RTO：小时）

在网络韧性方面，pilot light 是核心基础设施的小型缩减版本，以最低容量运行。这是一个您可以立即扩展到正常运行状态的系统。您将在此外部系统中托管任务关键型数据库和系统。每当灾难影响您的主系统时，您都可以切换到 pilot light 系统并扩大其规模，进而满足需求，同时努力恢复主系统。

暖备用（RTO：几分钟到几小时）

暖备用比 pilot light 策略更上一层楼，它会托管一套与您的活动运行环境近乎相同的克隆环境。工程师会定期将更新从主系统推送到这个克隆，这意味着如果您的主系统离线，它可以立即接管。暖备用系统是资源密集型的，因此它们通常仅用于无法承受较长停机时间的关键系统。

多站点多活（RTO：几秒到几分钟）

最后，多站点多活是并行运行系统的完整克隆。由于这些系统同时处于活动状态，并且它们之间有持续的数据流以保持同步，因此它们可以立即替换任何出现停机的系统。当然，这类方案非常耗费资源，仅用于无论如何都不能停机超过几分钟的系统。

AWS 提供一系列服务和架构模式，可帮助满足您在恢复事件中的 RTO 需求：

• Amazon Application Recovery Controller 可帮助您跨 AWS 区域和可用区（AZ）管理并自动执行应用程序的恢复。这些功能支持更轻松可靠地恢复应用程序，而无需像传统工具和流程那样进行繁琐的手动操作。
• AWS Backup 是一项完全托管式服务，能够跨 AWS 服务和混合工作负载集中、自动进行数据保护。
• AWS 弹性灾难恢复（AWS DRS）利用经济实惠的存储、极少的计算以及时间点恢复功能，通过快速、可靠地恢复本地应用程序和基于云的应用程序，最大限度地减少了停机时间和数据丢失。
• AWS 韧性监测中心是 AWS 管理控制台上用于管理和改善 AWS 应用程序韧性状况的中心位置。AWS 韧性监测中心使您能够定义韧性目标、根据这些目标评测韧性状况，并根据 AWS Well-Architected Framework 实施改进建议。

立即创建免费账户，开始在 AWS 上使用事件恢复解决方案。