【服務器在線 】

　　導讀：對于系統管理員來說如何管理自己的服務器已經是再簡單不過，但是如何管理好服務器卻不是一個簡單的事情。對于管理員來說重啟服務器可不是一件鬧著玩的事情。對于Windows服務器管理員來說經常性重啟Windows設備已經成為一種生活常態，但在Unix系統中這種辦法卻難以奏效——在默認情況下重新啟動不會帶來任何形式的改善。

　　關鍵詞： UNIX服務器

　　對于系統管理員來說如何管理自己的服務器已經是再簡單不過，但是如何管理好服務器卻不是一個簡單的事情。對于管理員來說重啟服務器可不是一件鬧著玩的事情。對于Windows服務器管理員來說經常性重啟Windows設備已經成為一種生活常態，但在Unix系統中這種辦法卻難以奏效——在默認情況下重新啟動不會帶來任何形式的改善。

　　我打算借此機會跟大家詳細聊聊重啟的問題。對于每一位服務器管理員來說這都算得上熱門話題，但在Unix極客們眼中它則屬于一種層次更深的課題——可能因為Windows管理員們往往把重啟當成故障排查工作的首要步驟之一，而Unix團隊則一般只在束手無策的情況下才進行嘗試。

　　Unix服務器重啟的兩種情況

　　實際情況是：服務器重啟操作應該極少出現——請注意是極少。在這里我列舉內核更新與硬件更換作為例子，因為它們是Unix領域中引發重新啟動的兩大主要原因。有些人一直在鼓吹什么不重啟服務器的話會帶來某些嚴重的安全風險，這簡直是一派胡言。如果服務項目與應用程序中確實存在安全風險，那么打上漏洞補丁就能解決問題了，而且補丁往往不要求重啟設備。而如果安全風險存在于內核模塊中，一般來說只需卸載對應模塊、安裝補丁，***后重新加載模塊。沒錯，我承認一旦內核中存在安全風險，那么重啟操作的確是必要的。但在這種情況之外，大家根本沒有切實的理由重新啟動Unix服務器。

　　有些人認為如果不進行重啟操作，其它形式的風險往往會接踵而至，例如某些關鍵性服務項目在開機時沒有得到正確啟用，而這將導致一系列隱患。當然，這種說法本身是正確的，但只要管理工作執行到位，這其實根本就是種杞人憂天。只有剛剛接掌服務器設備的菜鳥才會忘記正確設置服務項目的啟動參數。不過話說回來，如果大家的服務器正處于構建階段，且其中還不涉及任何生產方面的內容，那么不妨隨意進行各類重啟測試，這不會帶來任何不良影響。而且我認為這正是熟悉重啟機制的******時機。

　　但還有另一方面需要考慮：那些將重啟操作當成故障排查重要步驟之一的家伙是抱著死豬不怕開水燙的心態，打算一次性把問題都暴露出來。就說一套已經出現問題的Unix設備吧，某些還處于運行中的服務項目實際上已經無法再次啟動，而這一點在重啟之后就會顯現出來——也許是由于分段故障或者其它稀奇古怪的原因。

　　造成Unix服務器重啟的原因

　　如果我們只是簡單查看幾分鐘之后就一拍腦門決定重啟設備，那么也許故障的真正原因就徹底湮沒在時光中了——也許是某位初級管理員在運行一套自己編寫的愚蠢腳本時無意中刪除了/boot目錄或者/etc、/usr/lib64目錄下的部分內容。這正是引發分段故障以及設備不穩定情況的罪魁禍首。然而一旦我們選擇直接重啟服務器而沒有深入挖掘問題，那么顯然問題會變得更加嚴重，接下來不出意外的話大家應該會啟動恢復鏡像——這就代表需要面對大量恢復工作——而與此同時生產服務器也將陷入停機狀態。

　　以上只是我們在Unix領域中應該盡量避免重啟操作的原因之一。與其說這算是種故障排查方法，不如把它看作一類孤注一擲的豪賭——要么發現問題，要么親手毀掉一切再慢慢重建。總之，沒人能利用/var分區重啟設備就完全修正錯誤。(另外請別提什么打開文件句柄這類迂腐的蠢話——我想大家應該理解我的意思)

　　服務器重啟前請做完你該做的工作

　　在大多數情況下，不進行重啟是極其重要的，因為系統中能夠幫助我們修復問題的關鍵性內容在重啟前是一定存在的，但在重啟后卻未必還在。重啟之后問題******會再次出現，然而一旦解決方案隨重啟行為而煙消云散，那么故障本身就陷入了無解的死循環中。除非有人決定不進行重啟，而是嘗試找出問題的根源。遺憾的是，能做了這種明智選擇的人實在少之又少。實際情況是：一根小小的故障內存條就能給系統正常運行與設備啟動狀態帶來極大的麻煩。而這個時候，對癥下藥才是上策，一味重啟只會帶來額外的損失。

　　因此，今后大家在面對問題時，如果有某個家伙說什么“嘿，不如先重啟一下看看”，不妨直接給他兩個大嘴巴。重啟當然是方案之一，但在實施重啟前請務必確保我們已經采取了一切能夠想到的處理措施;畢竟節省下來的都是咱們自己的時間跟精力嘛。