“網(wǎng)絡(luò )就像wifi，沒(méi)有故障的時(shí)候，就沒(méi)有人意識到它的存在”，這句話(huà)有無(wú)數的翻版，但是對于網(wǎng)絡(luò )工程師來(lái)說(shuō)這就是現身說(shuō)法。由于網(wǎng)絡(luò )工程師的人數即便是在上千人的公司，也僅僅是個(gè)位數，所以他們的工作也鮮為人知 �！熬W(wǎng)絡(luò )是不是有問(wèn)題？”這句話(huà)幾乎成了所有SRE排錯時(shí)的口頭禪，如果這個(gè)時(shí)候網(wǎng)絡(luò )工程師表示沉默，或者無(wú)法拿出足夠的證據，那背鍋幾乎是無(wú)疑的，如何讓網(wǎng)絡(luò )環(huán)境的運行狀態(tài)更加透明，如何在每次業(yè)務(wù)故障的時(shí)候自證清白，這不僅是基礎服務(wù)團隊要關(guān)心的內容，更是整個(gè)技術(shù)團隊想要了解的黑匣子。

1、監控

網(wǎng)絡(luò )設備存活監控

對于SRE來(lái)說(shuō)需要監控程序是否正常，對于主機組來(lái)說(shuō)需要監控服務(wù)器硬件是否正常，對于網(wǎng)絡(luò )來(lái)說(shuō)我們首先需要關(guān)心網(wǎng)絡(luò )設備是否可達。當一臺TOR不可達時(shí)，基本上預示著(zhù)會(huì )有一片服務(wù)器不可達，業(yè)務(wù)的痛感是相當強烈的。

網(wǎng)絡(luò )設備的監控最好和業(yè)務(wù)監控系統盡量解藕，因為網(wǎng)絡(luò )故障極有可能引發(fā)業(yè)務(wù)系統異常，如果恰巧導致的是業(yè)務(wù)的監控系統異常，那網(wǎng)絡(luò )設備的告警將失去可靠性，“監控不準”且不說(shuō)這個(gè)鍋是誰(shuí)的，這種局面會(huì )讓網(wǎng)絡(luò )工程師Trouble Shooting時(shí)陷入被動(dòng)，延長(cháng)了故障時(shí)間。

每一個(gè)網(wǎng)工在走出校門(mén)的那一刻，都已經(jīng)具備基本的編程基礎， 況且交換機的數量和服務(wù)器的數量有著(zhù)量級上的差別，所以如果你能看懂幾句python，100+的python代碼即可搞定一個(gè)簡(jiǎn)易的設備存活監控的程序，Github中可搜索 NodePingManage 就是一個(gè)很好的例子，還可以通過(guò)多點(diǎn)部署來(lái)消除單點(diǎn)故障。有了這類(lèi)工具， 從此全網(wǎng)的各個(gè)角落的可達性終于明了， 漆黑的網(wǎng)絡(luò )環(huán)境，似乎反射出了一絲光明。

設備日志監控

設備存活告警雖然可以預警很多異常，并且準確度很高，但是對于冗余性做的比較好的網(wǎng)絡(luò )，能Ping通并不代表完全沒(méi)問(wèn)題，此時(shí)，細心的網(wǎng)絡(luò )工程師會(huì )去看日志，這里可以反映出更多細節。對于萬(wàn)臺服務(wù)器規模，網(wǎng)絡(luò )設備的數量也就千臺，但是逐臺查看日志，人肉判斷是否有異常，那簡(jiǎn)直是場(chǎng)噩夢(mèng)。

《日志告警》程序就成為網(wǎng)絡(luò )工程師們居家旅行必備之良品，只需要一臺Syslog服務(wù)器，部署一個(gè)日志監控程序，當發(fā)現日志中出現特殊關(guān)鍵字，觸發(fā)郵件+短信告警即可。這么高大上的工具當然需要更多的編程技巧，150+ python代碼才能搞定。Github中類(lèi)似的解決方法有很多，搜索 LogScanWarning 即可得到一個(gè)示范案例。

從此你可以在業(yè)務(wù)無(wú)感的情況下，發(fā)現網(wǎng)絡(luò )中的異常， 例如：風(fēng)扇轉速異常／電源模塊故障／ospf鄰居狀態(tài)抖動(dòng)／端口flapping／有黑客在爆破我的設備／設備硬件parity error／模塊收發(fā)光異常／Kernel報錯等等。優(yōu)秀的網(wǎng)絡(luò )工程師可以在故障發(fā)生時(shí)快速定位，牛X的網(wǎng)絡(luò )工程師可以在故障發(fā)生前就消除隱患，防范于未然。

流量監控

高速公路鋪的再好，也架不住車(chē)多人多。確保網(wǎng)絡(luò )順暢，品質(zhì)優(yōu)良，沒(méi)有丟包，延時(shí)穩定也是網(wǎng)絡(luò )工程師的職責 ，此時(shí)流量監控就成了剛需。業(yè)務(wù)的飛速發(fā)展體現在網(wǎng)絡(luò )層面就是DC內流量上漲／DCI流量上漲／IDC出口流量上漲／專(zhuān)線(xiàn)流量上漲，流量監控可以準確掌握業(yè)務(wù)的高峰和低谷，當線(xiàn)路需要擴容時(shí)，帶寬使用率是老板參考的重要數據。一般情況下線(xiàn)路中的流量超過(guò)50%即可發(fā)起擴容，因為這意味著(zhù)當備份鏈路down之后，主線(xiàn)路將出現擁塞。

接口error監控

接口的Error包監控和流量監控一樣，均可以通過(guò)snmp采集，OID：ifOutErrors，ifInErrors , Error包出現增量會(huì )直接影響業(yè)務(wù)的服務(wù)質(zhì)量，一旦發(fā)現需要優(yōu)先處理，否則業(yè)務(wù)會(huì )拎著(zhù)一堆TcpTimeOut指標找上門(mén)來(lái)。當然，可以通過(guò)snmp采集的信息還有很多，例如：設備的CPU／內存／溫度／防火墻的Session等，掌握這些信息對了解設備的工作環(huán)境也頗有益處，如果你要做一個(gè)自動(dòng)化巡檢工具，那么這些指標必不可少。市面上提供網(wǎng)絡(luò )監控的軟件有很多，例如：Falcon/Zabbix/Solarwinds/Cacti/Nigos 等，有開(kāi)源的也有收費的，功能類(lèi)似，此處不加贅述。

2、制造自動(dòng)化運維工具

第一章中的組合拳打完之后，基本上不會(huì )出現“意料之外的故障”，所有的異常都應該有據可查，當SRE莫名其妙提出對網(wǎng)絡(luò )環(huán)境的質(zhì)疑時(shí)，你應該早已心中有譜。但是網(wǎng)絡(luò )工程師的工作并非只有救火，日常運維工作中，經(jīng)常需要配合業(yè)務(wù)發(fā)展做一些線(xiàn)上變更/ 機房擴建／業(yè)務(wù)類(lèi)故障排查等。作為一名“懶惰”的網(wǎng)絡(luò )工程師，程序可以幫忙點(diǎn)什么忙呢？

UserDevice Tracker

這個(gè)名詞借用于Solarwinds套裝中的一個(gè)組件，直譯為“用戶(hù)設備追蹤器” ， 在中小型企業(yè)網(wǎng)運維中，經(jīng)常會(huì )有這樣的需求：

知道服務(wù)器的IP，請問(wèn)連接在交換機的哪個(gè)口？

知道交換機的某個(gè)端口，請問(wèn)連接的服務(wù)器的IP是多少？

給你一臺服務(wù)器的MAC地址，怎么知道在哪個(gè)交換機的哪個(gè)口？

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

一臺交換機有多個(gè)物理接口，一個(gè)物理接口下可以有多個(gè)MAC，一個(gè)MAC可以對應多個(gè)IP，或者不對應任何IP。 有了這個(gè)基本的模型，只需要做兩件事情即可找到全網(wǎng)設備這三元素的對應關(guān)系。首先去服務(wù)器直連的交換機獲取MAC表（即MAC<->PORT）， 然后再去服務(wù)器的網(wǎng)關(guān)設備獲取ARP表（即IP<->MAC），這兩張表根據MAC地址作為唯一主鍵即可得到 PORT <->MAC<->IP 的對應關(guān)系。 信息的獲取可以通過(guò)模擬登陸或者OID采集均可，Github中也有很多類(lèi)似的代碼可供參考，有了這個(gè)對應關(guān)系，即便沒(méi)有CMDB，你依然可以快速定位想要的信息， 普通網(wǎng)工查找這個(gè)信息需要5分鐘， 而你只需要5秒鐘。

網(wǎng)絡(luò )設備向接口的二次封裝

日常網(wǎng)絡(luò )運維工作中，經(jīng)常會(huì )有一些 “簡(jiǎn)單重復勞動(dòng)”，例如：為某個(gè)接口劃分Vlan／給某臺設備添加一條指向主機的路由等， 這些操作即沒(méi)有科技含量，還占用了工程師寶貴的時(shí)間，更要命的是再簡(jiǎn)單的人肉操作，重復的次數只要足夠多，總有失誤的時(shí)候，正所謂“常在河邊走，哪有不濕鞋”，但是在這種問(wèn)題上犯錯誤簡(jiǎn)直是對職業(yè)生涯的抹黑，如此“雞肋”的工作怎么才能干的漂亮？

以《自動(dòng)劃分交換機接口Vlan》的功能為例， 如果有一個(gè)工具只需要你提供三個(gè)參數：設備IP／端口／vlan編號， 就能自動(dòng)登陸設備把特定接口劃分到指定Vlan，那豈不是美哉。沒(méi)錯！你需要的是一個(gè)對設備封裝后的接口， 現在多數網(wǎng)絡(luò )設備廠(chǎng)商都會(huì )提供自己的API，無(wú)論是NETCONF還是RESTful，只要讀懂了使用手冊，即可通過(guò)程序輕松變更設備的配置，甚至你可以用更加”接地氣”的方法，用程序“模擬登陸”設備 ，雖然這個(gè)方法在效率上比不過(guò)NETCONF和RESTful API，但是在通用性上那簡(jiǎn)直無(wú)敵，因為沒(méi)有哪個(gè)廠(chǎng)商的設備不支持SSH或者TELNET的。

有了這個(gè)理論基礎，一些簡(jiǎn)單的網(wǎng)絡(luò )上的操作就可以通過(guò)自己封裝的接口來(lái)實(shí)現變更，甚至可以把變更的權限交給業(yè)務(wù)，只要業(yè)務(wù)提交的請求是合法的，變更可立即上線(xiàn)生效。此時(shí)，肯定會(huì )有人大驚失色！把網(wǎng)絡(luò )設備的權限交給業(yè)務(wù)，這樣真的好么？萬(wàn)一改壞了怎么辦…所有的疑惑都是正常的，同時(shí)也都是有解的。還以《自動(dòng)劃分交換機接口Vlan》舉例子，你可以限制程序執行的內容，你可以規定交換機只能是TOR不能是CSW，你可以約束接口只能是Access不能是Trunk，你可以限定被操作的接口下流量必須為0bps，以避免誤操作影響到業(yè)務(wù)，你可以通過(guò)動(dòng)態(tài)Token保證接口的安全，你可以要求必須提供接口下現存的MAC以定位接口的位置，你還可以對調用者加白名單，另外，操作成功后還需要有短信+郵件反饋操作后的結果，等等…

所有的考量都可以固化為代碼規則，只有程序是最忠實(shí)的執行者。接口可以提供7*24 小時(shí)全年無(wú)休的服務(wù)，而人的精力是有限的，用程序去應對業(yè)務(wù)那些簡(jiǎn)單有規律的需求，節省出工程師寶貴的時(shí)間來(lái)思考人生，這才是網(wǎng)絡(luò )工程師自動(dòng)化運維之路的正道。