基本上故障修復的方法有兩種，自上而下和自下而上。下面本站小編帶來網路故障自上而下的修復方法，希望對你有幫助!
在自上而下的方法中，我們從OSI協議棧的最上層開始分析。我們要先測試應用是否正常工作，然後ping伺服器，等等。直到我們到達協議棧的最底層，也就是物理層。這個方法最適用於多使用者進行服務檯呼叫的情況。物理層問題幾乎很少可能成為影響所有使用者的問題，當然，除非遇到伺服器連線問題時。這個方法可以用來確定應用或伺服器是否DOWN了、變慢了，或者其它某些原因沒有響應網路命令。為了有效地執行，它往往是在某種工具或者網路監控應用協助下工作的.，這些工具和應用是可以提供某種有規律和可操作的資料。
可操作的資料可能是簡單的ping，可能所有監控通過SNMP陷阱傳輸的位錯誤和其它錯誤的結果都是主機無法訪問。然而，真正的目的是確定錯誤的起因。為了有效地實現，必須有一個系統故障修復計劃。這當然不只包含重啟伺服器。如果伺服器出現故障，那麼它一定是由於某些原因引起的。雖然原因可能是記憶體洩露、處理器過度使用，或者其它問題，但是重啟只能作為臨時方法，而非根本的解決方案。因此，這時的可操作資料是什麼呢?就是能夠提供足夠有用和明確的資訊來確定行動計劃的資料。
大多數管理軟體包和監控工具允許網路管理員設定超出效能外的可接受範圍的限制。想要掌握應該在哪裡可以為特定問題設定限制是需要不斷地探索的。設定值過低將會造成警報過密，設定過高將會導致系統宕機。盲目地接受預設設定可以導致工具利用率不高。任何時候部署管理軟體，我都建議花點錢接受培訓。最理想的培訓是請通過軟體包認證的人來做實地培訓——在實際環境中。這樣我們就可以刪除不想要或者不需要的模組，同時優化能為我們提供最好資訊的模組。頻寬消耗大的應用和負載高的伺服器最好進行更多的調優。
管理軟體的另外一個優點是它能夠查詢不同的裝置和在報告工具中保留資料統計和變化趨勢。以前，我們必須根據伺服器軟體和啟用的電子器件來雙擊各種不同介面上的每臺交換機來檢視 ，至今很多環境仍然採用這種方法。這太繁瑣了!現在，只要一個工具，就可以對趨勢分析和綜合流量報告進行匯出、排序操作等等。這些也可以用來調整新的裝置和升級(這只是一個附加功能)。趨勢分析和利用模型的一個優點是它允許我們確定哪些伺服器可以受益於多網絡卡。同時，它也允許我們將交換機進行分組，這樣我們就可以平衡每臺交換機的總資料包，同時就不會出現有的交換機負載過高而有些使用不足。而且它還有助於我們瞭解各種型別的資料包的流向，從而可以對它們進行優化。