1. 一个具体问题
团队准备上线自动退款功能，测试只验证正常路径：收到申请、计算金额、打款成功。但如果同一申请被重复处理、金额单位混淆或到账通知丢失，会产生怎样的后果？上线前逐项讨论潜在失效，比事故后再解释为什么没想到更有价值。
2. 一句话解释
FMEA 从产品或流程的功能出发，识别可能怎样失效、造成什么影响、由什么因素触发，以及现有预防和探测措施是否足够。
3. 出处与原意
失效模式与影响分析最初发展于可靠性工程，后来用于设计、生产和服务。ASQ 将其作为前瞻性的风险分析方法介绍。不同领域有不同评分表和行动优先规则，不能拿一张通用模板代替本行业要求，也不能把表格填写完成视为风险已经降低。
4. 原理与机制
常见分析记录功能、失效模式、影响、原因、现有控制、行动及责任人。传统风险优先数 RPN 是严重度、发生度、探测难度评分的乘积；在常见约定中，越难在后果发生前发现，探测分越高。三种评分往往是顺序尺度，乘积不是真实损失或概率，相同乘积还可能隐藏完全不同的严重性。因此应先关注高严重度与必要控制，再参考排序，行动后用证据复评。
识别风险时应让使用、维护和一线操作人员参与，因为设计者不一定知道真实的误用情境。评分分歧也值得记录，它可能暴露信息缺口。与其用平均分掩盖争议，不如明确哪些证据能够帮助判断，并优先补齐。
5. 一个完整案例
以下是假设案例。团队使用一至十的内部量表，重复退款的严重度九、发生度二、探测难度二，乘积三十六；邮件通知延迟的评分为三、六、五，乘积九十。若只按乘积，邮件会排在前面，但团队认为重复退款造成的资金损失必须优先防范，于是增加幂等标识和账务校验，并测试重复请求。邮件延迟则增加重试和告警。团队没有把严重度从九降到三来美化分数，因为发生后的后果仍然严重；改善主要改变发生机会和发现能力。评审还检查退款接口失效时是否会误报成功。
6. 适用条件与反例
适合设计评审、流程变更和尚未发生但后果明显的失效调查。它依赖参与者知识，容易漏掉共同原因和复杂交互。反例是供应商为了达到统一的 RPN 门槛，把发生度从四改为三，却没有增加任何控制或新证据；数字变小不等于风险改变。
7. 今天可以尝试的行动
选一个即将变更的关键步骤，写出三种具体失效方式及用户后果。先圈出不能接受的后果，再检查预防、探测和恢复手段。为最重要的一项设计故障注入或异常测试，把验证记录作为关闭改进行动的条件。