

# REL13-BP01 定义停机和数据丢失的恢复目标
<a name="rel_planning_for_recovery_objective_defined_recovery"></a>

 工作负载具有恢复时间目标（RTO）和恢复点目标（RPO）。 

 *恢复时间目标 (RTO)* 是指服务中断和服务恢复之间的最大可接受延迟。这可以确定在服务不可用时被视为可接受的时间窗口。 

 *恢复点目标 (RPO)*  是指自上一个数据恢复点以来的最大可接受时间。这可以确定在上一个恢复点和服务中断之间可接受的数据丢失程度。 

 在为您的工作负载选择合适的灾难恢复（DR，Disaster Recovery）策略时，RTO 和 RPO 值是重要的考虑因素。这些目标由业务部门确定，然后由技术团队用来选择和实施 DR 策略。 

 **期望结果：**  

 每个工作负载都有一个根据业务影响定义的指定 RTO 和 RPO。工作负载被分配到一个预定义的层，该层定义服务可用性和可接受的数据丢失，以及关联的 RTO 和 RPO。如果无法进行这样的分层，那么可以为每个工作负载分配定制的分层，用于以后创建层。在为工作负载选择灾难恢复策略实施时，使用 RTO 和 RPO 作为主要考虑因素之一。在选择 DR 策略时还要考虑成本约束、工作负载依赖关系和运维需求。 

 对于 RTO，了解基于中断持续时间的影响。是线性的还是非线性的影响？（例如，四小时后，您关闭一条生产线，直到下一班开始）。 

 如下所示的灾难恢复矩阵可以帮助您了解工作负载的重要性与恢复目标之间的关系。（请注意，X 轴和 Y 轴的实际值应根据您组织的需求进行定制）。 

![\[显示灾难恢复矩阵的图表\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/2022-03-31/framework/images/disaster-recovery-matrix.png)


 **常见反模式：** 
+  未定义恢复目标。 
+  选择任意恢复目标。 
+  选择过于宽松并且不符合业务目标的恢复目标。 
+  不了解停机和数据丢失的影响。 
+  选择不切实际的恢复目标，如零恢复时间和零数据丢失，这对于您的工作负载配置可能无法实现。 
+  选择比实际业务目标更严格的恢复目标。这将强制实施比工作负载所需的成本更高并且更复杂的 DR。 
+  选择与所依赖工作负载的恢复目标不兼容的恢复目标。 
+  您的恢复目标没有考虑法规合规性要求。 
+  为工作负载定义了 RTO 和 RPO，但从未测试过。 

 **建立此最佳实践的好处：** 在指导您的 DR 实施时，需要您的恢复时间目标和数据丢失恢复目标。 

 **未建立此最佳实践暴露的风险等级：** 高 

## 实施指导
<a name="implementation-guidance"></a>

 对于给定的工作负载，您必须了解停机和数据丢失对业务的影响。随着停机时间或数据丢失的增加，影响通常会越来越大，但这种增长的形式可能会因工作负载类型而异。例如，您也许可以容忍长达一小时的停机时间而没有多大影响，但在一小时之后影响会迅速上升。对业务的影响表现为多种形式，包括货币成本（如收入损失）、客户信任（以及对声誉的影响）、运维问题（如错过工资发放或生产力下降）和监管风险。使用以下步骤了解这些影响，并为您的工作负载设置 RTO 和 RPO。 

 **实施步骤** 

1.  确定此工作负载的业务利益相关者，并与他们一起实施这些步骤。工作负载的恢复目标是一项业务决策。然后，技术团队与业务利益相关者合作，使用这些目标来选择 DR 策略。 
**注意**  
对于步骤 2 和 3，您可以使用 [实施工作表](#implementation-worksheet).

1.  通过回答以下问题，收集必要的信息来做出决策。 

1.  在组织中，您是否对工作负载影响的重要性进行了分类或分级？ 

   1.  如果有，请将此工作负载分配到一个类别 

   1.  如果没有，则建立这些类别。创建不超过五个类别，并细化每个类别的恢复时间目标范围。类别示例包括：关键、高、中、低。要了解工作负载如何映射到类别，请考虑工作负载是任务关键型、业务重要型还是非业务驱动型。 

   1.  根据类别设置工作负载 RTO 和 RPO。始终选择比进入此步骤时计算的原始值更严格的类别（更低的 RTO 和 RPO）。如果这导致值发生了不适当的较大改变，那么考虑创建一个新类别。 

1.  根据这些答案，为工作负载分配 RTO 和 RPO 值。这可以直接完成，也可以通过将工作负载分配给预定义的服务层来完成。 

1.  在工作负载团队和利益相关者可访问的位置，记录此工作负载的灾难恢复计划（DRP，disaster recovery plan），此计划是组织的 [业务连续性计划（BCP，Business Continuity Plan）](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/business-continuity-plan-bcp.html)的一部分 

   1.  记录 RTO 和 RPO，以及用于确定这些值的信息。包括用于评估工作负载对业务影响的策略 

   1.  除 RTO 和 RPO 之外，记录您根据灾难恢复目标正在跟踪或计划跟踪的其他指标 

   1.  在进行创建时，您将 DR 策略和运行手册的详细信息添加到此计划中。 

1.  通过在如图 15 所示的矩阵中查找工作负载的重要性，您可以开始建立为组织定义的预定义服务层。 

1.  根据 实施 DR 策略（或 DR 策略的概念验证）之后，[REL13-BP02 使用定义的恢复策略来实现恢复目标](rel_planning_for_recovery_disaster_recovery.md)测试此策略以确定工作负载的实际 RTC（Recovery Time Capability，恢复时间能力）和 RPC（Recovery Point Capability，恢复点能力）。如果这些能力没有达到所预期的恢复目标，那么，要么与您的业务利益相关者一起调整这些目标，要么对 DR 策略进行更改以便实现预期的目标。

 **主要问题** 

1.  在对业务产生严重影响之前，工作负载可以停止的最长时间是多少 

   1.  确定在工作负载中断时，每分钟业务的货币成本（直接财务影响）。 

   1.  请注意，影响并不总是线性的。影响可能在一开始是有限的，然后在超过一个关键时间点后迅速增加。 

1.  在对业务造成严重影响之前，可以丢失的最大数据量是多少 

   1.  对于最关键的数据存储，请考虑此值。确定其他数据存储的各自关键性。 

   1.  如果工作负载数据丢失，是否可以重新创建？ 如果这在操作上比备份和还原更容易，那么根据用于重新创建工作负载数据的源数据的重要性来选择 RPO。 

1.  此工作负载所依赖的工作负载（下游）或依赖于此工作负载的工作负载（上游）的恢复目标和可用性期望是什么？ 

   1.  选择使此工作负载能够满足上游依赖项要求的恢复目标 

   1.  根据下游依赖项的恢复能力，选择可实现的恢复目标。非关键的下游依赖项（您可以“绕过”它们）可以排除。或者，处理关键的下游依赖项，在必要时提高其恢复能力。 

 **其他问题** 

 考虑以下问题，以及它们如何应用于此工作负载： 

1.  根据中断类型（区域与可用区等），您是否有不同的 RTO 和 RPO？ 

1.  您的 RTO/RPO 是否会在特定时间（季节性、销售活动、产品发布）发生变化？ 如果是这样，不同的测量和时间边界是什么？ 

1.  如果工作负载中断，会有多少客户受到影响？ 

1.  如果工作负载中断，对声誉有何影响？ 

1.  如果工作负载中断，可能会产生哪些其他运营影响？ 例如，如果电子邮件系统不可用或工资单系统无法提交事务，则会影响员工的工作效率。 

1.  工作负载 RTO 和 RPO 如何与业务线和组织 DR 策略保持一致？ 

1.  是否存在提供服务的内部合同义务？ 不履行这些义务会受到处罚吗？ 

1.  数据的监管或合规性约束是什么？ 

## 实施工作表
<a name="implementation-worksheet"></a>

 您可以将此工作表用于实施步骤 2 和 3。您可以调整此工作表以满足您的特定需求，例如添加其他问题。 

<a name="worksheet"></a>![\[工作表\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/2022-03-31/framework/images/worksheet.png)


 **实施计划的工作量级别： **低 

## 资源
<a name="resources"></a>

 **相关最佳实践：** 
+  [REL09-BP04 定期执行数据恢复以验证备份完整性和流程](rel_backing_up_data_periodic_recovery_testing_data.md)
+ [REL13-BP02 使用定义的恢复策略来实现恢复目标](rel_planning_for_recovery_disaster_recovery.md) 
+ [REL13-BP03 测试灾难恢复实施以验证实施效果](rel_planning_for_recovery_dr_tested.md) 

 **相关文档：** 
+  [AWS 架构博客：灾难恢复系列](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/) 
+  [AWS 上工作负载的灾难恢复：云中的恢复（AWS 白皮书）](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html) 
+  [使用 AWS Resilience Hub 管理弹性策略](https://docs.aws.amazon.com/resilience-hub/latest/userguide/resiliency-policies.html) 
+  [AWS 合作伙伴：可以帮助进行灾难恢复的合作伙伴](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery) 
+  [AWS Marketplace：可以用于灾难恢复的产品](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery) 

 **相关视频：** 
+  [AWS re:Invent 2018：适用于多区域主动-主动应用程序的架构模式（ARC209-R2）](https://youtu.be/2e29I3dA8o4) 
+  [AWS 上工作负载的灾难恢复](https://www.youtube.com/watch?v=cJZw5mrxryA) 