排错思想

作为一名系统工程师，排错是工作过程中经常会遇到的内容，而需要排错的对象往往是千奇百怪，各种各样都有。系统工程师被誉为“什么都懂的人”，因此，一旦发生问题，往往就成为了第一个被想到的人。相信，广大一线运维工程师都有这样的经历。

无疑，排错是需要技巧的。因为这项工作不仅需要很好的逻辑思维能力和丰富的工作经验，同时还需要使用正确的方式，合理的行为，正确的过程。我曾经面试过、管理过很多系统工程师，也教过很多学生。在工作中我发现很多新手对于如何排错往往不那么在行。 

事实上，在经过无数次排错工作之后，我深深的感觉到：排错没有固定的方法和手段，掌握正确的排错思想才是最为重要的。我把我的排错思想总结为几个基本的步骤。在此，分享一下个人的体会，抛砖引玉，请各位指正。

第一步：观察错误

观察错误，说白了就是搞清楚发生了什么。

一些新手，特别是一些“文档工”只知道照着文档一步步敲命令，出现问题了，也只是按照一些所谓的技术手册或者故障手册去排查问题。这是不可取的。

你必须清楚发生了什么。

你可以通过标准错误输出（一般来说它们会直接输出到屏幕上）、错误日志、监控工具等途径获取到相应信息。有些linux工程师只知道去看/var/log/message日志，有些AIX工程师只知道看errpt，还有些windows工程师压根什么都不知道看。以上这些都是不可取的，错误的。你必须知道可以通过哪些途径获取到计算机给你的反馈。并且，通过这些反馈了解到底发生了什么。

第二步：分析问题

分析问题，说白了就是搞清楚在发生问题的时候计算机在干什么。

上面这句话说起来简单，实际上涉及的内容却很复杂。想要知道发生问题的时候计算机在干什么，首先要能够在第一步搞清楚发生了什么。之后，需要你对相关技术以及能够对发生问题的系统产生影响的相关技术都有很深刻的了解。不然，光靠拍脑门猜测是不行的。

举个例子，比如我在访问web服务器的时候发生了connect refused这个报错，该如何分析呢？

 

如上图所示，左边是分析发生问题的时候计算机在干什么的思路（出现报错->web服务得到请求了吗？），右边是由此产生的问题可能性罗列。通过这个图可以看出，当看到一个报错的时候，最好脑子里把整个流程跑一遍，然后清楚的知道哪个环节发生了问题，之后再由这个环节发散去想导致出现问题的可能性有哪些。

上面这个例子仅仅问题还是很简单的。有时候在生产环境里遇到的问题可能更加复杂，更加妖怪，所以更要好好在脑子里把流程跑清楚。要做到这一点，必须下功夫把所接触的技术研究透彻，至少要把内部工作机理搞清晰一些。这样才能开始做第三个步骤。

第三步：解决问题

解决问题要遵循三个原则：先备份后操作、优先解决和一次一项。

先备份后操作应该是每个系统工程师都遵循的原则。所谓手里有粮，心里不慌。有了备份，出现问题好歹有个回退的余地。不要忘记，管理员往往就是最危险的破坏者。

什么叫优先解决呢？意思就是，在上一个步骤的时候，把可能导致问题的可能性按照可能性的大小按照优先级别排列好。可能性越大的，越先去看。学过CISCO课程的人可能都知道“先硬后软”的道理，意思就是说遇到网络故障，先检查硬件上的问题，看看线路是否有问题，接口是否有问题，模块是否完好等等，然后再去调整设备内部的配置。这就是一个典型的例子。最怕的是随便抓一个可疑点就一脑袋扎进去，结果耗费了大量的时间，问题却得不到解决。

那么什么叫一次一项呢？意思就是，一次只改动一个配置，一次只变动一个设备。同时做多项改动很可能把原本简单的问题复杂化。倒霉的时候，你可能本来改对了，但是其他多余的变动导致出现了新的错误。到最后错上加错，问题越来越蹊跷诡异了。

第四步：后期跟踪

问题是否真的解决了？会不会对其他系统或者设备产生连带影响？一切都按照我们的设想继续下去了吗？这一切都需要后期跟踪才知道。所以说，不要想着一次排错之后，工作就结束了。后期的跟踪也很重要。如果你是甲方工程师，不要忘记这一点，否则会很难受。如果你是乙方工程师不要忽视这个工作，否则后面麻烦不断。

详情请看《Linux系统工程师的必备素质》http://johnwang.blog.51cto.com/474770/898278