大型DCI網路智慧運營實踐

＂鵝廠網事＂由深圳市騰訊計算機系統有限公司技術工程事業群網路平臺部運營，我們希望與業界各位志同道合的夥伴交流切磋最新的網路、伺服器行業動態資訊，同時分享騰訊在網路與伺服器領域，規劃、運營、研發、服務等層面的實戰乾貨，期待與您的共同成長。

網路平臺部以構建敏捷、彈性、低成本的業界領先海量網際網路雲端計算服務平臺，為支撐騰訊公司業務持續發展，為業務建立競爭優勢、構建行業健康生態而持續貢獻價值！

在2018 GOPS全球運維大會上海站，來自騰訊TEG網路平臺部網路運營負責人何維兵，做了主題為「大型DCI網路智慧運營實踐」的分享。以下為根據現場演講整理的文稿。

何維兵，來自騰訊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、excell的形式存在，或者裝在腦子裡面。沒有經過很好的抽象和封裝，把這些東西以引數、函式的方式表達出來，簡單說就是沒有模型化、結構化的抽象，沒有存在我們的資料庫中，系統不太能理解網路上的一些含義，比如一條連線代表什麼含義，一條配置代表什麼含義，一條syslog代表什麼含義。因此我們最近2年在對網路進行抽象建模，對硬體連線、對配置特性、引數，包括運營的狀態進行模型化的抽象定義，簡單說就是構建比較完整的網路知識圖譜。這個工作，挑戰性也蠻大的，我們還在不斷的摸索中，硬體部分我們已經完成，並應用在一些新建、擴容場景中，配置部分正在開展中。這是我們後續重點發力的方向。

第二個實踐，我們嘗試在配置管理上做一些突破。一臺TOR大概有5K行的配置，一臺CORE上萬行的配置，這麼多行裡挑哪一行錯了是很難的。同時每一天都有變更發生，你如何在動態的情況下管理它呢？這個挑戰是很大的。我們在想怎麼做呢？也無非就是找不同嘛，找誰的差異性比較大。  

舉個簡單的例子，比如說有這麼多籃的水果，如何把不同的水果籃挑出來呢？我先把水果堆在一起，看看哪些水果出現頻率是最高和最低的，然後把它進行聚類，把稀疏的專案篩掉，我們就用這種思路去管理。具體怎麼做呢？我們參考了TF-IDF的文字分析演算法，它主要是會過濾一些非關鍵的詞項。我們把這套方法叫做聚類+降維分析法，把它應用在了配置文字的管理上。

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

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

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

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

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

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

以上就是我們近期在網路AIOps上的一些探索和思考，僅僅是一個開頭，相關的專案仍在持續推進，我們正在實時黑鏡2.0專案，打造基於事件的智慧診斷平臺。會對更多的運營資料進行分析，並把檢測分析邏輯模型化，實時對全網進行大量的邏輯運算，提取異常事件，形成異常事件庫。會持續進行方法的最佳化，引入更多的演算法，提升準確性。最終將基於完整的知識圖譜，構建一個圖資料庫描述網路的軟硬體關係，基於異常事件對網元進行著色處理，然後根據中心度的演算法，進行故障定位計算。

這是我們下一步的方向和思路，歡迎業界同仁一起研究和探討。