淡若清风9815612
在实际的工作中，我们总是会有遇见生产环境出问题的时候。一旦出现问题。并且业务十分重要的时候。业务要求在最短时间内让系统恢复正常，这就会给人带来很大的压力。在这种重压之下有可能会让我乱了分寸茫了大脑。那我们要怎样快速的有针对性的进行故障排错，解决故障呢？问题是无穷的，个人觉得只有掌握了：故障排错的思想，思维，才有助于你每次排查故障都能够顶住压力，能够尽量缩短故障恢复时间。而且我觉得故障的排错、恢复，就和我们生病去医院看病有几分相似。于是我就把“看病的思维”和“故障排错的思想”两者稍微结合起来分享，自己对故障排错思想的认识。
中医看病讲究的是“望闻问切”，西医的套路就是：×××，化验，看报告，治疗。注重养生的人就讲究平日里的养生调理锻炼。系统出现故障就和我们人生病了一样。故障排错就相当于生病去看医生。运维的故障排错思想就是要综合中西医及养生者的理论，不仅是生病时要“望闻问切”，“诊断治疗”，还要讲解平日里的“养生调理”。我把这样的一个“看病”过程拆解为：
1、平日养生、预防：日常运维规范
2、望闻问切：病灶为何？情况如何？
3、×××化验看报告：定点求证，找出病因
4、下药治疗：解决故障，总结反馈
5、病后调理：亡羊补牢，完善内容
（注意：在故障排除过程中一定要做好系统信息，数据，故障现场的备份工作，避免在故障排除或故障修复过程中造成的二次伤害，就跟看病一样同样需要注意。本来人还活得好好的让你一治给治死了。）
1、平日养生、预防：日常运维规范
为了更好的避免日常环境中，因为误操作的原因或权限滥用等原因造成生产环境的故障。运维的日常操作规则就应该制定详细，并且要严于执行。很多公司虽有制定了良好的运维规则，可并没有落实到位，那其实就相当于废纸一张。运维规则，就相当于我们平日里会加强锻炼，这样你生病的（出故障）的几率就会大大降低。平日里的一些简单良好的操作习惯，能够避免很多麻烦。能够让你在出现故障时，减短很多系统恢复的时间。比如：详细的记录操作信息，权限管控细则，运维操作习惯规则，故障紧急恢复手册，系统&数据定时备份，相关人员的技能培训等等都是很好的预防手段。如果这些都能够做好的，其实是能够减少很多不必要的麻烦。
2、望闻问切：病灶为何？情况如何？
望、闻:观察。观察故障的表现是什么？系统此时的各个状态是什么？比如最直观的可能是客服报网站访问不了了或者是访问网站很慢了。再或者是数据丢失了，服务器负载过高了，流量异常了，服务器报警了等等。这些都是故障发生时，我们需要先明确，并记录下来的。因为此时如果连故障的最基本的表征是什么都不清楚的话，如何进行下一步的故障排查。至少你要清楚报错是什么、网站访问是哪里慢了，数据丢失了哪些等等。也就是说病了，你至少要说得清楚你哪里痛哪里痒哪来不舒服了，怎么个不舒服法，这样医生才能知道你可能得了生了什么病。
问：询问情况。此时我们就是需要根据我们的故障表现，来有针对性的查看系统日志、询问相关人员最近都相应做了什么操作，是否程序有进行了修改或配置文件做了修改。或者系统架构做了调整。询问此前是否也有出现这种情况。有些我们可以从他人那边得到，有些就需要我们自己通过系统日志文件或监控数据来进行查看，获取信息。并且做好相应的信息记录。（这个就相当于写病历一样）这个对于我们运维故障排错解决其实是很有帮助的，因为在后续的排错过程中，我们能够很清楚的知道可能涉及的故障方面有哪些。而且哪些是已经排查过，或者说能从最日志文件中判断出来不是某个方面的原因导致的。
做好排查过程中的信息记录，是对我们理清整个排错流程很有帮助的。
切:定位可能的病因。利用以上我们自己收集的信息，确定一个或多个可能出现故障的方面。硬件、网络、程序、配置、系统架构、数据库、误操作等等。（其实很多人觉得最难的还是在这点上。个人觉得要做好这方面并不难，首先你做到了以上两点之后，你对遇上的故障基本上都能够有一定的基本判断了。当然是基于对各个方面的知识有一个最基本的认识。还有一个方法就是按照常规方法“走一遍”你自己依靠纯理论的，模拟系统正常工作的样子，需要经过哪些环节，比如从某个客户的一个访问请求开始-->客户端的网络传输，服务器的网络传输，-->系统的运行-->程序运行再到涉及到的各个应用程序等的运行环节。首先你能够模拟正常工作时运行的各个原理部分，其次就是你一个一个环节上面给一个故障的假设，那么从理论上推导，是否会出现于你现在出现的故障同样的表现。如果有可能出现，那么这个环节就是有可能出现故障的方面。此时你就需要记录下来再你理论故障模拟的推导过程中，自己觉得可能的方面。
其实这个也和看病过程是一样的，医生总是会根据你的病症有一个初步的诊断，其实在他们理论体系里面就是按照一个人正常的时候是什么样的。如果某个地方出现病因，那么伴随的病症是什么样的，然后在同你个人出现的病情表现做对比，然后给出一个初定的诊断当然这个初定的诊断可能是多方面的。
并且这个过程是能够通过日常工作经验的积累，最终提高你对故障定位的敏感度。因为你所见过的可能出现的故障表现掌握越多，你越能够依托过去的表现，找到和现在可能相似的地方，帮助你定位可能的故障方面。
3、×××化验看报告：定点求证，找出病因
我们上医院看病，总是先来一堆×××化验，最终通过报告的情况来确定我们的病因是什么。而这堆报告的作用就是在于逐一排查可能存在的病因。或者是辅助我们排查病因。经过望闻问切之后，我们已经能够大概的确定我们可能存在的故障方面了。接下来就是利用排查法，一项一项的进行排除，当然如果你能够已经很直接的确定出来故障就是因为什么导致的，那可以直接采取“治疗”了。
逐一排除，定点求证。我们已确定可能的故障方面。那么我可以利用替代，对比，监控等方法来求证是否真是这个方面出现了错误。比如替代：我们可以使用在其他环境上使用正常的配置或程序等来进行替换。（注意：做好故障现场的备份工作）如果故障消失，那么可以确定是替换的这方面出现了问题。如果不是接着排查其他方面。对比：让处于同等环境下的两台机器，一个为故障机，一个为正常机。两者就某个相同的方面进行对比，如果一样那么这方面应该是属于正确，在这方面出现故障的几率很小。比如：处于同一个机房的两台机器，一台故障机，一台正常机。访问，检测正常机的网络情况是正常的。并且故障机和正常机在网络上面的环境，所处网络，配置一样。那么就可以判断出来故障出在网络方面是不太可能的。监控：对故障机的某个方面进行监控，监控从正常到故障的过程中，这个方面都发生了什么变化。如果发现没有发生什么具体的变化，或者说在某个方面上面找到了变化。那么基本上可以断定是某方面的原因了。
通过逐一排查，定点求证，慢慢抽丝剥茧似的将可能的故障方面进行排除，最终定位到故障的原因。那么接下来就是采取措施进行恢复了。
4、下药治疗：解决故障，总结反馈
当我们知道了我们的故障原因后，就是采取恢复措施了。注意:在进行故障恢复的时候，一定要对我们原有的系统信息，数据，故障现场做好备份工作。因为这样可以让我在故障恢复失败的时候，能够回滚回来，而且也可以帮我们在日后进行故障模拟。并且在解决故障的时候，一定不能够个人私自的进行解决，一定要通过上级领导的审批，通过后再采取措施，哪怕这个动作可能很小。你都要养成这个习惯。或者是通过简单的汇报，让领导知会此事，并同意这么做。如果涉及到多方人员的话，如果需需要召开会议商讨，那么就召开紧急会议。或通知多方人员，你在做相应的故障恢复措施，并且告知可能会发生什么样的影响，影响时间等。请大家不要小看了这个部分，因为有时候你如果没有协调好你本公司内部，你不会被用户吐槽死，你就先被你其他部门的同时吐槽死了。
解决完成故障问题，一定不能忘记要及时做好故障总结汇报，汇报给你的上级，分享给网络上的同学们。
5、病后调理：亡羊补牢，完善内容
我们处理完成了我们的故障，知道了原因，写完了汇报。那么最后呢，就是要好好思考一下出现这个故障的根本原因是什么，是因为权限问题，操作问题，还是运维规范制度问题，还是因为自己的技术不过关呢，监控不到位，系统不够自动化等等。并且针对此次原因，提出一个日后有效预防，避免，甚至是杜绝的方法，并且落实起来。让整个系统更健壮。
就像我们大病痊愈之后，也是需要好好调理身体，知道自己缺什么，加强锻炼，让身体强壮起来。
PS:自己没有什么运维的工作经验，所以很少遇见什么故障。但一些网络上面的故障排错，还是遇见不少的。个人觉得道理是相通的，所以大胆就写了个分享。以上的拙见，和实际上有出入的地方，还望各位帮忙纠正，在此不胜感激。
