不擴容提高十倍 x86 軟件性能，雲杉網絡如何用產品思路知足客戶需求？

雲時代，本地部署的企業級軟件在不擴容的狀況下，能作到短時間內十倍的性能提高的確是一件使人側目的成績。

衆所周知，x86 的性能已經被壓榨到了極致，帶着種種疑問 SegmentFault 思否社區採訪了雲杉網絡研發總監向陽。訪談中，向陽詳細談了在企業數據中心網絡場景下各類時序數據庫的表現，並解釋了雲杉網絡如何從工程的角度實現 x86 軟件十倍性能的提高。

---

向陽：雲杉網絡研發總監、網絡架構師。負責雲杉研發團隊的管理和 DeepFlow 的架構設計和核心功能實現。

2013 年獲清華大學計算機科學與技術博士學位，師從吳建平教授並獨立實現了世界上第一個基於關聯分析的 BGP 劫持檢測系統，所以摘得 Internet Measurement Conference（ IMC，網絡測量領域國際頂級會議）社區貢獻獎。2015年得到清華大學博士後證書，主要研究方向爲雲數據中心網絡架構，得到了多項網絡安全、雲數據中心相關專利。

---

思否：可否請您先介紹一下主要工做經歷，專一的技術研究方向，以及目前所負責的工做。

向陽：個人工做經歷其實比較簡單，在加入雲杉以前，我在清華大學讀博。師從吳建平院士作一些包括域間路由的算法和結構、域間路由的安全等等方面的工做。畢業後，我接觸到 SDN 的領域，也就瓜熟蒂落地加入雲杉，而後一直作 SDN 的研發工做直到如今。如今我在公司是研發團隊的負責人和 DeepFlow 產品線的負責人。

---

 

思否：隨着業務需求的提高以及雲計算等相關技術的發展，企業開始創建本身的雲數據中心，其中網絡是雲數據中心的重要組成部分之一。您認爲現代企業的雲數據中心在網絡架構的搭建上一般有哪些痛點？企業應當如何應對這些挑戰？

向陽：咱們能看到的企業在去作這一塊的時候，主要的一個挑戰其實能夠分爲兩個方面，一個方面就是說怎麼去建設，另一個方面，其實還要去考慮到怎麼樣去維護它。

建設主要解決兩個痛點：一個是網絡連通性的問題，一個是網絡服務化的問題。

爲了支撐業務，首先要把異構的資源、混合雲這些場景下作一個打通和互聯；而後在此之上提供豐富的網絡服務，包括像應用交付服務、安全服務等等。

與上述問題平行展開的，是複雜網絡的運營維護問題。由於如今網絡會至關的複雜，通常來說 IT 基礎設施會同時在公有云、在私有云不一樣的資源池上，此外還有虛擬化的一個容器資源池。在這樣一套 IT 基礎設施上要打通一個統一的網絡，才能支撐業務的靈活需求。

好比說一個業務要想在容器的資源池裏面去拿到幾個 POD，在虛擬機資源池裏面拿到一些虛擬機，在裸機資源池裏面拿到幾個物理機來實現一個業務需求，這個時候實際上這些資源池是互相獨立的，可是從網絡的視角看（這個業務）是一個總體，要將上述資源池的這些網絡打通、作統一的編排，這是一個挑戰。

在此基礎之上，若是說咱們把網絡作了打通，那麼這個網絡維護的難度也是很是高的，不可能再由人工去作維護 —— 若是說這張網增長了 10 倍的複雜度，那就意味着至少要投入 10 倍的人力，這件事難覺得繼。

---

思否：雲杉網絡爲了幫助企業解決網絡運維管理上的挑戰，早在 2016 年的時候就推出了雲網分析產品 DeepFlow，可否請您先介紹一下 DeepFlow的核心組件、功能特色以及應用場景？

向陽：實際上咱們把 DeepFlow 的一個解決方案劃分紅兩個場景，一個是採集分發，另一個是分析。那也就對應着DeepFlow的整個產品中的三個核心的組件：採集器、分析器和控制器。

從組件的角度來說，控制器負責中央的管控和大規模（採集器）的管理，由於咱們的採集器會運行在不少異構的環境裏面 —— KVM 虛擬化、VMware 虛擬化、公有云的環境、私有云的環境、容器的環境、Linux 的環境以及 windows 的環境 —— 這時採集器的特色是運行的環境異構，另外一個特色就是採集器的數量很是大。

控制器它須要作的就是一個集中的大規模的管控；而採集器須要作的就是剛纔對於這些異構環境的一個全網覆蓋，包括物理的、虛擬的等等，作一個全網的覆蓋；以及咱們須要有一個高性能的策略匹配的算法。

由於若是對全部的流量數據所有作處理，這個時候的資源開銷將會很是大。有的流量咱們可能只是但願看一看，有的流量咱們但願把它的一些 counter 記錄下來，還有的流量會進入它的 pcap 文件，進入它的一些詳細的數據包，以及把一些流量直接分發出去。

不一樣的流量需求，咱們就須要經過一個策略的體系去對它作一個至關於編排。經過匹配，把符合某意圖的一些流量，給到後端對應的消費工具裏面。這樣的話咱們在採集這一側是須要有一個較強的策略匹配引擎，再到後面咱們的流量除了去分發給第三方的分析工具，傳統的 NMP、DPI 之外，咱們還能本身作一些分析，這就是咱們的分析器。

咱們的分析器主要一個特色，就是經過一個分佈式的時序數據庫，來將網絡中的全部的狀態和統計數據存儲下來。這至關於對網絡的全景視圖作一個刻畫。客戶再去作混合雲場景下的一個網絡排障的時候，能把全部的這些關聯點，不一樣的網絡、不一樣的層面，不一樣的 Overlay、不一樣的 Underlay —— 好比說在容器的場景下多是雙層的 Overlay —— 把它們都聯繫起來。

再回到應用場景。第一個是混合雲上流量的採集和分發。這種應用場景通常是針對於客戶已經有了不少傳統的分析設備，好比說 DPI 的設備、NPM 設備等等，可是他們苦於沒法拿到虛擬網絡、容器網絡裏面的流量。

在虛擬網絡的場景下，網絡的規模很是大，如今一個服務器能夠虛擬出來 10 個虛擬機，一個虛擬機可能又有 10 個 POD，這個數量是很是龐大。所以在虛擬網絡裏你不能像傳統物理網絡那樣經過分光、鏡像直接拿流量。咱們能作到全網覆蓋，按需的把流量拿出來給到後端的分析工具。

另外一個場景就是混合雲的網絡診斷，這其實是網絡分析的場景。由於咱們看到如今的雲的網絡是充分複雜的，這裏面有異構的資源池，有不一樣層級的 Overlay，咱們怎樣在這樣一個複雜的網絡環境下去作故障的診判定位？這須要咱們有一個全網流量數據的分析能力，即網絡分析。

---

思否：DeepFlow 自 5.0 版本以後的每次更新都對性能進行了改善，尤爲是 5.5.6 版本後核心組件的性能再次大幅提高，這是如何實現的？是否與編程語言和數據庫有關？雲杉爲何如此看重性能上的提高？

向陽：首先來談一談這些性能的提高是如何實現的，其實總的來說包括幾個方面。採集這一側，咱們是對於新技術有一些引入，像 DPDK 以及像 Linux 內核高版本的 XDP 的技術，XDP 對於客戶的環境的依賴是比 DPDK 要低，而且流量的採集性能比咱們上一代的技術能有 10 倍的提高。

另外補充說明一下咱們對新技術的引入，咱們實際上是走在了社區的前面，2019 年發佈的 CentOS 8 使用的內核版本對於 XDP 的支持其實並很差，咱們也從內核的層面對 XDP 的支持作了一些提高，使得咱們能在低版本的 Linux 環境裏面將咱們的採集器的性能提高上來。

另一個方面是分析側，主要咱們是基於數據結構和算法的一個優化。咱們整個 DeepFlow 平臺，絕大部分的組件都是基於 Golang，稍後再講咱們爲何會去選擇 Go。咱們對它原生的數據結構 —— 像 map 這樣一些數據結構 —— 作了一些很是關鍵的算法和數據結構上的改變，使得其性能都提高了 10 倍。

這裏面咱們有一些專利存在，好比說咱們對於 Go 的對象資源池、內存池的一些改進，對於 map 的一些改進，這是在分析側的優化。

而後就是在存儲側的優化，咱們是基於 InfluxDB 數據庫，對它的內核作了全新的開發，實現了 10 倍讀寫性能的提高，以及具備一個水平擴展的能力，更重要的是使它更適合網絡的場景。

回過頭來講 Golang，其實和語言的關係還不是太大，若是說咱們須要去追求一個極致的性能，咱們可能會去選擇好比說像 C 這樣的語言。但這裏還有另一個問題，就是咱們的開發效率和適配性。若是咱們用 C 的話，可能對於環境（好比說 glibc 的版本）的依賴會比較嚴重。

Go 實際上是一個雲時代的語言，像 Docker 這樣的技術，就是構建在 Go 之上的，其依賴是很是小。咱們選擇 Go 可以在依賴性和開發效率上得到優點，此外咱們也會去克服它的缺點，像它的 GC 帶來的缺點、它的數據結構帶來的性能問題，這些方面咱們都作了提高。

最後說說咱們爲何如此關注於軟件的效率，由於咱們是一家軟件公司。硬件公司好比說作盒子的企業會更多地專一於作專用機之類的產品。咱們必須作一個雲原生的平臺軟件，這樣它才能夠運行在任何的地方 —— 在公有云裏面、私有云裏面、容器裏面 —— 它不該該對於運行環境的操做系統以及物理的機器有任何的假設，並且它還須要在不要求硬件環境的前提下給客戶更大的效益。

也就是說硬件咱們是沒有辦法改變的，所以咱們須要對軟件的性能有一個極致的追求，這樣才能給客戶帶來價值。

---

思否：雲杉網絡在產品研發過程當中曾採用過開源時序數據庫 InfluxDB，那麼 DeepFlow 進行數據庫選型與開發的依據是什麼？在 DeepFlow 持續迭代的 3 年時間中，在數據庫選擇方面是否有經歷過變更？

向陽：回到三年前，咱們最初在作這個產品的時候，發現時序數據庫的發展並很差。當時時序數據庫都是基於一些傳統的數據庫來作的，它不是一個直接面向時序數據場景的數據庫。好比說 Elasticsearch，它實際上是一個搜索引擎，但被當作時序數據庫在用。

當時 InfluxDB 的版本是在 0.x 的時代。咱們最初同時在使用 Elasticsearch 和 InfluxDB。一方面依賴於 Elasticsearch 的穩定性，以及它的大規模的水平擴展能力；另一個方面咱們當時其實也看到了，時序數據是一種新的數據類型，它不可以直接所有在現有的這些數據庫裏面去存儲，因此咱們當時在小範圍內選用了 InfluxDB。

後來咱們有一個重要的版本調整，由於 Elasticsearch 做爲一個搜索引擎消耗的資源量實在太大了，它不太適合於時序這個場景，更不太適合在一個大規模網絡監控數據的場景下作存儲。所以咱們又所有切換到了 InfluxDB，這至關因而咱們數據庫選型的第二階段。再日後其實就是第三階段，InfluxDB 在開源的版本里曾經一度存在過集羣的解決方案，可是在某個版本以後被刪掉了 —— 這個功能變成了商用的解決方案。

這是咱們切換數據庫的一部分緣由，其實另一部分緣由、也是更重要的緣由在於咱們發現 InfluxDB 不太適合網絡的場景。咱們用普通的時序數據庫去監控1萬臺服務器，這 1 萬臺服務器每一個時間點好比說每秒它都會有一個 CPU 的值，那麼其數據量就是每秒 1 萬的量級。

也就是說這些監控數據是和被監控服務器的數量強相關，可是在虛擬網絡場景下，機器（虛擬機）的數量高出幾個量級。仍是上面的場景，這時若是有任意兩個機器之間互訪，這個數據雖然到不了前面所說數據的平方量級，可是仍能高出幾個數量級以上，並且這種訪問的關係還可以去和其餘的維度，好比說協議類型（TCP/UDP）、端口號以及服務的數量直接相關。這裏面的數據是一個很是高維度的存儲，並且是一個至關於稀疏矩陣的存儲，它和經典的時序數據庫的應用場景仍是不太同樣。

另外網絡的場景下面也存在一些特定的一些需求，好比說查詢一個網段、作一個網段的權重匹配，尤爲是網絡流量基本都是經過負載均攤的方式給到不一樣的機器去處理。在這樣大的一個數據體量下，這個時候咱們如何去把不一樣機器處理的結果聚合以後存儲下來，這些場景 InfluxDB 都是不支持的。因此咱們基於 InfluxDB 核心的存儲和查詢引擎，在此基礎上作了性能的提高、作了水平擴展的支持、作了高可用的支持，以及作了更多的網絡數據的查詢、聚合、過濾的支持。這樣最終造成咱們如今使用的、自研的網絡時序數據庫。

咱們其實測過像 Prometheus 這樣的不少後端的長期存儲方案，由於 Prometheus 適合短時間的數據存儲 —— 一般就存一到兩天。它有不少後端的存儲，像 S3DB (Simple Sloppy Semantic Database)、VictoriaMetricsDB 等有不少這樣的數據庫。從開源社區的時序數據庫排行來看，InfluxDB 是排在第一位的，可是其餘的數據庫會比它的性能測試數據要好看。

這個性能測試其實也是各家測的，並且很重要的一點，其它的數據庫每每是侷限在某個特定的場景下的測試數據比較好看，或者它的使用量尚未達到普遍使用的程度。因此咱們在考量的時候，也基於InfluxDB去作本身的時序數據存儲。

另一個層面，現有的時序數據庫都是基於相同的場景，即對物理服務器進行固定頻率的監控，而網絡監控的場景不是這樣。網絡監控的對象是海量的一維 IP、二維的 IP 對、三維的 IP 端口號等等，這顯然不是固定頻率的監控，而是一個稀疏矩陣的監控。這種差別性使得咱們如今也在考慮，例如全部現存的時序數據庫都在使用 TSM 這種數據存儲結構，所以咱們也在這種數據存儲結構上進行下一代產品的研發，使之支持稀疏矩陣的 TSM 特性，以便更好的去存儲和檢索網絡數據。

簡單的說，由於 InfluxDB 的使用範圍更廣、更成熟、更穩定，並且其餘的時序數據庫在最底層的算法層面和 InfluxDB 其實是同樣的。那麼也就是說這個測試性能的差別，多是測試方法或者使用場景或者其餘方面的差別，咱們認爲這個（測試性能）差別實際上是能夠忽略的。

---

思否：雲杉網絡在產品研發過程當中採用了開源的數據庫組件，目前對開源有什麼想法嗎？

向陽：咱們目前還不是一家開源軟件驅動公司，將來咱們可能會把一些組件反饋給社區。咱們也看到在 InfluxDB 社區版本把集羣的能力拿掉了，咱們認爲咱們的集羣功能作的仍是至關好的，它很是方便運維，不依賴於像 zooKeeper 的 ZAB 或者 Raft 這樣的集羣協議，是一個很是適合時序數據場景的高可用的集羣方式。若是咱們把自研的集羣實現以及水平擴展的查詢能力貢獻到社區，這對於社區的運做可能會有衝擊，由於社區已經把一部分能力放到了商業化的版本里面。

---

思否：DeepFlow 開放了開發與數據的接口，客戶能夠在 DeepFlow 上開發個性化的應用與工具，那麼 DeepFlow 目前支持哪些編程語言？

向陽：對於客戶自定義開發，咱們如今提供了兩種方式，一種方式是 API，這個 API 由於它是 Restfull 的，全部的語言都可以去調用。

另外一種方式是基於 Python 的 SDK，咱們看到 Python 有不少方面的優點，包括它的用戶基數大、使用門檻低以及擁有豐富的庫，它在數據處理和網絡編排等方面有自然的優點。

---

思否：將來還會在編程語言的支持上進行擴展嗎，好比 Java？這些客戶自行開發個性化的應用會影響 DeepFlow 的性能嗎？

向陽：目前咱們在這一個方面的計劃主要是客戶驅動。客戶經過咱們的 API 自行開發的應用對 DeepFlow 的性能不會產生什麼影響。在咱們的產品模塊裏， InfluxDB 存儲引擎之上還有一個分佈式的查詢引擎，它主要作不少分佈式的計算。實際上 API 調用是把計算的任務交給了咱們的分析器集羣，大量的工做是在分析器的集羣裏完成的。所以 API 調用方的效率不會成爲整個查詢鏈條的瓶頸，由於最終給到API調用方的數據是一個充分聚合後的數據結果，它的體量和咱們在平臺裏面存儲的數據（例如一個月的網絡數據）相比遠不是一個量級。無論客戶選擇什麼語言進行自定義開發，DeepFlow 的性能都不會受影響。

---

思否：當前環境下，互聯網公司在產品研發上大都會選擇敏捷開發、快速迭代的方式。而 DeepFlow 則在 5.0 版本以後實現了軟件架構的解耦，那麼是什麼因素促使大家決定這樣作的呢？您又是如何看待軟件架構穩定性與需求變化快速應對能力之間的平衡的？

向陽：咱們在 DeepFlow 研發的過程當中，版本迭代週期也在不斷變化。在三年前咱們的迭代週期是 6 個月——這對於一家 to B的公司比較常見。可是咱們的產品是運行在雲的環境下，快速迭代的能力很是重要。咱們必須將產品快速交付給客戶，而客戶的環境對咱們來講不是一個可運營的系統，也沒法讓咱們的產品一天更新多少次。咱們須要在這種狀況下作一個取捨，確保咱們的迭代週期要儘可能低、同時產品的穩定性要很是高。

在這樣的背景下，咱們作了 DeepFlow 平臺的解耦，使得其迭代週期從三年前的 6 個月逐步降到 3 個月、再逐步降到如今的 6 周，知足了咱們對客戶需求的快速響應 —— 不是在項目中，而是在標準化的產品版本中就能知足。

咱們用產品化的思路應對不斷增加的客戶需求，解耦後的產品分上下兩層，上面是應用層、下面是平臺層。平臺層追求的是高性能和穩定，應用層追求的是靈活性和高效率。在產品迭代過程當中，咱們能夠有選擇的去安排上層和下層的迭代週期。好比說在連續的幾個版本里面，底層的平臺是不須要迭代的，但與此同時，每個版本咱們均可以對上層的應用作更新，以知足客戶的新需求。

---

思否：除了實現解耦以外， DeepFlow 在軟件架構上是否還進行了其餘方面的調整？緣由是什麼？

向陽：咱們在 DeepFlow 研發過程當中有一個很是明顯的變化，最初咱們在作這個產品的時候使用了大量的開源組件，這其實也是不少同類產品的作法，但這對產品的穩定性是一個很是大的考驗。由於開源組件更多的是面向運營，須要有人去值守；由於代碼不是徹底由咱們本身掌控的，一旦出了問題，解決的速度也會比較慢。

後來咱們慢慢的去切換到了另外一種模式，即自研大量的組件。如今咱們產品裏徹底屬於開源組件的是 MySQL，由於它實在太經典、太穩定，咱們不須要對它作什麼改動；除此以外，其餘組件都是咱們自研的。咱們從之前充分使用開源組件走到了自研加使用開源的庫的道路上來。由於開源組件好比 Elasticsearch 的核心其實很穩定，但它的不少周邊組件好比輸入輸出、啓停等操做每每容易發生問題。

咱們如今會用一些很是成熟的庫，咱們也會像替換 InfluxDB 同樣逐步替換其餘組件，如今咱們僅僅只是有 InfluxDB 核心的存儲和查詢引擎，但這一部分咱們也在慢慢替換，由於 InfluxDB 基於經典的 TSM、不太適用於網絡的場景。

---

思否：產品組件裏 MySQL 跟 InfluxDB 主要承擔的角色有什麼不一樣嗎？

向陽：MySQL 主要是存儲一些 metadata，咱們叫作元數據，就是一些業務層面的數據；而 InfluxDB 存儲的是時序數據，即有許多資源對象，它們每時每刻都在生成一些統計數據，咱們將這部分時間維度上的統計數據存在了 InfluxDB 裏面。

---

思否：元數據和時序數據存在不一樣的地方，查詢時的性能會不會有影響？

向陽：這兩種數據存在同一個地方並不太適合對數據進行維護。好比對於業務數據或者關係型的數據，例如對一個虛擬機關聯的 Interface、關聯的 IP 怎麼去作增、刪、查、改？

若是每一個時間點都去存對應的信息，一旦虛擬機自己產生了變化（這種狀況常常發生），那麼就須要對它的歷史數據作相應的改變。而時序數據則不一樣，時序數據是面向特定的對象的固定時間點的統計數據，基本不存在對於歷史數據作修改的狀況；惟一須要作修改的場景是在作故障恢復時，或者該對象有變更時。舉個容易理解的例子，數序數據的存儲場景有點就像對電商的產品頁面作存儲，一個 SKU 的商品名、圖片、介紹等屬性（特定對象）不多變更（除非下線），但價格和庫存的實時數據常常在變、甚至一直在變。

---

思否：DeepFlow 自身的應用在調用平臺層的時候跟客戶開發個性化應用時的調用有什麼不一樣？

向陽：區別就是咱們給客戶加上一個權限認證的機制，其餘的沒有大的區別。系統原生的應用和客戶本身開發的應用是徹底平等的。咱們很是重視讓客戶加入整個產品鏈條中來，包括客戶開發一些應用，以及客戶在咱們的產品裏生成的數據。

---

思否：雲杉的客戶主要都是集中在金融、電信、製造這些傳統行業的企業，咱們對這些企業的印象通常都是慢。這些客戶的業務沒有那麼多的快速變化，爲何雲杉要在性能上、在快速迭代上，去作這些極致的提高？

向陽：事實上如今客戶的總體技術環境已經發生了變化，尤爲是IT的環境。好比在金融銀行的客戶已經在生產環境大規模使用包括虛擬化、容器、微服務等應用。實際上客戶對新技術的引入是比較快的。另一個層面，這些客戶之前買的確實都是「盒子」，如今在雲的環境下要去買軟件。若是咱們的軟件去消耗了客戶過多的硬件資源，這時軟件的價值其實很難體現出來。

---

思否：那麼下一階段 DeepFlow 準備將在哪些方面爲客戶帶來新的提高？是否能透露 DeepFlow 接下來的研發重點？

向陽：在前面一個階段，咱們主要將 DeepFlow 數據的採集能力和一些數據統計的能力進行了產品化。下一個階段主要是提高數據的智能分析能力。智能分析能力首先體如今諸如怎樣去對於一個網元設備先後的流量作關聯等，例如一個防火牆、一個負載均衡器先後的流量，究竟哪些流量屬於同一個會話？一個客戶訪問負載均衡器、負載均衡器又訪問一個後端的主機，這個訪問鏈條該怎麼繪製？這些體現的都是智能分析能力。

另外一個層面是對於不一樣網絡層的關聯，像容器網絡的數據和下一層虛擬化網絡的數據和再下一層物理網絡的數據該怎麼作關聯？在混合雲場景下的這種關聯能給客戶帶來一個完整的、端到端的逐跳診斷能力，這是咱們產品演進的一個重要方向。咱們如今已經採集了很是多的網絡數據，怎樣基於這些網絡數據作智能的基線告警、作故障的告警處理，以及作故障的預警，這都是咱們下一步要作的事。

從客戶的使用層面，咱們會更多的去關注客戶生成的數據。剛纔也提到SDK的方式是一種客戶參與的手段，DeepFlow主要仍是作一個數據的平臺，咱們不會限定客戶怎麼使用這個平臺，客戶有本身解決問題的想法和思路。咱們讓客戶在這個平臺之上去靈活地構建一些監控數據的視圖，能便捷地從這些視圖中DIY本身的監控大屏，這是咱們對客戶定製化能力的提高。

---

思否：DeepFlow 有針對行業作一些調整嗎？

向陽：咱們主要是從解決方案的層面作調整。咱們會組合上下游的產品構建完整的解決方案去給到客戶，面向不一樣的場景、解決不一樣的問題。

---

思否：對於將來的雲網絡工程師來講，您認爲可能須要掌握哪些技能纔會適應未來雲時代的發展？

向陽：之前對於一個網工來說，面向的是 CLI、有時須要作一些自動化的工做，好比寫 Expect 腳本去抓一些 SNMP 數據，但這個時代正在慢慢的成爲過去。如今的網工可能更多的是從兩個方面提升本身，說到這裏我打個招聘廣告，歡迎對 SDN 有興趣的同仁加入咱們：https://www.liepin.com/compan...

首先是自動化。如今一個網工管理的設備數量級是之前管理的十倍，自動化確定是必須的。剛纔提到的Python實際上是比較適合自動化的編程語言，並且它的准入的門檻也不高。

其次是面向複雜系統的數據分析能力。不一樣崗位的人對一個系統監控數據的需求不盡相同，不能期待有一個產品級的東西點一下鼠標就能解決全部問題。網絡工程師須要具有，基於採集到的數據稍加處理，可以獲得一個本身想要的結果的能力。在網絡數據以外可能還有一些系統的數據，例如日誌的數據，怎樣去作這些數據的關聯和分析，目前仍然須要人的創造力。