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

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

我不贊同，在這篇文章里我會(huì)告訴你為什么我認(rèn)為網(wǎng)絡(luò)工程師的角色仍舊至關(guān)重要。主要是兩點(diǎn)：監(jiān)控和故障排除。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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