FMEA表核心字段的设计原则：功能点用户视角，故障模式只描述现象

[[FMEA方法的定位：对已设计架构做事后可用性隐患排查]]落地成的FMEA分析表，前几个核心字段的填写方式有明确讲究。”功能点”必须站在用户视角来划分，而不是按系统内部模块来划分——比如用户管理系统的FMEA分析里，”登录”“注册”才是功能点，数据库存储功能、Redis缓存功能这类系统内部实现细节不能作为功能点。”故障模式”指系统会出现什么样的故障现象，包括故障点和故障形式，但关键是不需要在这一步给出真正的故障原因——比如只需要假设”MySQL响应时间达到3秒”这个现象即可，不管背后是磁盘坏道、慢查询、网络故障还是MySQL bug导致的，只要现象一样，对业务的影响就是一样的（具体原因留到后面的”故障原因”字段单独展开）；故障模式的描述要尽量精确、多用量化表述，比如应该写”MySQL响应时间达到3秒”而不是模糊的”MySQL响应慢”。”故障影响”描述当故障模式发生时，对应功能点具体会受什么影响（如偶尔不可用、完全不可用、部分用户不可用、响应缓慢、出错等），同样要求尽量精确量化——推荐”20%的用户无法登录”而不是笼统的”大部分用户无法登录”，但也不需要精确到21.25%这种没有实际意义的小数点，估算个大致区间（20%还是40%）就够了。”严重程度”是站在业务视角评估故障影响的程度，按公式”严重程度＝功能点重要程度×故障影响范围×功能点受损程度”来判断，一般分致命/高/中/低/无五档——比如登录比修改资料重要得多、80%用户比20%用户范围更大、完全无法登录比登录缓慢更严重，同样级别的严重程度可能来自不同组合（如”超过70%用户无法登录”是致命，”所有用户都无法修改资料”只是中）；某个具体故障到底该定哪一档，有时会有争议，没有绝对标准，一般由相关人员讨论确定即可，争执不下时由架构师直接裁定，不值得为此花太多时间纠结。

结构图：

flowchart TB
  A["FMEA表核心字段"]
  A --> B["功能点<br/>用户视角(登录/注册)<br/>而非系统模块视角(数据库/缓存)"]
  A --> C["故障模式<br/>只描述故障现象，不涉及原因<br/>要求量化精确(如MySQL响应达到3秒)"]
  A --> D["故障影响<br/>该功能点受到的具体影响<br/>要求量化精确(如20%用户无法登录)"]
  A --> E["严重程度<br/>=功能点重要程度×影响范围×受损程度<br/>分致命/高/中/低/无五档"]
  E --> F["有争议时不必长时间讨论<br/>相关人员定或架构师直接裁定即可"]