# REL13-BP01 定义停机和数据丢失的恢复目标
故障可通过多种方式影响您的业务。首先，故障可能导致服务中断（停机时间）。其次，故障可能导致数据丢失、不一致或过时。为了指导您如何应对故障和从故障中恢复，请为每个工作负载定义恢复时间目标（RTO）和恢复点目标（RPO）。*恢复时间目标（RTO）*是指服务中断和恢复服务之间可接受的最大延迟。*恢复点目标（RPO）*是指在上一个数据恢复点之后可接受的最长时间。
**期望结果：**根据技术考虑和业务影响，每个工作负载都有指定的 RTO 和 RPO。
**常见反模式：**
+ 您尚未指定恢复目标。
+ 您选择任意的恢复目标。
+ 您选择的恢复目标过于宽松并且不符合业务目标。
+ 您尚未评估停机时间和数据丢失的影响。
+ 您选择不切实际的恢复目标，如零恢复时间或零数据丢失，这对工作负载配置而言可能无法实现。
+ 您选择的恢复目标比实际业务目标更苛刻。这会迫使实施恢复的成本和复杂度超出工作负载所需。
+ 您选择的恢复目标与相关工作负载的恢复目标不兼容。
+ 您没有考虑监管和合规要求。
**建立此最佳实践的好处：**在为工作负载设置 RTO 和 RPO 时，可以根据业务需求制定明确且可衡量的恢复目标。一旦设定了这些目标，就可以创建专为实现这些目标而量身定制的灾难恢复（DR）计划。
**在未建立这种最佳实践的情况下暴露的风险等级：**高
## 实施指导
构造一个矩阵或工作表，来协助指导灾难恢复规划。在矩阵中，创建不同的工作负载类别或层级，所依据的是这些类别或层级的业务影响（例如严重、高、中和低），以及每个工作负载类别或层级关联的目标 RTO 和 RPO。以下矩阵提供了您可以遵循的示例（请注意，RTO 和 RPO 值可能有所不同）：
![\[图中显示了灾难恢复矩阵\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/latest/framework/images/disaster-recovery-matrix.png)
对于每个工作负载，调查和了解停机时间和数据丢失对业务的影响。影响通常会随着停机时间和数据丢失而增加，但影响的形式可能会因工作负载类型而异。例如，长达一小时的停机时间可能影响很小，但在一小时之后，影响可能会迅速加剧。影响可能以多种形式呈现，包括财务影响（如收入损失）、声誉影响（包括失去客户信任）、运营影响（如错过工资发放或生产率下降）和监管风险。完成后，将工作负载分配到相应的层级。
分析故障所产生的影响时，请考虑以下问题：
1. 在对业务产生不可接受的影响之前，工作负载可以保持不可用的最长时间是多少？
1. 工作负载中断将对业务产生多大影响以及会产生什么样的影响？ 考虑各种影响，包括财务、声誉、运营和监管。
1. 在对业务造成不可接受的影响之前，可以丢失或无法恢复的最大数据量是多少？
1. 能否从其它来源重新创建丢失的数据（也称为*派生的* 数据）？ 如果是，还要考虑用于重新创建工作负载数据的所有源数据的 RPO。
1. 此工作负载所依赖的工作负载（下游）的恢复目标和可用性期望是什么？ 根据工作负载下游依赖关系的恢复能力，工作负载的目标必须是可实现的。考虑可能的下游依赖关系解决办法或缓解措施，以提高此工作负载的恢复能力。
1. 依赖于此工作负载的工作负载（上游）的恢复目标和可用性期望是什么？ 上游工作负载目标可能要求此工作负载具有比最初看起来更严格的恢复能力。
1. 根据事件的类型，是否有不同的恢复目标？ 例如，根据事件影响的是一个可用区还是整个区域，您可能有不同的 RTO 和 RPO。
1. 恢复目标在一年中的某些事件或时期是否会发生变化？ 例如，在假日购物季、体育赛事、特别促销和新产品发布期间，您可能有不同的 RTO 和 RPO。
1. 恢复目标如何与您可能拥有的任何业务线和组织灾难恢复策略保持一致？
1. 是否需要考虑法律或合同后果？ 例如，根据合同，您是否有义务提供具有给定 RTO 或 RPO 的服务？ 不履行这些义务会受到什么处罚？
1. 您是否需要维护数据完整性来满足监管或合规性要求？
以下工作表有助于您评估每项工作负载。您可以修改此工作表来满足具体的需求，例如添加附加问题。
![\[工作表\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/latest/framework/images/worksheet.png)
### 实施步骤
1. 确定业务利益相关方和负责每个工作负载的技术团队，并与他们互动。
1. 对组织中的工作负载影响创建严重性类别或层级。类别示例包括：严重、高、中和低。对于每个类别，请选择反映您的业务目标和要求的 RTO 和 RPO。
1. 将您在上一步创建的影响类别之一分配给每个工作负载。要决定工作负载如何映射到某个类别，请考虑工作负载对业务的重要性，以及中断或数据丢失的影响，并使用上述问题来提供指导。这将为每个工作负载生成一个 RTO 和 RPO。
1. 考虑上一步中确定的每个工作负载的 RTO 和 RPO。让工作负载的业务和技术团队参与进来，以确定是否应调整目标。例如，业务利益相关者可能确定需要更严格的目标。或者，技术团队可能决定应修改目标，以使这些目标能够在可用的资源和技术限制下得以实现。
## 资源
**相关最佳实践：**
+ [REL09-BP04 定期执行数据恢复以验证备份完整性和流程](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_backing_up_data_periodic_recovery_testing_data.html)
+ [REL12-BP01 使用行动手册调查故障](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_testing_resiliency_playbook_resiliency.html)
+ [REL13-BP02 使用定义的恢复策略来实现恢复目标](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_disaster_recovery.html)
+ [REL13-BP03 测试灾难恢复实施以验证实施效果](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_dr_tested.html)
**相关文档：**
+ [AWS Architecture Blog: Disaster Recovery](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)
+ [Managing resiliency policies with AWS Resilience Hub](https://docs.aws.amazon.com/resilience-hub/latest/userguide/resiliency-policies.html)
+ [APN 合作伙伴：可帮助进行灾难恢复的合作伙伴](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: Architecture Patterns for Multi-Region Active-Active Applications](https://youtu.be/2e29I3dA8o4)
+ [ 上工作负载的灾难恢复AWS](https://www.youtube.com/watch?v=cJZw5mrxryA)