可靠性测试技术

embnn

( Y0 a2 E" `8 ?3 X/ m+ T4 A, [
1 ~+ C; j+ b3 I6 Y6 X( Z一、Dependability & Security
(1)Attribute——可用性（Availability）、依赖性（Reliability）、安全性（Safety）、机密性（Confidentiality）、整体性、可维护性

(2)Threats——Faults、Error、Failures

(3)Means

2 d2 @" F$ i! x6 N6 S①　Fault Prevention

②　Fault Tolerance
% s/ ^) @1 |3 `/ M/ r1 B! g
( X) ]/ W8 V" f③　Fault Remove

% x+ Q7 n0 S, S3 v: G6 |& g5 g) H④　Fault Forecasting
/ d- o) z! {% o/ R# L
5 Q" x8 C) G4 |: l二、状态改变
3 E, l, U8 l4 @0 ~4 X                        Activation              Propagation            Causation

% j4 b0 \! z; E.......——Fault——————Errors——————Failures——————Fault.......

三、单点故障和多点故障
1、单点故障（single point of failure）
4 H( u1 m/ j& i6 ^  w（1）概念
4 B* d$ S- y5 @, z+ E! u从英文字面上可以看到是单个点发生的故障，通常应用于计算机系统及网络。实际指的是单个点发生故障的时候会波及到整个系统或者网络，从而导致整个系统或者网络的瘫痪。这也是在设计IT基础设施时应避免的。

1 E" r$ y7 j# f大脑对与人来说，就是一个单点，大脑损坏，人也完蛋；手是不是单点? 一只没了，另一只还能日常生活，从这个角度来说，不是单点。消除单点的最常见的做法：增加冗余。比如，人有两只手。其次，层次化。当然，分层的目的是便于隔离问题。电影 《2012》 中的这个问题，不知道谁是总架构师，看起来，隔离做得不太够

% {( P, X6 }7 {% ?# s( L2 V7 i（2）消除单点故障方法
& f( R! u% T, U6 `8 I5 F8 G! _大体可以从以下几个方面来消除单点故障：
" [/ H: d9 n: f; i, x7 b
1 X! o- p5 Q. r7 Q0 A一个网站，从基础的硬件层，到操作系统层，到数据库层，到应用程序层，再到网络层，都有可能产生单点故障。如果要有效地消除单点故障，最重要的一点是设计的时候要尽量避免引入单点，随着架构的变化，定期审查系统潜在的单点也是有必要的。
9 K& L8 x6 W8 s! C* Q0 h7 L, O. |
①　增加硬盘，做镜像。让出错的概率降低

②　网卡与网线的单点问题。系统里面最容易物理损坏的就是网线。网卡绑定(NIC bonding)一个很简单很通用的办法。配置多个网卡。
6 d  F8 X9 I1 |/ T" Y
③　SSH 服务器和Telnet 服务器共存。毕竟 SSH 和 Telnet 都不是百分之百靠谱的事。

④　IDC 机房的单点。由于中国特色的“南北互通”，所以选择IDC机房的时候，一定要有冗余。

⑤　靠谱的DNS解析。

（3）简单单点故障架构
0 Q8 h: a) s6 k; [6 T/ T8 E

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

2 F; h4 g, Y6 u! ?5 q8 z% u3 `

+ A/ l: s  a5 S8 w( s5 J+ o0 C$ L3 {2、多点故障
5 J9 ~" f5 m- y. Z: `' s8 \" _多个单点故障同时发生或者依次发生。
" `. ^; z( M# Q% O! l6 s7 V+ {& p$ {

5 a7 E' D* ~# C7 i& V0 y
; \/ P- O0 y  Y- Z四、存储高可用
存储高可用解决方案采用存储设备与管理设备冗余架构，任何设备出现设备故障。都不会影响整个存储系统的正常适用。故障切换完全自动完成，保证业务系统的连续性。


  }( m! q) x8 }# r7 I8 J* m+ o
2 a6 u) h, I4 v3 @  x五、故障注入
产品代码：故障处理代码——产品功能代码
" \2 b! G  O) D* Y: `
& r$ g" L- c, Q6 P! x! DChaos Monkey

, g/ K# g& x: E; J; c$ ^1 [Linux Fault-Injection
4 w4 p% f* T8 s5 Z
0 o# A0 w8 k/ E- @. @0 ]将故障注入内置于产品是最有效的做法，使得产品具有可测性

" X! s4 w& c4 `5 j: O8 ]; O+ l6 x

六、测试实战
未知故障、已知场景（压力、稳定性、流控测试）
/ G% P. c+ x1 w: d& U已知故障、已知场景（故障注入）
已知故障、未知场景（故障注入）
- j4 f( x! Q& M; P" y" ^! a; }未知故障、未知场景（可靠性预计于建模）
1、故障模式库——为可靠性测试提供测试输入，定义了测试范围

8 P  {& ^9 Q/ v4 I/ ?2、可靠性测试评估基线

8 a% o" U3 w- Z* H3、可靠性测试指导书
  F: s; d2 I5 F) |: W
4、评估产品的可靠性能力
8 W2 j$ V, p; n4 H2 T$ R
5、长稳测试
: P; Z$ G* y. m" e


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

' a4 `" q" T( W5 Q' A7 m& v, H! j对电子产品而言，产品宣传经常用可用度 n 个 9 来描述产品可靠性水平。n 个 9 表示在系统1年时间的使用过程中，系统可以正常使用时间与总时间（1年）之比，通过下面的计算来感受下 n 个 9 在不同级别的可靠性差异。

4个9：
% A* n3 X' H/ D
(1-99.99%)*365*24=0.876小时=52.6分钟，表示该系统在连续运行1年时间里最多可能的业务中断时间是52.6分钟。
, C  D9 h; M; N% j
4 Z8 G6 M& d* ^3 l- O- c( N2 y5个9：
8 t+ C" ?8 W7 @# \+ h7 ~: `
7 B& f1 X, p* j, ?8 T# s(1-99.999%)*365*24*60=5.26分钟，表示该系统在连续运行1年时间里最多可能的业务中断时间是5.26分钟。
* h" T2 X5 w1 V6 M, ]9 q3 S3 n3 S* B
& c( l# D6 [! M& D- |  v( T
& A! O2 U$ z3 E/ g+ Q" D3 F

dull

从英文字面上可以看到是单个点发生的故障，通常应用于计算机系统及网络。实际指的是单个点发生故障的时候会波及到整个系统或者网络，从而导致整个系统或者网络的瘫痪。这也是在设计IT基础设施时应避免的。

bow

大脑对与人来说，就是一个单点，大脑损坏，人也完蛋；手是不是单点? 一只没了，另一只还能日常生活，从这个角度来说，不是单点。消除单点的最常见的做法：增加冗余。比如，人有两只手。其次，层次化。当然，分层的目的是便于隔离问题。电影 《2012》 中的这个问题，不知道谁是总架构师，看起来，隔离做得不太够。