可靠性测试技术

rural

一、Dependability & Security
7 X- d3 K1 k' C4 E(1)Attribute——可用性（Availability）、依赖性（Reliability）、安全性（Safety）、机密性（Confidentiality）、整体性、可维护性

" ^8 O4 H% B9 e! t% r8 L(2)Threats——Faults、Error、Failures

(3)Means
3 W" X. x1 \" ~$ `1 G8 K9 |2 S! j. Y
/ O  B+ Z2 K; y" M9 o5 ^0 O( E6 z①　Fault Prevention

②　Fault Tolerance

③　Fault Remove
+ x6 _5 W2 D% B5 [+ `
④　Fault Forecasting
, }. d# S/ V' t, s  G4 j
二、状态改变
1 z9 u9 A$ Y, ^( x1 p                        Activation              Propagation            Causation
6 t, a) c/ E2 u  {) R0 }
4 f9 P8 e" b5 M* [+ E.......——Fault——————Errors——————Failures——————Fault.......

三、单点故障和多点故障
1、单点故障（single point of failure）
（1）概念
- A2 H5 v  M* v) B9 |; C: q从英文字面上可以看到是单个点发生的故障，通常应用于计算机系统及网络。实际指的是单个点发生故障的时候会波及到整个系统或者网络，从而导致整个系统或者网络的瘫痪。这也是在设计IT基础设施时应避免的。
2 w* O0 r9 F% N: C3 b
; n* A( n3 j0 b- g: u: T大脑对与人来说，就是一个单点，大脑损坏，人也完蛋；手是不是单点? 一只没了，另一只还能日常生活，从这个角度来说，不是单点。消除单点的最常见的做法：增加冗余。比如，人有两只手。其次，层次化。当然，分层的目的是便于隔离问题。电影 《2012》 中的这个问题，不知道谁是总架构师，看起来，隔离做得不太够
8 @8 \; N, K! n/ z; D
8 W: e. Q$ B- O（2）消除单点故障方法
) A$ d( F; Y# a4 E( T. {+ }, M大体可以从以下几个方面来消除单点故障：

1 O  t( o/ z8 V( [) o一个网站，从基础的硬件层，到操作系统层，到数据库层，到应用程序层，再到网络层，都有可能产生单点故障。如果要有效地消除单点故障，最重要的一点是设计的时候要尽量避免引入单点，随着架构的变化，定期审查系统潜在的单点也是有必要的。
4 k. E" x" l' \$ v3 o' q
①　增加硬盘，做镜像。让出错的概率降低
2 l4 E7 s8 t! o2 H
+ E2 Z& k6 d! I8 u8 S②　网卡与网线的单点问题。系统里面最容易物理损坏的就是网线。网卡绑定(NIC bonding)一个很简单很通用的办法。配置多个网卡。

③　SSH 服务器和Telnet 服务器共存。毕竟 SSH 和 Telnet 都不是百分之百靠谱的事。

) ?- C9 `; {2 W, G1 I④　IDC 机房的单点。由于中国特色的“南北互通”，所以选择IDC机房的时候，一定要有冗余。
- g- Y; _8 o9 f4 F5 h2 ~; V
⑤　靠谱的DNS解析。

0 M6 c+ l# M$ E, P! R( I（3）简单单点故障架构


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


' _9 Q$ a- |! E9 q, {; E
2、多点故障
多个单点故障同时发生或者依次发生。
2 q1 ?" g* Z3 p0 n

: W' G+ ~" b5 S$ y
四、存储高可用
存储高可用解决方案采用存储设备与管理设备冗余架构，任何设备出现设备故障。都不会影响整个存储系统的正常适用。故障切换完全自动完成，保证业务系统的连续性。



五、故障注入
产品代码：故障处理代码——产品功能代码

" k9 ]' \. v7 P2 D, ]Chaos Monkey
* D' I& m, b/ E/ G2 x
Linux Fault-Injection
& h/ R" Q) O$ L! ^! Y3 x! M/ s$ R
7 B" z' A: M: i4 J! i: m将故障注入内置于产品是最有效的做法，使得产品具有可测性


# w4 l0 n) o8 P! z" G7 V& l. q8 c( P# G
2 |! Z* B  f. y9 x3 z  s8 g六、测试实战
) {, u9 u/ f  o+ E( N未知故障、已知场景（压力、稳定性、流控测试）
& W( h7 ?- V1 N1 }, F% q已知故障、已知场景（故障注入）
已知故障、未知场景（故障注入）
未知故障、未知场景（可靠性预计于建模）
: U: D/ j: o. t7 S7 n) v( ^( q

6 H9 \2 }, M# {7 @, U; g1、故障模式库——为可靠性测试提供测试输入，定义了测试范围

! [( [% H0 ^! ]2 V6 B7 S9 L7 O2、可靠性测试评估基线

3、可靠性测试指导书
$ `. {& [0 z+ {
4、评估产品的可靠性能力
  V9 C& w$ x1 Z) z( B" ]' M
1 ~  @9 v+ o8 S3 e  j0 Y5 B2 X5、长稳测试
: w- o* M) M" d


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

; q+ N2 z! @" h* M, m2 Y& e. x对电子产品而言，产品宣传经常用可用度 n 个 9 来描述产品可靠性水平。n 个 9 表示在系统1年时间的使用过程中，系统可以正常使用时间与总时间（1年）之比，通过下面的计算来感受下 n 个 9 在不同级别的可靠性差异。
7 h6 |  S8 y0 G& e. G9 V% Y3 o! b, E
2 I$ k$ s$ }' S5 K3 H+ y! K3 R, P4个9：
4 J# [8 Y, ?/ b# C( t# G
(1-99.99%)*365*24=0.876小时=52.6分钟，表示该系统在连续运行1年时间里最多可能的业务中断时间是52.6分钟。
, j2 U; }$ j! V
3 H% a4 B! K5 f2 H1 V5个9：

* F$ V, S: {! m1 s& b(1-99.999%)*365*24*60=5.26分钟，表示该系统在连续运行1年时间里最多可能的业务中断时间是5.26分钟。

8 t; V0 k% `/ z! B, [
, d; H. x+ v) h4 P7 @- j" n8 h

wushy

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