可靠性测试技术

rural

一、Dependability & Security
(1)Attribute——可用性（Availability）、依赖性（Reliability）、安全性（Safety）、机密性（Confidentiality）、整体性、可维护性
( b& `% h/ y4 Z$ j4 N& R, u# V' N
9 _. Y3 `% M5 B. R3 u) M  [9 A0 F(2)Threats——Faults、Error、Failures
4 w9 N5 l. }8 }( g- A9 C" C
2 ?- H+ ^& o. c( P(3)Means
. s5 U/ |: W# K4 f: j' f/ T+ F
①　Fault Prevention
1 t1 v  N" e) g
②　Fault Tolerance

9 c0 s- w0 L/ Y: m' \' ?2 y③　Fault Remove
7 w# C' e5 u7 N' x0 x
④　Fault Forecasting
3 O& p+ I1 n. A, Y! c9 M! t, D
二、状态改变
                        Activation              Propagation            Causation
& J1 J- y+ o; |+ w9 i: c: o; b
.......——Fault——————Errors——————Failures——————Fault.......
/ j6 m6 V  N6 `6 s) A0 k  @
, n' y9 W' |) S/ d三、单点故障和多点故障
! i) f/ n, d' T1 e+ l! N1、单点故障（single point of failure）
. Y8 w. {- o6 w6 d; D( t9 Z（1）概念
1 s& a4 m8 v, N: `8 C- s从英文字面上可以看到是单个点发生的故障，通常应用于计算机系统及网络。实际指的是单个点发生故障的时候会波及到整个系统或者网络，从而导致整个系统或者网络的瘫痪。这也是在设计IT基础设施时应避免的。

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

' p# a5 t9 c; A; N/ n（2）消除单点故障方法
7 Q2 c1 U1 l* H+ \3 p, H- P" m大体可以从以下几个方面来消除单点故障：

5 H% }8 ~$ C  g' w一个网站，从基础的硬件层，到操作系统层，到数据库层，到应用程序层，再到网络层，都有可能产生单点故障。如果要有效地消除单点故障，最重要的一点是设计的时候要尽量避免引入单点，随着架构的变化，定期审查系统潜在的单点也是有必要的。

/ K- o2 K: _0 @( q' a7 I①　增加硬盘，做镜像。让出错的概率降低
4 @+ B/ c5 u5 v, @7 @" X
②　网卡与网线的单点问题。系统里面最容易物理损坏的就是网线。网卡绑定(NIC bonding)一个很简单很通用的办法。配置多个网卡。
% O) f. H" o7 X% |2 D0 V8 d
! e/ H. V7 w. D. b( k1 N③　SSH 服务器和Telnet 服务器共存。毕竟 SSH 和 Telnet 都不是百分之百靠谱的事。

7 G  |3 w( w) @& I④　IDC 机房的单点。由于中国特色的“南北互通”，所以选择IDC机房的时候，一定要有冗余。

. D# Y+ r: m4 i: l6 z! K9 O⑤　靠谱的DNS解析。
. @7 m: N; ?" n: i; v* ~1 y. B
（3）简单单点故障架构
% `, ]; S/ I3 a

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

4 i9 D5 U: I0 q7 l
- ]7 G+ Z7 K+ Y5 T/ U
2、多点故障
多个单点故障同时发生或者依次发生。
) e  f# ]3 Z( W- z1 a( u


8 X9 ^' Q+ j, Z! {5 D$ p四、存储高可用
- e0 ], z, ^* W1 j9 E存储高可用解决方案采用存储设备与管理设备冗余架构，任何设备出现设备故障。都不会影响整个存储系统的正常适用。故障切换完全自动完成，保证业务系统的连续性。
" `2 ~- p$ R# o  P" q, H


  |& Z# p( u8 J& l. P6 r/ U五、故障注入
产品代码：故障处理代码——产品功能代码
% w; M5 r0 A/ z( G4 |8 m
Chaos Monkey
0 B) R5 M9 B6 s3 `4 m
+ [' H* x0 ^) P" t1 vLinux Fault-Injection

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



0 c3 @( I: _9 Q六、测试实战
未知故障、已知场景（压力、稳定性、流控测试）
" M1 W: M3 @  y; N5 Q5 S& S已知故障、已知场景（故障注入）
0 \7 w  }9 H" ~9 U8 B7 x已知故障、未知场景（故障注入）
& b2 s* x( K0 X7 G' w未知故障、未知场景（可靠性预计于建模）


1、故障模式库——为可靠性测试提供测试输入，定义了测试范围
; H9 ]% @2 Y: }8 m: v3 @( N
2、可靠性测试评估基线
/ a8 u9 A$ H3 D
+ |( k) b- P+ U# X& R3、可靠性测试指导书
% k2 I+ T8 q& B6 R4 I
. A; ^4 j0 u( E) ]% W: @4、评估产品的可靠性能力
7 \8 k& L8 z' y
; f( `; s- D8 G  _5、长稳测试


, J$ T4 d: [2 [; x0 |* K$ B
七、“几个9”
产品的可靠性是指：产品在规定的条件下、在规定的时间内完成规定的功能的能力。
; v: [- _2 [! @* W  d2 a; b
3 g; J7 G! Y/ t% |- L对电子产品而言，产品宣传经常用可用度 n 个 9 来描述产品可靠性水平。n 个 9 表示在系统1年时间的使用过程中，系统可以正常使用时间与总时间（1年）之比，通过下面的计算来感受下 n 个 9 在不同级别的可靠性差异。
! [4 N% ^; I8 {& O$ Y9 H
; p4 }- h8 y: r2 p. F1 t. r. ?4个9：
+ _( S1 a1 F* g6 o# z6 L5 ~/ m4 }* g
(1-99.99%)*365*24=0.876小时=52.6分钟，表示该系统在连续运行1年时间里最多可能的业务中断时间是52.6分钟。
  v" m' g$ U1 P( o, M- H
3 X6 z# r' D' H$ a0 ^5个9：

(1-99.999%)*365*24*60=5.26分钟，表示该系统在连续运行1年时间里最多可能的业务中断时间是5.26分钟。

wushy

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