一、FEMA概述
FEMA(Failure Mode and Effects Analysis 故障模式与影响分析)是一套在各行各业都应用的可用性分析方法,包括半导体加工、餐饮服务、塑料制造、软件及医疗保健行业等。而在软件设计领域,FMEA具体的分析方法如下:
(1)给出架构设计图;
(2)假设架构中某个部位发生故障;
(3)分析此故障对系统功能造成的影响;
(4)根据分析结果判断架构是否需要进行优化。
具体做法是制作一张FMEA分析表,表格内容如下所示。
功能点 | 故障模式 | 故障影响 | 严重程度 | 故障原因 | 故障概率 | 风险程度 | 已有措施 | 规避措施 | 解决措施 | 后续规划 |
---|---|---|---|---|---|---|---|---|---|---|
- | - | - | - | - | - | - | - | - | - | - |
(1)功能点
这里的功能点是指站在用户的角度上看到的系统的功能点,比如“登录”、“注册”等,而不是“登录后用户数据放到Redis缓存”,也就是对用户无感知的系统内部功能点不纳入此表中。
(2)故障模式
故障模式指的是系统会出现什么样的故障,包括故障点和故障表现形式,比如【MySQL响应时间超过5秒】,需要注意的是,故障模式的描述需要量化,而不要采用抽象,带有主观性的描述,例如【MySQL响应慢】这种。
(3)故障影响
故障影响指的是当故障模式描述的故障发生时,对系统的影响是什么,比如【20%用户无法登录】,这里的描述同样需要量化,但是不用太精确,比如【20.21%用户无法登录】这种就没有太大意义,但需要规避类似【大部分用户无法登录】这种抽象描述。
(4)严重程度
严重程度指的是站在业务角度故障的影响程度,通常分为“致命 / 高 / 中 / 低”,严重程度按照这个公式进行评估:严重程度 = 功能点重要程度 × 故障影响范围 × 功能点受损程度。比如【所有用户无法登录】要比【20%用户无法登录】的严重程度要高,但指定严重程序通常带有主观性质,当存在分歧时,可以采用团队表决或者由架构师拍板的方式。
(5)故障原因
故障原因是对故障模式的一种分析,比如【MySQL响应时间超过5秒】的原因可能是:(1)没有走索引导致查询慢 (2)MySQL连接数不足,高并发情况下响应慢等等。
(6)故障概率
故障概率指的是对于故障原因发生的概率,一般分为【高 / 中 / 低】三档。
(7)风险程度
风险程度就是综合严重程度和故障概率来一起判断某个故障的最终等级,风险程度 = 严重程度 × 故障概率。因此可能出现某个故障影响非常严重,但其概率很低,最终来看风险程度就低。一般分为【高 / 中 / 低】三档。
(8)已有措施
针对具体的故障原因,系统现在是否提供了某些措施来应对,包括:检测告警、容错、自恢复等。
(9)规避措施
规避措施指为了降低故障发生概率而做的一些事情,可以是技术手段,也可以是管理手段。
(10)解决措施
解决措施指为了能够解决问题而做的一些事情,一般都是技术手段。
(11)后续规划
综合前面的分析,就可以看出哪些故障我们目前还缺乏对应的措施,哪些已有措施还不够,针对这些不足的地方,再结合风险程度进行排序,给出后续的改进规划。这些规划既可以是技术手段,也可以是管理手段;可以是规避措施,也可以是解决措施。
二、FEMA实战
如上面架构图,是我们在用的一个报表子系统,其中Application Server对外提供Web服务,供用户查询报表数据,Analysis Server用于定时分析数据并形成报表。下面对报表平台用户查询报表数据进行FEMA分析。
功能点 | 故障模式 | 故障影响 | 严重程度 | 故障原因 | 故障概率 | 风险程度 | 已有措施 | 规避措施 | 解决措施 | 后续规划 |
---|---|---|---|---|---|---|---|---|---|---|
查询报表 | 报表无数据 | 用户体验差 | 高 | Analysis Server宕机 | 低 | 中 | 通过运维工具把Analysis Server纳入监控体系 | 无 | 无 | 调整Analysis Server实现方式,采用多节点热备设计 |
查询报表 | 报表无数据 | 用户体验差 | 高 | MySQL宕机 | 低 | 中 | 通过运维工具把MySQL纳入监控体系 | 无 | MySQL采用双主架构 | 无 |