24 | FMEA方法,排除架构可用性隐患的利器

2018-06-21 李运华
《从 0 开始学架构》
课程介绍


讲述:黄洲君

时长:大小6.24M


我在前面的专栏分析高可用复杂度的时候提出了一个问题:高可用和高性能哪个更复杂,大部分同学都分析出了正确的答案:高可用更复杂一些,主要原因在于异常的场景很多,只要有一个场景遗漏,架构设计就存在可用性隐患,而根据墨菲定律“可能出错的事情最终都会出错”,架构隐患总有一天会导致系统故障。因此,我们在进行架构设计的时候必须全面分析系统的可用性,那么如何才能做到“全面”呢?
我今天介绍的FMEA 方法,就是保证我们做到全面分析的一个非常简单但是非常有效的方法。

FMEA 介绍

FMEA(Failure mode and effects analysis,故障模式与影响分析)又称为失效模式与后果分析、失效模式与效应分析、故障模式与后果分析等,专栏采用“故障模式与影响分析”,因为这个中文翻译更加符合可用性的语境。FMEA 是一种在各行各业都有广泛应用的可用性分析方法,通过对系统范围内潜在的故障模式加以分析,并按照严重程度进行分类,以确定失效对于系统的最终影响。

展开全文
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。

精选留言

  • 云学
    2018-06-21
    我们公司也在用这套方法,这套方法其实就是多设计一些异常case,系统能够依然保持稳定,当然正常的case也是很重要的。

    作者回复: 知道这套方法论的公司不多,说明你们公司技术比较厉害👍

    共 4 条评论
    72
  • yason li
    2018-06-21
    请教老师:
    根据网上查到的资料发现,经过多年的演进FMEA从定性和定量两个维度分别延伸出了FMECA和FMEDA,实际进行架构分析时是不是使用FMECA会更好一些?
    还有就是FMEA分析貌似比较适合系统中单点故障的评估。如果系统比较复杂完成故障的原因有可能是多点同时互相影响那么评估时候是不是使用FTA 故障树分析更合适呢?

    作者回复: 1. 我也是看了你的评论才知道还有FMECA和FMEDA,我查了一下资料,其实都是FMEA的扩展版,其实我们在具体实践的时候,分析纬度已经包括FMECA中的危害性分析(文中的“严重程度”),以及FMEDA中的诊断分析(文中的“已有措施”)

    2. FTA我理解是一种故障影响分析方式,例如FMEA中分析“故障影响”

    
    30
  • 金蝉子
    2019-05-17
    FMEA分析表:
    1、功能点;2、故障模式;3、故障影响;4、严重程度;5、故障原因;6、故障概率;7、风险程度;8、已有措施;9、规避措施;10、解决措施;11、后续规划
    
    13
  • 小喵喵
    2018-07-28
    MySQL 主备机,当业务服务器检测到主机无法连接后,自动连接备机,这个是需要这程序来感知主机是否联通的吗?若是,这个怎么写这个程序呢?还有如何自动切换到备机呢?我基础太差了,谢谢老师的每次回答我的问题。

    作者回复: 1. java有jdbc异常,你可以详细看看,其他语言类似
    2. 切换到备机其实就是重新连接备机,jdbc中的getconnection

    
    9
  • 赵春辉
    2020-04-14
    之前搞过一些军方的项目,就是搞FMEA的,主要做硬件的可靠性分析,没想到在这里能看到。

    作者回复: 挺好的一个方法

    
    7
  • 花花大脸猫
    2019-04-23
    如果一个公司的架构师连公司本身的业务都不清楚的情况下,直接进行架构设计,这样做出来的架构能用么?是不是您所说的PPT架构师?

    作者回复: 不是,PPT架构师一般指业务很熟,画框图很厉害,各种技术术语也很熟,但是技术细节和实现不懂

    
    6
  • 王宁
    2018-07-07

    HDFS可以从
    网络原因分片传输
    存储分片大小
    DataNode故障
    NameNoe故障
    如果两个NameNode都出现问题这个时候就需要人工介入了吧。
    展开

    作者回复: 是的

    
    6
  • Hook
    2018-06-21
    请教老师:
    FMEA 实战表格中(正文的倒数第二张图),故障原因是 “MySQL 服务器断电” 对应了 2 个功能点,分别为:登录、注册。
    其中,“登录”功能点它的“后续规划”列中写的是“增加备份 MySQL”,而“注册”功能点对应的是“无,因为即使增加备份机器,也无法作为主机写入”。
    我的问题是:
    “注册”功能点对应的后续规划可不可以是:“增加 mysql 主从切换功能”呢?老师写“无”是从什么角度来思考“后续规划”的。
    展开

    作者回复: 确实可以这么做,但有些场景没必要做这么复杂,注册不了过段时间注册就可以了😄

    
    5
  • 小喵喵
    2018-07-28
    FMEA除了分析高可用,也能分析其他架构吗,比如高性能,冗余等架构?

    作者回复: 不能,只适合分析高可用

    
    3
  • 邱昌ོ
    2018-07-11
    老师,Mysql响应慢超过5秒,是如何做出影响60%的结论? 实际应用中这种如何评估?

    作者回复: 根据业务具体情况评估,不是绝对的

    
    3
  • 王磊
    2018-06-21
    hdfs
    对于datanode failure, hdfs的应对方式是数据存在多份拷贝,当某个结点down掉后,系统会检测到 under replication, 数据的其他拷贝会在其他可用结点上再增加一份拷贝;
    对于那么node failure,hdfs
    的应对方式是secondary namenide.

    作者回复: 两个namenode挂掉呢?

    
    3
  • 谭方敏
    2020-03-07
    fmea(failure mode and effects analysis )全称为故障模式与影响分析。

    fmea的整体思路:
    给出初始的架构设计图。
    假设架构中某个部件发生故障。
    分析此故障对系统功能造成的影响。
    根据分析结果,判断架构是否需要进行优化。
    展开
    
    3
  • 王宁
    2018-07-07
    这个名词虽然不熟悉,不过这几个步骤在风险管理里面很熟悉。
    风险程度=严重程度*故障概率等。
    
    2
  • prader26
    2021-04-18
    FMEA(Failure mode and effects analysis,故障模式与影响分析)又称为失效模式与后果分析、失效模式与效应分析、故障模式与后果分析等,专栏采用“故障模式与影响分析”,因为这个中文翻译更加符合可用性的语境。
    具体包括
    1 功能点 2故障模式 3 故障影响 4 严重程度 5 故障原因 6故障概率 7 风险程度 8 已有措施 9 规避措施 10 解决措施
    
    1
  • 钱
    2019-08-30
    第一次听说这个,长见识了,实际工作中也会分析下系统是否高可用,不过没这个系统,主要集中在代码逻辑层面。
    FMEA——故障模式与影响分析。

    作者回复: 很有用的方法

    
    1
  • 小喵喵
    2018-10-08
    如何做容错机制呢?
    比如for (int i = 0; i < length; i++)
                {
                    try
                    {

                    }
                    catch (Exception)
                    {
                        
                     
                    }
                }
    这个也算吗?及时程序中一项出现异常,依然会跑完。
    展开

    作者回复: FMEA是架构层的容错,不是代码层的错误和异常处理

    
    1
  • 小喵喵
    2018-07-28
    如何在SQL SERVER中找慢查询语句呢?你说log配置,怎么配?谢谢

    作者回复: 请上网搜索😊

    
    1
  • Kepler
    2021-12-06
    有些复杂了,感觉这套方法论

    作者回复: 再认真看看,并不复杂,维度虽然多,但是都很好理解

    
    
  • 麦耀锋
    2021-11-01
    例如,“所有用户都无法修改资料”,有的人认为是高,有的人可能认为是中,这个没有绝对标准,一般建议相关人员讨论确定即可。也不建议花费太多时间争论,争执不下时架构师裁定即可。

    上面这一段,实际上在“争执不下”的时候,make decision的不是架构师,而是产品经理或者业务负责人。因为只有产品、业务的人才知道,这个影响对于用户而言意味着什么,影响有多大。架构师一般不具备这方面的知识。

    作者回复: 架构师要求懂业务的,如果完全由产品经理或者业务负责人来定,他们基本都是“越高越好”、“永远不出错最好”这种想法 :)

    
    1
  • Drake敏
    2021-09-17
    感觉服务器负载keepalived和mysql主从,数据备份是每家公司必定要考虑的点

    作者回复: 这个是基本的高可用知识点

    
    