運維是一門藝術，也是一門苦差事，每個人對此均有不同的理解，正所謂一千個人眼中有一千個哈姆雷特。幹一行就要愛一行，既然選擇了這個行業，最好是能把它做到最好，發揮自己最大的價值。
分為以下四個方面：
· 一、系統運維網絡方面的規劃和思考
· 二、系統運維中網絡方面操作梳理
· 三、系統運維過程中需要掌握的利器
· 四、故障的診斷與分析
同時也將分享一些具有參考意義的經驗和方法。
一、系統運維中網絡方面的規劃與思考
在很多公司，崗位職責都是很明確的，專職轉崗，每人或者每組負責一塊業務。系統運維崗基本上在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.交換機老舊，處理能力不足
後續應該針對此類事情多多的總結，升級換代產品，深入瞭解業務特性。
8
閱讀更多 不一樣的旋旋 的文章
