执行故障模式分析的体系结构策略

适用于此 Azure Well-Architected 框架可靠性清单建议：

本指南介绍了为工作负荷执行故障模式分析（FMA）的最佳做法。 FMA 是确定工作负荷中潜在故障点和关联的流以及相应地规划缓解作的做法。 在流的每个步骤中，你都会确定多个故障类型的爆破半径，这有助于设计新的工作负荷或重构现有工作负荷，以最大程度地减少故障的广泛影响。

FMA 的关键原则是，无论应用多少层复原，都会发生故障。 更复杂的环境暴露在更多类型的故障中。 鉴于这种现实，FMA 允许你设计工作负荷，以便在发生故障时能够承受大多数类型的故障并正常恢复。

如果完全跳过 FMA 或执行不完整的分析，则工作负荷面临未预测行为和由欠佳设计引起的潜在中断的风险。

定义

查看并实施 用于标识流的建议。 假设你已根据关键性识别和确定用户和系统流的优先级。

你收集的数据和你在工作中创建的项目为你提供了整个流中涉及的数据路径的具体说明。 若要在 FMA 工作中取得成功，项目的准确性和彻底性至关重要。

确定关键流后，可以规划其所需的组件。 接下来，逐步执行每个流来标识依赖项，包括第三方服务和潜在故障点，并规划缓解策略。

分解工作负荷

从理念迁移到设计时，需要确定支持工作负荷所需的组件类型。 工作负荷确定必须计划的必要组件。 通常，需要规划入口控制、网络、计算、数据、存储、支持服务（例如身份验证、消息传送和机密或密钥管理），以及出口控制。 在设计工作的此阶段，你可能不知道要部署的特定技术，因此你的设计可能如以下示例所示。

创建初始体系结构设计后，可以覆盖流以识别这些流中使用的离散组件，并创建描述流及其组件的列表或工作流关系图。 若要了解组件的关键性，请使用分配给流的关键性定义。 请考虑组件故障对流的影响。

标识依赖项

确定工作负荷依赖项以执行单一故障点分析。 分解工作负荷和覆盖流可提供对工作负荷内部和外部的依赖项的见解。

内部依赖项是工作负荷运行所需的工作负荷范围中的组件。 典型的内部依赖项包括 API 或机密/密钥管理解决方案，例如 Azure Key Vault。 对于这些依赖项，请捕获可靠性数据，例如可用性 SLA 和缩放限制。 外部依赖项是工作负荷范围之外的必需组件，例如其他应用程序或第三方服务。 典型的外部依赖项包括身份验证解决方案，例如Microsoft Entra ID 和云连接解决方案，例如 Azure ExpressRoute。

识别并记录工作负荷中的依赖项，并将其包含在流文档项目中。

评估故障点

在工作负荷的关键流中，请考虑每个组件并确定该组件及其依赖项可能受到故障模式的影响。 请记住，规划复原和恢复时需要考虑许多故障模式。 任何一个组件都可以在任何给定时间受到多个故障模式的影响。 这些故障模式包括：

• 区域性中断。 整个 Azure 区域不可用。

• 可用性区域中断。 Azure 可用性区域不可用。

• 服务中断。 一个或多个 Azure 服务不可用。

• 分布式拒绝服务（DDoS）或其他恶意攻击。

• 应用或组件配置错误。

• 运算符错误。

• 计划内维护中断。

• 组件重载。

分析应始终位于要尝试分析的流上下文中，因此请务必记录该流对用户和预期结果的影响。 例如，如果你有电子商务应用程序并正在分析客户流，则特定故障模式对一个或多个组件的影响可能是所有客户都无法完成结帐。

请考虑每种故障模式的可能性。 有些不太可能发生，例如多区域或多区域中断，在冗余之外添加缓解计划并不是很好地利用资源和时间。

缓解措施

缓解策略分为两大类：为性能下降构建更多复原能力和设计。

构建更多复原能力包括向组件（如基础结构、数据和网络）添加冗余，并确保应用程序设计遵循持久性的最佳做法，例如将整体式应用程序分解为独立的应用和微服务。 有关详细信息，请参阅 有关冗余的建议 和 自我保存的建议。

若要针对性能下降进行设计，请确定可能禁用流的一个或多个组件但未完全禁用该流的潜在故障点。 若要维护端到端流的功能，可能需要将一个或多个步骤重新路由到其他组件或接受失败的组件运行函数，以便该函数在用户体验中不再可用。 若要返回到电子商务应用程序示例，微服务等失败组件可能会导致建议引擎不可用，但客户仍可以搜索产品并完成其交易。

还需要规划依赖项的缓解措施。 强依赖项在应用程序功能和可用性中起着关键作用。 如果他们缺席或遇到故障，可能会产生重大影响。 缺少弱依赖项可能会影响特定功能，不会影响整体可用性。 这种区别反映了维护服务与其依赖项之间的高可用性关系的成本。 将依赖项分类为强或弱，以帮助确定哪些组件对应用程序至关重要。

如果应用程序具有无法运行的强大依赖项，则这些依赖项的可用性和恢复目标应与应用程序本身的目标保持一致。 最大程度地减少依赖项以实现对应用程序可靠性的控制。 有关详细信息，请参阅 最大程度地减少应用程序服务之间的协调，以实现可伸缩性。

如果应用程序生命周期与其依赖项的生命周期紧密耦合，则应用程序的作灵活性可能会受到限制，尤其是对于新版本。

检测

故障检测对于确保已正确识别分析中的故障点并正确规划缓解策略至关重要。 在此上下文中进行检测意味着监视基础结构、数据和应用程序，并在出现问题时发出警报。 尽可能自动执行检测，并将冗余构建到作流程中，以确保始终捕获警报，并快速响应以满足业务需求。 有关详细信息，请参阅 有关监视的建议。

结果

为了获得分析结果，请创建一组有效传达调查结果的文档、与流组件和缓解相关的决策，以及故障对工作负荷的影响。

在分析中，根据严重性和可能性确定的故障模式和缓解策略的优先级。 使用此优先顺序将文档重点介绍那些常见且严重到足以保证花费时间、精力和资源来设计缓解策略方面的故障模式。 例如，某些故障模式在发生或检测时可能非常罕见。 围绕这些策略设计缓解策略并不值得成本。

有关文档起点，请参阅以下示例 表 。

在最初的 FMA 练习中，你生成的文档主要是理论规划。 应定期查看和更新 FMA 文档，以确保它们与工作负荷保持 up-to日期。 混沌测试和实际体验将帮助你随时间推移优化分析。

Azure 便利化

使用 Azure Monitor 和 Log Analytics 检测工作负荷中的问题。 若要进一步深入了解与基础结构、应用和数据库相关的问题，请使用 Application Insights、 ContainerInsights、Network Insights、 VM Insights 和 SQL Insights 等工具。

Azure Chaos Studio 是一种托管服务，它使用混沌工程来帮助衡量、了解和改进云应用程序和服务复原能力。

在 Azure 网络观察程序中使用 连接监视器 和 连接故障排除，以便在部署之前对网络连接场景进行建模和验证。 通过模拟综合测试和对潜在路由路径进行故障排除，这些工具可帮助你预测并记录网络体系结构中可能出现的故障模式。 此外，通过分析历史虚拟网络流日志和 流量分析，可以识别可能通知 Azure 基础结构中 FMA 文档的受阻或异常流量模式。

有关将 FMA 原则应用于常见 Azure 服务的信息，请参阅 Azure 应用程序的故障模式分析。

Example

下表显示了 Azure Front Door 托管在 Azure 应用服务实例上的电子商务网站的 FMA 示例，该网站由 Azure Front Door 托管。

用户流：用户登录、产品搜索和购物车交互

相关链接

• Azure 应用程序的故障模式分析
• 复原能力和依赖项

可靠性清单

请参阅完整的建议集。