了解工作负载

要应用该框架，首先需了解要分析的工作负载。系统架构图可作为记录系统最具相关性细节的起点。但是，尝试分析整个工作负载可能很复杂，因为许多系统都包含众多组件和交互。因此，我们建议您重点关注用户故事，这些故事是从最终用户角度编写的非正式、概括性软件功能说明。其目的是阐明软件功能如何为客户提供价值。然后，您可以使用架构图和数据流程图模拟这些用户故事，以便更轻松地评测提供所述业务功能的技术组件。例如，一个应用内手机游戏购买解决方案可能包含两个用户故事：“购买应用内点数”和“获得应用内退款”，如下图所示。（此示例架构重点展示如何将系统分解为用户故事；而非表示具有高韧性的应用程序。）

每个用户故事都包含四个常见组件：代码和配置、基础设施、数据存储以及外部依赖关系。您的图表应包含所有这些组件，并反映各组件之间的交互。例如，如果您的 Amazon API Gateway 端点负载过高，请考虑如何将该负载级联到系统中的其他组件，例如 AWS Lambda 函数或 Amazon DynamoDB 表。跟踪这些互动有助于您了解故障模式如何影响用户故事。如上图所示，您可以使用数据流程图或在架构图中使用简单的流程箭头直观地捕获此流程。对于每个组件，请考虑捕获所传输的信息类型、接收的信息、通信是同步还是异步，以及跨越哪些故障边界等详细信息。在该示例中，DynamoDB 表在两个用户故事中共享，如您所见，箭头指示应用内退款故事中的 Lambda 组件访问了应用内购买故事中的 DynamoDB 表。这意味着，由于故障共担，由应用内购买用户故事引起的故障可能会级联到应用内退款用户故事。

此外，了解每个组件的基准配置十分重要。基准配置明确约束条件，例如每秒平均和最大事务数、有效载荷最大大小、客户端超时以及资源的默认或当前服务配额。如果您要模拟新设计，我们建议您记录设计的功能要求并考虑各项限制。这可以帮助您了解故障模式可能如何在组件中表现出来。

最后，您应该根据用户故事提供的商业价值来确定其优先级。这种优先级排序可帮助您首先专注于工作负载中最关键的功能。然后，您可以将分析重点放在构成该功能关键路径的工作负载组件上，并更快地利用该框架实现价值。随着流程的迭代，您可以依次分析不同优先级的其他用户故事。