你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

执行故障模式分析的建议

  • 项目

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

RE：03 使用故障模式分析 (FMA) 来识别解决方案组件中的潜在故障并确定其优先级。 执行 FMA 以帮助你评估每种故障模式的风险和影响。 确定工作负载如何响应和恢复。

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

FMA 的一个关键原则是，无论应用了多少层复原层，都会发生故障。 更复杂的环境会面临更多类型的故障。 鉴于此现实，FMA 允许将工作负载设计为可承受大多数故障类型，并在发生故障时正常恢复。

如果完全跳过 FMA 或执行不完整的分析，工作负载将面临因设计不理想而导致的不可预测行为和潜在中断的风险。

定义

术语 定义
故障模式 一种可能导致一个或多个工作负荷组件降级或严重影响到不可用的问题类型。
缓解措施 已确定以主动或被动方式解决问题的活动。
检测 基础结构、数据和应用监视和警报过程和过程。

关键设计策略

先决条件

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

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

FMA 方法

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

分解工作负荷

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

显示设计示例的关系图。

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

标识依赖项

确定工作负荷依赖项以执行单一故障点分析。 分解工作负荷和覆盖流可深入了解工作负载内部和外部的依赖项。

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

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

故障点

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

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

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

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

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

  • 应用或组件配置错误。

  • 运算符错误。

  • 计划内维护中断。

  • 组件重载。

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

考虑每种故障模式的可能性。 有些服务不太可能发生，例如多区域或多区域服务中断，而增加超出冗余的缓解计划并不是充分利用资源和时间。

缓解措施

缓解策略分为两大类：构建更高的复原能力和针对性能下降进行设计。

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

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

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

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

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

检测

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

业务成效

为了获得分析结果，请创建一组可有效传达结果的文档、针对流组件和缓解措施做出的决策，以及故障对工作负载的影响。

在分析中，根据严重性和可能性确定的故障模式和缓解策略的优先级。 使用此优先级将文档集中在那些常见且严重到足以保证花费时间、精力和资源来设计缓解策略的故障模式上。 例如，可能存在一些在发生或检测中非常罕见的故障模式。 围绕它们设计缓解策略不值得付出代价。

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

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

Azure 简化

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

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

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

示例

下表显示了电子商务网站的 FMA 示例，该网站托管在具有 Azure SQL 数据库的 Azure 应用服务 实例上，并且前面是 Azure Front Door。

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

组件 风险 可能性 效果/缓解/注意 中断
Microsoft Entra ID 服务中断 低 工作负荷完全中断。 依赖于 Microsoft 进行修正。 完全
Microsoft Entra ID 配置错误 中型 用户无法登录。 无下游影响。 技术支持向标识团队报告配置问题。 无
Azure Front Door 服务中断 低 外部用户完全中断。 依赖于 Microsoft 进行修正。 仅外部
Azure Front Door 区域中断 极低 最小效果。 Azure Front Door 是一项全球服务，因此全局流量路由会将流量定向到未受影响的 Azure 区域。 无
Azure Front Door 配置错误 中型 部署期间应捕获配置错误。 如果在配置更新期间发生这种情况，管理员必须回滚更改。 配置更新会导致短暂的外部中断。 仅外部
Azure Front Door DDoS 攻击 中型 可能会中断。 Microsoft 管理 DDoS (L3 和 L4) 防护，Azure Web 应用程序防火墙阻止大多数威胁。 L7 攻击的潜在影响风险。 部分中断的可能性
Azure SQL 服务中断 低 工作负荷完全中断。 依赖于 Microsoft 进行修正。 完全
Azure SQL 区域中断 极低 自动故障转移组故障转移到次要区域。 故障转移期间的潜在中断。 恢复时间目标 (RTO) ，恢复点目标 (RPO) 可靠性测试期间确定。 可能已满
Azure SQL 可用性区域中断 低 无影响 无
Azure SQL 恶意攻击 (注入) 中型 最低风险。 所有Azure SQL实例都通过专用终结点和网络安全组进行虚拟网络绑定， (NSG) 添加进一步的虚拟网络内部保护。 潜在的低风险
应用服务 服务中断 低 工作负荷完全中断。 依赖于 Microsoft 进行修正。 完全
应用服务 区域中断 极低 最小效果。 受影响区域中用户的延迟。 Azure Front Door 自动将流量路由到未受影响的区域。 无
应用服务 可用性区域中断 低 无效。 应用服务已部署为区域冗余。 如果没有区域冗余，可能会产生效果。 无
应用服务 DDoS 攻击 中型 最小效果。 入口流量受 Azure Front Door 和 Azure Web 应用程序防火墙保护。 无

可靠性清单

请参阅完整的建议集。

可靠性清单