可靠性测试技术

rural

一、Dependability & Security
(1)Attribute——可用性（Availability）、依赖性（Reliability）、安全性（Safety）、机密性（Confidentiality）、整体性、可维护性
/ V9 T7 i/ s6 x: ?
(2)Threats——Faults、Error、Failures

(3)Means
0 ]/ T2 f! N# I$ u% n3 U/ c) s# B
①　Fault Prevention
7 b+ T+ W" S, W% N
5 ?2 I* r8 v  }: Z# _3 f( V$ |5 b②　Fault Tolerance

6 v2 V' D. i( c0 J- v4 V# Y③　Fault Remove

④　Fault Forecasting
# z5 m: P- W3 E
二、状态改变
$ i' n* S6 p) Y& r8 g2 ]( ]- J                        Activation              Propagation            Causation

2 k2 n6 |* w: `+ }3 N.......——Fault——————Errors——————Failures——————Fault.......
! Q. \4 Z( u0 o- G; Q
三、单点故障和多点故障
" s! Y7 S# [$ T4 W) F9 K  X$ ^1、单点故障（single point of failure）
7 j: p6 E7 b+ O0 @3 H! u5 H. V（1）概念
从英文字面上可以看到是单个点发生的故障，通常应用于计算机系统及网络。实际指的是单个点发生故障的时候会波及到整个系统或者网络，从而导致整个系统或者网络的瘫痪。这也是在设计IT基础设施时应避免的。
% ]- Y) w; X; n; Y0 R$ c
& M. }2 J, {6 G) w& p大脑对与人来说，就是一个单点，大脑损坏，人也完蛋；手是不是单点? 一只没了，另一只还能日常生活，从这个角度来说，不是单点。消除单点的最常见的做法：增加冗余。比如，人有两只手。其次，层次化。当然，分层的目的是便于隔离问题。电影 《2012》 中的这个问题，不知道谁是总架构师，看起来，隔离做得不太够

$ Z& D" [' O/ u2 n7 t4 J+ s: o（2）消除单点故障方法
8 `. m0 H9 o5 |+ n7 c; S( n大体可以从以下几个方面来消除单点故障：
( ^# e' b! \6 B: G; R' f
一个网站，从基础的硬件层，到操作系统层，到数据库层，到应用程序层，再到网络层，都有可能产生单点故障。如果要有效地消除单点故障，最重要的一点是设计的时候要尽量避免引入单点，随着架构的变化，定期审查系统潜在的单点也是有必要的。

' Y4 Z3 j7 F% g. ~% ?①　增加硬盘，做镜像。让出错的概率降低

( z- x6 |1 r( `# P# v- d& j②　网卡与网线的单点问题。系统里面最容易物理损坏的就是网线。网卡绑定(NIC bonding)一个很简单很通用的办法。配置多个网卡。

' [. x1 J5 s* c" P! m+ V: u; R③　SSH 服务器和Telnet 服务器共存。毕竟 SSH 和 Telnet 都不是百分之百靠谱的事。

1 ^8 ]7 d) M# k& ~/ {, U④　IDC 机房的单点。由于中国特色的“南北互通”，所以选择IDC机房的时候，一定要有冗余。

⑤　靠谱的DNS解析。

（3）简单单点故障架构


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


: {5 I# s) P0 T4 {
1 f' s9 C6 }/ \/ s. B2、多点故障
: I  P) |- i1 ?# r6 R/ _多个单点故障同时发生或者依次发生。
3 c, S5 D) `6 ~7 {7 A

- |) I- E6 j! ]7 p
% F  Y0 N: z' U0 ?2 ]7 Y四、存储高可用
8 H$ w' a& h/ i* s8 \存储高可用解决方案采用存储设备与管理设备冗余架构，任何设备出现设备故障。都不会影响整个存储系统的正常适用。故障切换完全自动完成，保证业务系统的连续性。


) D8 s1 X- e) g6 y# j# g0 m
五、故障注入
+ n! a% i& [, u- \3 k: H' [% k' A产品代码：故障处理代码——产品功能代码
- f, |; p- X! U% I
7 D3 B! A* _8 r- }# qChaos Monkey
) l$ Y9 o. n/ C6 G0 E, |4 w
Linux Fault-Injection
: z- Y$ @% [1 P* b
将故障注入内置于产品是最有效的做法，使得产品具有可测性
* V1 ^( v% J9 J
9 f, A: d( L% r3 _8 V/ Z

六、测试实战
未知故障、已知场景（压力、稳定性、流控测试）
- a7 j8 j+ }6 O  L已知故障、已知场景（故障注入）
已知故障、未知场景（故障注入）
: }# M0 L) _6 U" k" r未知故障、未知场景（可靠性预计于建模）
8 d) {7 d4 X, C
( b# n8 Z. W2 j8 |& D& h; }
+ \0 n" y! r) J" K( P1 n" l! o1、故障模式库——为可靠性测试提供测试输入，定义了测试范围
7 F+ I* e7 T6 U2 Q6 ?" D. L) w! M
2、可靠性测试评估基线

3、可靠性测试指导书

4、评估产品的可靠性能力
1 Y) _" Q1 s/ v2 {" N
5、长稳测试


6 D4 p  U" Q( k- [9 I
七、“几个9”
# s+ F% ?: e! E9 P( N8 q产品的可靠性是指：产品在规定的条件下、在规定的时间内完成规定的功能的能力。
* b1 z/ q) U; c0 f  i) a- h
对电子产品而言，产品宣传经常用可用度 n 个 9 来描述产品可靠性水平。n 个 9 表示在系统1年时间的使用过程中，系统可以正常使用时间与总时间（1年）之比，通过下面的计算来感受下 n 个 9 在不同级别的可靠性差异。

% g/ D! y) i8 T, {5 f4 \# \4个9：
9 I7 K. S5 }) w- K6 |3 s" |9 H4 n
" R% D+ ^6 k% o: |5 D& E0 e$ G4 y(1-99.99%)*365*24=0.876小时=52.6分钟，表示该系统在连续运行1年时间里最多可能的业务中断时间是52.6分钟。

! V# z/ v' K, S) t& r/ U5个9：
# w( s1 ?) n2 {% @* O3 N1 r  o
% m' ?3 E) u, ?(1-99.999%)*365*24*60=5.26分钟，表示该系统在连续运行1年时间里最多可能的业务中断时间是5.26分钟。
- {2 y) y6 N; d. {$ v( C! o

wushy

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