之前做过一两年的Linux系统技术支持的工作，帮助客户解决了上百个Linux系统的故障问题，涉及到了Linux大部分方面的问题，期间形成了自己的一套分析解决Linux系统故障问题的方法，特此总结出来分享给大家，希望可以帮助到从事相关行业的朋友们。
1.查看经验文档
首先去查看历史经验文档，这是最快、最高效的解决方法。当然了，前提是别人或者你自己有整理过类似问题清单、经验总结这样的文档。
如果遇到的问题正好有详细的记录，那么恭喜你，你可以快速解决这个问题了。如果没有，那也不要紧，条条大路通罗马嘛，后面还有很多方法。
顺便说一句，问题解决之后要及时写一下总结文档，于己于人都有好处。
2.检查系统运行情况
这一环节主要是使用一些工具来检查CPU、内存、网络、磁盘IO、进程等等系统的运行情况，当然了，工具有很多，除了很多开源软件之外，其实Linux本身自带了很多系统检查的命令，用这些命令也基本足够了。像netstat、find、awk、iostat、strace、ping、traceroute、ifconfig、top、free、ps等命令，都是很强大的。
在这里举一个之前遇到的一个案例，问题现象是这样的：在Linux系统上运行了一个应用（C语言编写的），但是运行一段时间之后发现系统内存消耗很快，大概3、5天就把系统的32GB内存消耗差不多了，有的甚至开始使用swap了，内存不够之后系统运行就非常缓慢，甚至出现ssh不上的情况，只能强制重启。这个应该算是非常严重的一个问题了，当时用了很久时间才得以解决。具体的分析过程是这样的：首先就是通过上面的那些Linux命令来查看系统CPU、内存、进程等情况，然后编写了一个shell监控脚本每隔5分钟记录一次，记录一段时间之后再去分析产生的记录日志。通过分析，确认是应用本身的问题，应用因为程序错误导致申请的内存未被释放。最终按照客户的要求，应用那边去修改自己的程序错误，Linux系统这边也要做一些限制以避免类似情况再次出现，就这样双管齐下将这个问题解决了。
3.分析日志
日志的重要性不言而喻，如果没有日志，我们在分析问题的时候跟一个瞎子差不多。很多问题其实从日志的错误信息中都是可以找到答案的。
接着上面的那个内存不断消耗的案例来讲，其实在解决这个问题的过程中，日志也起到了非常重要的作用，在系统的日志文件中就已经明确记录了C应用产生的大量段错误。这其实是提供了强有力的证据，来向客户证明这个问题是应用厂商引起的，而不是Linux系统的问题。虽然最终两边都做了修改来解决这个问题，但是对于高可靠的系统而言，客户的这个要求并不过分。
4.对比
这里指的是对比故障系统和正常系统之间的异同，通过分析两者的异同点来判断出故障系统的问题原因。个人觉得这个方法在解决故障的时候是最合适的方法，可以将正常系统上的配置、环境移植到故障系统中，继而缩小排查范围，往往可以达到事半功倍的效果。
5.运用排除法
这个方法不用多说，大家平常用的都挺多的，主要目的是能缩小范围，减少分析故障所用的时间。
举个以前处理过的一个故障作为例子吧。故障现象是这样的：一台Linux服务器的网络（IP为10.71.1.105，网关为10.71.1.1）断断续续，连通30秒之后就会断掉30秒，很有规律，但是其他服务器的网络都是OK的。上面提到的各种办法用尽都没能解决，后来就用排除法进行定位分析：
首先，查看连接同一个交换机的其他服务器的网络，一切正常，排除了交换机侧的网络问题。
然后，重接网线到其他交换机，重新配置IP（改为10.71.5.235）、网关（改为10.71.5.1），一切正常，这就排除了硬件故障，也排除了网卡驱动的故障。
剩下的就只有网卡配置的问题了，下面就从这个地方入手。接下来将网线重新接回原来的交换机，IP、网关配置也该回原来的（IP为10.71.1.105，网关为10.71.1.1），也就是相当于还原回故障状态。此时，将网卡的IP改为同一网段的其它IP（改为10.71.1.221），改完之后网络也是正常的，进一步断定是网卡的IP配置问题。但是从配置来看，也只是一个IP地址不一样而已，难道是这个IP地址（10.71.1.105）有问题？接着就主要分析这个IP去了，偶然的机会试着ping了一下原来的那个故障IP，居然是通的！至此您应该明白问题原因了吧？IP冲突了，修改一下吧。
总结一下吧，这个问题虽然解决的有点幸运成分（偶然ping了一下才知道问题原因的），但是主要还是运用排除方法是正确的，将范围缩小到只有那个IP地址了，我想或早或晚都会ping它一下的吧。
6.求助