FMEA(Failure mode and effects analysis,故障模式与影响分析)又称为失效模式与后果分析、失效模式与效应分析、故障模式与后果分析等,本文采用“故障模式与影响分析”
FMEA 最早是在美国军方开始应用的,20世纪40年代后期,美国空军正式采用了 FMEA
二十世纪60年代,在开发出将宇航员送上月球并安全返回地球的手段的同时,FMEA 得到了初步的推动和发展
二十世纪70年代后期,福特汽车公司在平托事件之后,出于安全和法规方面的考虑,在汽车行业采用了 FMEA
FMEA 之所以能够在这些差异很大的领域都得到应用,根本原因在于FMEA 是一套分析和思考的方法,而不是某个领域的技能或者工具
FMEA 并不能指导我们如何做架构设计,而是当我们设计出一个架构后,再使用FMEA 对这个架构进行分析,看看架构是否还存在某些可用性的隐患

Failure:假设系统某系组件或者模块出现故障
Mode:故障发生的方式、可能性
Effect:故障的影响
Analysis:分析系统的可能反应,以及如何改进


| 业务功能 | 故障模式 | 故障影响 | 严重程度 | 故障原因 | 故障概率 | 风险程度 | 已有措施 | 规避措施 | 解决措施 | 后续规划 |
|---|---|---|---|---|---|---|---|---|---|---|
| FMEA分析涉及的功能点 | 系统可能会出现什么样的故障 | 当发生故障模式中描述的故障时,业务功能具体会受到什么影响 | 故障对业务的影响程度 | 导致故障现象发生的原因,不同原因可能导致相同的故障 | 某个具体故障原因发生的概率 | 综合严重程度和故障概率来一起判断某个故障的最终等级 | 针对具体的故障原因,系统现在是否提供了某些措施应对 | 为了降低故障发生概率或者故障影响采取的一些措施 | 解决措施指为了能够解决问题而做的一些事情 | 系统的后续改进规划 |
不需要记住这11个维度,需要的时候直接用就行
用户角度划分的业务相关的功能点
从用户角度而不是系统角度
例如:对于一个用户管理系统,使用 FMEA 分析时 “登录”“注册”才是功能点,而用户管理系统中的数据库存储功能、Redis缓存功能不能作为 FMEA 分析的功能点
系统会出现什么样的故障,包括故障点和故障形式
故障模式并不需要给出真正的故障原因,只需要假设出现某种故障现象即可
故障模式的描述要尽量精确,多使用量化描述,避免使用泛化的描述。例如,推荐使用“MySQL响应时间达到3秒”,而不是“MySQL 响应慢”
故障发生后业务功能具体会受到什么影响
常见的影响有:功能点偶尔不可用、功能点完全不可用、部分用户功能点不可用、功能点响应缓慢、功能点出错等
故障影响也需要尽量准确描述。例如,推荐使用“20%的用户无法登录”,而不是“大部分用户无法登录”
从业务角度看故障的影响程度
导致故障现象出现的原因
故障现象相同,对业务影响相同;故障原因不同,发生概率、检测手段、处理措施不同
例如:
某个具体故障原因发生的概率
一般分为“高/中/低”三档即可,几个特别注意的现象:
综合严重程度和故障概率来一起判断某个故障的最终等级
风险程度 = 严重程度 × 故障概率
某个故障影响非常严重,但其概率很低,最终来看风险程度就低
例如:“某个机房业务瘫痪”对业务影响是致命的,但如果故障原因是“地震”,如果机房在广州概率就很低,如果机房在东京,概率就高很多
针对具体的故障原因,系统现在是否提供了某些措施来应对
常见措施有:
为了降低故障发生概率或者故障影响而采取的一些措施
可以是技术手段,也可以是管理手段
例如:
为了能够解决问题而采取的一些措施
一般都是技术手段,例如:
如果某个故障既可以采取规避措施,又可以采取解决措施,优先选择解决措施
针对 FMEA 分析表格,查漏补缺,优化系统架构
具体步骤:
技巧:
| 技巧 | 说明 |
|---|---|
| 抓住核心 | 优先针对核心场景进行分析 |
| 分工合作 | 可以安排给初级架构师或者高级开发人员,锻炼架构思维 |
| 适可而止 | 严重程度为高的必须解决,严重程度为中的做好检测和告警 |