|
|
EDA365欢迎您登录！
您需要 登录 才可以下载或查看，没有帐号？注册
x
一、Dependability & Security
$ U* k7 R0 w+ J1 w1 u O6 {(1)Attribute——可用性（Availability）、依赖性（Reliability）、安全性（Safety）、机密性（Confidentiality）、整体性、可维护性. r/ d! n: a F3 l0 A" p- t
5 S0 a$ N8 J x' E1 J(2)Threats——Faults、Error、Failures
& K8 _! q$ Y! I9 h
' U k" j, `# F& ?(3)Means
! D8 F# H. i2 {( R: w% T; b
9 k. k- ^, t6 @. I% F* S$ ?① Fault Prevention
+ |- T8 l- a+ k6 e( L8 c$ \6 b, t. H& v1 S7 m/ p- Y
② Fault Tolerance
4 g+ O+ W/ \9 ~, l% S8 o8 r3 X( H8 r3 F+ U, }" ~
③ Fault Remove
$ E( ?+ {# `3 I" X3 @# a4 Q+ G% C) _3 D' A7 |8 o
④ Fault Forecasting
. L6 V2 U' F9 {* ^" l
2 i$ R( P) R% ~- e0 P e" y4 G二、状态改变) T% B! @" B. k: X; t) G# y K
Activation Propagation Causation
+ [! ~. N7 q8 ]: l) P
. @' n' |5 @1 B% m. G.......——Fault——————Errors——————Failures——————Fault.......
" z. _. `% z2 K* @( x9 n; t. N' p7 b# A$ g: N8 t
三、单点故障和多点故障9 F: X% n' R, Y+ Y4 o
1、单点故障（single point of failure）1 R |1 f& A7 v" t/ d
（1）概念: q4 ?' Z [2 a& W! _% u, e
从英文字面上可以看到是单个点发生的故障，通常应用于计算机系统及网络。实际指的是单个点发生故障的时候会波及到整个系统或者网络，从而导致整个系统或者网络的瘫痪。这也是在设计IT基础设施时应避免的。3 K: G( M8 {4 o8 B
% @5 ]8 r! R) s: v
大脑对与人来说，就是一个单点，大脑损坏，人也完蛋；手是不是单点? 一只没了，另一只还能日常生活，从这个角度来说，不是单点。消除单点的最常见的做法：增加冗余。比如，人有两只手。其次，层次化。当然，分层的目的是便于隔离问题。电影 《2012》 中的这个问题，不知道谁是总架构师，看起来，隔离做得不太够 
. Z4 Z6 c9 E g V# v5 A
0 b! Q: |8 D- m$ `7 D9 ~+ t5 v( r2 ^（2）消除单点故障方法
( {; T( Z- L! \1 V1 h. E" t大体可以从以下几个方面来消除单点故障：
" N- f5 l1 ~* e( ~" `/ {: V" i' Q
一个网站，从基础的硬件层，到操作系统层，到数据库层，到应用程序层，再到网络层，都有可能产生单点故障。如果要有效地消除单点故障，最重要的一点是设计的时候要尽量避免引入单点，随着架构的变化，定期审查系统潜在的单点也是有必要的。; q$ ?1 e9 R) E% G9 ?9 N* ?$ R; \
3 j, K8 m- Q2 B' i- [
① 增加硬盘，做镜像。让出错的概率降低+ Q( r- ]; v. ]1 T! E5 Z$ N
/ y9 l" ~& m" _5 r% M* ~' l7 J② 网卡与网线的单点问题。系统里面最容易物理损坏的就是网线。网卡绑定(NIC bonding)一个很简单很通用的办法。配置多个网卡。4 b& G% k l7 Z: N
7 D+ D8 p5 k4 M, l3 ^: H3 C
③ SSH 服务器和Telnet 服务器共存。毕竟 SSH 和 Telnet 都不是百分之百靠谱的事。5 k6 D4 H! y) Q
& r( h- ], _, D- k
④ IDC 机房的单点。由于中国特色的“南北互通”，所以选择IDC机房的时候，一定要有冗余。
2 N0 a3 r) J& r1 ]1 }9 J! p) D" j; L, m( u1 c% t
⑤ 靠谱的DNS解析。, }8 Q; J8 Y+ ], u) V; C
2 M8 }, x# n* o' |, W) G0 J0 c
（3）简单单点故障架构* e' e& \* O+ b+ s3 H5 @1 `/ ~$ m
/ g$ L) X6 b8 B) \" W- X' N* l) C
* F: S5 L" S9 _, a* Y% J+ Y3 x若干台云服务器通过负载均衡对外提供服务，在另一台云服务器上安装了MySQL作为应用数据库，为了提高性能，在服务器和数据库之间搭一个Redis缓存服务器。在这样的架构中，缓存服务器和数据库都存在单点隐患，可以考虑主从备份的设计。缓存服务器可以利用Redis对主从的支持特性设计成Master-Slave部署，数据库是在ECS上安装MySQL，虽然也可以在另一台服务器上安装MySQL，配置主从，但是可靠性仍然依赖于云服务器，故建议改用RDS。RDS是内在支持主从的阿里云关系型数据库产品，用户无需操心数据同步、主备切换等细节，使用更为方便。优化后的架构如下图所示：
3 {) S9 T" r# X3 A% K' |
7 x$ A) ]. B7 D# w& ]# s$ ~* ]! L) t# p, f
/ R5 X z) T+ F4 l4 w7 c- u
2、多点故障$ L+ y3 [2 O; A6 ?$ G
多个单点故障同时发生或者依次发生。; U1 |* ?( r- t) Q
% }3 k3 A% p7 ?1 P( D/ ?5 X+ j
- \) r" X+ s# |" q- X% L; r3 |5 @4 x' N+ I. ^+ ?, C) t$ I
四、存储高可用7 j8 C, [* N3 Q: v9 \6 M$ w0 L8 x# ~
存储高可用解决方案采用存储设备与管理设备冗余架构，任何设备出现设备故障。都不会影响整个存储系统的正常适用。故障切换完全自动完成，保证业务系统的连续性。
: T9 T" y. ]: M- v: r
0 u8 v3 e/ b7 ], c: I: x. O* N% z& F7 G
3 u1 W+ N4 J; H6 x! s6 B五、故障注入
/ W7 ]# [; J3 i6 Q- N1 H3 Y3 [产品代码：故障处理代码——产品功能代码1 Q8 D6 i9 Y. n- A* @8 t
# N3 l0 u4 h' A9 {* @1 f1 v* }6 lChaos Monkey
- r7 p) {- J* W+ g
. A7 [- p9 f. I& f' VLinux Fault-Injection: c+ w1 m& o* e$ R2 l! o4 X3 T9 ^
( Q0 h7 A7 ?! A) T: }9 X/ E/ y将故障注入内置于产品是最有效的做法，使得产品具有可测性
& R. @5 l* J: t1 g$ A
8 _- r: n0 P3 b* m$ F8 B S4 l% A* F
0 L7 r4 r& x3 c$ q8 _; b4 g: P G/ R# D; E1 A
六、测试实战
! ]$ z. r. C# {5 ?: O' }未知故障、已知场景（压力、稳定性、流控测试）
6 o# r# V Q4 Q$ o已知故障、已知场景（故障注入）
0 Y# ~7 ]- N2 Q. M! s" u: P已知故障、未知场景（故障注入）' c9 g0 c y: Q) D* M& ~/ l
未知故障、未知场景（可靠性预计于建模）
9 r, X" S. O5 L( P% f1 F2 o
( L' v1 b) S6 ^7 g$ I9 l+ Y4 `+ F- q o4 f- \) \
1、故障模式库——为可靠性测试提供测试输入，定义了测试范围
; c5 Y( v! X# |: a0 j- J; a1 t9 v( i
2、可靠性测试评估基线
8 V+ w- r9 ^6 C# a0 J
, w% a) v( o6 E5 u% z3、可靠性测试指导书
; b" z& Q/ y8 r" u. r8 d _( _5 F& Z9 I5 _- I4 Y
4、评估产品的可靠性能力0 t5 I+ U3 `) e- a* N, F! w
]% t/ T1 E$ u: Z$ q5、长稳测试
1 _3 Q+ S( U9 g! R; Z
3 _' y7 w2 d6 W9 u' a& h
# c3 q5 H* K- ~9 }- A9 A, p; U( y; B6 z
七、“几个9”
" |- V; c- w( O2 s G' [产品的可靠性是指：产品在规定的条件下、在规定的时间内完成规定的功能的能力。
" p) y5 i$ L. U' V. _ b2 H6 ?/ N5 K2 g0 b) D3 f
对电子产品而言，产品宣传经常用可用度 n 个 9 来描述产品可靠性水平。n 个 9 表示在系统1年时间的使用过程中，系统可以正常使用时间与总时间（1年）之比，通过下面的计算来感受下 n 个 9 在不同级别的可靠性差异。 / B/ \: x" X" `! c
$ v6 T0 v o: |( w4个9：% Y5 ~3 h) A3 [% i8 W! H: o
9 q7 N7 k. q' ?(1-99.99%)*365*24=0.876小时=52.6分钟，表示该系统在连续运行1年时间里最多可能的业务中断时间是52.6分钟。
; s* o8 \" H4 F3 V9 K8 h3 p$ e1 T0 |* T# X
5个9：6 z9 Q' E c, `* k
# v$ H: h8 h( P+ H
(1-99.999%)*365*24*60=5.26分钟，表示该系统在连续运行1年时间里最多可能的业务中断时间是5.26分钟。
: J% X0 |5 z3 x P2 w/ }+ u* n) e# T: ]0 s: s; ~
3 {5 [$ q- D2 p |
|
/1 
发表于 2021-8-31 14:30
收藏
淘帖
支持！
反对！