9月14-15日，GOPS全球運維大會上海站圓滿舉行，為期兩天的運維盛宴，為各位運維人帶來了相互交流和學習的絕佳平臺，來自騰訊技術工程事業群（TEG）網絡平臺部的何維兵給大家帶來了「大型DCI網絡智能運營實踐」的主題分享。

我們同步了嘉賓現場沙龍分享視頻（內含高清PPT），請點擊下方「騰訊技術課小程序」卡片即可查看：

同時附上整理好的演講稿：

何維兵，來自騰訊TEG網絡平臺部，資深運維老兵，擁有10年運營商網絡、6年互聯網基礎設施運營經驗，擅長大型骨干網絡、數據中心網絡維護管理和運營支撐系統規劃建設，目前專注于網絡自動化運營、NetDevOps以及網絡智能運營的實踐探索。

運營苦、運營累，關鍵時刻不能跪！！！

記得有一年微信年會，老板現場發紅包給大家，結果紅包沒發出去，因為網絡出故障了！你們能想象到當時有多尷尬。隨后老板找到我們提了需求，重要業務要在三分鐘恢復！

我們來分析一下這個需求，這是截取的一些公開資料，大部分互聯網公司都差不多，從A端到B端的訪問路徑算了一下，大概經過32個網絡結點，中間路徑1000條，這么多路徑、這么多節點，三分鐘時間內搞定這些問題還是挺有挑戰的。

需求是合理的，老板的方向也是對的。于是我們啟動了一個項目，黑鏡1.0：網絡故障智能定位，嘗試解決這個需求。出發點是：圍繞著故障發現、定位、恢復這三個階段，看看每個階段能做哪些事情或提升！

我們總結了一下思路，稱之為“3M大法”。首先把自己的眼睛擦亮，通過Meshping的方案做了高精度的監控感知系統。第二，基于以往故障的經驗總結哪些東西是跟故障強相關的因素，定義為Multi-KPI的體系，通過這種方式我們來定位故障。第三，把所有的冗余組件封裝好，用的時候直接調用組件Moveout故障點。

第一個Meshping探測，原理并不復雜。過去我們7*24小時坐在NOC監控中心，但很多時候并沒有發現問題，都是業務發現后找到我們。為什么出現這樣的情況呢？因為業務非常多，它分布的太廣了，它的敏捷度遠遠比我們高。那我們就想，干脆就從業務的角度監控，就拿機房的海量服務器去做這樣的事情。

其實很簡單，就是選取一部分機器作為探測對象，然后機器之間交叉探測。聽起來很簡單，但是要達到既能覆蓋所有的路徑，同時也在一定的時間之內，高效的把結果計算出來，并且達到高精度的報警，這還是很有挑戰的。

一方面要解決海量ping側任務和結果的計算，還要把中間的探索路徑記錄了下來，這么多的樣本記錄下來挑戰也很大，我們當時做的時候也繳了一些“學費”，把設備搞奔潰的情況也出現過。

另外隨著故障場景的積累，還需要更豐富的探測元素，比如說大小包的組合、QoS標記組合、UDP資源探測等等，我們現在還在持續的優化Meshping探測方案。

第二個就是Mulit-KPI指標系統。過去排查故障時，往往花大量的時間分析數據、找線索，就像上面提到的從那么復雜的一個路徑中，串行的執行那么多的分析工作，很難在很短的時間內定位故障的來源。所以后來我們不找細節的東西了，去找什么東西能夠代表它的故障，或者說哪些趨勢變化跟故障強相關。

舉例其中一個KPI指標：設備轉發效能比，它是基于包量守恒原理(二層環境除外)，把設備上所有的的入和出的數據包采集出來，做成一個比值曲線。大家可以看一下這個真實的數據，平時是很穩態的，但是故障發生后，這個曲線會有明顯的突變。我們把這樣的類似的趨勢變化，定義為故障關聯的KPI指標，這些指標不一定要多，但一定要準確和故障關聯。

第三個是Moveout隔離屏蔽。我們對所有的網絡冗余組件做了屏蔽操作的自動化封裝。有些不具備屏蔽的條件，也會設置一些靜默的通道放在這里，平時不用，需要使用的時候就開啟它。所以至少核心的層的組件都具備“逃生”的能力。

整套定位平臺框架由以上三個部分組成，其故障定位的原理也很簡單，把所有的探測的流采集出來，記錄下來探測流的路徑，通過這些異常流的特性鎖定一批設備，然后對這些設備計算KPI指標，通過KPI指標的疊加，就能看到誰是最可能的故障點了。

通過這套系統，可以在三分鐘內檢測到異常，并通過微信推送告警；然后4分鐘內完成定位計算，推薦故障定位結論；下一步就是人去決策要不要做相應的動作？

初期以安全為主，只在部分場景做成全自動化。通過這套黑鏡網絡自動化的診斷、定位系統，我們在網絡故障時，最快可以十分鐘內恢復故障，大部分場景在30分鐘之內搞定故障。

上述方法讓運營能力得到很大的提升，網絡質量監控很準確了，達到90%以上；但定位準確性不高，大概有50%（不準確性），還不能滿足需求。

有沒有辦法進一步提升呢？

這幾年大家都在談AIOps的理念，我們想能不能把AIOps引進來做一些嘗試。

想法很好，如何落地呢？

談到AIOps、機器學習，其主要的核心是要有高質量的數據，要有豐富的輸入和輸出，從這些數據樣本中去找到一些隱含的規律把它提取出來。

但是我們網絡的數據是什么樣的？

先看看網絡故障數據，發現有三個特點：

第一個就是稀有性，網絡上惡性故障樣本非常少，一年下來大概兩只手就可以數過來了；

第二個就是新興性，我們發現每次故障和上次故障重復的比例并不多，它都是新興的故障，特別是配置，每次配置發生的問題都是有差異性的，它的規律性其實并不強；

第三個是傳播性，網絡是一個mesh的連接，節點之間的存在較大的干擾。基于這幾個特性，我們發現網絡上的故障數據質量其實并不高，并不具備特別強的規律性。

那是不是不能做了呢？再看看網絡上還有什么樣的數據。

第一類是時序類的，比如我們通過SNMP采集的流量數據；還有一類是文本類的，比如config、syslog；這些數據能不能有小應用的場景呢？

我們結合一些行業的經驗和做法，選取了2個場景來進行試點：

第一個就是時序曲線的檢測，這個是業界應用最多的；

第二個就是文本的聚類分析，對配置文件進行審計校驗。

我們的想法是，一方面能看能否對KPI指標的監控準確性有所提升；另一方面通過配置文件的管理，減少故障的發生。

我們來看一看具體是怎么做的。

第一個流量的異常檢測，我們聯合內部SNG的織云做了嘗試，直接拿他們Metis平臺的成熟算法應用。把網絡的實時流量數據和歷史數據導到Metis平臺，平臺返回檢測結果，不需要我們進行任何配置，只需要對結果進行標記反饋。

用了這套方法之后，我們發現可以很好的解決單幅圖的監控，幫助我們解決鋸齒性、周需期性的誤告問題。但也發現還存在一些問題，主要是曲線之間的關聯問題。比如一個負載均衡的多個端口，像左邊的圖下降了，右邊升高了，這是一個正常的網絡切換行為，并不需要告警。這是在傳統的監控中沒有解決的問題，這里仍然解決不了。

那這種關聯性如何解決呢？

過去我們對網絡的管理的模式和方法不夠精確，很多的網絡知識，比如對網絡的連接、配置等，大部分是以PPT、WORD、EXCEL的形式存在，或者裝在腦子里面。沒有經過很好的抽象和封裝，把這些東西以參數、函數的方式表達出來，簡單說就是沒有模型化、結構化的抽象，沒有存在我們的數據庫中，系統不太能理解網絡上的一些含義，比如一條連線代表什么含義，一條配置代表什么含義，一條syslog代表什么含義。

因此我們最近2年在對網絡進行抽象建模，對硬件連接、對配置特性、參數，包括運營的狀態進行模型化的抽象定義，簡單說就是構建比較完整的網絡知識圖譜。這個工作，挑戰性也蠻大的，我們還在不斷的摸索中，硬件部分我們已經完成，并應用在一些新建、擴容場景中，配置部分正在開展中。這是我們后續重點發力的方向。

第二個實踐，我們嘗試在配置管理上做一些突破。一臺TOR大概有5K行的配置，一臺CORE上萬行的配置，這么多行里挑哪一行錯了是很難的。同時每一天都有變更發生，你如何在動態的情況下管理它呢？這個挑戰是很大的。

我們在想怎么做呢？也無非就是找不同嘛，找誰的差異性比較大。

舉個簡單的例子，比如說有這么多籃的水果，如何把不同的水果籃挑出來呢？我先把水果堆在一起，看看哪些水果出現頻率是最高和最低的，然后把它進行聚類，把稀疏的項目篩掉，我們就用這種思路去管理。

具體怎么做呢？

我們參考了TF-IDF的文本分析算法，它主要是會過濾一些非關鍵的詞項。我們把這套方法叫做聚類+降維分析法，把它應用在了配置文本的管理上。

首先把配置文件拆分成很多的模塊，每一個模塊把詞聚集起來，比如說一百個文件中的同一個配置模塊聚在一起，然后計算每個詞出現的頻率是多少，出現頻率比較低的直接篩掉。然后會形成幾個模板，這個模板會代表大多數的“廣泛意見”，然后拿這個模板和現網的配置進行對比，從而實現審計校驗的功能。

它可以用在兩個場景，第一個場景就是可以在存量的配置里提取有哪幾種配置標準，給到負責配置規范的同事去核驗；第二，就是對存量的小眾配置的設備，去看為什么不一樣？是不是哪里配錯了？這個方法在標準化程度比較高的架構中效果不錯，但一些邊緣接入的差異性比較大的場景則不是很好，另外對一些參數錯誤、或全局錯誤也不能發現。

通過這兩個案例，我們在網絡AIOps方面做了初步的探索和實踐，沒有用很高深的算法。在這個過程當中我們也總結了一些經驗，供大家在網絡領域進行AIOps嘗試提供一些參考，主要有三點：

第一點，就是網絡要系統建模。當前的網絡的抽象程度不夠，系統沒有辦法理解網絡上的語言和行為，要把網絡上的對象、事件、行為標準化的定義出來，讓系統能夠理解。今天上午清華的裴丹老師也提到過，這個工作是基礎當中的基礎。當然這個挑戰性非常大，需要大量的投入；

第二點，不需要過多關注算法細節。網絡從業人員在算法上不具備優勢，在算法領域可以充分借鑒參考成熟的經驗或開放資源，把重心放在場景、數據的挖掘和分析上。關鍵是利用算法的思路，看他能解決什么問題，比如我們第二個案例，實際上并沒有用到機器學習，只是用了一個數學算法，降低了問題的復雜度；

第三點，要加大在數據挖掘和DevOps上的投入。未來的運營，大部分是圍繞數據的提取、分析、挖掘等工作，如何對數據進行快速的提取、分析，把分析、處理邏輯準確定義好，這是我們重點投入的方向。

以上就是我們近期在網絡AIOps上的一些探索和思考，這些工作只是一個開頭，相關的項目仍然在持續的推進，我們正在開展黑鏡2.0的項目，打造基于事件的智能診斷平臺。會對更多的運營數據進行分析，并把檢測分析邏輯模型化，實時對全網進行大量的邏輯運算，提取異常事件，形成異常事件庫。會持續的進行一些方法的優化，引入更多的算法，提升準確性。

最終將基于完整的知識圖譜，構建一個圖數據庫描述網絡的軟硬件關系，基于異常事件對網元進行著色處理，然后根據中心度的算法，進行故障定位計算。

這是下一步的方向和思路，這里有很多的細節東西還沒有想清楚，還在落實當中。這里也是歡迎各位一起研究和探討。

總結

以上是生活随笔為你收集整理的大型DCI网络智能运营实践的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。