不管網(wǎng)絡(luò )如何發(fā)展和改革，監控功能一直都存在。這就是為什么網(wǎng)絡(luò )工程師的角色仍然至關(guān)重要的原因之一。

過(guò)去幾年里，行業(yè)內一直充斥著(zhù)諸如“網(wǎng)絡(luò )將永遠是相同的”，“網(wǎng)絡(luò )工程師的角色已經(jīng)不再需要”，以及“所有網(wǎng)絡(luò )工程師都需要去學(xué)習寫(xiě)代碼”這樣的觀(guān)點(diǎn)。

為什么我認為網(wǎng)絡(luò )工程師的角色仍舊至關(guān)重要。主要是兩點(diǎn)：監控和故障排除。

從18年前我開(kāi)始成為一名網(wǎng)絡(luò )工程師到現在，網(wǎng)絡(luò )監控功能大致維持不變。

讓我們一起來(lái)看一下在現代化網(wǎng)絡(luò )中，監控功能是如何運作的。跟蹤一個(gè)生產(chǎn)網(wǎng)絡(luò )的狀態(tài)并不容易，以前我反復假設過(guò)很多次，認為有效監控網(wǎng)絡(luò )的關(guān)鍵是對重量級的把握，這可能比創(chuàng )建一個(gè)網(wǎng)絡(luò )并保持其運行更困難，尤其是運營(yíng)商和服務(wù)提供商的網(wǎng)絡(luò )架構。造成這樣的結果有幾個(gè)原因，其中最大的在于機構用于獲取數據的簡(jiǎn)單網(wǎng)絡(luò )管理協(xié)議(SNMP, Simple Network Management Protocol)。

在我踏進(jìn)這個(gè)行業(yè)之前，簡(jiǎn)單網(wǎng)絡(luò )管理協(xié)議(SNMP)就已經(jīng)存在很久了。而且，它看起來(lái)應該還會(huì )存在更久。簡(jiǎn)單網(wǎng)絡(luò )管理協(xié)議(SNMP)給輪詢(xún)數據和推動(dòng)事件都提供了基本要素。而且，其問(wèn)題在于很神秘。簡(jiǎn)單網(wǎng)絡(luò )管理協(xié)議(SNMP)讓網(wǎng)絡(luò )設備和虛弱的CPU捆綁在一起，不僅如此，它還經(jīng)常被貧困和笨重的主機堵塞。

盡管存在這些問(wèn)題，簡(jiǎn)單網(wǎng)絡(luò )管理協(xié)議(SNMP)卻沒(méi)有合理的替代者

不幸的是，對于網(wǎng)絡(luò )工程師來(lái)說(shuō)，沒(méi)有合理的替代來(lái)獲取這樣的網(wǎng)絡(luò )性能數據作為接口計數器、錯誤統計、CPU負載、三重內容可尋址存儲器信息或功率信息。簡(jiǎn)單網(wǎng)絡(luò )管理協(xié)議(SNMP)就是標準。結合簡(jiǎn)單網(wǎng)絡(luò )管理協(xié)議(SNMP)、簡(jiǎn)單網(wǎng)絡(luò )管理協(xié)議(SNMP)陷阱、系統日志數據、互聯(lián)網(wǎng)控制消息協(xié)議數據、延遲信息以及吞吐量信息，網(wǎng)絡(luò )工程師就有了合理的網(wǎng)絡(luò )監測基礎。

那么網(wǎng)絡(luò )工程師又該如何使用這些監測基礎信息呢？如何利用這些信息來(lái)促進(jìn)軟件定義網(wǎng)絡(luò )、DevOps的發(fā)展，在未來(lái)5到10年改變網(wǎng)絡(luò )監控？

讓我們通過(guò)一些示例來(lái)分析。示例中我們將數據中心和局域網(wǎng)的刷新周期假設為3-5年，廣域網(wǎng)刷新周期為5-7年，而傳輸刷新周期通常為10年。

示例一：在一個(gè)給定的數據中心，你部署了一個(gè)典型的葉-棘式網(wǎng)絡(luò )。你如何得知一片葉子故障了？很可能是通過(guò)一則系統日志消息或者一個(gè)簡(jiǎn)單網(wǎng)絡(luò )管理協(xié)議(SNMP)陷阱。如果問(wèn)題出現在網(wǎng)絡(luò )邊緣，也可能是通過(guò)一則OpenFlow消息得知故障。這個(gè)功能又如何連接到現有的網(wǎng)絡(luò )運營(yíng)中心(NOC, network operation center)工具呢？網(wǎng)絡(luò )運營(yíng)中心(NOC)可以監控到這一故障嗎?當然會(huì )。因為傳統的監控和報警系統會(huì )有一個(gè)鏈接。鏈接？指的是綠地嗎？綠地也是一個(gè)公正的說(shuō)法。然后網(wǎng)絡(luò )運營(yíng)中心(NOC)將會(huì )檢查控制器拓撲界面。所以以后故障的獲取和處理這一切會(huì )如何發(fā)生呢？我打賭還是要使用以上提到的方法之一。

示例二：服務(wù)提供商MPLS Network正在使用類(lèi)似Border Gateway Protocol Link-State，OpenFlow 1.3或可能只是內部開(kāi)發(fā)的DevOps工具。那么網(wǎng)絡(luò )工程師怎么知道標簽交換路徑中出現了問(wèn)題呢？如何得知一個(gè)暗光纖路徑無(wú)法切換到冗余路徑呢？網(wǎng)絡(luò )運營(yíng)中心(NOC)又如何得知這些消息？你或許已經(jīng)猜中了，三種方法：簡(jiǎn)單網(wǎng)絡(luò )管理協(xié)議(SNMP)陷阱，系統日志或拓撲圖(基于簡(jiǎn)單網(wǎng)絡(luò )管理協(xié)議(SNMP)的一種方法)。

代碼技能是很有價(jià)值的，但是......

DevOps和編寫(xiě)代碼技能都是很有價(jià)值的。我必須要學(xué)習，許多在關(guān)鍵網(wǎng)絡(luò )管理平臺、整體網(wǎng)絡(luò )管理平臺、無(wú)線(xiàn)和軟件定義控制器、廠(chǎng)商支持的自動(dòng)化系統，以及點(diǎn)擊式管理軟件方面開(kāi)始職業(yè)生涯的人們也必須學(xué)習。真正把事情解決的唯一方法就是自己寫(xiě)代碼并運行腳本。

但是，說(shuō)網(wǎng)絡(luò )工程師功能已經(jīng)“死掉”是目光短淺的錯誤看法�；�本的網(wǎng)絡(luò )工程師功能在至少未來(lái)十年里是必需的，甚至更久，許多基本的技能，如解決低級別的故障，會(huì )繼續保持。

最有經(jīng)驗的網(wǎng)絡(luò )工程師至少會(huì )熟悉幾個(gè)可用的管理系統，雖然關(guān)于這些系統的技能和知識可能會(huì )隨著(zhù)時(shí)間褪色，但是這些工程師不會(huì )消失。往昔的知識價(jià)值可能會(huì )漸漸風(fēng)化，但是至少一小部分相關(guān)從業(yè)者會(huì )需要這些技能。

如果說(shuō)寫(xiě)代碼和網(wǎng)絡(luò )工程師的聯(lián)系，那就是學(xué)習寫(xiě)代碼的工程師只是為了鞏固網(wǎng)絡(luò )專(zhuān)業(yè)技能。他們需要擁有去探索網(wǎng)絡(luò )的膽量，去鉆研別人不敢觸及的深奧難解的角落，而這些角落將被那些擁有不屈不饒的動(dòng)力和勇氣的人征服。

說(shuō)了這么多，其實(shí)在IT行業(yè)，唯一不變的就是變化。今天軟件定義網(wǎng)絡(luò )和DevOps的繁榮就證明了這一點(diǎn)。我們都必須適應這些發(fā)展，否則最終會(huì )步渡渡鳥(niǎo)的后塵。而這一切的核心，就是愿意接受改變，這也是DevOps技術(shù)的核心。