本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# 第一阶段：设定目标
了解所需的韧性水平以及衡量方式是*设定目标*阶段的基础。如果您没有目标，也无法进行衡量，则很难改进。
并非所有应用程序都需要相同的韧性水平。在设定目标时，请考虑所需的水平，以便作出正确的投资和权衡取舍。一个很好的类比是汽车：一辆车有四个轮胎，但只携带一个备胎。行驶途中多个轮胎同时爆胎可能性很低，而携带多个备胎可能会影响载货空间或燃油效率等其他功能，因此这是一个合理的权衡取舍。
确定目标后，您需要在后续阶段（[第二阶段：设计与实施](stage-2.md)和[第四阶段：运营](stage-4.md)）中实施可观测性控制，以了解目标是否已实现。
## 映射关键应用程序
定义韧性目标不应仅仅是一场技术对话。相反，应从以业务为导向的重点入手，了解应用程序应提供的功能以及受损的后果。这种对业务目标的理解随后会延伸到架构、工程和运营等领域。您定义的任何韧性目标都*可能*适用于所有应用程序，但是衡量目标的方式通常会因应用程序的功能而异。您可能正在运行一个对业务至关重要的应用程序，如果此应用程序受到损害，您的组织可能会损失大量收入或遭受声誉损害。或者，您可能还有另一个不那么重要的应用程序，它可以容忍一些停机时间，而不会对组织的业务能力产生负面影响。
例如，设想一家零售公司的订单管理应用程序。如果订单管理应用程序的组件受损且无法正常运行，则新的销售将无法处理。这家零售公司还在某栋办公楼中为其员工开设了一家咖啡店。咖啡店有一个在线菜单，员工可以在静态网页上访问该菜单。如果该网页不可用，一些员工可能会抱怨，但这不一定会对该公司造成经济损失。基于此示例，企业可能会选择为订单管理应用程序设定更严格的韧性目标，但不会投入大量资源来确保 Web 应用程序的韧性。
确定最关键的应用程序、投入最多精力的领域以及进行权衡取舍的因素，与衡量应用程序在生产中的韧性同样重要。为了更好地了解损害的影响，您可以进行[业务影响分析（BIA）](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-of-on-premises-applications-to-aws/business-impact-analysis-and-risk-assessment.html)。BIA 提供了一种结构化和系统化的方法来识别关键业务应用程序并确定其优先级，评测潜在的风险和影响，并确定支持依赖关系。BIA 可帮助量化组织中最重要的应用程序的*停机时间成本*。该指标有助于明确特定应用程序受损且无法完成其功能时的成本。在前面的示例中，如果订单管理应用程序受损，零售企业可能会损失大量收入。
## 映射用户故事
在 BIA 过程中，您可能会发现某个应用程序负责多项业务功能，或者某项业务功能需要多个应用程序。以之前的零售公司为例，订单管理功能可能需要单独的应用程序进行结账、促销和定价。如果一个应用程序发生故障，企业和与该公司互动的用户可能会受到影响。例如，公司可能无法添加新订单、提供对促销和折扣的访问或更新其产品的价格。订单管理功能所需的这些不同功能可能依赖于多个应用程序。这些功能还可能有多个外部依赖关系，从而使实现纯粹以组件为中心的韧性的过程过于复杂。处理这种情况更好的方法是关注[用户故事](https://en.wikipedia.org/wiki/User_story)，这些故事概述了用户在与一个或一组应用程序交互时所期望的体验。
关注用户故事可以帮助您了解客户体验最重要的部分，这样您就可以建立机制来防范特定的威胁。在前面的示例中，一个用户故事可以是“结账”，其涉及结账应用程序，并且依赖于定价应用程序。另一个用户故事可以是“查看促销活动”，其涉及促销应用程序。在映射最关键的应用程序及其用户故事之后，您可以开始定义用于衡量这些用户故事韧性的指标。这些指标可以应用于整个产品组合，也可以应用于单个用户故事。
## 定义衡量指标
[恢复点目标（RPO）](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-of-on-premises-applications-to-aws/recovery-objectives.html)、[恢复时间目标（RTO）](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-of-on-premises-applications-to-aws/recovery-objectives.html)和[服务水平目标（SLO）](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/availability-with-dependencies.html)是标准的行业衡量指标，用于评测给定系统的韧性。RPO 是指在发生故障时企业能够容忍的数据丢失量，而 RTO 则是应用程序在中断后必须恢复可用的速度衡量指标。这两个指标以时间单位衡量：秒、分钟和小时。您还可以衡量应用程序正常运行的时间；即按设计执行其功能并可供其用户访问的时间。这些 SLO 详细说明了客户将获得的预期服务水平，并通过在不到一秒的响应时间内无错误处理请求的百分比（%）等指标来衡量（例如，每月 99.99% 的请求将得到响应）。 RPO 和 RTO 与灾难恢复策略有关，假设应用程序运行和恢复过程会中断，并且恢复过程范围从恢复备份到重定向用户流量。通过实施高可用性控制措施可解决 SLO，这通常能缩短应用程序的停机时间。
SLO 指标通常用于定义服务水平协议（SLA），即服务提供商与最终用户之间的合同。SLA 通常附带财务承诺，并规定当协议未得到满足时服务提供商需支付的罚款。但是，SLA 并非韧性状况的衡量指标，提高 SLA 也不能使您的应用程序更具韧性。
您可以基于 SLO、RPO 和 RTO 开始设定目标。在定义韧性目标并明确了解 RPO 和 RTO 目标之后，您可以使用 [AWS Resilience Hub](https://aws.amazon.com/resilience-hub/) 对架构进行评估，以发现潜在的韧性相关弱点。AWS Resilience Hub 根据 AWS Well-Architected Framework 最佳实践评估应用程序架构，并针对需要改进的具体方面分享修复指导，以实现您确定的 RTO 和 RPO 目标。
## 创建其他衡量指标
RPO、RTO 和 SLO 是衡量韧性的良好指标，但您也可以从业务角度考虑目标，并围绕应用程序的功能定义目标。例如，您的目标可以是：*如果前端和后端之间的延迟增加 40%，则每分钟的成功订单数将保持在 98% 以上。*或：*即使丢失了特定组件，每秒启动的流数仍将保持在平均值的标准偏差范围内。*您还可以创建目标，以缩短已知故障类型的平均恢复时间（MTTR）；例如：*如果发生任何已知问题，恢复时间将缩短 x%。*创建与业务需求一致的目标可以帮助您预测应用程序应容忍的故障类型。它还可以帮助您确定降低应用程序受损可能性的方法。
如果考量在丢失 5% 为应用程序提供支持的实例时仍继续运行的目标，您可能会认为应用程序应预先扩展，或者能够以足够快的速度进行扩展，以支持在该事件期间产生的额外流量。或者，您可以决定应使用不同的架构模式，如[第二阶段：设计与实施](stage-2.md)部分中所述。
您还应该针对特定业务目标实施可观测性措施。例如，您可以跟踪*平均订单率*、*平均订单价格*、*平均订阅数量*或根据应用程序行为提供业务健康状况洞察的其他指标。通过为应用程序实施可观测性功能，您可以创建告警，并在这些指标超出定义的边界时采取措施。[第四阶段：运营](stage-4.md)部分将更详细地介绍可观测性。