最近互联网也是非常有意思，接二连三的发生故障，让我们一起先回顾一下。

2015年5月11号晚上21点左右开始，网易的网易新闻、云音乐、易信、有道云笔记等移动应用均无法正常刷新，网易名下的游戏也全线瘫痪。故障原因：骨干网络遭受攻击。

2015年5月27日下午，部分用户反映其支付宝出现网络故障，账号无法登录或支付。故障原因：光纤挖断。影响时长：4个小时

2015年5月28日上午11:09，携程官网及APP出现故障无法打开，到28日23:29全面恢复，整个过程耗费12个多小时。故障原因：误操作。影响时长：12个小时左右

2015年6月5日今日头条网首页和APP都无法访问，直接提示500错误。故障原因：不明影响时长：30分钟左右。

2015年6月15日12点30分知乎网无法打开，直接提示【服务器提出了一个问题】错误，在13点45分左右的时候，知乎页面恢复正常。故障原因：机房故障影响时长：60分钟左右

到底是怎么了，是什么让我们的互联网业务如此脆弱?真的是运营商老是在后面干坏事?还是我们的系统架构不给力?还是我们运维能力真的很弱?如果广义的去看这个，我还会把它归结成运维问题。不过对于以上的故障，从运维的角度来说，我依然会说官方结论不够专业，希望内部不是这样的哈。

1、网易说骨干网收到网络攻击影响业务，貌似那天好像也就网易业务受到影响?

2、光纤挖断影响四个小时，从这么核心的业务来说，第一原则一定是恢复业务，我想支付宝即使没做双活，肯定也会有一个可用的备份中心，为什么没切过去了?一定是内部出了乱子。不过阿里流弊的地方，负面的事情他可以变成正面，他们把"5.27"变成了技术保障日，大肆宣传。

3、携程事件，我之前写过一篇文章【携程事件：运维债务的深度分析和解决方案】，不详谈了。

4、今日头条，500内部错误，这条新闻可以让自己上头条，但也没有正式的给出解释。从500错误的恢复时间来说，有点长，500错误是十分好定位，我的怀疑是数据库的压力不够，导致后面的扩容变更，也只有数据库分库分表扩容时间需要这么长了。另外头条君的首页上直接给个500的错误，技术表述，十分的不友好，建议你服务降级啊，推个大众版的新闻，不做个性化推荐，这个可以做一个缓存就可以解决的。

5、知乎故障，直接说是机房故障，太简单了，但我觉得最大的可能应该是Tengine后端服务超时导致的，而非简单的一个机房故障引起。

在每一次故障发生的时候，其实都是伤害了我们的用户，内部的表述就是可用性或者质量。因此我们必须要足够的重视，更需要我们把它变成宝贵的经验。那到底什么是可用性和可靠性?影响可用性的因素有哪些?运维如何提高可用性?等等。

一、什么是可用性和可靠性

可靠性是在给定的时间间隔和给定条件下，系统能正确执行其功能的概率。可用性是指系统在执行任务的任意时刻能正常工作的概率。先来看一些指标定义：

1. MTBF——全称是Mean Time Between Failure，即平均无故障工作时间。就是从新的产品在规定的工作环境条件下开始工作到出现第一个故障的时间的平均值。MTBF越长表示可靠性越高正确工作能力越强。

2. MTTR——全称是Mean Time To Repair，即平均修复时间。是指可修复产品的平均修复时间，就是从出现故障到修复中间的这段时间。MTTR越短表示易恢复性越好。

3. MTTF——全称是Mean Time To Failure，即平均失效时间。系统平均能够正常运行多长时间，才发生一次故障。系统的可靠性越高，平均无故障时间越长。

可用性Availability = MTBF / (MTBF + MTTR)，一般我们都是用N个9来表达系统可用性，用宕机时长来说更好理解，如果以全年为周期(24*365=8760个小时)，3个9(99.9%)就意味着全年宕机时长是525.6分钟，4个9(99.99%)是52.6分钟，5个9(99.999%)是5分钟。

从这些时间指标上可以反向去推导IT能力不足的地方，比如说一个故障恢复时间很长，一定是自动恢复、运维意识、处理过程、系统架构等地方不对，导致了这个宕机时间过长;平均失效时间短，一定是系统的可靠性出了问题，找技术设计的问题，找依赖的硬件环境问题等等

二、影响可用性的因素

影响可用性的因素非常的多，但是可以从几个维度去看，人与组织、流程、技术和业务管理等四个维度。

1、人与组织

其实这个地方可以谈谈你的人和组织类型了，领导是否重视IT?是否重视运维?组织是否已经认识IT带来的价值，把IT当作自己的一个核心能力来看待?是否把面向用户的业务能力和IT能力很好的对接?是否建立起用户质量的组织文化?等等。

2、流程

流程是梳理多个角色自己的关系和职责。我们第一个要去看这个流程在面对故障的是否起到了积极的作用，比如说能够确保故障信息的准确送达，同时保证处理人的角色和职责是清晰的。其次不断去检查流程是否可以自动化驱动，而非人为驱动。人是不可靠之源!我们最终希望形成是一个自动化、标准化的流程，这样的流程不容易被异化，且能保证预期执行结果一致。

3、技术

很多时候大家看到的技术是运维技术，其实恰恰相反对于互联网业务来说，对其高可用的影响，必然是业务IT技术架构，因此在其中需要遵循很多原则，有一些原则需要有普适的参考价值。比如说服务降级、灰度发布、过载保护、服务公共化等等。这些方法论是否已经融入到研发和运维的架构设计哲学之中?现实是产品功能需求优先，而非可运维性优先，可运维性最终就是业务的质量。

4、业务管理

把你的IT能力最终都业务能力看板化，你可以转换成我们多个业务指标，比如说质量、可用性、用户体验、用户满意度、成本等等，有了这些业务导向性指标，才能把IT能力和业务更好的对接起来。否则很容易在组织内，形成“IT是支撑部门”认识，而非创造价值部门。这一点还有一个重要性，就是让IT部门也要足够的认识到，他们的能力直接和业务相关，需要增强业务敏感度。

三、如何提高系统的可用性

刚刚上面讲到了影响可用性的因素，分成了四个方面，但我想提高系统的可用性从另外一个角度来描述，能把握一些核心准则(其实还有更多)。

1、故障发生前，建立运维质量仪表盘

我们一定要建立运维数据看板，这个看板的数据并且要在业务、研发、测试和运维达成一致，让大家足够重视这份数据，这样数据便有了推动力。建议这个地方的核心数据指标不要太多，因为涉及到多个团队，大家不能够一致理解，特别是传达到管理层，太多的指标，容易失去关注的焦点。

通行的做法，就是用可用性来做运维的数据看板。可用性的计算方法有简单的方法，也有复杂的方法。简单的方法就是在监控系统中搞一些探针来模拟用户监控，最后我们能得出故障的时长和可用性的时间，这样我们可以建立每天、每周、每月、每Q的可用性