最新IT圈最火的支付宝与携程，注定要将蓝翔神技与运维逆袭载入史册。无论故障的过程与真实原因如何，都足以让大家对整个生产系统的建设进行反思并加以检讨。
多年以来各设备厂商，解决方案都在强调自身系统可用有多高，可用达到n个9。而这些n个9的SLA承诺通常是在使用统计学上的概念，甚至于在配置了双机或集群的状态下，计算可用性直接将故障率直接相乘，即（1-（1-99%）*（1-99%））=99.99%。这样的算法对于实际工作来说，其实是无意义的。
系统出故障好比中彩票，谈论百分比毫无意义。中了的人就是中了，100%；没中就是没中，0%。中奖的人不会把奖金分给没中奖的人，同理，出故障的系统不会因为系统中的设备众多而减少故障处理时间，或因平摊设备故障而减少故障时间。
系统n个9的高可用是外企在推销产品时的传统促销手段，即如国外的司法上流行的无罪推定论，强调的是产品的有效性。然而，任何人都不能保证建设系统后不出故障，我们向客户推荐高可用、容灾系统解决方案就是为了将故障损失降低到最低。
故此，我们在向客户推荐高可用，容灾系统解决方案的时候应当抛弃传统SLA的n个9的概念，直接用有罪推定论，直接告诉客户，当你的系统故障后恢复需要多长的时间，如：
1. 硬件故障后更换备件所需要的时间。包括故障诊断时间，备件到场时间，以及备件现场更换时间等（可以想象偏远地区客户多么悲催）；
2. 系统故障后恢复系统需要的时间。包括故障诊断时间，系统启动时间（虚拟机包括宿主机及虚拟机启动时间），双机切换时间，集群漂移时间，甚至于重新安装系统的时间等；
3. 应用故障后恢复应用需要的时间。包括故障诊断时间，应用启动时间，数据完整性校验时间，相关系统恢复时间等；
4. 不可抗力故障后恢复的时间。包括自然灾害，楼宇基础设施故障（风火水电），相关供应商故障（万能的挖掘机）等；
5. 人为故障后恢复的时间。包括黑客入侵，内部破坏，操作失误等引起的故障，甚至与法律法规类的伟大的墙等。
以上只是系统运行过程中可能遇到的故障大致分类，具体内容还需要大家进一步发掘。有人可能要说我是不是太悲观了？我说我是个乐观主义者，最大灾难不过一地的楼倒了，数据没了，只要世界还在，一切数据都可以重来。
“Tomorrowis another day.”
让我们抛弃n个9的SLA观念，用系统有罪推断论来建议客户吧，只有客户真正理解了故障所能引起的灾难性后果，才能珍视IT人员的价值，才能在系统建设之初就能选择更加合理的方案。