引言

　　业务中断了！

　　老板咆哮，主管抓狂，而你就是那个要去处理故障、恢复业务的不幸的人。

　　你独自一人在阴暗的隔间里。

　　北边是老板的办公室，西边是Team Leader的办公室，南面是茶水间，在那你能泡上一杯热咖啡。

　　问题没有一点进展，你郁闷地盯着显示器。

　　这时，电话再次响起，你不用接听也已知道又是一通抱怨用户连接不上服务器的电话，

　　因为就在半小时内，已经有四通电话催问你进展了。

　　你将会怎么做？泡一杯咖啡准备通宵苦战？此时，或许你的心底也充满无奈：

　　Linux服务器上部署的业务出现中断时，为快速处理问题、消除故障，避免以上苦逼的剧情发生，我们可以做哪些准备吗？

　　工欲善其事，必先利其器

　　Linux自身以及开源社区已经提供了很多工具，帮助我们快速定位问题。我们需要做的，就是在故障发生之前，确保机器上安装了这些工具，并进行适当的配置，使其正常运转，下面列举几个常用的问题诊断工具。

　　syslog/syslog-ng  记录系统服务进程和操作系统本身的日志，我们可以对日志输出的内容、输出到哪些文件进行配置，利用这些日志，可以查到诸如机器重启时间、命令执行记录等信息，查看/var/log/messages里记录的一些异常信息，往往是我们处理问题的第一步。

　　strace：跟踪进程运行过程中产生的系统调用，当程序、命令执行挂死或缓慢时，我们可以通过分析相关系统调用信息，缩小问题范围、查找故障原因。

　　atop：通过定时采样系统资源使用情况、进程运行状态，为我们提供了较全面的操作系统信息。

　　LKCD/kdump  是一种内核转储机制，当系统发生kernel crash时，它将寄存器中的值、内存中的堆栈信息保存到磁盘中，形成的vmcore文件提供了crash时间点所有进程的状态、内存的使用情况等信息，根据寄存器的值，我们甚至能找到内核中相应的代码进行分析。

　　除以上所列，ping、ps、lsof、dmesg等查询命令也被经常用到。

　　现在，我们面前摆放着各式各样、功能不同的工具，有了这么一个强大的工具套件，是否意味着来一个问题我们就能解决一个，来两个问题我们就能消灭一双呢？

　　非也。仅仅拥有齐备的问题诊断工具是远远不够的，更需要我们掌握怎么使用（How）以及什么时候（When）使用这些工具、熟悉Linux操作系统本身，甚至需要深入了解Linux内核源码。是否能解决、快速解决Linux故障问题，取决于问题处理人员的技能水平。

　　问题处理与个人能力提升

　　当故障发生时，尽早恢复业务固然重要，但对个人而言，恢复业务并不是目的，更多地是通过处理问题过程提升自己的技能。进行Linux服务器相关故障处理的时，我们需要考量以下几方面：

　　1、快速解决问题

　　2、提升自身技能

　　3、向高人求助