CTO眼中的系统高可用

任何一个互联网公司的CTO对系统的稳定性都会非常重视，这关系到他的个人尊严（毕竟是首席技术官，虽然有时候他们对技术本身不太重视）以及是否可以长期在公司待下去，如果系统时不时就宕机不可用，尤其是做2C业务的公司，那后果不堪设想，下面我就以10几年的IT从业经历，抛砖引玉，聊一聊系统高可用的话题。

计算机系统的可用性定义为：A  = MTBF/(MTBF+MTTR) * 100%，MTTR (Mean Time To Repair，平均修复时间)，MTBF (Mean Time Between Failure，平均故障间隔)，MTTF (Mean Time To Failure，平均无故障时间)，MTBF = MTTF + MTTR，由于MTTR远远小于MTBF，所以一般情况下认为MTBF = MTTF。

7*24小时无间断服务示意图：

99.9%  = 0.1% * 365 * 24 * 60 = 525.6min，99.99% =  0.01% * 365 * 24 * 60 = 52.56min，2个9是基本可用，3个9是较高可用，4个9是具有自动恢复能力的高可用，5个9是极高可用性，假设我们需要达到 4 个 9 的可用性（99.99%），全年的不可用时间52.56分钟，每个月的不可用时间 4.38 分钟，大的公有云厂商对外提供的服务等级协议（Service-Level Agreement, SLA）可达到4个9，严格按照公式计算，真正做到4个9的都很少 ，Twitter 据说也只有2个9。

投入和可用性的关系：

从上图可以看出，随着可用性的提高，投入所产出的可用性边际效益越来越小。一般公司对外宣称的高可用其实只是商业策略，很多时候高可用并不是公司主要考虑的因素，真正促使它提供高可用服务的还是背后的直接经济利益和造成事故时需要赔偿的名誉和金钱损失，依稀记得2015年5月28日携程网瘫痪事件，按照携程一季度财报公布的数据，携程宕机的损失为平均每小时106.48万美元。

墨菲定律其实已经是一个几乎所有地球人都知道的定律了，它在大多数的时候都会被解释成凡是可能出错的事情就一定会出错，任何一个线上的服务能够正常运行都是极其偶然的，只要时间拉的足够长，我们就没有办法保证任何服务100% 的可用性，虽然高可用只是一种商业策略，但是我们还是可以采用一些手段来提升可用性，冗余复制，灾备切换是高可用的不二法门，高可用性是由多个层次组件共同决定的，一个应用的最终可用性计算如下：A(x) = A_IDC(x) * A_ISP(x) * A_ROUTER(x) * A_Hardware(x) * A_APP(x) * A_DB(x) * A_Dependency(x)...

网络：多DNS、多IDC、多线、多CDN、冗余路由器、双链路、双网卡...

负载均衡：LVS集群、HAProxy集群、Nginx upstream...

应用系统：master/slave、master/master

数据库、缓存、存储：master/slave

磁盘：RAID-n

电源：双电源

风扇：...

从可用性度量公式 A  = MTBF / (MTBF+MTTR)，可以看出，提高可用性无非两个途径：

1、提高 MTBF ，少出故障

2、减少 MTTR ，快速修复故障

以在京东商城一线核心研发的工作经验和后来去电商创业公司做技术委员会主席的经验，总结如下，欢迎拍砖。

推荐阅读：

技术（二）

技术（五）

技术（六）