可靠性测试技术

rural

一、Dependability & Security
! e2 I. c. e6 q6 e+ X! B# T0 o(1)Attribute——可用性（Availability）、依赖性（Reliability）、安全性（Safety）、机密性（Confidentiality）、整体性、可维护性

(2)Threats——Faults、Error、Failures
8 s" c0 H9 s; i1 M8 f
: U% ~9 G) F  x: ^2 Y(3)Means

9 f% \) |  t1 p, h" b/ v2 x! s①　Fault Prevention

- ]- y6 w. f; H②　Fault Tolerance
( l* i  q: M: ]! E' Y5 c: ^
③　Fault Remove

3 _- Q" Q& }* L! B④　Fault Forecasting
5 z2 ]9 x: f. p
& B& p* [( a* O7 o  ?二、状态改变
                        Activation              Propagation            Causation
1 x8 L% e3 x4 W
" d  k* g; Y3 S; x0 E5 r.......——Fault——————Errors——————Failures——————Fault.......
) U2 P6 J0 O, i4 c' b4 T( \" C# h
三、单点故障和多点故障
# X4 u1 f6 W# t1、单点故障（single point of failure）
' ?1 E! _8 j( ^' f" X（1）概念
从英文字面上可以看到是单个点发生的故障，通常应用于计算机系统及网络。实际指的是单个点发生故障的时候会波及到整个系统或者网络，从而导致整个系统或者网络的瘫痪。这也是在设计IT基础设施时应避免的。
% i. F4 u7 b  d9 M7 j5 ~# ?4 N
大脑对与人来说，就是一个单点，大脑损坏，人也完蛋；手是不是单点? 一只没了，另一只还能日常生活，从这个角度来说，不是单点。消除单点的最常见的做法：增加冗余。比如，人有两只手。其次，层次化。当然，分层的目的是便于隔离问题。电影 《2012》 中的这个问题，不知道谁是总架构师，看起来，隔离做得不太够

2 {( e8 l9 g- D7 t（2）消除单点故障方法
/ P9 n& y% C/ p; K$ y: {大体可以从以下几个方面来消除单点故障：

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

①　增加硬盘，做镜像。让出错的概率降低
/ ?, y  R+ c' n, W# e
: \4 N; F" n. |$ V1 v! k( R②　网卡与网线的单点问题。系统里面最容易物理损坏的就是网线。网卡绑定(NIC bonding)一个很简单很通用的办法。配置多个网卡。

2 w( }& W) Z  K! X0 o③　SSH 服务器和Telnet 服务器共存。毕竟 SSH 和 Telnet 都不是百分之百靠谱的事。

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

⑤　靠谱的DNS解析。
: p) _6 L4 L* L+ W
6 K6 u# B5 M. Z# i（3）简单单点故障架构
- [/ `7 L/ A- F2 i

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


; `# G. H2 `0 j4 {: j2、多点故障
多个单点故障同时发生或者依次发生。



* d! ]& l/ p2 \( p3 J1 g四、存储高可用
存储高可用解决方案采用存储设备与管理设备冗余架构，任何设备出现设备故障。都不会影响整个存储系统的正常适用。故障切换完全自动完成，保证业务系统的连续性。



五、故障注入
8 c. d% O& E$ Q1 L1 A+ R0 M产品代码：故障处理代码——产品功能代码

4 j3 T) C0 _2 L& ?Chaos Monkey

% p& Y. c4 ~* z3 k/ }Linux Fault-Injection
4 r, W' ^$ \# o* q6 V+ I3 G; F
将故障注入内置于产品是最有效的做法，使得产品具有可测性

4 K6 k; U+ B- b2 t6 W

& D2 U4 K% e' Q六、测试实战
; ~( O( Z9 F- D- G) C6 R; I未知故障、已知场景（压力、稳定性、流控测试）
! ?* P& }. W) G) l; |1 m/ |' ^已知故障、已知场景（故障注入）
6 S1 V, `  E! H! h已知故障、未知场景（故障注入）
1 }0 q: m: [5 Z8 i7 q8 A  |1 ?未知故障、未知场景（可靠性预计于建模）

* ?/ r5 j" K3 n5 C  [. I
0 z+ V% T, x; t) h1、故障模式库——为可靠性测试提供测试输入，定义了测试范围
, }. @2 @. c2 }* s& e, z/ c
2 ]) o& [3 }$ B1 D" f2、可靠性测试评估基线

$ n  ?  m4 j8 f  y3、可靠性测试指导书

( L! l# o! V& O  I. n' S4、评估产品的可靠性能力
9 r/ i  x0 r4 O7 l: [7 I: p, Z
: A. ^9 x( Y; Q8 Q/ v5、长稳测试

/ H* l0 P1 U" m+ c+ V3 |/ @

  `) v. c# p+ f; B: V6 s# n七、“几个9”
4 |- d1 K, z% a产品的可靠性是指：产品在规定的条件下、在规定的时间内完成规定的功能的能力。
" @2 G0 a0 \0 `1 p- ~
对电子产品而言，产品宣传经常用可用度 n 个 9 来描述产品可靠性水平。n 个 9 表示在系统1年时间的使用过程中，系统可以正常使用时间与总时间（1年）之比，通过下面的计算来感受下 n 个 9 在不同级别的可靠性差异。
; j3 S. ~3 j3 H2 O  @* G' D! e
7 E( W6 C- G# e! f. d2 c4个9：
! \& _& J& ~, t8 r( n4 \
(1-99.99%)*365*24=0.876小时=52.6分钟，表示该系统在连续运行1年时间里最多可能的业务中断时间是52.6分钟。
: h6 x9 S, C9 S( L
# n& |% ^3 o" p' v  x5个9：

' \2 Z4 y- }- r# U# ~1 ?5 L(1-99.999%)*365*24*60=5.26分钟，表示该系统在连续运行1年时间里最多可能的业务中断时间是5.26分钟。
8 D& d& S$ ~1 |0 ?! W
* M1 p. x, V0 g- {
& S. R+ P% n2 q

wushy

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