对于系统管理员来说如何管理自己的服务器已经是再简单不过，但是如何管理好服务器却不是一个简单的事情。对于管理员来说重启服务器可不是一件闹着玩的事情。对于Windows服务器管理员来说经常性重启Windows设备已经成为一种生活常态，但在Unix系统中这种办法却难以奏效——在默认情况下重新启动不会带来任何形式的改善。

我打算借此机会跟大家详细聊聊重启的问题。对于每一位服务器管理员来说这都算得上热门话题，但在Unix极客们眼中它则属于一种层次更深的课题——可能因为Windows管理员们往往把重启当成故障排查工作的首要步骤之一，而Unix团队则一般只在束手无策的情况下才进行尝试。

Unix服务器重启的两种情况

实际情况是：服务器重启操作应该极少出现——请注意是极少。在这里我列举内核更新与硬件更换作为例子，因为它们是Unix领域中引发重新启动的两大主要原因。有些人一直在鼓吹什么不重启服务器的话会带来某些严重的安全风险，这简直是一派胡言。如果服务项目与应用程序中确实存在安全风险，那么打上漏洞补丁就能解决问题了，而且补丁往往不要求重启设备。而如果安全风险存在于内核模块中，一般来说只需卸载对应模块、安装补丁，最后重新加载模块。没错，我承认一旦内核中存在安全风险，那么重启操作的确是必要的。但在这种情况之外，大家根本没有切实的理由重新启动Unix服务器。

有些人认为如果不进行重启操作，其它形式的风险往往会接踵而至，例如某些关键性服务项目在开机时没有得到正确启用，而这将导致一系列隐患。当然，这种说法本身是正确的，但只要管理工作执行到位，这其实根本就是种杞人忧天。只有刚刚接掌服务器设备的菜鸟才会忘记正确设置服务项目的启动参数。不过话说回来，如果大家的服务器正处于构建阶段，且其中还不涉及任何生产方面的内容，那么不妨随意进行各类重启测试，这不会带来任何不良影响。而且我认为这正是熟悉重启机制的好时机。

但还有另一方面需要考虑：那些将重启操作当成故障排查重要步骤之一的家伙是抱着死猪不怕开水烫的心态，打算一次性把问题都暴露出来。就说一套已经出现问题的Unix设备吧，某些还处于运行中的服务项目实际上已经无法再次启动，而这一点在重启之后就会显现出来——也许是由于分段故障或者其它稀奇古怪的原因。

造成Unix服务器重启的原因

如果我们只是简单查看几分钟之后就一拍脑门决定重启设备，那么也许故障的真正原因就彻底湮没在时光中了——也许是某位初级管理员在运行一套自己编写的愚蠢脚本时无意中删除了/boot目录或者/etc、/usr/lib64目录下的部分内容。这正是引发分段故障以及设备不稳定情况的罪魁祸首。然而一旦我们选择直接重启服务器而没有深入挖掘问题，那么显然问题会变得更加严重，接下来不出意外的话大家应该会启动恢复镜像——这就代表需要面对大量恢复工作——而与此同时生产服务器也将陷入停机状态。

以上只是我们在Unix领域中应该尽量避免重启操作的原因之一。与其说这算是种故障排查方法，不如把它看作一类孤注一掷的豪赌——要么发现问题，要么亲手毁掉一切再慢慢重建。总之，没人能利用/var分区重启设备就完全修正错误。（另外请别提什么打开文件句柄这类迂腐的蠢话——我想大家应该理解我的意思）

服务器重启前请做完你该做的工作

在大多数情况下，不进行重启是极其重要的，因为系统中能够帮助我们修复问题的关键性内容在重启前是一定存在的，但在重启后却未必还在。重启之后问题绝对会再次出现，然而一旦解决方案随重启行为而烟消云散，那么故障本身就陷入了无解的死循环中。除非有人决定不进行重启，而是尝试找出问题的根源。遗憾的是，能做了这种明智选择的人实在少之又少。实际情况是：一根小小的故障内存条就能给系统正常运行与设备启动状态带来极大的麻烦。而这个时候，对症下药才是上策，一味重启只会带来额外的损失。

因此，今后大家在面对问题时，如果有某个家伙说什么“嘿，不如先重启一下看看”，不妨直接给他两个大嘴巴。重启当然是方案之一，但在实施重启前请务必确保我们已经采取了一切能够想到的处理措施；毕竟节省下来的都是咱们自己的时间跟精力嘛。