可靠性测试技术

rural

一、Dependability & Security
: q  I2 d" F  n$ [3 Y) Y2 I(1)Attribute——可用性（Availability）、依赖性（Reliability）、安全性（Safety）、机密性（Confidentiality）、整体性、可维护性

(2)Threats——Faults、Error、Failures

& b; t: a; U) _(3)Means

①　Fault Prevention

②　Fault Tolerance
& D$ p5 @- _0 W3 F& f1 |
③　Fault Remove
' O) b& ]/ H  m5 g+ d5 Y, e
④　Fault Forecasting

二、状态改变
/ ?$ ]% x8 F7 A0 `9 o                        Activation              Propagation            Causation
) H: t& s& l1 ?  e) v. A/ F% x
.......——Fault——————Errors——————Failures——————Fault.......
4 ^* B* _1 X; Y7 n8 z" F3 c" x
三、单点故障和多点故障
+ w. s8 V  P1 Q# H1、单点故障（single point of failure）
3 A) }2 d0 b8 s' F, j（1）概念
从英文字面上可以看到是单个点发生的故障，通常应用于计算机系统及网络。实际指的是单个点发生故障的时候会波及到整个系统或者网络，从而导致整个系统或者网络的瘫痪。这也是在设计IT基础设施时应避免的。
- S& s2 ?# U( D# t9 ?0 r6 B
大脑对与人来说，就是一个单点，大脑损坏，人也完蛋；手是不是单点? 一只没了，另一只还能日常生活，从这个角度来说，不是单点。消除单点的最常见的做法：增加冗余。比如，人有两只手。其次，层次化。当然，分层的目的是便于隔离问题。电影 《2012》 中的这个问题，不知道谁是总架构师，看起来，隔离做得不太够
, p5 Q4 L" W6 C3 B: f
（2）消除单点故障方法
$ d: m$ F, V+ I* E$ @& F大体可以从以下几个方面来消除单点故障：
/ l. b* L2 L6 K9 j( v2 y$ X" Z
& h3 @% z4 q9 ^8 V& }一个网站，从基础的硬件层，到操作系统层，到数据库层，到应用程序层，再到网络层，都有可能产生单点故障。如果要有效地消除单点故障，最重要的一点是设计的时候要尽量避免引入单点，随着架构的变化，定期审查系统潜在的单点也是有必要的。

①　增加硬盘，做镜像。让出错的概率降低

4 G' o# h7 J* ~$ J②　网卡与网线的单点问题。系统里面最容易物理损坏的就是网线。网卡绑定(NIC bonding)一个很简单很通用的办法。配置多个网卡。

( ]/ G. Y. E  b$ i4 D& P! n③　SSH 服务器和Telnet 服务器共存。毕竟 SSH 和 Telnet 都不是百分之百靠谱的事。
2 s+ `9 m( W% u9 g1 a: M
( a; X- `2 M% d3 N④　IDC 机房的单点。由于中国特色的“南北互通”，所以选择IDC机房的时候，一定要有冗余。
* H7 E* Z/ b5 _$ X4 _& D3 y' j
⑤　靠谱的DNS解析。

# @. s$ a- e" v4 |（3）简单单点故障架构
* K; K( o5 I, @$ I# B' R4 ^

若干台云服务器通过负载均衡对外提供服务，在另一台云服务器上安装了MySQL作为应用数据库，为了提高性能，在服务器和数据库之间搭一个Redis缓存服务器。在这样的架构中，缓存服务器和数据库都存在单点隐患，可以考虑主从备份的设计。缓存服务器可以利用Redis对主从的支持特性设计成Master-Slave部署，数据库是在ECS上安装MySQL，虽然也可以在另一台服务器上安装MySQL，配置主从，但是可靠性仍然依赖于云服务器，故建议改用RDS。RDS是内在支持主从的阿里云关系型数据库产品，用户无需操心数据同步、主备切换等细节，使用更为方便。优化后的架构如下图所示：
) P, J7 ~- a- X7 l  b


) j/ \( q8 u- I% W& _2、多点故障
多个单点故障同时发生或者依次发生。
( \/ [! ]7 h) j+ N0 {

% m( @  `& R* W- Y3 D
四、存储高可用
# |& W. O7 `& _存储高可用解决方案采用存储设备与管理设备冗余架构，任何设备出现设备故障。都不会影响整个存储系统的正常适用。故障切换完全自动完成，保证业务系统的连续性。
$ D" B* G2 f3 W: c3 a( J6 C
. S& F: S( l- M9 {0 Q8 \/ u* L  e
9 x8 G6 r: p( [
五、故障注入
产品代码：故障处理代码——产品功能代码
0 E# E: c* o  [9 a1 N
Chaos Monkey
- v* @! k  f0 n1 s* w
2 y  b+ K9 c) f0 o- bLinux Fault-Injection

将故障注入内置于产品是最有效的做法，使得产品具有可测性

2 k3 v8 _5 N$ R$ ]  E

. z" o/ G0 C, [0 B. }六、测试实战
未知故障、已知场景（压力、稳定性、流控测试）
# E- P; R; f0 ]; @, I% c" U! p9 G已知故障、已知场景（故障注入）
- `# P' m5 b  O% c: L% k* K已知故障、未知场景（故障注入）
未知故障、未知场景（可靠性预计于建模）

3 K, z) u; i0 U: x9 i' r
1、故障模式库——为可靠性测试提供测试输入，定义了测试范围
0 Q4 n, T! H& I1 c+ k
2、可靠性测试评估基线

3、可靠性测试指导书
# X7 M  O! {+ h3 o, u" T$ e3 v1 A9 L6 Y" J
8 U, u: I# M9 k0 i) `( w& D6 ~4、评估产品的可靠性能力

8 _" ]& v; k8 B, D9 g6 X5、长稳测试
  Y2 O' `7 q1 u8 P' A9 P
- t. s# }" q) ]" i

七、“几个9”
产品的可靠性是指：产品在规定的条件下、在规定的时间内完成规定的功能的能力。

, u, x* X) k- X* ]  {5 e6 n对电子产品而言，产品宣传经常用可用度 n 个 9 来描述产品可靠性水平。n 个 9 表示在系统1年时间的使用过程中，系统可以正常使用时间与总时间（1年）之比，通过下面的计算来感受下 n 个 9 在不同级别的可靠性差异。

) t4 S8 z# A! i' u1 x' S4个9：

(1-99.99%)*365*24=0.876小时=52.6分钟，表示该系统在连续运行1年时间里最多可能的业务中断时间是52.6分钟。
; L3 Q& w8 n8 _  K
/ K4 ]# r, X& }' X2 j7 ^( B- ~5个9：
( h, E0 K7 X# V
(1-99.999%)*365*24*60=5.26分钟，表示该系统在连续运行1年时间里最多可能的业务中断时间是5.26分钟。
: k" k- m: M8 a& s/ T* D% ]
. z- I) n# e; {! e0 I

wushy

网卡与网线的单点问题。系统里面最容易物理损坏的就是网线。网卡绑定(NIC bonding)一个很简单很通用的办法。配置多个网卡。