軟體工程與網路維護的統一方法論

今天下午協助諾西的工程師解決了一個網路的小故障，回來的路上回想了整個解決問題的過程，發現解決問題的思路和軟體工程的解決問題的方法是一致的，基本上就是一個套路，方法論是抽象於技術之上的。

問題是這樣的：前天下午我們網管區域網路突然出現大量丟包，網路嚴重阻塞，到其中一個機房的資料通訊全阻。整個區域網路處於一個廣播域，我的機子也在這個廣播域中，也受到影響。不多說直接上wireshark，抓包結果發現大量的Ethnet II的包，源和目的地址都是mac地址，協議unknown，很顯然是這是個廣播風暴。由於到那個機房最嚴重，完全不通，無法維護軟交換裝置了，叫上公司的車趕到機房先看看再說。

開啟機櫃門，諾西廠家最近新加了一對CE和一對SPC，四根網管的網線赫然接到同一個網管交換器上，這個交換器級聯到匯聚交換器再到省裡去，簡單粗暴的拓撲，呵呵。上網管的時間和故障發生時間幾乎都是在那天下午，時間上一致，應該和這個有關係，因為裝置還沒上線，斷然拔掉這四根網線，測試，故障消失。

第一感覺就是有環路，這也比較明顯，有網路基本知識的都知道。

回來後把問題告知廠家檢查CE和SPC之間是不是有環路串連，廠家認為CE間是三層串連不會出現環路。

今天廠家約我一起到機房去查故障，好吧，去看看。筆記本接上網管交換器，持續ping網關，測試丟包情況。

廠家說他們核查沒什麼問題，我說這樣吧，你把拓撲給我：

上面是拓撲圖,顯然四根線都有可能分別形成一個環路。

撕下一頁紙，把拓撲複製一份，標上1,2,3,4，我說你到那頭去，先把1234都拔掉，然後我要你插那根你就插哪根，一根一根加，看什麼時候會丟包。

先加1，沒有丟包

再加2，沒有丟包

再加3，出現丟包

拔掉3，插上4，沒有丟包

明顯就是3所在的這個環有問題，廠家這時說三層的路由器的怎麼會呢，我說那要看是不是二層串連，這時廠家說CE1和CE2的這兩個介面屬於同一個VLAN，我說那不就出來了嗎，你兩個CE處於同一個VLAN16然後又接到一個廣播域裡面去，不就創造了一個環路嗎。廠家說看看網管交換器資料， 顯示配置沒有STP，於是說STP沒開所以會有這個問題。這時我就不同意了，STP產生樹檢測不能為環路的出現負責，假定其他的裝置將STP開啟的前提是沒有道理的，因為沒有STP你也應該消除環路，stp的職責是檢測和保護不是允許你出現環路。 我說這根本的原因不是STP，而是你不該做CE的trunk透傳這個vlan的資料，每根線都獨立串連到網管交換器，網管又不需要保護切換，這個資料是多餘的。廠家點頭，對，是不需要。

取消trunk的vlan16，問題解決。

----------------------------------------------

 這是網管維護中的一個很小的故障，但是我後來想了一下發現很有意思，因為我處理這個問題很多地方都體現了一個程式員的思維。

步驟：

	Programming Debug	Networking Troubleshooting
1	分析你的架構，定位你的問題可能出現在哪些代碼模組，估算大概位置	畫出網路拓撲圖，找出可能的環，標出可疑的串連
2	退到可測試通過的版本，然後一點一點的增加代碼，測試，再增加，測     試，直到問題出現	拔掉可疑的所有串連，回到正常情況。增加一根，測試，再增加一根，測試，直到問題出現
3	找到問題代碼後，分析出現的原因	找到問題鏈路後，分析出現的原因
4	修改資料或者重構，解決問題。	修改資料，解決問題

原則：

1、不要認為你的代碼沒有問題：

          三層串連沒有環路嗎？如果是二層呢？

2、不要用其他的理由為你的問題找借口，不要讓你的代碼高耦合，成功運行不應該依賴於附加的非必要的前提條件：

      STP不應該為環路的出現負責，查環路不應該把STP作為前提，應該在沒有STP檢測保護的情況下也能正常工作。

類比：

設計模式和通訊協定也是一樣

如TCP/IP七層協議:

底層好比抽象類別，上層好比實現，實現必須依賴於抽象。

下層封裝了上層資料，抽象封裝了多種實現。

上層出問題，先看下層有沒有問題，一層一層來看。模式架構的問題首先出現在抽象層封裝不好。

凡事的道理都差不多，抽象，高觀點的看待問題總是能發現問題的一致性，從而可以重用移植方法達到共性的解決。

掌握科學的思維工具所獲得的生產力是巨大的。