本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# 应用框架
<a name="applying-framework"></a>

应用韧性分析框架的最佳方法是从一组按故障类别组织的标准问题开始，应询问您正在分析的用户故事中的每个组件。如果某些问题不适用于工作负载中的所有组件，请使用最适合的问题。

您可以从两个角度思考故障模式：
+ 故障如何影响组件支持用户故事的能力？
+ 故障如何影响组件与其他组件的交互？

例如，当您考虑数据存储和过高负载时，可能会思考数据库承受过高负载而导致查询超时的故障模式。您可能还会思考，数据库客户端如何通过重试使数据库不堪重负或无法关闭数据库连接，从而耗尽连接池。另一个例子是身份验证流程，该流程可能包括多个步骤。您需要仔细考虑多重身份验证（MFA）应用程序或第三方身份提供者（IdP）的故障可能会如何影响此身份验证系统中的用户故事。

在回答以下问题时，应考虑故障的根源。例如，过载是由客户激增引起的，还是由人工运营人员在维护活动期间将过多节点停止使用造成的？ 您也许能够在每个问题中找出多种故障来源，而这些来源可能需要不同的缓解措施。在提出这些问题的同时，请记录您发现的潜在故障模式、其适用的组件，以及每个故障的来源。

**单点故障**
+ 该组件是否采用冗余架构设计？
+ 如果该组件发生故障会发生什么？
+ 您的应用程序能否容许单个可用区部分或全部失效？

**延迟过长**
+ 如果此组件的延迟时间增加，或者与其交互的组件延迟增加（或发生网络中断，例如 TCP 重置），会发生什么？
+ 您是否已适当配置超时和重试策略？
+ 采用快速失效机制还是慢速失效机制？ 是否存在级联效应，例如，由于采用快速失效机制而无意中将所有流量发送到受影响的资源？
+ 对此组件提出的最耗费资源的请求是什么？

**负载过高**
+ 哪些因素可能导致该组件不堪重负？ 该组件又如何可能导致其他组件不堪重负？
+ 如何避免将资源浪费在注定失败的工作上？
+ 您是否为该组件配置了断路器？
+ 是否存在无法解决的积压问题？
+ 此组件在哪些情况下可能出现双模态行为？
+ 可能会超出哪些限制或服务配额（包括存储容量）？
+ 组件在负载下如何扩展？

**配置错误和错误**
+ 如何防止将错误配置和错误部署到生产环境？
+ 您能否自动回滚错误的部署，或将流量从部署更新或更改的故障容器中移开？
+ 您有哪些护栏可以防止运营人员失误？
+ 哪些项目（例如凭证或证书）可能会过期？

**故障共担**
+ 您的故障隔离边界是什么？
+ 对部署单元所做的更改是否至少与预期的[故障隔离边界](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/abstract-and-introduction.html)一样小，但理想情况下更小？例如，单机环境（故障隔离边界内的单个实例）。
+ 此组件是否在多个用户故事或其他工作负载之间共享？
+ 还有哪些组件与此组件紧密耦合？
+ 如果此组件或其依赖关系出现部分故障或灰色故障会发生什么？

提出这些问题之后，您还可以使用 SEEMS 来制定针对您的工作负载和每个组件的其他具体问题。SEEMS 最适合用作思考故障模式的结构化方法，也可用作执行韧性分析时的灵感来源。它并非僵化的分类体系。不要花时间纠结特定的故障模式属于哪个类别，这无关紧要。重要的*是*您想到了该故障并将其记录下来。没有错误答案；发挥创造力并跳出固有思维方式是有益的。此外，不要假设某个故障模式已经得到缓解；请包括您能想到的所有潜在故障模式。

您不太可能在第一次练习时就预见到所有潜在的故障模式。多次迭代框架可以帮助您生成更完整的模型，因此不必在第一次分析时就尝试解决所有问题。您可以按定期（每周或每两周）的节奏进行分析。在每个会话中，重点关注特定故障模式或组件。这有助于稳步、循序渐进地提升工作负载的韧性。收集用户故事的潜在故障模式列表后，您可以决定如何应对这些模式。