本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
第 1 阶段：设定目标
了解所需的弹性水平以及如何衡量弹性是设定目标阶段的基础。如果你没有目标，也无法衡量它，那么很难改进一些东西。
并非所有应用程序都需要相同级别的弹性。在设定目标时，请考虑所需的水平，以便进行正确的投资和权衡取舍。一个很好的类比是一辆汽车：它有四个轮胎，但只有一个备用轮胎。在骑行过程中出现多个漏气轮胎的可能性很低，而拥有额外的备件可能会影响其他功能，例如载货空间或燃油效率，因此这是一个合理的权衡。
定义目标后，您将在后期阶段（第 2 阶段：设计和实施，第 4 阶段：运营）实施可观测性控制，以了解目标是否得到满足。
映射关键应用程序
定义弹性目标不应仅仅是一场技术对话。取而代之的是，从以业务为导向的重点开始，以了解应用程序应该提供什么以及减值的后果。然后，这种对业务目标的理解会延伸到架构、工程和运营等领域。您定义的任何弹性目标都可能应用于您的所有应用程序，但是衡量目标的方式通常会因应用程序的功能而异。您可能正在运行对业务至关重要的应用程序，如果此应用程序受到损害，您的组织可能会损失大量收入或声誉受到损害。或者，您可能还有另一个不那么重要的应用程序，它可以容忍一些停机时间，而不会对组织的业务能力产生负面影响。
举个例子，想想零售公司的订单管理应用程序。如果订单管理应用程序的组件受损且无法正常运行，则新的销售将无法通过。这家零售公司还在其一栋大楼内为员工开设了一家咖啡店。咖啡店有一个在线菜单，员工可以在静态网页上访问该菜单。如果该网页不可用，一些员工可能会抱怨，但这不一定会对公司造成经济损失。基于此示例，企业可能会选择为订单管理应用程序设定更激进的弹性目标，但不会为确保 Web 应用程序的弹性进行大量投资。
确定最关键的应用程序、在哪里投入最多精力以及在何处进行权衡取舍，与衡量应用程序在生产中的弹性同样重要。为了更好地了解减值的影响，您可以进行业务影响分析 (BIA)。BIA 提供了一种结构化和系统的方法来识别关键业务应用程序并确定其优先级，评估潜在的风险和影响，并确定支持依赖关系。BIA 有助于量化组织中最重要的应用程序的停机成本。该指标有助于概述如果特定应用程序受损且无法完成其功能，将花费多少钱。在前面的示例中，如果订单管理应用程序受损，零售业务可能会损失大量收入。
映射用户故事
在 BIA 过程中，您可能会发现一个应用程序负责多个业务职能，或者一个业务职能需要多个应用程序。以之前的零售公司为例，订单管理功能可能需要单独的结账、促销和定价应用程序。如果一个应用程序失败，企业和与公司互动的用户可能会感受到影响。例如，公司可能无法添加新订单，无法提供促销和折扣的访问权限，也无法更新其产品的价格。订单管理功能所需的这些不同功能可能依赖于多个应用程序。这些函数还可能有多个外部依赖关系，这使得实现纯粹以组件为中心的弹性的过程过于复杂。处理这种情况的更好方法是关注用户故事，这些故事
关注用户故事可以帮助你了解客户体验中哪些部分最重要，这样你就可以建立机制来防范特定的威胁。在前面的示例中，一个用户情景可能是结账，它涉及结账应用程序，并且依赖于定价应用程序。另一个用户故事可能是观看促销活动，其中涉及促销应用程序。在绘制了最关键的应用程序及其用户情景之后，您可以开始定义用于衡量这些用户情景弹性的指标。这些指标可以应用于整个产品组合或个人用户故事。
定义测量
恢复点目标 (RPO)、恢复时间目标 (RTO) 和服务级别目标 (SLO) 是标准的行业衡量标准，用于评估给定系统的弹性。RPO 是指在发生故障时企业可以容忍多少数据丢失，而 RTO 则是衡量应用程序在停机后必须以多快的速度恢复可用的标准。这两个指标以时间单位衡量：秒、分钟和小时。您还可以衡量应用程序正常运行的时间长度；也就是说，它按设计执行其功能并可供其用户访问。这些 SLO 详细说明了客户将获得的预期服务级别，并通过诸如在不到一秒的响应时间内毫无错误地得到处理的请求的百分比 (%) 等指标来衡量（例如，99.99% 的请求每月将收到响应）。 RPO 和 RTO 与灾难恢复策略有关，假设应用程序操作和恢复过程会中断，从恢复备份到重定向用户流量。通过实施高可用性控制来解决 SLO，这往往会减少应用程序的停机时间。
SLO 指标通常用于服务级别协议 (SLA) 的定义，服务级别协议 (SLA) 是服务提供商与最终用户之间的合同。SLA通常附带财务承诺，并概述了如果这些协议未得到满足，则提供商需要支付的罚款。但是，SLA 并不能衡量您的弹性状况，提高 SLA 并不能使您的应用程序更具弹性。
您可以开始基于 SLO、RPO 和 RTO 来设定目标。在定义了弹性目标并清楚地了解了 RPO 和 RTO 目标之后，您可以使用对架构进行评估，AWS Resilience Hub
创建其他测量
RPO、RTO 和 SLO 是衡量弹性的良好指标，但您也可以从业务角度考虑目标，并围绕应用程序的功能定义目标。例如，您的目标可能是：如果我的前端和后端之间的延迟增加40％，则每分钟的成功订单将保持在98％以上。或者：即使丢失了特定组件，每秒启动的直播也将保持在平均值的标准差之内。您还可以创建目标，以缩短已知故障类型的平均恢复时间 (MTTR)；例如：如果出现任何已知问题，恢复时间将缩短 x%。创建与业务需求相一致的目标可以帮助您预测应用程序应容忍的故障类型。它还可以帮助您确定降低应用程序受损可能性的方法。
如果您考虑一下在丢失为应用程序提供支持的实例的 5% 时继续运行的目标，那么您可能会认为您的应用程序应该预先扩展，或者能够以足够快的速度扩展以支持该事件期间产生的额外流量。或者，您可以决定应使用不同的架构模式，如第 2 阶段：设计和实施部分中所述。
您还应该针对您的特定业务目标实施可观察性衡量标准。例如，您可以跟踪平均订单率、平均订单价格、平均订阅数量或其他指标，这些指标可以根据应用程序的行为提供对业务健康状况的见解。通过为应用程序实现可观察性功能，您可以创建警报，并在这些指标超出您定义的界限时采取行动。第 4 阶段：操作部分更详细地介绍了可观察性。
