引言

“網絡就像wifi，沒有故障的時候，就沒有人意識到它的存在”，這句話有無數的翻版，但是對于網絡工程師來說，這就是現身說法。

[[274952]]

由于即便是在上千人的公司，網絡工程師的人數也僅僅是個位數，所以他們的工作也鮮為人知 。

“網絡是不是有問題?”這句話幾乎成了所有SRE排錯時的口頭禪，如果這個時候網絡工程師表示沉默，或者無法拿出足夠的證據，那背鍋幾乎是無疑的。

如何讓網絡環境的運行狀態更加透明?如何在每次業務故障的時候自證清白?這不僅是基礎服務團隊要關心的內容，更是整個技術團隊想要了解的黑匣子。

監控

網絡設備存活監控

對于SRE來說，需要監控程序是否正常;對于主機組來說，需要監控服務器硬件是否正常;對于網絡來說，我們首先需要關心網絡設備是否可達。當一臺TOR不可達時，基本上預示著會有一片服務器不可達，業務的痛感是相當強烈的。

網絡設備的監控最好和業務監控系統盡量解藕，因為網絡故障極有可能引發業務系統異常，如果恰巧導致的是業務的監控系統異常，那網絡設備的告警將失去可靠性，且不說“監控不準”這個鍋是誰的，這種局面會讓網絡工程師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監控

接口的Error包監控和流量監控一樣，均可以通過snmp采集，OID：ifOutErrors，ifInErrors , Error包出現增量會直接影響業務的服務質量，一旦發現需要優先處理，否則業務會拎著一堆TcpTimeOut指標找上門來。

當然，可以通過snmp采集的信息還有很多，例如：設備的CPU/內存/溫度/防火墻的Session等，掌握這些信息對了解設備的工作環境也頗有益處，如果你要做一個自動化巡檢工具，那么這些指標必不可少。市面上提供網絡監控的軟件有很多，例如：Falcon / Zabbix / Solarwinds / Cacti / Nigos等，有開源的也有收費的，功能類似，此處不加贅述。

制造自動化運維工具

第一章中的組合拳打完之后，基本上不會出現“意料之外的故障”，所有的異常都應該有據可查，當SRE莫名其妙提出對網絡環境的質疑時，你應該早已心中有譜。

但是網絡工程師的工作并非只有救火，日常運維工作中，經常需要配合業務發展做一些線上變更/ 機房擴建/業務類故障排查等。作為一名“懶惰”的網絡工程師，程序可以幫忙點什么忙呢?

UserDevice Tracker

這個名詞借用于Solarwinds套裝中的一個組件，直譯為“用戶設備追蹤器” ， 在中小型企業網運維中，經常會有這樣的需求：

• 知道服務器的IP，請問連接在交換機的哪個口?
• 知道交換機的某個端口，請問連接的服務器的IP是多少?
• 給你一臺服務器的MAC地址，怎么知道在哪個交換機的哪個口?

大型互聯網公司一般會有CMDB或者網絡管理平臺來記錄這些信息， 但是如果你是一家中小型企業的網管，沒有運維研發團隊做支持，并且還在沿用二層的環境(服務器網關在核心設備)，那就比較費勁了。以上幾個問題其實歸根到底是要捋清楚三個要素的對應關系：PORT<>MAC<>IP 。

舉個例子：

一臺交換機有多個物理接口，一個物理接口下可以有多個MAC，一個MAC可以對應多個IP，或者不對應任何IP。有了這個基本的模型，只需要做兩件事情即可找到全網設備這三元素的對應關系。

首先去服務器直連的交換機獲取MAC表(即MAC<->PORT)，然后再去服務器的網關設備獲取ARP表(即IP<->MAC)，這兩張表根據MAC地址作為唯一主鍵即可得到PORT <->MAC<->IP的對應關系。

信息的獲取可以通過模擬登陸或者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小時全年無休的服務，而人的精力是有限的，用程序去應對業務那些簡單有規律的需求，節省出工程師寶貴的時間來思考人生，這才是網絡工程師自動化運維之路的正道。

總結

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