03 失效模式——事情在哪一步最容易搞砸

开篇除恐

"失效模式"这四个字，像一门你已经交了学费的选修课。拆开来看，它的意思其实是一只落在地上的苹果。

失效：没按计划工作。 模式：具体的出错方式。

苹果从树上掉下来，是一种"失效"。但苹果是被人推下来的，是树根断了掉下来的，还是自己熟了掉下来的——这三种"出事的方式"完全不同，处理也完全不同。这三个"怎么掉"就是失败模式。

FMEA 里的"失效模式"说得更精确：它问的不是"这件事会不会出问题"，而是"这件事有几种不同的出问题的方式"。

白话化：到底什么叫"失效模式"

你不需要去翻标准定义。只说两件事：

第一位：失效模式以"组件"为单位，不跨越组件。刹车手柄失效是一个模式，钢线失效是另一个模式。不能写"整个刹车系统失效"——那是"效果"，不是模式。这是 FMEA 表格第一列最常见的初学者错误。下面会专门提醒你。

第二位：列失效模式时只写"它是怎么坏的"，不写"谁让它坏的"或"它坏了怎么样"——那些是后面几章的内容。一列写一种情况，一种情况写一句话。

直觉先行：列一个清单

拿登录流程来想。你前面已经把流程拆成组件了。现在逐个问：每个组件会怎么出问题？

在同一组件下有几种模式，就写几条。比如"输入框"这个组件，可以出三种问题：留空、写错格式、注入恶意字符。

这时候你看，同一组件有多少条失效模式，直接反映了这个组件的"脆弱程度"——脆弱的东西失效方式多，就该多花心思。

术语脱西装

怎么列：一个自检清单

写失效模式的时候，每完成一行问自己三个问题：

1. 我说的是一件组件的事，还是跨越了两个组件？（如果是，拆开）
2. 我写的是"怎么坏的"，还是"坏了对谁有影响"？（如果是后者，那是 Effect，不是 Mode）
3. 这行够具体吗？（"出问题"这种写法没有用，要写"数据由 8 位密码被截断为 6 位留存"）

例子

☼ 热身：自行车前刹车的一个组件 ⎯⎯ 列出失效模式（自编）

组件：自行车刹车钢线。它对应用的是"传导刹车主 pulling force"。

答（三条就够了）：

1. 钢线锈蚀，断裂
2. 钢线与手柄连接处的接头松动脱落
3. 钢线被轮圈卡住，无法回缩

注意写法：这三个条目说的都是"钢线自己怎么坏的"，没有写"骑行者摔出去"（那是效果，第四章讲）。写清楚了。

☼☼ 正经：登录按钮的完整失效模式（自编）

取登录流程的前两个组件："界面（显示登录按钮）"和"输入框（接收账号密码）"，列出各自可能怎么失效。

我想到的（怎么想的：每个组件，我逐个问"它本来该干嘛，它有什么方式干不成"——这是 FMEA 最常用的思考框架）：

界面——"显示登录按钮"： - 按钮颜色和背景色对比度不足，色盲用户看不见 - 按钮在移动端缩小到 44×44 以下，太小点不到 - 按钮在弱网下没加载出来，显示空白区域

输入框——"接收账号密码"： - 必填项留空，前端未拦截，直接发请求 - 不限制输入长度，超长字符串截断后存入 - 密码框类型设为 text，明文显示在屏幕上

这就是一份 FMEA 表第一列的内容。纯列模式，没碰严重度，没碰后果，也没碰谁负责修它们。

这一章要带走的东西：

• "失效模式"就是"出事的方式"，以组件为单位，不跨组件，不写后果。
• 列模式时只写"怎么坏的"，不写"坏了对谁有影响"——这些分在不同列。
• 写模式时自检三题：跨组件了吗？写到后果了吗？具体吗？
• 一个组件如果列出的模式超过三条，说明它相对脆弱，值得重点看后面的频度。

就这样。