Linux故障处理最佳实践
2012-03-03 20:57 bangerlee 阅读(4255) 评论(2) 编辑 收藏 举报引言
业务中断了！
老板咆哮，主管抓狂，而你就是那个要去处理故障、恢复业务的不幸的人。
你独自一人在阴暗的隔间里。
北边是老板的办公室，西边是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服务器相关故障处理的时，我们需要考量以下几方面：
- 快速解决问题
- 提升自身技能
- 向高人求助
某年某月某日，一个系统启动过程中挂死的问题需要你处理，这时恰好你身边就有一位Linux专家，他对系统启动过程了如指掌。这时你有两种选择：
1. 问Linux专家，问题立马可以得到解决
2. 查阅相关资料，自己解决问题
如果你尝试依靠自己的能力解决该问题，或许你需要花费很多时间和精力，查阅很多介绍Linux操作系统启动过程的资料，但因此你也了解了各个启动阶段的功能、对应加载的服务项，甚至能学到在不同启动阶段挂死的恢复处理方法。
相比直接使用google搜索答案或问相应专家，独立解决问题，即使问题最终没能靠自身力量得到解决，但学习和独立思考的过程也让自身的技能得到了提升。
但也并非所有问题都有必要作深入研究，当问题属于以下类型：
- 十分紧急，稍有延误就会带来重大损失
- 非自身发展领域相关
那我们不妨采取另一种策略，google之，或找相关领域的专家迅速地将问题解决。
问题处理参考方法
现在你手头有很多可用于问题诊断的工具，你也认识到可以通过独立处理问题，来提升自身技能，接下来就真正进入问题处理环节咯，具体怎么进行问题处理呢？
首先我们需要收集问题相关的信息：
1.问题现象
处理问题之前，首先得了解清楚问题现象。
业务出现异常，是响应慢还是完全没有响应？
主机僵死，能否ping通？能否进行终端切换？是crash还是hang？
2.发生时间
如果问题发生的时间有一定规律，这时我们可以通过排查系统的定时任务，从而找出问题根因；另外，根据时间点我们可以迅速找到相关日志，减少查找日志花费的时间。
3.做过哪些操作
安装了补丁包？修改了系统配置参数？了解问题出现之前做了什么操作，能为我们处理问题提供指引。
4.OS相关信息
利用工具可收集问题出现时间点CPU负载、内存利用、磁盘IO、网络收发包等OS信息，这些信息为我们提供了较为全面的参考。
为了全面地收集OS信息，需要执行很多命令。这时，可以将这些命令集合到一个脚本中，利用脚本进行信息收集，节省了输入命令的时间，对于无法自行登录的远程服务器，使用脚本收集更显便捷。
总之，信息收集越全越好。即使自己找不出问题根因，后续向他人求助时，也不会因为缺少日志信息而犯愁。
了解了问题现象，又有了日志信息，那我们就可以结合日志对问题进行分析了。
首先判别问题类型、缩小问题范围：
是硬件问题，还是软件问题？
是业务进程层面的，还是系统层面的？
CPU、内存、网络、磁盘，哪一方面出现异常？
对于可复现(reproducible)的问题，我们可搭建环境进行问题复现，在实验环境中对问题处理方法进行验证，可降低对现网环境的影响；对于复杂地、不可复现的问题，我们就得做好长期作战的准备了，除了收集以上所列信息外，还需记录问题处理的过程、尝试过哪些处理方法等，这样，当有其他人参与进来一同处理该问题的时候，就能更快速地熟悉问题情况。
小结
本文讨论了Linux故障处理的方式方法。能否顺利解决故障，首先取决于我们的技能水平，其次需要依靠各种问题诊断工具。处理问题的过程可以与个人技能提升很好地结合起来，好的处理方式需要经验的积累，但个中也有规律可寻。
从提升个人技能的角度出发，即使面对紧急问题，我们也能变得更加淡定和坦然。再有业务中断情况，老板、主管都还在抓狂，但你...
Reference: Self-Service Linux
