不管網絡如何發展和改革，監控功能一直都存在。這就是為什么網絡工程師的角色仍然至關重要的原因之一。

過去幾年里，行業內一直充斥著諸如“網絡將永遠是相同的”，“網絡工程師的角色已經不再需要”，以及“所有網絡工程師都需要去學習寫代碼”這樣的觀點。

我不贊同，在這篇文章里我會告訴你為什么我認為網絡工程師的角色仍舊至關重要。主要是兩點：監控和故障排除。

從18年前我開始成為一名網絡工程師到現在，網絡監控功能大致維持不變。

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

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

盡管存在這些問題，簡單網絡管理協議(SNMP)卻沒有合理的替代者

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

那么網絡工程師又該如何使用這些監測基礎信息呢?如何利用這些信息來促進軟件定義網絡、DevOps的發展，在未來5到10年改變網絡監控?

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

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

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

代碼技能是很有價值的，但是......

DevOps和編寫代碼技能都是很有價值的。我必須要學習，許多在關鍵網絡管理平臺、整體網絡管理平臺、無線和軟件定義控制器、廠商支持的自動化系統，以及點擊式管理軟件方面開始職業生涯的人們也必須學習。真正把事情解決的唯一方法就是自己寫代碼并運行腳本。

但是，說網絡工程師功能已經“死掉”是目光短淺的錯誤看法。基本的網絡工程師功能在至少未來十年里是必需的，甚至更久，許多基本的技能，如解決低級別的故障，會繼續保持。

最有經驗的網絡工程師至少會熟悉幾個可用的管理系統，雖然關于這些系統的技能和知識可能會隨著時間褪色，但是這些工程師不會消失。往昔的知識價值可能會漸漸風化，但是至少一小部分相關從業者會需要這些技能。

如果說寫代碼和網絡工程師的聯系，那就是學習寫代碼的工程師只是為了鞏固網絡專業技能。他們需要擁有去探索網絡的膽量，去鉆研別人不敢觸及的深奧難解的角落，而這些角落將被那些擁有不屈不饒的動力和勇氣的人征服。

說了這么多，其實在IT行業，唯一不變的就是變化。今天軟件定義網絡和DevOps的繁榮就證明了這一點。我們都必須適應這些發展，否則最終會步渡渡鳥的后塵。而這一切的核心，就是愿意接受改變，這也是DevOps技術的核心。