你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
有关执行故障模式分析的建议
适用于此 Azure 架构良好的框架可靠性清单建议：
| RE：03 | 使用故障模式分析 (FMA) 识别解决方案组件中的潜在故障并确定其优先级。 执行 FMA 以帮助评估每个故障模式的风险和效果。 确定工作负荷如何响应和恢复。 |
|---|
本指南介绍了为工作负荷执行故障模式分析（FMA）的最佳做法。 FMA 是确定工作负荷中潜在故障点和关联的流以及相应地规划缓解操作的做法。 在流的每个步骤中，你都将确定多个故障类型的爆炸半径，这有助于设计新的工作负载或重构现有工作负载，以最大程度地减少故障的广泛影响。
FMA 的关键原则是，无论应用多少层复原，都会发生故障。 更复杂的环境暴露在更多类型的故障中。 鉴于这种现实，FMA 允许你设计工作负荷，以便在发生故障时能够承受大多数类型的故障并正常恢复。
如果完全跳过 FMA 或执行不完整的分析，则工作负荷面临未预测行为和由欠佳设计引起的潜在中断的风险。
定义
| 术语 | 定义 |
|---|---|
| 故障模式 | 一种可能导致一个或多个工作负荷组件降级或严重影响到不可用点的问题。 |
| 缓解措施 | 已确定以主动或被动方式解决问题的活动。 |
| 检测 | 基础结构、数据和应用监视和警报过程和过程。 |
关键设计策略
查看并实施 用于标识流的建议。 假设你已根据关键性识别和确定用户和系统流的优先级。
你收集的数据和你在工作中创建的项目为你提供了整个流中涉及的数据路径的具体说明。 若要在 FMA 工作中取得成功，项目的准确性和彻底性至关重要。
确定关键流后，可以规划其所需的组件。 接下来，逐步执行每个流来标识依赖项，包括第三方服务和潜在故障点，并规划缓解策略。
分解工作负荷
当从构思转向设计时，需要识别支持你的工作负载所需的组件类型。 你的工作负载决定了你必须规划的必要组件。 通常，需要规划入口控制、网络、计算、数据、存储、支持服务（例如身份验证、消息传送和机密或密钥管理），以及出口控制。 在设计工作的此阶段，你可能不知道要部署的特定技术，因此你的设计可能如以下示例所示。
创建初始体系结构设计后，可以覆盖流以识别这些流中使用的离散组件，并创建描述流及其组件的列表或工作流关系图。 若要了解组件的关键性，请使用分配给流的关键性定义。 请考虑组件故障对流的影响。
标识依赖项
确定工作负荷依赖项以执行单一故障点分析。 分解工作负荷和覆盖流可提供对工作负荷内部和外部的依赖项的见解。
内部依赖项是工作负荷运行所需的工作负荷范围中的组件。 典型的内部依赖项包括 API 或机密/密钥管理解决方案（如 Azure Key Vault）。 对于这些依赖项，请捕获可靠性数据，例如可用性 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 App 服务实例上，并且由 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 应用程序防火墙保护。 | 无 |
相关链接
可靠性清单
请参阅完整的建议集。