一、Dependability & Security
(1)Attribute——可用性(Availability)、依赖性(Reliability)、安全性(Safety)、机密性(Confidentiality)、整体性、可维护性
(2)Threats——Faults、Error、Failures
(3)Means
① Fault Prevention
② Fault Tolerance
③ Fault Remove
④ Fault Forecasting
二、状态改变
Activation Propagation Causation
.......——Fault——————Errors——————Failures——————Fault.......
三、单点故障和多点故障
1、单点故障(single point of failure)
(1)概念
从英文字面上可以看到是单个点发生的故障,通常应用于计算机系统及网络。实际指的是单个点发生故障的时候会波及到整个系统或者网络,从而导致整个系统或者网络的瘫痪。这也是在设计IT基础设施时应避免的。
大脑对与人来说,就是一个单点,大脑损坏,人也完蛋;手是不是单点? 一只没了,另一只还能日常生活,从这个角度来说,不是单点。消除单点的最常见的做法:增加冗余。比如,人有两只手。其次,层次化。当然,分层的目的是便于隔离问题。电影 《2012》 中的这个问题,不知道谁是总架构师,看起来,隔离做得不太够 :)
(2)消除单点故障方法
大体可以从以下几个方面来消除单点故障:
一个网站,从基础的硬件层,到操作系统层,到数据库层,到应用程序层,再到网络层,都有可能产生单点故障。如果要有效地消除单点故障,最重要的一点是设计的时候要尽量避免引入单点,随着架构的变化,定期审查系统潜在的单点也是有必要的。
① 增加硬盘,做镜像。让出错的概率降低
② 网卡与网线的单点问题。系统里面最容易物理损坏的就是网线。网卡绑定(NIC bonding)一个很简单很通用的办法。配置多个网卡。
③ SSH 服务器和Telnet 服务器共存。毕竟 SSH 和 Telnet 都不是百分之百靠谱的事。
④ IDC 机房的单点。由于中国特色的“南北互通”,所以选择IDC机房的时候,一定要有冗余。
⑤ 靠谱的DNS解析。
(3)简单单点故障架构
若干台云服务器通过负载均衡对外提供服务,在另一台云服务器上安装了MySQL作为应用数据库,为了提高性能,在服务器和数据库之间搭一个Redis缓存服务器。在这样的架构中,缓存服务器和数据库都存在单点隐患,可以考虑主从备份的设计。缓存服务器可以利用Redis对主从的支持特性设计成Master-Slave部署,数据库是在ECS上安装MySQL,虽然也可以在另一台服务器上安装MySQL,配置主从,但是可靠性仍然依赖于云服务器,故建议改用RDS。RDS是内在支持主从的阿里云关系型数据库产品,用户无需操心数据同步、主备切换等细节,使用更为方便。优化后的架构如下图所示:
2、多点故障
多个单点故障同时发生或者依次发生。
四、存储高可用
存储高可用解决方案采用存储设备与管理设备冗余架构,任何设备出现设备故障。都不会影响整个存储系统的正常适用。故障切换完全自动完成,保证业务系统的连续性。
五、故障注入
产品代码:故障处理代码——产品功能代码
Chaos Monkey
Linux Fault-Injection
将故障注入内置于产品是最有效的做法,使得产品具有可测性
六、测试实战
- 未知故障、已知场景(压力、稳定性、流控测试)
- 已知故障、已知场景(故障注入)
- 已知故障、未知场景(故障注入)
- 未知故障、未知场景(可靠性预计于建模)
1、故障模式库——为可靠性测试提供测试输入,定义了测试范围
2、可靠性测试评估基线
3、可靠性测试指导书
4、评估产品的可靠性能力
5、长稳测试
七、“几个9”
产品的可靠性是指:产品在规定的条件下、在规定的时间内完成规定的功能的能力。
对电子产品而言,产品宣传经常用可用度 n 个 9 来描述产品可靠性水平。n 个 9 表示在系统1年时间的使用过程中,系统可以正常使用时间与总时间(1年)之比,通过下面的计算来感受下 n 个 9 在不同级别的可靠性差异。
4个9:
(1-99.99%)*365*24=0.876小时=52.6分钟,表示该系统在连续运行1年时间里最多可能的业务中断时间是52.6分钟。
5个9:
(1-99.999%)*365*24*60=5.26分钟,表示该系统在连续运行1年时间里最多可能的业务中断时间是5.26分钟。
注:部分图片和内容来自:点击打开链接