以“看病的思维”谈运维故障排错的思想

分类:CentOS运维 阅读:42217 次

在实际的工作中,我们总是会有遇见生产环境出问题的时候。一旦出现问题。并且业务十分重要的时候。业务要求在最短时间内让系统恢复正常,这就会给人带来很大的压力。在这种重压之下有可能会让我乱了分寸茫了大脑。那我们要怎样快速的有针对性的进行故障排错,解决故障呢?问题是无穷的,个人觉得只有掌握了:故障排错的思想,思维,才有助于你每次排查故障都能够顶住压力,能够尽量缩短故障恢复时间。而且我觉得故障的排错、恢复,就和我们生病去医院看病有几分相似。于是我就把“看病的思维”和“故障排错的思想”两者稍微结合起来分享,自己对故障排错思想的认识。

中医看病讲究的是“望闻问切”,西医的套路就是:抽血,化验,看报告,治疗。注重养生的人就讲究平日里的养生调理锻炼。系统出现故障就和我们人生病了一样。故障排错就相当于生病去看医生。运维的故障排错思想就是要综合中西医及养生者的理论,不仅是生病时要“望闻问切”,“诊断治疗”,还要讲解平日里的“养生调理”。我把这样的一个“看病”过程拆解为:

1、平日养生、预防:日常运维规范

2、望闻问切:病灶为何?情况如何?

3、抽血化验看报告:定点求证,找出病因

4、下药治疗:解决故障,总结反馈

5、病后调理:亡羊补牢,完善内容

(注意:在故障排除过程中一定要做好系统信息,数据,故障现场的备份工作,避免在故障排除或故障修复过程中造成的二次伤害,就跟看病一样同样需要注意。本来人还活得好好的让你一治给治死了。)


1、平日养生、预防:日常运维规范

为了更好的避免日常环境中,因为误操作的原因或权限滥用等原因造成生产环境的故障。运维的日常操作规则就应该制定详细,并且要严于执行。很多公司虽有制定了良好的运维规则,可并没有落实到位,那其实就相当于废纸一张。运维规则,就相当于我们平日里会加强锻炼,这样你生病的(出故障)的几率就会大大降低。平日里的一些简单良好的操作习惯,能够避免很多麻烦。能够让你在出现故障时,减短很多系统恢复的时间。比如:详细的记录操作信息,权限管控细则,运维操作习惯规则,故障紧急恢复手册,系统&数据定时备份,相关人员的技能培训等等都是很好的预防手段。如果这些都能够做好的,其实是能够减少很多不必要的麻烦。


2、望闻问切:病灶为何?情况如何?

望、闻:观察。观察故障的表现是什么?系统此时的各个状态是什么?比如最直观的可能是客服报网站访问不了了或者是访问网站很慢了。再或者是数据丢失了,服务器负载过高了,流量异常了,服务器报警了等等。这些都是故障发生时,我们需要先明确,并记录下来的。因为此时如果连故障的最基本的表征是什么都不清楚的话,如何进行下一步的故障排查。至少你要清楚报错是什么、网站访问是哪里慢了,数据丢失了哪些等等。也就是说病了,你至少要说得清楚你哪里痛哪里痒哪来不舒服了,怎么个不舒服法,这样医生才能知道你可能得了生了什么病。

问:询问情况。此时我们就是需要根据我们的故障表现,来有针对性的查看系统日志、询问相关人员最近都相应做了什么操作,是否程序有进行了修改或配置文件做了修改。或者系统架构做了调整。询问此前是否也有出现这种情况。有些我们可以从他人那边得到,有些就需要我们自己通过系统日志文件或监控数据来进行查看,获取信息。并且做好相应的信息记录。(这个就相当于写病历一样)这个对于我们运维故障排错解决其实是很有帮助的,因为在后续的排错过程中,我们能够很清楚的知道可能涉及的故障方面有哪些。而且哪些是已经排查过,或者说能从最日志文件中判断出来不是某个方面的原因导致的。

做好排查过程中的信息记录,是对我们理清整个排错流程很有帮助的。

切:定位可能的病因。利用以上我们自己收集的信息,确定一个或多个可能出现故障的方面。硬件、网络、程序、配置、系统架构、数据库、误操作等等。(其实很多人觉得最难的还是在这点上。个人觉得要做好这方面并不难,首先你做到了以上两点之后,你对遇上的故障基本上都能够有一定的基本判断了。当然是基于对各个方面的知识有一个最基本的认识。还有一个方法就是按照常规方法“走一遍”你自己依靠纯理论的,模拟系统正常工作的样子,需要经过哪些环节,比如从某个客户的一个访问请求开始-->客户端的网络传输,服务器的网络传输,-->系统的运行-->程序运行再到涉及到的各个应用程序等的运行环节。首先你能够模拟正常工作时运行的各个原理部分,其次就是你一个一个环节上面给一个故障的假设,那么从理论上推导,是否会出现于你现在出现的故障同样的表现。如果有可能出现,那么这个环节就是有可能出现故障的方面。此时你就需要记录下来再你理论故障模拟的推导过程中,自己觉得可能的方面。

其实这个也和看病过程是一样的,医生总是会根据你的病症有一个初步的诊断,其实在他们理论体系里面就是按照一个人正常的时候是什么样的。如果某个地方出现病因,那么伴随的病症是什么样的,然后在同你个人出现的病情表现做对比,然后给出一个初定的诊断当然这个初定的诊断可能是多方面的。

并且这个过程是能够通过日常工作经验的积累,最终提高你对故障定位的敏感度。因为你所见过的可能出现的故障表现掌握越多,你越能够依托过去的表现,找到和现在可能相似的地方,帮助你定位可能的故障方面。


3、抽血化验看报告:定点求证,找出病因

我们上医院看病,总是先来一堆抽血化验,最终通过报告的情况来确定我们的病因是什么。而这堆报告的作用就是在于逐一排查可能存在的病因。或者是辅助我们排查病因。经过望闻问切之后,我们已经能够大概的确定我们可能存在的故障方面了。接下来就是利用排查法,一项一项的进行排除,当然如果你能够已经很直接的确定出来故障就是因为什么导致的,那可以直接采取“治疗”了。

逐一排除,定点求证。我们已确定可能的故障方面。那么我可以利用替代,对比,监控等方法来求证是否真是这个方面出现了错误。比如替代:我们可以使用在其他环境上使用正常的配置或程序等来进行替换。(注意:做好故障现场的备份工作)如果故障消失,那么可以确定是替换的这方面出现了问题。如果不是接着排查其他方面。对比:让处于同等环境下的两台机器,一个为故障机,一个为正常机。两者就某个相同的方面进行对比,如果一样那么这方面应该是属于正确,在这方面出现故障的几率很小。比如:处于同一个机房的两台机器,一台故障机,一台正常机。访问,检测正常机的网络情况是正常的。并且故障机和正常机在网络上面的环境,所处网络,配置一样。那么就可以判断出来故障出在网络方面是不太可能的。监控:对故障机的某个方面进行监控,监控从正常到故障的过程中,这个方面都发生了什么变化。如果发现没有发生什么具体的变化,或者说在某个方面上面找到了变化。那么基本上可以断定是某方面的原因了。

通过逐一排查,定点求证,慢慢抽丝剥茧似的将可能的故障方面进行排除,最终定位到故障的原因。那么接下来就是采取措施进行恢复了。


4、下药治疗:解决故障,总结反馈

当我们知道了我们的故障原因后,就是采取恢复措施了。注意:在进行故障恢复的时候,一定要对我们原有的系统信息,数据,故障现场做好备份工作。因为这样可以让我在故障恢复失败的时候,能够回滚回来,而且也可以帮我们在日后进行故障模拟。并且在解决故障的时候,一定能够个人私自的进行解决,一定要通过上级领导的审批,通过后再采取措施,哪怕这个动作可能很小。你都养成这个习惯。或者是通过简单的汇报,让领导知会此事,并同意这么做。如果涉及到多方人员的话,如果需需要召开会议商讨,那么就召开紧急会议。或通知多方人员,你在做响应的故障恢复措施,并且告知可能会发生什么样的影响,影响时间等。请大家不要小看了这个部分,有时候你如果没有协调好你本公司内部,你不会被用户吐槽死,你就先被你其他部门的同时吐槽死了。

解决完成故障问题,一定不能忘记要及时做好故障总结汇报,汇报给你的上级,分享给网络上的同学们。


5、病后调理:亡羊补牢,完善内容

我们处理完成了我们的故障,知道了原因,写完了汇报。那么最后呢,就是要好好思考一下出现这个故障的根本原因是什么,是因为权限问题,操作问题,还是运维规范制度问题,还是因为自己的技术不过关呢,监控不到位,系统不够自动化等等。并且针对次原因,提出一个日后有效预防,避免,甚至是杜绝的方法,并且落实起来。让整个系统更健壮。

就像我们大病痊愈之后,也是需要好好调理身体,知道自己缺什么,加强锻炼,让身体强壮起来。


PS:自己没有什么运维的工作经验,所以很少遇见什么故障。但一些网络上面的故障排错,还是遇见不少的。个人觉得道理是相通的,所以大胆就写了个分享。以上的拙见,和实际上有出入的地方,还望各位帮忙纠正,在此不胜感激。

本文出自 “从头开始” 博客,请务必保留此出处http://atong.blog.51cto.com/2393905/1349768