网络故障运维人应该知道的那些事

发布人：佚名 发布时间：2016.10.17 来源：网络

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

一、什么是可用性和可靠性
可靠性是在给定的时间间隔和给定条件下，系统能正确执行其功能的概率。可用性是指系统在执行任务的任意时刻能正常工作的概率。先来看一些指标定义：
1.MTBF——MeanTime Between Failure，即平均无故障工作时间。
就是从新的产品在规定的工作环境条件下开始工作到出现第一个故障的时间的平均值。MTBF越长表示可靠性越高正确工作能力越强。
2.MTTR——全称MeanTimeTo Repair，即平均修复时间。
是指可修复产品的平均修复时间，就是从出现故障到修复中间的这段时间。MTTR越短表示易恢复性越好。
3.MTTF——全称是MeanTimeToFailure，即平均失效时间。
系统平均能够正常运行多长时间，才发生一次故障。系统的可靠性越高，平均无故障时间越长。
可用性Availability=MTBF/(MTBF+MTTR)，一般我们都是用N个9来表达系统可用性，用宕机时长来说更好理解，若以全年为周期（24*365=8760小时），3个9意味着全年宕机时长是525.6分钟，4个9是52.6分钟，5个9是5分钟。
从这些时间指标上可以反向去推导IT能力不足的地方，比如说一个故障恢复时间很长，一定是自动恢复、运维意识、处理过程、系统架构等地方不对，导致了这个宕机时间过长；平均失效时间短，一定是系统的可靠性出了问题，找技术设计的问题，找依赖的硬件环境问题等等。
二、影响可用性的因素
影响可用性的因素非常的多，但是可以从几个维度去看，人与组织、流程、技术和业务管理等四个维度。
1、人与组织
其实这个地方可以谈谈你的人和组织类型了，领导是否重视IT？是否重视运维？组织是否已经认识IT带来的价值，把IT当作自己的一个核心能力来看待？是否把面向用户的业务能力和IT能力很好的对接？是否建立起用户质量的组织文化？等等。
2、流程
流程是梳理多个角色自己的关系和职责。我们第一个要去看这个流程在面对故障的是否起到了积极的作用，比如说能够确保故障信息的准确送达，同时保证处理人的角色和职责是清晰的。其次不断去检查流程是否可以自动化驱动，而非人为驱动。人是不可靠之源！我们最终希望形成是一个自动化、标准化的流程，这样的流程不容易被异化，且能保证预期执行结果一致。
3、技术
很多时候大家看到的技术是运维技术，其实恰恰相反对于互联网业务来说，对其高可用的影响，必然是业务IT技术架构，因此在其中需要遵循很多原则，有一些原则需要有普适的参考价值。比如说服务降级、灰度发布、过载保护、服务公共化等等。这些方法论是否已经融入到研发和运维的架构设计哲学之中？现实是产品功能需求优先，而非可运维性优先，可运维性最终就是业务的质量。
4、业务管理
把你的IT能力最终都业务能力看板化，你可以转换成我们多个业务指标，比如说质量、可用性、用户体验、用户满意度、成本等等，有了这些业务导向性指标，才能把IT能力和业务更好的对接起来。否则很容易在组织内，形成“IT是支撑部门”认识，而非创造价值部门。这一点还有一个重要性，就是让IT部门也要足够的认识到，他们的能力直接和业务相关，需要增强业务敏感度。
三、如何提高系统性的可用性
刚刚上面讲到了影响可用性的因素，分成了四个方面，但我想提高系统的可用性从另外一个角度来描述，能把握一些核心准则(其实还有更多)。
1、故障发生前，建立运维质量仪表盘
我们一定要建立运维数据看板，这个看板的数据并且要在业务、研发、测试和运维达成一致，让大家足够重视这份数据，这样数据便有了推动力。建议这个地方的核心数据指标不要太多，因为涉及到多个团队，大家不能够一致理解，特别是传达到管理层，太多的指标，容易失去关注的焦点。
通行的做法，就是用可用性来做运维的数据看板。可用性的计算方法有简单的方法，也有复杂的方法。简单的方法就是在监控系统中搞一些探针来模拟用户监控，最后我们能得出故障的时长和可用性的时间，这样我们可以建立每天、每周、每月的可用性，可以做到分业务、分服务(更细粒度)等等；
复杂的方法在模拟数据的基础上，可以把事件系统记录的时间数据拿过来作为评估的标准。另外可以把可用性上升到质量层面，这个里面涉及到的评估维度(成本、用户体验、满意度)就更多了，数据获取的来源也变得更多，有些是来自于客服系统，有些是来自于舆情监控，有些是来自于运维容量系统，有些是来自于事件系统等等，不过最终呈现的指标就是一个——质量。
2、故障发生前，设定技术准则和要求
运维需要和研发建立整体的技术标准和规范要求，这块是腾讯做得非常好的地方，其“海量服务运营之道”非常值得业内学习。需要强调的是，运维一定要把标准化作为核心要务来推进，建立标准化的运维环境，建立标准化的技术栈(和研发确定)，建立标准化的高可用方法论，最终这个业务的可用性一定是有保证的。
3、故障发生时，恢复是第一要务
故障发生的时候，“恢复、恢复、恢复”必须是运维人脑子里面要时刻记住的。
在故障的当下，定位故障原因是大忌，这往往让故障时长变得不可控，因为会直接影响MTTR(平均修复时间)，影响用户的业务使用。不过有人会有疑问，不知道故障原因怎么知道如何解决？从经验来看，你一定有一些简单粗暴的原则去隔离故障，比如说服务器重启，链路禁用，DNS切换等等。
4、故障发生后，仔细的复盘
每一次故障发生后，运维人需要牵头去复盘故障，刚刚说了我们恢复是第一要务，所以故障的根本原因我们可能还不知道，此时就需要运维、测试和研发一起仔细的去看整个的故障过程，看看到底哪儿有什么问题？基本上也是从刚才说的四个方面来评估。不断的审视我们运维的能力和IT的能力，说“故障是运维最好的老师”的原因也在于此，它能够不断驱使我们走向更高的成熟度。
5、故障发生后，复盘措施有讲究
故障复盘后，制定改进措施也是非常重要的，需要把握以下几点：
•故障的措施必须是可落实，且具体的，要落实到具体的负责人，具体的时间
•故障的措施优先是必须技术的，然后是流程，最后是人的
•故障的措施可以分为长期措施和临时措施
•故障的措施一定要仅仅扣住故障的根因，避免流于形式和表面
•故障的措施切忌“亡羊补牢”式的，需要全面细致的分析
•故障的措施一定要保证后续的持续跟进

一叶可以障目，但也可以一叶知秋，就看我们是否真的去认真对待。从故障中学习、提高如何去做运维，故障虽然不会带来运维人的春天，但这是运维人真正春天的开始。

相关推荐《数据中心内虚拟机迁移带来的网络技术难题》