从0开始学架构_25_24_FMEA方法排除架构可用性隐患的利器
你好，我是华仔。
今天我和你分享的主题是FMEA方法。
我在前面的专栏分析高可用复杂度的时候提出了一个问题，高可用和高性能哪个更复杂？大部分同学都分析出了正确的答案。
高可用更复杂一些，主要原因在于异常的场景很多，只要有一个场景遗漏架构设计，就存在可用性隐患。
而根据墨菲定律可能出错的事情，最终都会出错，架构隐患总有一天会导致系统故障。
那此我们在进行架构设计的时候，必须全面分析系统的可用性。
那么如何才能做到全面呢？我今天介绍的FMEA方法，就是保证我们做到全面分析的一个非常简单，但是非常有效的方法。
Fmea故障模式与影响分析，又称为失效模式与后果分析、失效模式与效应分析、故障模式与后果分析等专栏采用故障模式与影响分析，因为这个中文翻译更加符合可用性的语境。
Fmea是一种在各行各业都有广泛应用的可用性分析方法，通过对于系统范围内潜在的故障模式加以分析，并按照严重程度进行分类，以确定失效。
对于系统的最终影响，FMEA最早是在美国军方开始应用的。
二十世纪四十年代后期，美国空军正式采用了FMEA.尽管最初是在军事领域建立的方法，但FMEA方法现在已经广泛应用于各种各样的行业，包括半导体加工、餐饮服务、塑料制造、软件及医疗保健行业。
Fma之所以能够在这些差异很大的领域都得到应用，根本原因在于FMA是一套分析和思考的方法，而不是某个领域的技能或者工具。
回到软件架构设计领域。
Fma并不能指导我们如何做架构设计，而是当我们设计出一个架构后，再使用FMEA对这个架构进行分析，看看架构是否还存在某些可用性的隐患。
在架构设计领域，FMEA的具体分析方法是给出初始的架构设计图，假设架构中某个部件发生故障分析，此故障对系统功能造成的影响，根据分析结果判断架构是否需要进行优化。
Fmea分析的方法呢其实很简单，就是一个FMEA分析表常见的FMEA分析表格包含下面部分，一功能点，当前的FMA分析设计的功能点。
注意，这里的功能点指的是从用户角度来看的，而不是从系统各个模块功能点划分来看的。
例如对于一个用户管理系统使用FMEA分析时登录和注册才是功能点。
而用户管理系统中的数据库存储功能、REDIS缓存功能不能作为FMEA分析的功能点。
二、故障模式故障模式指的是系统会出现什么样的故障，包括故障点和故障形式。
需要特别注意的是，这里的故障模式并不需要给出真正的故障原因。
我们只需要假设出现某种故障现象即可。
例如，mysql响应时间达到三秒，造成mysql响应时间达到三秒，可能的原因有很多，比如说磁盘坏道慢，查询服务器到mysql的连接网络故障、mysql bug等。
我们并不需要在故障模式中一一列出来，而是在后面的故障原因一节中列出来。
因为在实际应用过程中，不管哪种原因，只要现象是一样的，对业务的影响就是一样的。
此外，故障模式的描述要尽量精确，多使用量化描述，避免使用泛化的描述。
例如推荐使用mysql响应时间达到三秒，而不是mysql响应慢三故障影响。
当发生故障模式中描述的故障时，功能点具体受到什么影响？常见的影响有功能点偶尔不可用，功能点完全不可用，部分用户功能点不可用，功能点响应缓慢、功能点出错等故障影响也需要尽量准确描述。
例如推荐使用百分之二十的用户无法登录，而不是大部分用户无法登录。
要注意这里的数字呢不需要完全精确，比如百分之二十一点二五，这样的数据其实是没有必要的。
我们只需要预估影响是百分之二十还是百分之四十四，严重程度严重程度只站在业务的角度，故障的影响程度一般分为致命高中低五五个档次，严重程度按照这个公式进行评估，严重程度等于功能点重要程度成故障影响范围成功能点受损程度。
同样以用户管理系统为例，登录功能比修改用户资料要重要的多，百分之八十的用户比百分之二十的用户范围更大，完全无法登录，比登录缓慢要更严重。
因此，我们可以得出如下故障模式的严重程度，致命，超过百分之七十的用户无法登录。
高超过百分之三十的用户无法登录中，所有用户登录时间超过五秒。
第一，百分之十的用户登录时间超过五秒中，所有用户都无法修改资料。
第一，百分之二十的用户无法修改头像，对于某个故障的影响到底属于哪个档次。
有时呢会出现一些争议，例如所有用户都无法修改资料，有的人认为是高，有的人可能认为是中，这个没有绝对标准，一般建议相关人员讨论确定即可，也不建议花费太多时间争论争执不下时，架构师裁定即可。
五、故障原因故障模式中只描述了故障的现象，并没有单独列出故障原因，主要原因在于，不管什么故障原因，故障现象相同，对功能点的影响就相同。
那为何这里还要单独将故障原因列出来呢？主要原因有这几个。
第一，不同的故障原因发生概率不相同。
例如导致mysql查询响应慢的原因可能是mysql bug,也可能是没有索引。
很明显，mysql bug的概率要远远低于没有索引，而不同的概率又会影响我们具体如何应对这个故障。
第二，不同的故障原因检测手段不一样。
例如磁盘坏道导致mysql响应慢，那我们需要增加机器的磁盘坏道检查。
这个检查很可能不是当前系统本身去做，而是另外运维专门的系统。
如果是慢查询导致mysql慢，那我们只需要配置mysql的慢，查询日志即可。
第三，不同的故障原因的处理措施不一样。
例如，如果是mysql bug,我们的应对措施只能是升级mysql版本。
如果是没有索引，我们的应对措施就是增加索引六故障概率。
这里的概率就是指某个具体故障原因发生的概率，例如磁盘坏掉的概率，mysql bug的概率没有索引的概率，一般分为高中低三档即可。
具体评估的时候需要有以下几点，需要重点关注。
第一，硬件硬件随着使用时间推移，故障概率会越来越高。
例如，新的硬盘坏到几率很低，但使用了三年的硬盘坏到几率就会高很多。
第二，开源系统成熟的开源系统bug率低，刚发布的开源系统bug率相比会高一些，自己已经有使用经验的开源系统bug率会低，刚开始尝试使用的开源系统bug率会高。
第三，自研系统和开源系统类似成熟的资源系统故障概率会低，而新开发的系统故障概率会高。
高中低是相对的，只是为了确定优先级，以决定后续的资源投入，没有必要绝对量化。
因为绝对量化是需要成本的，而且很多时候都没法量化。
例如，叉叉开源系统是三个月故障一次还是六个月才故障一次，是无法评估的。
七、风险程度、风险程度就是综合严重程度和故障概率来一起判断某个故障的最终等级，风险程度等于严重程度呈故障概率，因此可能出现某个故障影响非常严重，但其概率很低，最终看来，风险程度就低。
某个机房业务瘫痪对业务影响是致命的，但如果故障原因是地震，那概率就很低。
例如，广州的地震概率就很低，五级以上地震的二十世纪才一次。
如果故障的原因是机房空调烧坏，则概率就比低震高很多了，可能是两年一次。
如果故障的原因是系统所在机架掉电，这个概率比机房空调又要高了，可能是一年一次。
同样的故障影响不同的故障原因有不同的概率，最终得到的风险级别就是不同的。
八、已有措施针对具体的故障原因，系统现在是否提供了某些措施来应对，包括检测警告、容错自恢复等。
第一，检测警告。
最简单的措施就是检测故障，然后警告系统自己不针对故障进行处理，需要人工干预。
第二，容错检测到故障后，系统能够通过备份手段应对，例如mysql主备机。
当业务服务器检测到主机无法连接后，自动连接备机读取数据。
第三，自恢复检测到故障后，系统能够自己恢复。
例如hadoop检测到某台机器故障后，能够将存储在这台机器的副本重新分配到其他机器。
当然，这里的恢复主要还是指业务上的恢复，一般不太可能将真正的故障恢复。
例如，hadoop,不可能将产生了磁盘坏掉的磁盘，修复成没有坏掉的磁盘。
九、规避措施规避措施指的是为了降低故障发生概率而做的一些事情，可以是技术手段，也可以是管理手段。
例如，技术手段是为了避免引入新的芒狗DB丢失数据。
在mysql中冗余一份管理手段是为了降低磁盘坏掉的概率，强制统一更换服务器时间超过两年的磁盘。
十、解决措施。
解决措施指的是为了能够解决问题而做的一些事情，一般都是技术手段。
例如为了解决密码暴力破解，增加密码重试次数限制。
为了解决脱库导致数据泄露，将数据库中的敏感数据加密保存。
为了解决非法访问，增加白名单控制。
一般来说，如果某个故障既可以采取规避措施，又可以采取解决措施，那么我们会优先选择解决措施，毕竟能解决问题当然是最好的。
但很多时候有些问题是系统自己无法解决的。
例如磁盘坏道、开源系统bug这类故障呢只能采取规避措施，系统能够自己解决的故障，大部分是和系统本身功能相关的。
十一、后续规划综合前面的分析就可以看出哪些故障。
我们目前还缺乏对应的措施，哪些已有措施还不够。
针对这些不足的地方，再结合风险程度进行排序，给出后续的改进规划。
这些规划呢既可以是技术手段，也可以是管理手段，可以是规避措施，也可以是解决措施，同时需要考虑资源的投入情况，优先将风险程度高的系统隐患解决。
例如，地震导致机房业务中断，这个故障模式就无法解决，只能通过备份中心规避，尽量减少影响。
而机柜断电导致机房业务中断，可以通过将业务机器分散在不同机柜来规避敏感数据。
泄露这个故障模式，可以通过数据库加密的技术手段来解决。
蒙狗DB断电丢数据这个故障模式可以通过将数据冗余一份在mysql中、在故障情况下重建数据来规避影响。
下面呢我以一个简单的样例来模拟一次FMEA分析。
假设我们设计一个最简单的用户管理系统，包含登录和注册两个功能，其初始架构请点击文稿查看。
初始架构很简单，mysql负责存储main cash,负责缓存server负责业务处理。
我们来看看这个架构，通过FMEA分析后，能够有什么样的发现。
Fmea分析表请点击文稿查看。
经过FMA分析，将后续规划列的内容汇总一下，我们最终得到了下面几条需要改进的措施。
Mysql增加备机MC从单机扩展为集群。
Mysql双网卡连接改进后的架构图，你可以在文稿中查看。
今天我为你讲了FMEA高可用分析方法，并且给出了一个简单的案例描述。
如何操作FMEA是高可用架构设计的一个非常有用的方法，能够发现架构中隐藏的高可用问题，希望对你有所帮助。
这就是今天的全部内容，留一道思考题给你吧。
请使用FMEA方法分析一下HDFS系统的架构，看看HDFS是如何应对各种故障的。
并且分析一下HDFS是否存在高可用问题。
欢迎你把答案写到留言区，和我一起讨论。
相信经过深度思考的回答，也会让你对知识的理解更加深刻。