执行故障模式分析的建议

项目
10/16/2024

适用于此 Power Platform Well-Architected 可靠性检查表建议：

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

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

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

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

定义

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

关键设计策略

在 FMA 中，了解先决条件至关重要。首先审查和实施识别流的建议，根据关键性确定流程的优先级。数据项目在描述这些流中的数据路径方面起着关键作用。深入研究 FMA 方法时，重点规划关键流的组成部分，确定依赖项（内部和外部），并设计缓解策略。

先决条件

审查并实施识别和评定流的建议。假设您已根据关键性识别用户和系统流并设置其优先级。

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

FMA 方法

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

分解工作负载

从构思转向设计时，需要确定支持工作负载所需的组件类型。工作负载决定必须规划的必要组件。

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

标识依赖项

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

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

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

故障点

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

区域中断：整个 Power Platform 或 Azure 区域不可用
服务中断：一个或多个 Power Platform 或 Azure 服务不可用
分布式拒绝服务 (DDoS) 或其他恶意攻击
应用程序或组件配置错误
运算符错误
计划内维护中断
组件过载

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

缓解

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

构建更多复原能力意味着确保应用程序设计遵循持久性的最佳做法，例如将整体式应用程序分解为独立的应用和微服务，并使用平台提供的复原能力配置，如重试策略。有关更多信息，请参阅冗余建议和自我保留建议。

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

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

如果应用程序具有无法运行的强大依赖项，则这些依赖项的可用性和恢复目标应与应用程序本身的目标保持一致。如果应用程序生命周期与其依赖项的生命周期紧密结合，则应用程序的操作敏捷性可能会受到限制，尤其是对于新版本。

检测

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

结果

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

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

请参考示例表，了解文档的起点。

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

示例

下表显示了一个费用应用程序的 FMA 序示例，该应用程序托管为 Power Apps 画布应用程序，Microsoft Dataverse 后端和 API 托管在 APIM 中，用于与第三方系统进行交互。

用户流程：用户登录、提交费用报销单、与费用报告交互

组件	风险	可能性	效果/缓解/注意	故障
Microsoft Entra ID	服务中断	低	全部工作负载中断。取决于 Microsoft 修复。	完全
Microsoft Entra ID	配置错误	Medium	用户无法登录。无下游影响。技术支持向标识团队报告配置问题。	None
Power Apps	服务中断	低	外部用户完全中断。取决于 Microsoft 修复。	完全
Power Apps	区域中断	非常低	外部用户完全中断。取决于 Microsoft 修复。	完全
Power Apps	DDoS 攻击	Medium	可能会中断。 Microsoft 管理 DDoS（L3 和 L4）保护。	部分中断的可能性
Dataverse	服务中断	低	全部工作负载中断。取决于 Microsoft 修复。	完全
Dataverse	区域中断	非常低	自动故障转移组故障转移到次要区域。故障转移期间的潜在中断。恢复时间目标 (RTO) 和恢复点目标 (RPO) 在可靠性测试期间确定。	可能完全中断
Dataverse	恶意攻击（注入）	Medium	风险最小。	潜在的低风险
API 管理	服务中断	低	外部用户完全中断。取决于 Microsoft 修复。	完全
API 管理	区域中断	非常低	外部用户完全中断。取决于 Microsoft 修复。	完全
API 管理	DDoS 攻击	Medium	可能会中断。 Microsoft 管理 DDoS（L3 和 L4）保护。	部分中断的可能性
您的 Power Platform 解决方案	配置错误	Medium	部署期间应发现错误配置。如果在配置更新期间发生这些情况，管理员必须回滚更改。配置更新导致短暂的外部中断。	完全中断的可能性

Power Platform 简化

Power Platform 与 Application Insights 集成，后者是 Azure Monitor 生态系统的一部分。使用该集成可：

订阅 Application Insights 中 Dataverse 平台捕获的遥测数据，了解应用程序在Dataverse 数据库和模型驱动应用中执行的诊断、性能和操作。遥测提供可用于诊断和解决与错误和性能有关的问题的信息。
将您的画布应用程序连接到 Application Insights，以使用这些分析来诊断问题，了解用户实际使用您的应用程序做了什么，推动更好的业务决策，并提高您的应用程序的质量。
将 Power Automate 遥测数据配置为流入 Application Insights。您可以使用此遥测数据来监控云端流执行，并为云端流运行失败创建警报。
从 Copilot Microsoft Copilot Studio 捕获遥测数据以在 Azure Application Insights 中使用。您可以使用此遥测来监控发送到 Copilot 和从 Copilot 发送的记录消息和事件、在用户对话期间触发的主题，以及可以从您的主题发送的自定义遥测事件。

Power Platform resources 在 Purview 合规门户中 Microsoft 记录活动。大多数事件在活动开始后 24 小时内可用。不要将这些信息用于实时监控。有关 Power Platform 中日志记录活动的更多信息，请参见：

可靠性清单

请参考整套建议。

可靠性检查表

通过