单独拆出"故障原因"的价值，及风险程度＝严重程度×故障概率

[[FMEA表核心字段的设计原则：功能点用户视角，故障模式只描述现象]]里”故障模式”只描述现象、不涉及原因，但FMEA表里依然单独设了一个”故障原因”字段，原因有三层：一是不同故障原因发生的概率不一样——比如同样导致MySQL查询响应慢，可能是MySQL本身有bug，也可能只是没建索引，前者的概率远低于后者，而概率高低直接影响该怎么应对；二是不同故障原因的检测手段不一样——磁盘坏道导致的响应慢需要靠专门的运维系统去做磁盘坏道检查，慢查询导致的响应慢只需要配置MySQL慢查询日志就能发现；三是不同故障原因的处理措施不一样——MySQL bug的应对通常只能是升级版本，没建索引的应对就是直接加索引。”故障概率”指某个具体故障原因发生的可能性，一般分高/中/低三档，评估时要重点考虑：硬件会随使用年限增加故障概率（新硬盘坏道率低，用了三年的硬盘坏道率明显更高）；开源系统成熟版本bug率低、刚发布的版本bug率高，自己有使用经验的开源系统bug率低、刚开始尝试的bug率高；自研系统同理，成熟系统故障概率低、新开发的系统故障概率高。这里高中低只是为了确定优先级、决定后续资源投入方向，没必要也没办法做绝对精确的量化（比如某开源系统到底是3个月还是6个月故障一次，这种精确数字本身就评估不出来，强行量化反而是浪费成本）。有了严重程度和故障概率，就能算出”风险程度”：风险程度＝严重程度×故障概率——这个公式说明影响再严重的故障，如果发生概率极低，最终风险程度依然可以很低（比如”某机房业务瘫痪”这个后果是致命的，但如果诱因是”地震”，广州这类地区5级以上地震几十年才发生一次，概率极低）；反过来同样的故障影响，换一个更常见的诱因（比如”机房空调烧坏”可能两年一次，”机架掉电”可能一年一次），风险程度就会随概率的上升而明显变高——这也是为什么FMEA要把”故障原因”和”故障概率”单独拆出来分析，而不是只停留在”故障影响有多严重”这一层。

结构图：

flowchart TB
  A["为何单独拆出'故障原因'"]
  A --> B["原因①不同原因发生概率不同<br/>如MySQL bug概率<<没建索引概率"]
  A --> C["原因②不同原因检测手段不同<br/>磁盘坏道靠专门运维系统检查<br/>慢查询靠MySQL慢查询日志"]
  A --> D["原因③不同原因处理措施不同<br/>bug只能升级版本，缺索引直接加索引"]
  A --> E["故障概率评估：<br/>硬件用得越久概率越高<br/>系统越成熟/越有使用经验概率越低"]
  E --> F["风险程度 = 严重程度 × 故障概率"]
  F --> G["同样后果致命的故障：<br/>诱因是地震(概率极低)→风险程度低<br/>诱因是机房空调烧坏(概率较高)→风险程度高"]