收藏！系統運維中網路知識實用總結

【摘要】運維是一門藝術，也是一門苦差事，每個人對此均有不同的理解，正所謂一千個人眼中有一千個哈姆雷特。幹一行就要愛一行，既然選擇了這個行業，最好是能把它做到最好，發揮自己最大的價值。本文來聊聊在日常運維當中涉及網路的方方面面。分為以下四個方面：系統運維網路方面的規劃和思考、系統運維中網路方面操作梳理、系統運維過程中需要掌握的利器、故障的診斷與分析，同時也將分享一些具有參考意義的經驗和方法。

【作者】董志衛，任職於李寧（中國）體育有限公司，深耕運維領域多年。

來源：twt企業IT社群

一、系統運維中網路方面的規劃與思考

在很多公司，崗位職責都是很明確的，專職轉崗，每人或者每組負責一塊業務。系統運維崗基本上在IT架構上相對偏後一些，該崗位和網路管理崗基本上是平行的。因為今天我們們說的是系統運維方面網路方面的事情，或多或少都會和網路崗打交道，那麼談一點網路崗的內容就顯得很有必要。

系統運維建立在網路的基礎之上，如果沒有一個相對合理的網路架構，恐怕系統運維做起來也不是那麼的順手。一個公司基本上都會把網路和伺服器獨立開來，劃分不同的區域擺放裝置，很多時候都是物理隔離。伺服器接入交換機大多是經過配線架連線起來和有的伺服器機櫃頭櫃安裝網路交換機，是相對比較常見的兩種方式。

走線從側面可以反映一個企業對IT的重視程度和投入，很多企業是做不到如圖這麼漂亮的效果的。這一切一切還要立足於預算，現在基本上沒有預算啥事也幹不了。

大多數IT機房當初建立的時候，從裝置混亂擺放到區域明確劃分存放，又從區域功能明確到後來的後來的功能區域模糊，都反映了一個問題：計劃趕不上變化。十年前還相當前衛的規劃，到現在已經跟不上時代，這並不是誰的錯，還是要求我們去適應去改變，業務引領變革，基礎架構也需要做相應調整，所謂唯一不變的就是變。

我心中企業目前現階段相對比較理想的架構這樣的，如圖所示：

這樣一個傳統企業典型的網路結構，保證每個核心節點都是雙鏈路，鏈路異常自動切換，各種切換在這種典型的網路結構上都或多或少的簡單或複雜，不盡相同。網路方面關注幾個點：穩定，安全，自動化。業務系統元件也儘量避免單點問題。

這樣後端業務系統在連線網路層面穩定性就有了保障，在主機系統層面，儘量避免單獨問題，消除效能瓶頸，異常能夠自動告警自動修復得相對比較完美，當然這一切還要立足於預算。

二、系統運維中網路方面操作梳理

在系統運維中，經常涉及的網路方面的操作，一般由以下幾個方面組成。

1.裝置上線，物理連線設定

很多運維人員要從事從剛開始立項到專案上線再到後期運維的一條龍服務，每個環節都要自己親自動手，這是好事也是壞事，好的是自己的環境一般會非常的熟悉，不好的是事必躬親，不出活，業績不明顯。插個線都要自己來，你恐怕也沒太多精力幹其他的，這就是個矛盾體，自己把握就好。

2.網路邏輯配置調整

這一塊內容就涉及到了具體的操作，你可以手工一步一步操作，也可以藉助高大上的工具批次完成，這個要看企業的IT建設的能力。一個掩碼一個點錯誤都會導致網路連線異常。如果自己有開發能力也可以使用指令碼或語言寫成成型的東西，平時多多積累，使用的時候就會方便很多。

具體內容涉及：

1） 配置ip，別名，設定個埠監聽，繫結個網路卡，設定個路由

2） 劃分個vlan，配置個trunk

3） 測試個埠，配置個監控

具體的操作過程在此不做過多的介紹，比如做個網路卡繫結啊，測試個埠啊，這些操作網上有大批的文件可以查閱，本節內容就是描述在日常的Linux系統運維方面所涉及網路方面的操作，有一個整體的印象。

3.效能分析與最佳化

該部分內容相對不太容易操作，不是隨隨便都可以依葫蘆畫瓢就能完成，效能穩定分析和定位相對困難一些，很多場景都需要結合多個方面進行統一分析。這個需要一些工作經驗的結論和沉澱，選擇合適的工具，多方面配合往往會有比較好的效果。

工欲善其事，必先利其器：

熟練掌握該圖上面的各種工具，基本上可以解決效能分析99%的工作，那剩下的1%的不是bug就是天災。這裡其實在說笑了，但這也說明一個好的工具有多麼的重要。剩餘就是要仔細認真，再好的工具，不會用也不行，態度是第一位的。

三、系統運維過程中需要掌握的利器

在上文中分享了一個圖，該圖涵蓋的面比較廣，本節內容主要針對網路方面進行一些梳理，分享一下在工作當中經常使用的利器。

首先我們來分享一張目前Linux 系統效能檢視調優工具圖：

這張圖片基本上涵蓋了Linux系統各個方面的效能工具，可以說相當的全面，下面我們看一下有關網路方面我們常用的命令或工具有哪些，這樣有助於大家方便檢視和使用。

以上工具基本上在日常工作當中經常會使用到，每個工具都有其側重點，這裡列舉的只是大量工具中的一小部分，因為每個人使用習慣不一樣，各有側重，選擇適合自己就好，以上工具僅供參考。

本文內容意在梳理分享，不在具體的工具使用方面做更加深入的講解，因為每一個工具如果詳細講起來都會涉及大量篇幅，也不可能面面俱到，有興趣的可以在社群或搜尋引擎搜尋之。

推薦小工具：

Dig，ethtool，iperf，iftop，dstat，mtr

比如在你想知道兩個主機之間的頻寬是否能夠到達相應的頻寬，請使用iperf。想動態的檢視目的地是否可到以及延遲等資訊，請使用mtr。

四、故障的診斷與分析

故障診斷處理方面不是一兩句話就可以說清楚的，很大程度上在於平時經驗的積累，很多故障都是相互關聯的，如何順藤摸瓜，找到問題的最終原因，有一些方法可以借鑑。這裡不具體描述解決那個問題用了什麼方法，只是聊聊解決問題有哪些經驗和技巧。

分享一點小小的經驗：

a)平時要多問幾個為什麼

b)故障是否可以重現，找到第一個場景，關注整體結合細節

c)多方面相互參考，同事之間相互配合

d)可以多做幾個假設，直到推翻自己的想法

e)自己的工具箱要有幾個使用順手的TOOLS，包括自己開發的

以上只是一些解決問題的方法，具體問題還要具體分析。

下面我們結合一個真實的案例來描述一下：在出現網路故障時，。我們如何想辦法快速的排除問題。

場景描述：

某日下午，公司裡內部的業務系統突然出現反應比較慢的問題，多個業務管理員過來描述問題現象。近期一段時間內曾出現過類似的問題，該類問題的原因是由於業務區的防火牆老舊，處理能力不足，導致CPU在短時間內使用率激增，超過了境界閾值很多，導致此類現象的發生。

解決思路：

1）初步定位

又是類似問題的出現，肯定不是個別業務系統的問題，一看就是有共性的，問題應該是出現在網路裝置上才對，這樣才會造成大面積的問題，可是該防火牆一週前已經升級換代了，不應該有此類問題了。檢視業務區域拓撲，因為拓撲已經在心中，直接搞起。

2） 逐步排查

首先登入新的防火牆，檢視CPU使用率，一切正常，看來問題不在此。

然後登入業務系統去交換機檢視負載，一看果然是高，高達99%，我勒個去，配合網路管理員檢視問題原因，檢視各種效能資訊，初步沒有太合理的線索，不能精準定位問題。收集各種資訊準備發給廠商支援。

3) 協助排查

多方回憶近期有無做過其他操作。

網路方面： 一週前升級換代該區域防護牆

主機方面： 昨天接入6太新裝置，並做埠繫結bond

4）再次排查

由於該區域Windows主機裝置均已經安裝防毒軟體，病毒的可能性不大，Linux 病毒可能性就更小了，先初步忽略。 由於昨天上線6個主機裝置，著重觀察網路裝置所連線埠，

透過交換機和監控效能檢視分析該埠今天出現流量過大的問題，埠飽和。由於影響業務面比較廣，需要快速定位問題或者暫時消除影響。初步意見，交換機上線shutdown 這6臺機器所連埠。持續觀察了一段時間，交換機CPU 負載下來了，其他業務逐漸恢復。考慮到已經下班，暫時觀察一下，明天看情況再做調整。並結合一下廠商意見。

5） 第二日上班後，6臺機器業務恢復，交換機CPU負載又上來了，但是其他業務沒有影響，什麼情況？再次進行梳理，找問題線索。

6） 進一步排查

網路管理員開啟debug 檢視資訊，經過一段時間的分析梳理發現有12個mac 地址頻繁的在兩臺交換機來回出現，核對mac 後，可以定位引起CPU過載的原因是這新上線的6臺機器（每臺機器兩個埠bond），果斷拔掉其中一個埠，交換機CPU負載很快下來，那麼就可以能定位bond繫結有問題。

7） 系統進一步排查

我做了很多次bond了，就算這次換了一個高版本作業系統應該也沒有問題啊，果斷檢查之，檢視繫結模式，一看模式為0 ，當時一驚，不應該啊。進一步檢視確實是模式配置錯誤了，當初我想設定的是模式6，後來不知道怎麼寫成0 了，以為其他機器都是複製過去的，所以都是模式0了，立馬改之。重啟網路卡，一切看似正常，重新插入網線觀察交換機CPU 負載很穩定。這次CPU高應該是這個引起的無疑了，這個鍋扣到我腦袋上了。

8）下午14:00，問題又出現了，這次交換機的cpu也不高了，什麼情況，一臉懵逼的狀態。

再次排查，這次聚焦交換機，收集大量資訊反饋給廠商，很快廠商給出的建議說是埠飽和丟包嚴重，影響了其他業務埠的正常使用，經過廠商進一步排查確認，該型號交換機雖然以前效能很好，但是已經屬於老舊裝置，該型號埠組背板能力只有1G，該組其他埠頻寬總和已經超過了1G，屬於交換機處理能力不足。

9) 進一步協調該專案人員，調整大量互動埠成內網私有網段，單獨使用一個千兆交換機做內部業務互動使用，外部訪問還繼續走這個交換機。最終這個問題得到解決。

總結：

此次事件引出三個問題：

1.埠繫結不可馬虎，需要仔細再仔細，並做驗證

2.預估業務埠網路流量不足，主機裝置連線分配不合理

3.交換機老舊，處理能力不足

後續應該針對此類事情多多的總結，升級換代產品，深入瞭解業務特性。