一个产品准备上线。
功能测试通过了，核心流程跑通了，发布计划也排好了。会议上大家主要讨论的是：什么时候发公告，第一批用户怎么邀请，数据看板怎么做，增长目标设多少。看起来，项目已经到了“只差临门一脚”的阶段。
但真正上线后，问题不是“产品完全不能用”，而是许多小失败同时出现：老用户导入数据时字段错位，客服不知道如何解释新价格，支付失败没有清晰提示，灰度名单里混进了不该进入的客户，回滚脚本没有演练，某个第三方接口限流后订单状态卡在中间态。每个问题单独看都不算灾难，可它们连在一起，用户信任下降，团队整晚救火，原本应该验证需求的上线，最后变成验证组织能不能熬夜。
这类失败最让人不甘心。因为它们不是完全不可预见的天灾，而是很多人在行动前“隐约知道可能出问题”，却没有把这些可能性系统地列出来、排序、检测和预防。
故障模式分析要解决的，就是这个问题：
不要只问系统如何成功；
还要系统化地问：它会以哪些方式失败？
它不是让人悲观，也不是让计划永远停在风险讨论里。它是一种工程化的逆向思维：把一个系统、流程或决策拆开，逐项列出可能的失败方式，追问每种失败的原因、影响、发生概率、检测难度和预防措施，再把最值得处理的失败路径转化成设计改进、监控指标、检查清单和应急预案。
一句话说：
故障模式分析不是预测世界会怎样坏，
而是提前识别哪些坏法最值得现在处理。
一、什么是故障模式
故障模式，指的是一个部件、步骤、角色、接口或假设发生失败的具体方式。
“系统有风险”不是故障模式。它太抽象，不能直接改变行动。
“支付接口可能出问题”也还不够具体。真正有用的表达应该更接近：
支付接口超时后，订单状态没有自动回滚，用户重复付款，客服无法判断哪一笔有效。
这句话同时说明了失败方式、触发条件、影响对象和后续混乱。
故障模式分析的价值，就在于把模糊担忧改写成具体路径。它不满足于说“人员风险”“技术风险”“市场风险”，而是继续追问：
- 哪个环节会失败？
- 会以什么方式失败？
- 为什么会失败？
- 失败后会影响谁？
- 我们能不能及时发现？
- 发现后能不能阻止扩大？
- 现在能做什么，让它不发生，或发生后不致命？
工程里的 FMEA，通常会把这些问题写成表格：功能、故障模式、故障原因、故障后果、严重度、发生概率、检测难度、风险优先级、控制措施、责任人和完成时间。
表格只是形式。真正重要的是思维顺序：
从成功流程出发，
逐步反向列出失败路径，
再把高价值风险变成可执行动作。
如果只列风险不改设计，它只是担忧清单。
如果只改设计不理解失败路径，它可能只是碰运气。
故障模式分析要求二者接上：因为知道会怎样坏，所以知道该怎样加固。
这背后其实站着一条广为人知的经验法则——墨菲定律（Murphy's Law）：
凡是可能出错的事，就一定会出错。
墨菲定律常被当成一句悲观的玩笑，但它原本是工程可靠性文化里的严肃态度。它的意思不是“世界跟你作对”，而是：只要一种失败在物理上、流程上是可能发生的，只要时间足够长、次数足够多，它迟早会发生一次。因此，一个可靠的设计，不能依赖“大家都会小心”“正常情况下不会这样”，而要假设每一个可能出错的地方终将被触发。故障模式分析可以看成墨菲定律的工程化落地：墨菲定律给出态度（凡可能出错者必出错），故障模式分析给出方法（把所有“可能出错”逐条列出、排序、检测、加固）。前者提醒你别心存侥幸，后者告诉你侥幸该怎样被系统替代。
二、它和普通风险讨论的区别
普通风险讨论经常停在分类层面。
一个项目计划里可能写：
市场风险：用户接受度不及预期。
技术风险：系统稳定性不足。
运营风险：团队协作不畅。
政策风险：监管环境变化。
这些话没有错，但太宽。它们像天气预报里说“未来可能有不确定性”，听起来谨慎，却不能指导具体动作。
故障模式分析会把同样的问题拆得更细。
市场风险不是一个标签，而可能是：
目标客户愿意试用，但不愿意迁移历史数据，导致激活率高、留存率低。
技术风险不是一个标签，而可能是：
高峰期批量任务占满数据库连接，正常下单请求被拖慢，用户误以为付款失败。
运营风险不是一个标签，而可能是：
价格规则变更后，销售、客服和财务使用不同版本的解释口径，导致客户投诉和收入确认混乱。
差别在这里：
普通风险讨论问：有哪些风险类别？
故障模式分析问：失败会通过哪条路径具体发生？
前者适合提醒，后者适合改造系统。
三、核心机制：失败不是一个点，而是一条链
很多人低估风险，是因为他们把失败想成一个点。
比如：
服务器宕机。
核心员工离职。
最大客户流失。
供应商延期。
投资标的业绩不及预期。
但真实失败通常是一条链。
服务器宕机之后，监控有没有报警？报警有没有到人？值班人员有没有权限？备份是否可恢复？客户是否知道状态？数据是否会重复写入？恢复后是否能确认哪些交易成功、哪些失败？
核心员工离职之后，知识是否在文档里？系统权限是否可交接？客户关系是否只在私人聊天里？团队是否知道历史决策为什么这样做？继任者是否能判断哪些地方不能随便改？
最大客户流失之后，现金流能撑多久？产能能否转向其他客户？产品路线是否被这个客户过度定制？销售团队是否还有独立获客能力？融资叙事是否会被打断？
故障模式分析的底层机制，是把“一个坏结果”拆成“触发、传导、放大、暴露、恢复”几个环节。
可以用一个简单结构来想：
故障原因 -> 故障模式 -> 直接影响 -> 连锁影响 -> 检测信号 -> 控制措施
例如：
原因：第三方接口限流
模式：订单状态长时间停在处理中
直接影响：用户不知道是否付款成功
连锁影响：重复下单、客服压力、财务对账困难
检测信号：处理中订单数量异常上升
控制措施：超时回滚、幂等设计、状态提示、客服查询入口、限流预案
这样一拆，行动就出现了。
你不再只是说“第三方接口有风险”，而是知道要做幂等、超时、监控、提示、客服工具和对账流程。
四、真正要排序的是三类失败
故障模式可以无限列。任何系统都能想出很多坏法。
如果不排序，故障模式分析会变成焦虑制造机。真正有价值的排序，通常看三个维度：
严重度：一旦发生，损害多大？
发生概率：它有多可能发生？
检测难度：发生后，我们有多容易及时发现？
严重度高的失败，需要优先处理。比如数据永久丢失、现金流断裂、用户安全事故、关键许可失效、声誉不可逆损害。
发生概率高的失败，也需要优先处理。比如高峰期流量超过容量、人工录入出错、新人漏掉关键步骤、供应商常规延期。
检测难度高的失败尤其危险。因为有些故障不是一发生就爆炸，而是悄悄积累。数据口径错误、激励机制扭曲、客户满意度下降、产品质量漂移、投资假设失效，早期都可能看起来正常。等指标暴露时，损害已经很大。
在传统 FMEA 里，常把这三个维度评分，然后得到一个风险优先级。分数本身不必迷信，但这个思路很重要：不要平均处理所有风险，而要先抓住那些高影响、高概率、难检测的失败路径。
最危险的故障模式往往长这样：
发生前不显眼；
发生时不容易被发现；
发现后已经造成严重后果；
修复成本很高，甚至不可逆。
这就是为什么故障模式分析特别适合放在上线前、签约前、投资前、扩张前、流程固化前。它要在系统还有修改空间时，提前把最贵的错误找出来。
五、产品上线：不要只测 happy path
产品团队最容易犯的错误，是只沿着成功路径检查。
用户注册成功，浏览商品成功，下单成功，付款成功，收到通知成功，数据看板成功。这些当然要测，但它们只是 happy path。
真实世界里，用户会填错信息、重复点击、断网、取消支付、半途退出、用旧版本客户端、在边界时间下单、使用异常字符、导入脏数据、遇到第三方接口超时，还会在客服最忙的时候提出最复杂的问题。
故障模式分析会要求产品上线前逐段追问：
- 用户输入错误时，系统会怎样响应？
- 外部接口失败时，内部状态会不会卡住？
- 重复提交会不会产生重复订单、重复扣款或重复通知？
- 灰度发布时，新旧版本数据结构是否兼容？
- 回滚时，已经产生的新数据如何处理？
- 客服、销售、财务是否知道异常状态怎么解释？
- 监控是否能发现“部分失败”，而不只是发现系统完全宕机？
这些问题看起来琐碎，但产品事故往往就藏在琐碎处。
更重要的是，故障模式分析会把上线从“发布功能”改成“发布一个能承受异常的系统”。真正成熟的上线清单，不只是问功能能不能用，还要问：
它失败时，用户是否知道发生了什么？
团队是否知道哪里坏了？
系统是否能避免把一次失败变成多次失败？
我们是否能回滚、补偿、解释和复盘？
如果这些答案不清楚，功能跑通并不等于上线准备好了。
六、企业经营：增长计划也有故障模式
企业经营中的故障模式，不一定像机器故障那样直观。
一个扩张计划看起来很合理：开更多门店、招更多销售、进入更多城市、增加更多产品线。每一步都像增长。但它可能有一串隐藏故障模式。
门店扩张可能失败在选址模型过度依赖早期样本；销售扩张可能失败在新人培训跟不上；进入新城市可能失败在供应链半径超过管理能力；产品线增加可能失败在品牌定位变模糊；组织扩张可能失败在中层管理不足；融资扩张可能失败在收入增长慢于固定成本增长。
如果只看成功路径，经营者会问：
增长空间有多大？
我们能不能抓住机会？
故障模式分析会补上另一组问题：
这个增长计划最可能在哪里失真？
哪个假设一错，后面的动作都会变坏？
哪个指标会让我们误以为一切正常？
哪个环节失败后会拖累现金流、团队和客户信任？
比如，很多公司不是死于没有需求，而是死于增长质量差：收入上升，但回款变慢；客户变多，但交付复杂度指数级上升；渠道铺开，但单位经济模型没有跑通；组织人数增加，但决策速度下降、责任边界模糊。
这些都是经营故障模式。
企业越大，故障模式越可能来自“局部合理、整体失灵”。销售为了业绩承诺过度定制，产品为了客户妥协架构，财务为了利润推迟必要投入，管理层为了增长忽视质量信号。每个部门都在优化自己的局部指标，系统却在积累全局风险。
所以，企业经营里的故障模式分析不只看机器、流程和合同，也要看激励、指标、权责、现金流和文化。
七、投资：先问这笔钱会怎样永久亏掉
投资里的故障模式分析，和芒格的逆向思维非常接近。
买入之前，不要只写这家公司为什么优秀，还要写它会怎样让你永久亏损。
永久亏损的故障模式可能有很多：
- 护城河被替代技术削弱，但财务报表滞后反映。
- 管理层为了增长做高价并购，商誉减值吞掉多年利润。
- 企业过度依赖单一客户、单一供应商、单一平台或单一监管许可。
- 行业需求仍在增长，但竞争结构恶化，利润留不下来。
- 资产负债表太脆弱，周期低谷时被迫融资或出售优质资产。
- 会计利润很好看，但现金流质量持续恶化。
- 投资者买入价格太高，即使企业不错，长期回报也被估值消化。
这些故障模式不一定都会发生。分析它们的目的，也不是把自己吓到什么都不买。
真正的目的，是把投资判断从“故事好不好”拉回到“失败路径是否可承受”。
可以用一组问题：
这家公司最关键的三个假设是什么？
哪个假设最可能错？
哪个假设一错会造成永久性损失？
这种错误能否被早期信号发现？
价格是否给了足够安全边际？
我是否有能力持续判断这个故障模式是否正在发生？
投资最大的危险之一，是故障模式发生了，投资者却还在用旧叙事解释新事实。故障模式分析会提前写下“什么信号说明我错了”，让人更难在坏消息出现时继续自我安慰。
八、组织流程：流程不是写出来就会被执行
组织里的很多失败，看似是人的问题，其实是流程故障模式。
例如：
审批流程存在，但关键人出差时没人能代批。
交接文档存在，但没有人验证新人是否真的能按文档完成任务。
复盘会议存在，但没有把结论写入下一次上线清单。
客户投诉系统存在，但投诉无法回流到产品和管理层。
预算制度存在，但各部门用不同口径计算成本。
流程文件存在，不代表流程可靠。流程只有在压力、缺人、信息不完整、时间紧张、跨部门协作时仍然能工作，才算可靠。
故障模式分析会追问：
- 这个流程最常被跳过的步骤是什么？
- 哪些判断完全依赖个人经验？
- 哪个交接点最容易丢信息？
- 哪个角色没有足够权限，却承担了结果责任？
- 哪个指标会诱导人做出局部正确、整体错误的动作？
- 流程异常时，谁有权停止、升级或改道？
组织流程的故障模式经常有一个共同原因：系统假设人会稳定、完整、诚实、及时地传递信息。但人在真实环境中会疲劳、回避冲突、害怕承担责任、受激励影响、误解口径，也会被层级和气氛压住。
因此，好的流程设计不是假设每个人永远可靠，而是承认人会漏、会怕、会忙、会错，然后用清晰边界、交叉检查、自动记录、升级机制和复盘更新来降低故障概率。
九、个人计划：失败常常不是意志力不够
个人计划也可以做故障模式分析。
很多人制定计划时，只写成功路径：
每天早起学习。
每周运动三次。
三个月写完一个项目。
一年内换到更好的岗位。
这些目标没有问题，但它们通常没有列出故障模式。
早起学习会怎样失败？可能是前一天睡太晚，学习材料没有提前准备，手机干扰太强，计划太大导致启动成本高，连续两天中断后产生挫败感。
运动计划会怎样失败？可能是健身房太远，天气不好就中断，强度一开始过高导致受伤，没有固定时间，缺少同伴和反馈。
换工作会怎样失败？可能是只投简历不补能力，只准备面试不积累作品，只看薪资不看行业，拖到现金压力太大时被迫接受不适合的机会。
故障模式分析会把“我不够自律”改写成更可处理的问题：
哪个触发条件最容易让计划中断？
中断后有没有恢复路径？
环境是否在诱导失败？
计划是否依赖过多意志力？
有没有早期信号提醒我正在偏离？
个人改变不是机械系统，但人的行为同样有故障模式。识别它们，常常比责备自己更有用。
十、做一次故障模式分析的简单流程
故障模式分析可以很复杂，也可以很朴素。对大多数决策，一个简化流程已经足够。
第一，定义对象和边界。
你分析的是一次产品上线、一项投资、一个流程、一家公司的扩张计划，还是个人年度计划？边界越清楚，分析越不容易发散。
第二，画出成功流程。
不要先凭空想风险。先写出系统要成功，必须经过哪些关键步骤、角色、资源、接口、假设和外部条件。
第三，逐项问“它会怎样失败”。
对每个步骤，不写抽象风险，而写具体故障模式。好的句子通常包含：哪个环节、什么情况下、以什么方式失败、造成什么后果。
第四，写出原因和影响。
同一种故障模式可能有不同原因。比如数据错误可能来自输入、转换、权限、接口、版本、口径或人工修改。影响也要分直接影响和连锁影响。
第五，评估严重度、发生概率和检测难度。
不需要假装精确。可以用高、中、低，也可以用 1 到 5 分。关键是让团队承认：有些风险比其他风险更值得先处理。
第六，设计控制措施。
控制措施有几类：消除原因、降低概率、提高可检测性、限制影响范围、准备恢复路径、设置退出条件。
第七，把结果沉淀到系统里。
如果输出只是一次会议纪要，价值会很快消失。它应该进入上线清单、监控报警、设计规范、培训材料、合同条款、投资备忘录、复盘模板或个人日程。
一个简化模板可以这样写：
环节：
故障模式：
可能原因：
直接影响：
连锁影响：
严重度：
发生概率：
检测难度：
早期信号：
预防措施：
发生后的处理办法：
责任人 / 触发条件：
模板的作用不是制造文档负担，而是逼人把“担心”翻译成“动作”。
十一、边界：不是无限想象灾难
故障模式分析有一个明显误用：把它变成无限灾难想象。
任何事情都可能坏。供应商可能倒闭，客户可能消失，员工可能离职，政策可能变化，市场可能反转，系统可能崩溃，自己也可能判断失误。如果只是不断扩展风险清单，人会越来越焦虑，行动会越来越慢，最后模型反而伤害决策。
正确边界是：
优先识别高概率、高影响、难检测的失败路径；
把它们转化为检查清单和设计改进；
对低价值风险保持记录，但不让它们主导行动。
故障模式分析也不是要求零风险。
零风险通常不存在，追求零风险还会引入新的复杂性。每多一个审批、备份、监控、角色和流程，都可能增加成本、降低速度，甚至制造新的故障模式。可靠性不是把所有可能性都防住，而是在成本、速度、复杂性和安全之间做清醒取舍。
它也不能替代专业知识。
一个不懂制造的人，只能写出“生产可能出问题”。有经验的人会写出：某个工序温度窗口窄，原材料批次差异会改变良率，检测点在后段才发现问题，返工成本高，且旺季没有替代产能。后者才是有效的故障模式分析。
所以，越重要的系统，越要让真正懂现场的人参与。故障模式分析不是会议室里的想象比赛，而是把现场知识结构化。
最后，它不是事前验尸的同义词。
事前验尸通常从一个整体失败场景出发：假设项目已经失败，再倒推原因。故障模式分析更细，它沿着系统结构逐项寻找失败方式，并为每个失败方式设计检测和控制。二者可以配合：事前验尸帮助发现大的死因，故障模式分析把死因拆成可管理的路径和动作。
十二、和其他模型的关系
故障模式分析和单点故障关系很近，但角度不同。
单点故障问的是：
哪个节点一坏，全局就会坏？
故障模式分析问的是：
每个关键节点可能以哪些方式坏？
坏了以后会怎样被发现、传导和控制？
前者更像找关键脆弱点，后者更像系统化展开失败路径。
它和检查清单方法天然相连。故障模式分析的输出，应该变成下一次行动前的检查清单。一次事故、一轮复盘、一项新风险，都应该进入清单，避免同类失败反复发生。
它和极端情景模拟互补。极端情景模拟问“如果最坏情况发生，我能不能承受”；故障模式分析问“最坏情况可能由哪些具体故障路径累积出来”。一个看压力，一个看路径。
它和乘法系统思维相连。复杂系统的成功常常依赖多个环节同时成立，任何关键环节失败都可能拖累整体。故障模式分析能帮助你找出乘法链条中最容易断、最难发现、后果最大的环节。
它和冗余备份系统、容错设计与优雅降级相连。故障模式分析负责找出会怎样坏；冗余、容错和降级负责让系统坏了以后仍然能维持关键功能。
它和安全边际相连。不是所有故障模式都能消除。对于无法消除但必须承受的风险，就要用现金、时间、库存、权限、价格折扣、低杠杆和可逆性留下安全边际。
十三、一份可直接使用的故障模式检查清单
面对一个重要系统或计划，可以按下面的问题走一遍。
定义对象
- 这次分析的对象是什么？
- 它最重要的成功结果是什么？
- 哪些环节、人员、系统、资金、供应商、客户和外部条件不可缺少？
列出故障模式
- 每个关键环节会以哪些具体方式失败？
- 失败是完全停止、性能下降、数据错误、延迟、误解、重复、遗漏，还是错误激励？
- 哪些失败过去发生过，或在相似系统中发生过？
- 哪些失败平时不明显，但会悄悄积累？
分析原因和影响
- 这个故障最可能由什么触发？
- 直接影响是谁承受？
- 第二层、第三层连锁影响是什么？
- 它是否会造成不可逆损害？
- 它是否会触发单点故障或级联失败？
排序
- 严重度高不高？
- 发生概率高不高？
- 检测难度高不高？
- 哪三到五个故障模式最值得现在处理？
控制
- 能否直接消除原因？
- 能否降低发生概率？
- 能否增加早期检测信号？
- 能否把损害隔离在局部？
- 能否建立备用路径或优雅降级？
- 发生后谁有权启动应急方案？
沉淀
- 哪些内容要进入发布清单、投资备忘录、流程文档或个人计划？
- 哪些监控指标需要新增？
- 哪些假设需要定期复核？
- 事故或复盘之后，清单如何更新？
这份清单的目标不是让你变得保守，而是让你少靠运气。
十四、一句话总结
故障模式分析最重要的提醒是：
一个系统真正的可靠性，
不取决于它在顺利路径上看起来多漂亮，
而取决于它在失败路径上是否被认真设计过。
不要只问项目怎样成功、产品怎样上线、企业怎样增长、投资怎样赚钱、计划怎样完成。还要问：它会怎样坏？为什么会坏？坏了谁先知道？信号在哪里？损害会不会扩大？现在能不能改设计、加监控、留余量、写清单、做演练？
成熟的行动不是假设世界配合自己，而是在行动前承认系统会出错、人会遗漏、接口会超时、客户会变化、指标会误导、叙事会失真，然后把这些失败模式提前放到桌面上。
先把坏法列出来，不是为了害怕行动，而是为了让行动更稳。
来源说明
- 《查理·芒格的思维模型·完整版》：场景索引中的“故障模式分析（Failure Mode Analysis / FMEA）”，以及工程与可靠性类相邻模型，是本文的主要来源框架。
- 工程可靠性中的 FMEA 方法，为本文关于故障模式、故障原因、故障影响、严重度、发生概率、检测难度、风险优先级和控制措施的解释提供基础。
- 本文关于产品上线、企业经营、投资、组织流程和个人计划的讨论，是对该模型在商业、决策和日常行动中的延展应用。
- 本文覆盖并合并了 TODO 中的
故障模式分析 / 墨菲定律。墨菲定律（凡可能出错者必出错）是故障模式分析背后的态度前提，已在第一节末尾作为经验法则显式引入并与 FMEA 方法接上：前者提供“别心存侥幸”的态度，后者提供“把可能出错逐条列出并加固”的方法。