服務器故障排除是一門精細的工藝，但也有一些方法和技巧可以把這件事情變得簡單和快速。

ITIL方法深入研究如何解決服務器故障或相關問題，但總的主旨是盡可能快速和有效地縮小問題范圍。

退一步想想如何從邏輯上解決中斷期間的問題。例如，如果有用戶抱怨不能訪問一些東西，看看其他用戶有沒有相同的問題，這樣可以消除本地某個具體終端用戶設備問題的可能性。

以下全方面指南旨在幫你考慮故障診斷流程和過程。請結合你自己的指導原則和技術優勢使用。

問題普遍存在嗎？

你需要的第一條信息是停機或效率變慢發生的范圍以及產生了什么樣的影響。就像是網絡問題可能是因為踩線而影響了一臺PC或小的群集。

如果同一問題影響到了多位用戶，可以排除環境變量，比如本地PC上的軟件誤操作或硬件問題。

如果你有多個網站，它們全部受影響嗎？這樣可以確定問題是否在于本地服務器。

是服務器引起的問題嗎？

不同的部門之間傾向于相互指責。系統管理員會將服務前臺緩慢的應用程序響應歸咎于網絡；網絡管理員抱怨存儲區域網絡（SAN）；存儲管理員指責軟件部門。如果你正在解決一個問題——尤其是像應用程序變慢這類無法確定原因所在的問題——那么，確定數據中心里哪些區域的基礎設施受到了影響。當多個服務器和應用程序發生故障，通常可以排除服務器問題，真正的問題可能來自網絡或存儲陣列。虛擬化環境中，檢查所有受影響的虛擬機的物理主機位置，確保它們沒有共享受損的硬件。

通過排除，結果最終通常會指向某個明確的罪魁禍首，但并非總是如此。發現問題的共性，嘗試不同的因素組合，以縮小可能性。例如，問題可能源于文件共享時復制時間過長。如果在相同站點上，從一臺服務器復制到另一臺服務器時，是否也很緩慢？如果是的話，可排除廣域網絡的嫌疑。在服務器上的本地磁盤之間復制過程是否緩慢？如果是的話，可排除SAN或局域網的嫌疑。如果你不得不使用數據包捕獲

或輸入/輸出（I/O）速度測試，故障排除可能需要很長時間。

文檔

文檔是一個非常有價值的故障診斷工具，可輕松訪問你的環境的拓撲，并了解應用程序是如何工作的，讓你能夠迅速排除服務器問題。

你需要有扎實的數據中心操作知識，并拷問自己幾個重要的問題：每個應用程序涉及多少臺服務器？基本的網絡設置是什么？當前是什么基礎設施？這些問題很有價值。例如，如果你有兩臺應用服務器供客戶端通過循環DNS訪問，同時你的一半用戶反饋有問題。你從一開始就知道一半的用戶連接到各自的服務器，因此你不會將時間浪費到另外一臺服務器上并試圖解決問題。

溝通

溝通是診斷服務器故障的關鍵。例如你的同事昨晚更改了服務器設置，結果第二天一些東西無法使用。你需要了解做了哪些更改，因為這可能就是原因所在。大型企業有正式的改革形勢，涉及到每個人，但并不是所有的IT小組都會享受（或者阻礙，這得看你怎么看待這件事了）的。

當一個新的應用程序或其他項目改變投入生產時，溝通可以幫助數據中心團隊做好準備并積極地檢查環境。否則當終端用戶開始抱怨應用無法正常工作的時候，你不得不詢問新應用程序的部署和資源需求等情況。

監控

在對服務器進行故障排除時，對正在進行的操作進行完整的描述可以幫助節省時間。

市場上有很多監控工具用于不同規模和架構的數據中心。正確配置之后，它們會跟蹤關鍵指標，如延遲和I/O速度等。監控工具還會提醒你潛在的有用的信息，例如一個只剩1%磁盤空間的驅動器將要導致服務器問題。

很多產品還會對服務進行監控，因此如果某個關鍵服務崩潰或中斷，監控工具會發出警告或自動按照已設置的規則嘗試重啟。

檢查日志

令人驚訝的是，服務器和相關的日志常常被忽視。

當出現問題時，技術人員認為他們知道問題出自哪里，并且會花好幾個小時來證明他們的正確性。但是如果他們花上幾分鐘的時間檢查一下日志，會發現已記錄下來的確切的問題。例如，如果你知道正在交互的兩件事情以及它們的賬戶，就能夠很容易解決許可問題。

查看微軟Windows中的Event Viewer日志或Unix/Linux服務器上的系統記錄，這上面顯示了警告和錯誤。應用程序日志也值得一看，因為它們通常包含錯誤的數據，為你指向正確的根本方向。

支持

有些管理員調用供應商和日志記錄，但最好不要這樣做。檢查基礎事項之后，花幾分鐘調用日志，而不是直到停機幾個小時后再這樣做。

在解決事情之前不要著急，檢查數據中心供應商支持的服務水平協議。如果你的供應商直到第二個工作日都沒主動聯系你，記錄問題可以盡早避免一個令人沮喪的夜晚。

許多供應商網上有具體說明如何解決服務器問題。從知識庫和在線論壇中檢查供應商的資源。

不能排除服務器問題并且在前五分鐘內解決問題著實會令人沮喪，但是不要害怕尋求幫助。充足的準備、溝通和對環境的理解是拯救錯誤的有利工具。