记coolshell.cn博文《AWS 的 S3 故障回顾和思考》

原文链接：http://coolshell.cn/articles/17737.html

此文个人感触较深的关键点：

这个事件，再次映证了我在《关于高可用的系统》中提到的观点：一个系统的高可用的因素很多，不仅仅只是系统架构，更重要的是——高可用运维。

在《关于高可用性的系统》中，有一段关于高可用性对比的表格：

上面那些都不是本文的重点，本文的重点现在开始，如何测量系统的高可用性。当然是SLA，全称Service Level Agrement，也就是有几个9的高可用性。

工业界有两种方法来测量SLA，

一个是故障发生到恢复的时间

另一个是两次故障间的时间

但大多数都采用第一种方法，也就是故障发生到恢复的时间，也就是服务不可用的时间，如下表所示：

系统可用性%              宕机时间/年          宕机时间/月          宕机时间/周          宕机时间/天

90% (1个9)              36.5 天            72 小时          16.8 小时            2.4 小时

99% (2个9)              3.65 天            7.20 小时        1.68 小时            14.4 分

99.9% (3个9)            8.76 小时          43.8 分          10.1 分钟            1.44 分

99.99% (4个9)            52.56 分            4.38 分          1.01 分钟            8.66 秒

99.999% (5个9)          5.26 分            25.9 秒          6.05 秒              0.87 秒

比如，99.999%的可用性，一年只能有5分半钟的服务不可用。感觉很难做到吧。

就算是3个9的可用性，一个月的宕机时间也只有40多分钟，看看那些设计和编码不认真的团队，把所有的期望寄托在人肉处理故障的运维团队， 一个故障就能处理1个多小时甚至2-3个小时，连个自动化的工具都没有，还好意思在官网上声明自己的SLA是3个9或是5个9，这不是欺骗大众吗？。