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

本文從一名網工從業者的角度出發，探討了在企業網運維過程當中，網絡工程師能夠用什麼樣的工具讓網絡更加透明高效。

上篇文章回顧：Apache Ranger——Hadoop ACL控制工具

                                          引言

「網絡就像wifi，沒有故障的時候，就沒有人意識到它的存在」，這句話有無數的翻版，可是對於網絡工程師來講這就是現身說法。因爲網絡工程師的人數即使是在上千人的公司，也僅僅是個位數，因此他們的工做也不爲人知 。「網絡是否是有問題？」這句話幾乎成了全部SRE排錯時的口頭禪，若是這個時候網絡工程師表示沉默，或者沒法拿出足夠的證據，那背鍋幾乎是無疑的，如何讓網絡環境的運行狀態更加透明，如何在每次業務故障的時候自證清白，這不只是基礎服務團隊要關心的內容，更是整個技術團隊想要了解的黑匣子。

                                       一、監控

1.1網絡設備存活監控

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

網絡設備的監控最好和業務監控系統儘可能解藕，由於網絡故障極有可能引起業務系統異常，若是恰巧致使的是業務的監控系統異常，那網絡設備的告警將失去可靠性，「監控不許」且不說這個鍋是誰的，這種局面會讓網絡工程師Trouble Shooting時陷入被動，延長了故障時間。

每個網工在走出校門的那一刻，都已經具有基本的編程基礎， 何況交換機的數量和服務器的數量有着量級上的差異，因此若是你能看懂幾句python，100+的python代碼便可搞定一個簡易的設備存活監控的程序，Github中可搜索 NodePingManage 就是一個很好的例子，還能夠經過多點部署來消除單點故障。有了這類工具， 今後全網的各個角落的可達性終於明瞭， 漆黑的網絡環境，彷佛反射出了一絲光明。

1.2設備日誌監控

設備存活告警雖然能夠預警不少異常，而且準確度很高，可是對於冗餘性作的比較好的網絡，能Ping通並不表明徹底沒問題，此時，細心的網絡工程師會去看日誌，這裏能夠反映出更多細節。對於萬臺服務器規模，網絡設備的數量也就千臺，可是逐臺查看日誌，人肉判斷是否有異常，那簡直是場噩夢。

《日誌告警》程序就成爲網絡工程師們居家旅行必備之良品，只須要一臺Syslog服務器，部署一個日誌監控程序，當發現日誌中出現特殊關鍵字，觸發郵件+短信告警便可。這麼高大上的工具固然須要更多的編程技巧，150+ python代碼才能搞定。Github中相似的解決方法有不少，搜索 LogScanWarning 便可獲得一個示範案例。

今後你能夠在業務無感的狀況下，發現網絡中的異常， 例如：風扇轉速異常／電源模塊故障／ospf鄰居狀態抖動／端口flapping／有黑客在爆破個人設備／設備硬件parity error／模塊收發光異常／Kernel報錯等等。優秀的網絡工程師能夠在故障發生時快速定位，牛X的網絡工程師能夠在故障發生前就消除隱患，防範於未然。

1.3流量監控

高速公路鋪的再好，也架不住車多人多。確保網絡順暢，品質優良，沒有丟包，延時穩定也是網絡工程師的職責 ，此時流量監控就成了剛需。業務的飛速發展體如今網絡層面就是DC內流量上漲／DCI流量上漲／IDC出口流量上漲／專線流量上漲，流量監控能夠準確掌握業務的高峯和低谷，當線路須要擴容時，帶寬使用率是老闆參考的重要數據。通常狀況下線路中的流量超過50%便可發起擴容，由於這意味着當備份鏈路down以後，主線路將出現擁塞。

1.4接口error監控

接口的Error包監控和流量監控同樣，都可以經過snmp採集，OID：ifOutErrors，ifInErrors , Error包出現增量會直接影響業務的服務質量，一旦發現須要優先處理，不然業務會拎着一堆TcpTimeOut指標找上門來。固然，能夠經過snmp採集的信息還有不少，例如：設備的CPU／內存／溫度／防火牆的Session等，掌握這些信息對了解設備的工做環境也很有益處，若是你要作一個自動化巡檢工具，那麼這些指標必不可少。市面上提供網絡監控的軟件有不少，例如：Falcon/Zabbix/Solarwinds/Cacti/Nigos 等，有開源的也有收費的，功能相似，此處不加贅述。

                          二、製造自動化運維工具

第一章中的組合拳打完以後，基本上不會出現「意料以外的故障」，全部的異常都應該有據可查，當SRE莫名其妙提出對網絡環境的質疑時，你應該早已心中有譜。可是網絡工程師的工做並不是只有救火，平常運維工做中，常常須要配合業務發展作一些線上變動/ 機房擴建／業務類故障排查等。做爲一名「懶惰」的網絡工程師，程序能夠幫忙點什麼忙呢？

2.1UserDevice 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秒鐘。

2.2網絡設備北向接口的二次封裝

平常網絡運維工做中，常常會有一些 「簡單重複勞動」，例如：爲某個接口劃分Vlan／給某臺設備添加一條指向主機的路由等， 這些操做即沒有科技含量，還佔用了工程師寶貴的時間，更要命的是再簡單的人肉操做，重複的次數只要足夠多，總有失誤的時候，正所謂「常在河邊走，哪有不溼鞋」，可是在這種問題上犯錯誤簡直是對職業生涯的抹黑，如此「雞肋」的工做怎麼才能乾的漂亮？

以《自動劃分交換機接口Vlan》的功能爲例， 若是有一個工具只須要你提供三個參數：設備IP／端口／vlan編號， 就能自動登錄設備把特定接口劃分到指定Vlan，那豈不是美哉。沒錯！你須要的是一個對設備封裝後的接口， 如今多數網絡設備廠商都會提供本身的API，不管是NETCONF仍是RESTful，只要讀懂了使用手冊，便可經過程序輕鬆變動設備的配置，甚至你能夠用更加」接地氣」的方法，用程序「模擬登錄」設備 ，雖然這個方法在效率上比不過NETCONF和RESTful API，可是在通用性上那簡直無敵，由於沒有哪一個廠商的設備不支持SSH或者TELNET的。

有了這個理論基礎，一些簡單的網絡上的操做就能夠經過本身封裝的接口來實現變動，甚至能夠把變動的權限交給業務，只要業務提交的請求是合法的，變動可當即上線生效。此時，確定會有人大驚失色！把網絡設備的權限交給業務，這樣真的好麼？萬一改壞了怎麼辦…全部的疑惑都是正常的，同時也都是有解的。還以《自動劃分交換機接口Vlan》舉例子，你能夠限制程序執行的內容，你能夠規定交換機只能是TOR不能是CSW，你能夠約束接口只能是Access不能是Trunk，你能夠限定被操做的接口下流量必須爲0bps，以免誤操做影響到業務，你能夠經過動態Token保證接口的安全，你能夠要求必須提供接口下現存的MAC以定位接口的位置，你還能夠對調用者加白名單，另外，操做成功後還須要有短信+郵件反饋操做後的結果，等等…

全部的考量均可以固化爲代碼規則，只有程序是最忠實的執行者。接口能夠提供7*24 小時整年無休的服務，而人的精力是有限的，用程序去應對業務那些簡單有規律的需求，節省出工程師寶貴的時間來思考人生，這纔是網絡工程師自動化運維之路的正道。

                                                      總結

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

本文首發於公衆號」小米運維「，點擊查看原文。