網路工程師眼中的自動化運維

“網路就像wifi，沒有故障的時候，就沒有人意識到它的存在”，這句話有無數的翻版，但是對於網路工程師來說這就是現身說法。由於網路工程師的人數即便是在上千人的公司，也僅僅是個位數，所以他們的工作也鮮為人知 。“網路是不是有問題？”這句話幾乎成了所有SRE排錯時的口頭禪，如果這個時候網路工程師表示沉默，或者無法拿出足夠的證據，那背鍋幾乎是無疑的，如何讓網路環境的執行狀態更加透明，如何在每次業務故障的時候自證清白，這不僅是基礎服務團隊要關心的內容，更是整個技術團隊想要瞭解的黑匣子。    

網路裝置的監控最好和業務監控系統儘量解藕，因為網路故障極有可能引發業務系統異常，如果恰巧導致的是業務的監控系統異常，那網路裝置的告警將失去可靠性，“監控不準”且不說這個鍋是誰的，這種局面會讓網路工程師Trouble Shooting時陷入被動，延長了故障時間。

每一個網工在走出校門的那一刻，都已經具備基本的程式設計基礎， 況且交換機的數量和伺服器的數量有著量級上的差別，所以如果你能看懂幾句python，100+的python程式碼即可搞定一個簡易的裝置存活監控的程式，Github中可搜尋 NodePingManage 就是一個很好的例子，還可以透過多點部署來消除單點故障。有了這類工具， 從此全網的各個角落的可達性終於明瞭， 漆黑的網路環境，似乎反射出了一絲光明。 

裝置存活告警雖然可以預警很多異常，並且準確度很高，但是對於冗餘性做的比較好的網路，能Ping通並不代表完全沒問題，此時，細心的網路工程師會去看日誌，這裡可以反映出更多細節。對於萬臺伺服器規模，網路裝置的數量也就千臺，但是逐臺檢視日誌，人肉判斷是否有異常，那簡直是場噩夢。

《日誌告警》程式就成為網路工程師們居家旅行必備之良品，只需要一臺Syslog伺服器，部署一個日誌監控程式，當發現日誌中出現特殊關鍵字，觸發郵件+簡訊告警即可。這麼高大上的工具當然需要更多的程式設計技巧，150+ python程式碼才能搞定。Github中類似的解決方法有很多，搜尋 LogScanWarning 即可得到一個示範案例。

從此你可以在業務無感的情況下，發現網路中的異常， 例如：風扇轉速異常／電源模組故障／ospf鄰居狀態抖動／埠flapping／有駭客在爆破我的裝置／裝置硬體parity error／模組收發光異常／Kernel報錯等等。優秀的網路工程師可以在故障發生時快速定位，牛X的網路工程師可以在故障發生前就消除隱患，防範於未然。

高速公路鋪的再好，也架不住車多人多。確保網路順暢，品質優良，沒有丟包，延時穩定也是網路工程師的職責 ，此時流量監控就成了剛需。業務的飛速發展體現在網路層面就是DC內流量上漲／DCI流量上漲／IDC出口流量上漲／專線流量上漲，流量監控可以準確掌握業務的高峰和低谷，當線路需要擴容時，頻寬使用率是老闆參考的重要資料。一般情況下線路中的流量超過50%即可發起擴容，因為這意味著當備份鏈路down之後，主線路將出現擁塞。

介面的Error包監控和流量監控一樣，均可以透過snmp採集，OID：ifOutErrors，ifInErrors ,  Error包出現增量會直接影響業務的服務質量，一旦發現需要優先處理，否則業務會拎著一堆TcpTimeOut指標找上門來。當然，可以透過snmp採集的資訊還有很多，例如：裝置的CPU／記憶體／溫度／防火牆的Session等，掌握這些資訊對瞭解裝置的工作環境也頗有益處，如果你要做一個自動化巡檢工具，那麼這些指標必不可少。市面上提供網路監控的軟體有很多，例如：

Falcon/Zabbix/Solarwinds/Cacti/Nigos 等，有開源的也有收費的，功能類似，此處不加贅述。

第一章中的組合拳打完之後，基本上不會出現“意料之外的故障”，所有的異常都應該有據可查，當SRE莫名其妙提出對網路環境的質疑時，你應該早已心中有譜。但是網路工程師的工作並非只有救火，日常運維工作中，經常需要配合業務發展做一些線上變更/ 機房擴建／業務類故障排查等。作為一名“懶惰”的網路工程師，程式可以幫忙點什麼忙呢？

這個名詞借用於Solarwinds套裝中的一個元件，直譯為“使用者裝置追蹤器” ， 在中小型企業網運維中，經常會有這樣的需求：

• 知道伺服器的IP，請問連線在交換機的哪個口？

• 知道交換機的某個埠，請問連線的伺服器的IP是多少？

• 給你一臺伺服器的MAC地址，怎麼知道在哪個交換機的哪個口？

大型網際網路公司一般會有CMDB或者網路管理平臺來記錄這些資訊， 但是如果你是一家中小型企業的網管，沒有運維研發團隊做支援，並且還在沿用二層的環境（伺服器閘道器在核心裝置），那就比較費勁了。以上幾個問題其實歸根到底是要捋清楚三個要素的對應關係： PORT<>MAC<>IP   

舉個例子：

一臺交換機有多個物理介面，一個物理介面下可以有多個MAC，一個MAC可以對應多個IP，或者不對應任何IP。 有了這個基本的模型，只需要做兩件事情即可找到全網裝置這三元素的對應關係。首先去伺服器直連的交換機獲取MAC表（即MACPORT）， 然後再去伺服器的閘道器裝置獲取ARP表（即IPMAC），這兩張表根據MAC地址作為唯一主鍵即可得到 PORT MACIP 的對應關係。 資訊的獲取可以透過模擬登陸或者OID採集均可，Github中也有很多類似的程式碼可供參考，有了這個對應關係，即便沒有CMDB，你依然可以快速定位想要的資訊， 普通網工查詢這個資訊需要5分鐘， 而你只需要5秒鐘。

日常網路運維工作中，經常會有一些 “簡單重覆勞動”，例如：為某個介面劃分Vlan／給某臺裝置新增一條指向主機的路由等， 這些操作即沒有科技含量，還佔用了工程師寶貴的時間，更要命的是再簡單的人肉操作，重覆的次數只要足夠多，總有失誤的時候，正所謂“常在河邊走，哪有不濕鞋”，但是在這種問題上犯錯誤簡直是對職業生涯的抹黑，如此“雞肋”的工作怎麼才能幹的漂亮？

以《自動劃分交換機介面Vlan》的功能為例， 如果有一個工具只需要你提供三個引數：裝置IP／埠／vlan編號， 就能自動登陸裝置把特定介面劃分到指定Vlan，那豈不是美哉。沒錯！你需要的是一個對裝置封裝後的介面， 現在多數網路裝置廠商都會提供自己的API，無論是NETCONF還是RESTful，只要讀懂了使用手冊，即可透過程式輕鬆變更裝置的配置，甚至你可以用更加”接地氣”的方法，用程式“模擬登陸”裝置 ，雖然這個方法在效率上比不過NETCONF和RESTful API，但是在通用性上那簡直無敵，因為沒有哪個廠商的裝置不支援SSH或者TELNET的。

有了這個理論基礎，一些簡單的網路上的操作就可以透過自己封裝的介面來實現變更，甚至可以把變更的許可權交給業務，只要業務提交的請求是合法的，變更可立即上線生效。此時，肯定會有人大驚失色！把網路裝置的許可權交給業務，這樣真的好麼？萬一改壞了怎麼辦…所有的疑惑都是正常的，同時也都是有解的。還以《自動劃分交換機介面Vlan》舉例子，你可以限製程式執行的內容，你可以規定交換機只能是TOR不能是CSW，你可以約束介面只能是Access不能是Trunk，你可以限定被操作的介面下流量必須為0bps，以避免誤操作影響到業務，你可以透過動態Token保證介面的安全，你可以要求必須提供介面下現存的MAC以定位介面的位置，你還可以對呼叫者加白名單，另外，操作成功後還需要有簡訊+郵件反饋操作後的結果，等等…   

 所有的考量都可以固化為程式碼規則，只有程式是最忠實的執行者。介面可以提供7*24 小時全年無休的服務，而人的精力是有限的，用程式去應對業務那些簡單有規律的需求，節省出工程師寶貴的時間來思考人生，這才是網路工程師自動化運維之路的正道。

以上，是筆者結合自身工作經歷總結的一些心法，寫程式碼對於網路工程師來說確實有些難度，但是隻要跨過這道坎，你會得到更多富裕的時間來擴充套件自己的專業道路，謹以此文，希望能拋磚引玉為自動化網路運維盡綿薄之力。