2.1 數據驅動的網絡運維

數據價值在大數據時代得到了更為直觀的體現，眾多企業已由“業務驅動”型戰略轉向了“數據驅動”型戰略。對數據進行有效的存儲和管理是實現大數據分析的基礎[1]。一個高效安全的數據分析平臺可以完成數據收集、存儲和計算甚至可視化等任務，可以極大地提升網絡運維的效率，是實現運維智能化的基礎，也是網絡運維中至關重要的一環。優秀的數據分析平臺需要具備高可靠性以保證數據的安全、高擴展性以適應不斷變化的需求、高效性以處理龐大的數據量。隨著時代的發展，實時性逐漸開始占據重要地位：運維平臺需要能夠及時反饋系統運行狀態，幫助運營維護人員完成日常監測，實時掌握系統的整體狀態。

對于數據驅動的網絡運維，目前業界的實踐可以分為以下幾個階段。

? 網絡運維 1.0 階段：實現了對網絡運維中所產生數據的集中存儲與審計，沒有復雜的事務處理，完全依靠網絡管理員的個人經驗實現運維管理。

? 網絡運維2.0階段：利用Hadoop、Spark等分布式大數據平臺實現了離線批處理，適合大規模的網絡運維數據處理，但缺乏易用的數據分析平臺，仍然需要依靠領域專家的功能開發。

? 網絡運維3.0階段：出現了對網絡運維數據進行存儲、管理、分析以及可視化的平臺套件，如業界常用的Splunk、ELK等，但無法滿足運維中的復雜需求。

? 網絡運維4.0階段：誕生了結合大數據挖掘技術的一站式智能運維平臺，在網絡運維3.0階段的基礎上，結合自然語言處理、大數據挖掘和機器學習等技術處理異構日志、故障溯源及工單分析等復雜的運維任務，研發領域相關的可定制化高可用處理引擎，構建基于多源數據的智能運維協同分析平臺[2]。

下面將對這4個階段進行具體分析，配以實例詳細分析網絡運維的發展過程以及未來的發展方向。

2.1.1 網絡運維1.0階段：簡單數據處理

計算機在工作過程中會生成大量的日志數據，對這些日志進行分析處理、故障溯源，是運維中非常重要的一部分。日志是指帶時間戳的基于時間序列的機器數據，它包含設備名稱、操作時間以及服務器等系統信息[3]。日志是非常重要的數據源，可以準確而充分地反映用戶的實際行為，具有很高的分析價值。

在網絡運維1.0階段，網絡運維所產生的日志數據并不是很多，數據級別多是MB級或是GB級，尚處于單機能夠處理的范圍。syslog是用來記錄和保存系統日志的協議，它支持標準的純文本日志形式。計算機系統每進行一次操作，就會產生相應的操作日志，并被syslog保存下來[4]。在Linux/UNIX系統下，有諸如grep、sort、join 等現成的工具可以進行日志分析。邏輯稍微復雜一點的，可以利用 Perl 或者Python腳本語言編寫相應的腳本，完成所要完成的工作。

當我們需要頻繁、多次地對日志數據進行操作分析時，上述方法顯然并不適用。如果每次對日志進行操作分析時，都需要網絡管理員編寫相應的腳本，會極大地增加網絡管理員的工作量。此外，對于一些常見操作會出現許多重復的代碼，造成資源的浪費。數據庫的使用能夠很好地解決這一問題。數據庫可以輕松地完成數據的錄入、保存、查詢以及簡單的修改等操作。數據庫的優點在于其結構化的數據存儲形式便于對大量數據進行管理：將日志中一些不必要的字段去掉，只保留如 id、time、agent 等重要的字段信息。因而可以很輕松地實現對結構化數據的統計。例如針對MySQL數據庫，完成統計數據庫中存儲的網頁瀏覽總量的任務，只需進行簡單的“SELECT + COUNT”操作即可，極大地簡化了網絡管理員的工作量。

2.1.2 網絡運維2.0階段：分布式大數據處理框架

隨著數據量的快速增長，數據處理的級別已經達到了TB級甚至PB級，并且日志數據的特征之一就是隨時間持續增長。因此傳統的單機數據庫已經無法處理如此龐大繁雜的數據。分布式處理技術的出現很好地解決了這一問題，大大提高了數據處理的效率。

對大數據的處理通常包括數據收集、數據接入、數據計算、數據輸出4個步驟[5]，也就是對數據的收集、存儲、計算以及可視化展示。一個完整的大數據系統應該包括這 4個過程[6]。數據收集是大數據處理的第一個環節，也是非常重要的一環，直接決定了接下來所處理數據的完整性和代表性。一個好的數據收集系統要做到能從多個數據源收集各種類型的數據。目前比較主流的開源數據收集系統有 Apache 的Chukwa、Facebook使用的Scribe、Cloudera的Flume、LinkedIn使用的Kafka以及Fluentd等[7]。存儲同樣是數據處理過程中非常重要的一個階段。為了防止數據丟失，數據存儲系統應當有自己的容錯機制。HDFS是Hadoop中的數據存儲模塊，在其他系統中的應用也非常廣泛。數據的分析處理主要是利用數據計算引擎，結合數據挖掘算法整合出隱藏于數據中的有價值的信息。目前主流的數據計算系統主要有Hadoop的MapReduce、Spark等，之后它們又各自發展了Storm和Spark Streaming來處理流式數據。

2.1.3 網絡運維3.0階段：網絡運維平臺套件

可以看到網絡運維2.0階段的幾個分布式大數據平臺有著各自的優缺點，可以滿足不同的網絡運維要求。在這一階段，幾大主流的分布式大數據平臺的性能已經足夠滿足大規模網絡運維的數據處理要求。但是它們遠遠沒有達到簡單易用的程度，對操作人員的專業能力要求較高，缺少簡單易用的數據開發平臺。

隨著大數據技術的發展，業內迫切需要開發完整、簡單易用的大數據處理套件，從而實現網絡運維的智能化。在網絡運維3.0階段，出現了Splunk、日志易等大數據處理軟件，也有類似于ELK的開源大數據處理套件。它們都能夠實現大數據的采集、存儲、處理，并展示這一完整的大數據處理流程，功能十分強大。

ELK、Splunk與日志易之類的一站式大數據處理軟件/組合的出現，標志著網絡運維朝著智能化的方向更近了一步。開發者不需要將大量時間花費在調研數據處理的各個過程中所需系統的優劣、不同系統組合后性能是否達標等問題。這些大數據處理套件的性能足夠強大，開發者可以即拿即用，節省了大量的時間。并且，經過廣泛的使用與經驗總結，這些系統的資料信息已經大批量地出現在網絡上，開發者遇到的問題幾乎都可以找到解決方案。簡言之，這些套件已經是十分成熟的系統。

2.1.4 網絡運維4.0階段：智能化網絡運維

數據驅動的網絡運維發展到3.0階段，大數據處理框架和平臺已經能夠很好地完成數據的采集、存儲、處理和可視化展示等工作，功能已經十分強大，但是這些分析平臺在智能化方面做得還不夠出色。面對實際應用中異構日志的技術處理、故障溯源、工單分析等復雜的運維需求，它們并不能提供較為完美的解決方案[8]。下一步，我們需要在已有智能運維平臺的基礎上，分析具體的項目需求，結合自然語言處理、大數據挖掘和機器學習技術，開發高效的算法，研發該領域相關的可定制化高可用處理引擎，構建基于多源數據的智能運維協同分析平臺[9-10]。例如，利用智能運維平臺進行工單質檢，加入相應的規則算法，對已經存儲在平臺中的工單數據的字段值進行抽取，自動篩選出諸如關鍵字段值為空或字段類型明顯與實際不符的錯誤。另外，抽取工單的時間字段，比對告警發生時間與解決時間，篩選出有明顯時間邏輯錯誤的工單。通過類似于上述兩種工單的質檢規則，可以自動篩選出滿足算法中關于“質量不合格”定義的工單，將不合格的工單交由運維人員集中進行人工審核，這樣就能夠極大地減輕運維人員的工作量，提高工作效率。