對於管理員來說重啟服務器可不是一件鬧著玩的事情。對於Windows服務器管理員來說經常性重啟Windows設備已經成為一種生活常態，但在Unix系統中這種辦法卻難以奏效——在默認情況下重新啟動不會帶來任何形式的改善。
Unix服務器重啟的兩種情況
實際情況是：服務器重啟操作應該極少出現——請注意是極少。在這裡我列舉內核更新與硬件更換作為例子，因為它們是Unix領域中引發重新啟動的兩大主要原因。有些人一直在鼓吹什麼不重啟服務器的話會帶來某些嚴重的安全風險，這簡直是一派胡言。如果服務項目與應用程序中確實存在安全風險，那麼打上漏洞補丁就能解決問題了，而且補丁往往不要求重啟設備。而如果安全風險存在於內核模塊中，一般來說只需卸載對應模塊、安裝補丁，最後重新加載模塊。一旦內核中存在安全風險，那麼重啟服務器操作的確是必要的。但在這種情況之外，大家根本沒有切實的理由重新啟動Unix服務器。
有些人認為如果不進行重啟操作，其它形式的風險往往會接踵而至，例如某些關鍵性服務項目在開機時沒有得到正確啟用，而這將導致一系列隱患。當然，這種說法本身是正確的，但只要管理工作執行到位，這其實根本就是種杞人憂天。只有剛剛接掌服務器設備的菜鳥才會忘記正確設置服務項目的啟動參數。不過話說回來，如果大家的服務器正處於構建階段，且其中還不涉及任何生產方面的內容，那麼不妨隨意進行各類重啟測試，這不會帶來任何不良影響。而且我認為這正是熟悉重啟機制的最好時機。
但還有另一方面需要考慮：那些將重啟操作當成故障排查重要步驟之一的家伙是抱著死豬不怕開水燙的心態，打算一次性把問題都暴露出來。就說一套已經出現問題的Unix設備吧，某些還處於運行中的服務項目實際上已經無法再次啟動，而這一點在重啟之後就會顯現出來——也許是由於分段故障或者其它稀奇古怪的原因。
Unix服務器重啟的原因
如果我們只是簡單查看幾分鐘之後就一拍腦門決定重啟設備，那麼也許故障的真正原因就徹底湮沒在時光中了——也許是某位初級管理員在運行一套自己編寫的愚蠢腳本時無意中刪除了/boot目錄或者/etc、/usr/lib64目錄下的部分內容。這正是引發分段故障以及設備不穩定情況的罪魁禍首。然而一旦我們選擇直接重啟服務器而沒有深入挖掘問題，那麼顯然問題會變得更加嚴重，接下來不出意外的話大家應該會啟動恢復鏡像——這就代表需要面對大量恢復工作——而與此同時生產服務器也將陷入停機狀態。
以上只是我們在Unix領域中應該盡量避免重啟操作的原因之一。與其說這算是種故障排查方法，不如把它看作一類孤注一擲的豪賭——要麼發現問題，要麼親手毀掉一切再慢慢重建。總之，沒人能利用/var分區重啟設備就完全修正錯誤。
服務器重啟前請做完你該做的工作
在大多數情況下，不進行重啟是極其重要的，因為系統中能夠幫助我們修復問題的關鍵性內容在重啟前是一定存在的，但在重啟後卻未必還在。重啟之後問題絕對會再次出現，然而一旦解決方案隨重啟行為而煙消雲散，那麼故障本身就陷入了無解的死循環中。除非有人決定不進行重啟，而是嘗試找出問題的根源。遺憾的是，能做了這種明智選擇的人實在少之又少。實際情況是：一根小小的故障內存條就能給系統正常運行與設備啟動狀態帶來極大的麻煩。而這個時候，對症下藥才是上策，一味重啟只會帶來額外的損失。
因此，今後大家在面對問題時，如果有某個家伙說什麼“嘿，不如先重啟一下看看”，不妨直接給他兩個大嘴巴。重啟當然是方案之一，但在實施重啟前請務必確保我們已經采取了一切能夠想到的處理措施;畢竟節省下來的都是咱們自己的時間跟精力嘛。
