|
|
EDA365欢迎您登录！
您需要 登录 才可以下载或查看，没有帐号？注册
x
一、什么是FMEA* d! y# i) n3 l
! q4 i( h+ H- g0 ?! @, H2 nFMEA，Failure mode and effects analysis，故障模式与影响分析。FMEA是一种可靠性设计的重要方法。它实际上是FMA（故障模式分析）和FEA（故障影响分析）的组合。它对各种可能的风险进行评价、分析，以便在现有技术的基础上消除这些风险或将这些风险减小到可接受的水平。FMEA之所以能够在各个领域得到应用，根本原因在于FMEA是一套分析和思考的方法，而不是某个领域的技能或者工具，是"道"层面的东西。
7 `, T/ w- ^; g. ~% V2 O9 n
4 b. W4 |2 C+ T1 Y0 x二、FMEA的目标/ _$ |, Q5 P, ^) @, [
: d" i9 Z1 T7 Z/ z( a0 l
2.1 在设计系统架构的时候，经常会遗漏掉一些关键环节的隐患的容错考虑，这些盲点没有在高可用设计中被考虑到；7 P+ _ E) j- T3 K
0 |5 G9 C3 o! f$ i2.2 同时也在测试case中被忽略，那么上线之后，当隐患暴露，那么极大可能对线上系统稳定性造成巨大影响。
4 Z6 D6 L( H) Z2 G& z( j l+ j" J, ]6 o7 G& c
因此我们做FMEA的目的是：能够容易、低成本地对产品或过程进行修改，从而减轻事后危机的修改；找到能够避免或减少这些潜在失效发生的措施。, Z4 b0 a0 ~5 r# i7 m
9 f, h/ Z, L7 Z. {3 R三、FMEA在架构设计中的使用) T. i1 t n: w4 c
. L, Y. p4 Z8 X: ]
回到软件架构设计领域，FMEA并不能知道我们如何做架构设计，而是当我们设计出一个架构后，再使用FMEA对这个架构进行分析，看看架构是否还存在某些可用性的隐患。3 G, A' G C! E2 Y
' N) `; i2 W/ J# d _ Y- D
在架构设计领域，FMEA的具体方法是：
9 K6 e w" e& A& s; L& E* A* F
a; N5 ~1 b% l) e; v6 e8 z给出初始的架构设计图
; Y. p$ w# x/ j( H. r$ E+ @# O! a x- r5 Q( |& q
假设架构中某些部件发生了故障
& U, ]. E2 F1 T" }8 O- n# A' a! m) X9 r; F3 [
分析此故障对系统功能造成的影响7 \3 x2 E% N" i+ ~' ]1 S1 G
* a' N- i, C* l2 E
根据分析结果，判断架构是否需要进行优化
% S9 {7 O* A8 E0 `2 K) M$ O' U
+ G$ o, q- c1 ^* V6 R9 t3.1 功能点
! g( F( `8 D7 W$ a( `8 n$ U$ \- |) k8 {5 S
从用户角度分析的功能点，而不是从模块功能划分。# v4 B/ b+ K4 H3 o! Y1 a
, P& _! K9 z2 U3.2 故障模式& C4 D/ h7 _) O# Z$ g2 d% m7 V, b
2 U9 F8 T x" ?
系统会出现什么样的故障，包括故障点和故障形式。故障模式不是原因，只需要假设出某种故障现象即可。+ H; }- @0 v- y$ f4 J4 a% D+ g
+ j: `' l/ ]) q9 z0 t7 ] @0 D
3.3 故障影响
2 R' o2 H j9 o8 x' B2 b# v0 j7 x; s& z+ j' a7 \
当发生故障模式中描述的故障时，功能点具体会受到什么影响。常见的影响有：功能点偶尔不可用、功能点完全不可用、部分用户功能点不可用、功能点响应缓慢、功能点出错；
% R/ O' m6 J) s7 V& v
& R' g: I' _1 u8 M, Q. m故障影响需要通过数字尽量准确描述。比如"20%用户无法登陆"等。
1 h, i. u7 Z1 o! _ k, v% [4 j5 ` M$ R5 W8 v
3.4 严重程度 n2 n! p7 Y+ z$ p
$ b) N9 E4 z' a2 T. |& S7 B
站在业务的角度故障的影响程度，一般分为"致命 、 高 、 中 、低、无"五个档次。& q2 c. ^* g8 H9 N
' S" o! a( C/ `0 e$ m/ z
严重程度评估公式：严重程度 = 功能点重要程度 * 故障影响范围 * 功能点受损程度。
9 K- I6 g7 E: c1 e! ^% p& w* a, `9 D- |5 F5 W: b' m/ N9 C0 Z5 T
3.5 故障原因
- i3 r" g8 {; n6 H( `/ c: S
. V6 ]. C' h9 a"故障模式"中只描述了故障的现象，并没有单独列出故障原因。主要原因在于不管什么故障原因，故障现象相同 ，对功能点的影响就相同。为何单独列出故障原因？' }& j: o6 t/ K: b5 L* k
5 ^! T, f2 e: N5 K
不同的故障原因发生概率不相同' b$ f+ _: X$ Y3 z8 z
6 W5 r& ^; H( i* Q不同的故障原因检测手段不一样( H; e- ]3 I) d/ ?9 U* y8 q* [
! |- I3 F6 O; Q, s9 v& C' o& H
不同的故障原因处理措施不一样
, c r' A: q8 j2 _/ \1 W: |6 H3 d$ v+ R& a
3.6 故障概率
% p% s" q# N* t8 K" K' o9 m' T9 W3 E$ V
某个故障原因发生的概率。例如mysql没有索引的概率，接口不可用的概率，redis挂掉的概率。一般分为"高、中、低"三个档次。
0 a( s) @$ L- p' E2 G& N/ G- x3 J5 w7 b
3.7 风险程度1 }# V2 e7 b+ \4 h$ s) g% `
- J4 V4 J2 R6 u风险程度就是综合严重程度和故障概率来一起判断某个故障的最终等级，风险程度 = 严重程度 * 故障概率。- o) \: b. w& Q% q- _
0 ` Q0 t+ M7 v1 H+ ?) n( a3.8 已有措施5 l$ L0 L/ S' ?+ }$ [
$ F& r- B; n) R/ {
针对具体的故障原因，系统现在是否提供概率某些措施来应对，包括：检测告警、容错、自恢复等。
2 y; h) X% G- k5 O
, }0 B& H; F: N( `! f0 j4 X, G: E6 T3.9 规避措施
( Z% k8 G0 Y6 W5 d8 B) V( {9 j
" _8 r$ P3 O; m为了降低故障发生概率而做的一些事情，可以是技术手段，也可以是管理手段。
+ {: V2 ^% L% Y8 b: u# B4 j A) ^$ i# p, k m
3.10 解决措施, h+ _# l6 k8 Z- B
" s7 z l; p4 k: V2 T9 ?- t7 u解决措施指为了能够解决问题而做的一些事情，一般都是技术手段。1 y, ?) R. \3 r; _
6 K) j, C' p4 S# P8 v5 f; x
3.11 后续规划' m# Y# L& l. C& A" c
% U# W! B" P; k. p综合分析，勘测处哪些故障是我们目前还缺乏的应对的措施，哪些已有措施还不够，针对不足地方，结合风险程度进行排序，给出后续改进规划。这些规划既可以是技术手段，也可以是管理手段；可以是规避措施，也可以是解决措施。
/ P+ |9 ]6 ^+ K$ h( P5 z& _ |
|
/1 
发表于 2021-8-9 09:48
收藏
淘帖
支持！
反对！