作者簡介
朱鋒
廣東移動
網絡運維監控專家
謝謝大家，其實很榮幸今天來到這個舞臺來講這些東西，我今天的主題是叫智能運維，我們用的質心算法實現網絡故障無差別自動定位，我來自廣東移動，一直在監控一線的工作，說簡單點就是監控值班人員。
今天上午講的平臺我不太懂，架構我接觸的也比較少，所以說今天只能講一個我實際工作當中的案例，其實是一個小而美運維的實踐。
看到目錄就和他們不太一樣，大家都是做運維的，都知道運維的困難非常多，但是我們運維人的辦法更多，辦法比困難多，很多辦法的效果還不錯，特別在 DevOps 時代，運維開發，然後人工智慧這些工作，運維的未來其實是非常值得期待的。
1. 困難—有很多第一部分先做個廣告，大家接觸過的都知道，2015年移動推出VOLTE業務，VOLTE就是高清語音業務，發展很快，現在基本上已經有4個多億的用戶，最大的優點，接通時長非常短，2.7秒，推出高質量的語音業務是有代價的，代價是網絡越來越複雜了，目前這個網絡是我們接觸的最複雜的一個業務。
這個其實就是一個簡單的視頻，當初的時候我們內部培養要花很大量的精力，當時讓我們自己人掌握VOLTE的流程都花了很久。
這個圖也是當時畫的，2015年畫的第一版，今年更新了第二版，也是給內部人員學習的，基本上是我們的這種核心網的示意圖。為什麼放圖在這裡呢，其實只是感受一下網絡的複雜性，因為我們維護對象就是他們，我們要保障這張網絡的可靠。
其實左邊這塊就是接入網，就是用戶直觀看到的各種鐵塔，這邊是中間以前4G的核心網的架構，簡單就是這種基本邏輯的核心架構。右側比較多的紅色虛線連起來就是複雜的VOLTE新引出來的，具體不展開講。我們跟網際網路的企業差別非常大。
同樣也是來體現這個複雜性，不僅是說剛才的圖講這個原理業務非常複雜，但是我們移動端還有另外一個特點，我們的網絡是中國最大的，而廣東移動也是我們中國移動基本上全國最大的省級網絡了。
右邊這個圖系我們內部畫的簡單的示意圖，我們的網絡基本上分這種概念，底層這幾層是龐大的傳送網，基本上就是動力設備這些保證連通性的，中間是一種承載網，大家知道路由器組成的，上面才是我們的核心就是控制層這塊，根據技術的演進，從以前的2G到現在的5G，每一代的網絡側重特點不一樣。在這些網絡當中我們提供了多種多樣的業務，現在的業務越來越個性化了。
簡單給大家看這個數據，之前放了一個數據在上面，這是目前我們廣東移動的數據，登記用戶數目前大概1.2億，這個是總的用戶數，全部在網的，不包括物聯網。4G用戶數佔了三分之二，有8000萬的用戶已經在使用4G業務了，說明老人機還是很多的。
4G用戶當中其中7100萬開通了VOLTE功能，有3600萬正在使用VOLTE功能，家寬業務今年發展比較快，這兩年剛起步，現在廣東是1200萬左右。流量今年長得很猛的，今年各個省推出了不限量套餐，以前我們日流量14個PB，家寬流量好像40幾個PB，話務量我們日均2000萬，什麼概念呢？如果按照我們1.2億總用戶數來說，也就是平均用戶每天通話10分鐘。這是我們業務的規模，非常大的，支撐這個業務規模我們的網元數130萬以上，日均會產生530萬以上的告警，我們會派發3萬多的工單。
所以說其實我們的挑戰非常多，簡單這裡列了兩個，一個是隨著技術的發展，我們的核心網已經由過去這種單一的網絡演變成多網協同，多鏈路交織的。我不展開講，基本上就是說主網的結構會越來越複雜，我們的通信的網連形態跟網際網路是不一樣的，我們的網聯形態非常多，業務需求比以前更豐富了，以前用戶能打電話，發簡訊、上網就可以了，現在越來越複雜，越來越個性化。現在問題多，這是第一個挑戰。
第二個挑戰是NFV演進，我們以前自己叫CT工程師是做通信的，我們維護的是通信網絡，我們的設備大部分都是專用的，也就是說我們都是各個廠家定製的不同的功能，而不像大部分接觸的都是伺服器。
現在大家說NFV演進的功能虛擬化了，以前專用的設備不用了，現在全部用X80伺服器，加載不同的軟體實現通信的專用的設備，對我們來說是網絡更複雜了，是整個通訊更複雜了，右邊的這個圖，以前我們有一個叫OTS（音），現在可能惠普給我們提供了一些伺服器，把這些伺服器組成一個資源池，然後華為說你按照我這個設計。
基本上就是左邊這種列的總結，不會太展開，基本上我們提的這幾條，對我們的人員要求不僅要懂CT，還要懂IT，我們做「ICT」融合的人才。
其實網絡這種變化，我們現在內部的職責現在在調整，現在我們可能要成立專門的IT資源的部門，底層的這種。
看一下我們的工作環境。（圖）
看起來高大上，其實挺苦逼的，全年無休，24小時加班。平時日常工作就是一忙起來就是三五個人聚在一起，要協調處理了。沒事的時候相對好一點。特別是春節，節假日我們是比較更苦逼一點的，平時還能休假，一旦到了節假日你沒有任何理由請假。
剛才說了我們的網聯功能很多，我們的維護或者說我們的工作流程，我們保證130多萬網聯正常的工作，我們怎麼幹的呢？現在還在幹的套路就是用不同的採集機，把信息都採集上來，每個省不一樣，第三方廠家把這些信息匯總起來，我們那些監控人員就是跟著它，有問題趕緊處理，最怕的就是出現紅色的，紅色的時候可能要影響業務了，第二怕的就是突然閃屏了，滿屏幕都是。
所以說我們的工作基本上大部分就是盯著它，重要的時候，像這種一次普通的故障處理會涉及到很多東西，比如首先發現告警，或者說你收到10086轉過來的投訴，一旦有10個用戶以上的投訴我們就怕了。
如果這個時候有投訴，要結合投訴的信息，因為投訴基本上打投訴號碼我們對號碼進行分析，號碼做分析主要為了結合這種業務，包括拓撲繪製，前面Spark是全鏈路的拓撲，我們可能繪製這次故障，這次用戶投訴相關的圖，繪製這個圖很需要經驗，非常複雜，你到底畫哪些，哪些不畫，因為要把關鍵的信息呈現出來，我們要查工程，工程就是變更，我們要多測業務指標，我們的監控相對來說做的比較前一點，我們不僅僅是說看到就行了，我們做了很多後臺專業的，所以我們要實現一個定位。
其實說困難很多，總結得不是很到位，其實基本上網絡這個東西越來越複雜，所謂的四代共生，2345G都有了，最關鍵的是對我們的人員要求更高了，我們的人員流失非常大，越來越招不到高質量的人才。以前大家知道招聘平臺是挺嚴的，現在大班可以進的。
所以說我覺得運維人員還是不足的，我們整個一直在做的都是想謀求運維轉型，當年我們想做這個方面轉變的時候也沒有想到這些高大上的名詞，就是想工作簡單一些。這是困難的一部分。
2. 辦法—比困難多分享一下辦法，其實辦法說高大上一點，標準化、自動化、智能化，大家都提了。我們今年集團提了一個IT換人戰略。我們當年想改變的時候，我想不到IT化，我只是想面臨的這些問題處理起來少一些，不要遇到下一次故障的時候會自己再背鍋，類似於這種，沒有及時發現，沒有及時處理，僅僅是這個想法這個出發點。
首先我們做了一個標準化的事件距離模型，這是幹嘛用的？剛才大家看到的，以前我們處理告警的時候很重要的一步，特別是海量告警的時候，我們首先會做關聯分析，以前做關聯分析非常依賴於專家經驗，他知道A標題和B標題，A告警和B告警關聯度非常大，我們把這些規則提給廠家，然後他們做配置、開發、實現。
但是現在雖然還在幹，但是已經越來越不能解決各種遇到的問題了，主要是網絡太複雜了，技術更新化太快了，我們學4G沒有多久，馬上又學5G了，所以說再厲害的專家不能在短時間分析關聯出來上千條告警，我做這個事的出發點，2016年中的時候一個非常小的故障，當時我們三個工作五六年的老骨幹在一起花了基本上快半個小時才大概找出來原因，700條告警。
當時覺得很鬱悶，那次覺得以後不能再這樣了，再這樣肯定不是辦法。所以當時，記得那段時間失眠，晚上睡覺的時候基本上會想這個問題，基本上快忘光了以前的數學知識，會想著量化，把以前定性的分析變成定量的，我量化任意兩個告警的相關性，第一個考慮的是距離。
有這個想法以後，當時經過了一系列的優化，大概有這個結果，為了這個結果基本上首先我們拓展了，雖然開始的出發點我們想做告警，其實後面我們做的不僅僅是告警，是我們運維接觸任何一條異常事件，一個客戶投訴了，一條日誌，我們提煉出來目前主要這個事件發生的時間和位置，當然其實如果考慮精確一點的話是應該發生什麼事，這三個因素。
其實我們在做的時候發現前兩個因素更重要，什麼時間、什麼位置發生的異常點。這是我們提煉出來的因子，可以說是因素，這個模型我們想定義標準化的距離，當然距離越小越相關，這裡面再點一下，這裡面發生的位置其實與我兩個位置之間找到定義距離，其實有考慮過類似現實世界的物理距離，我們所維護的是運維的虛擬世界，我們考慮的是虛擬世界的拓撲距離。我當然還是想總結出類似萬有引力這種公式，當然這很難。
我覺得兩個事件間的距離肯定跟它發生時間差是有關係的，以及它發生的位置和位置的拓撲距離，這只是我嘗試的一個理論公式，後面我實際做的時候是一個近似值，我覺得工程和理論是有差別的。
看一個我們通信網絡的例子，圖畫的不是很好，這是2016年我說的讓我下定決心來轉變的出發點，當時這其中挑了兩個事件，一個是BSA，它控制了你們看到的鐵塔，一個BSA可能控制一百個鐵塔鏈路。另外一個負責DRA，出現的業務故障到底明顯告訴你的最多的這也是我們花時間做出來的，我們做了一些提取和優化才能夠在這條異常信息裡面呈現更多的信息。
這兩個事件在我的標準模型裡面簡化成距離是0.15，為什麼是0.15呢？差了16秒，它們兩個的拓撲，實際上按照原始的套路應該要+1，當然後面我忘了A點到E點的網聯，所以說由於這個DSC（音），這個依賴於我們的資源關係，網絡的拓撲結構，這個數據我們是有的，所以說我們依賴於這兩個節點之間的這種連接關係，我們定義了這種事件，這個叫邏輯之間的配置。當然還有其他的連接關係，比如說兩個網線插起來，就是基於這種關係。
簡單說一個例子，說明這個事是可行的，是一個理論的考慮點、出發點，有了距離還不行，得有算法，剛才說了傳統的告警關聯基本上是定性的，因為標題都是文字的，不同廠家，華為是中文的，電信還是英文的呢，就是需要定性的專家來定義。
一旦有了標準化的度量以後，一旦定量以後它就可以自動來學習了，機器學習可以來分類。2016年我對這個只是小白，只是聽過這個概念，但是怎麼幹這個事不知道。
所以2016年中開始看書，發現其實有很多成熟的算法，你們應該比我知道的更多，比如說聚類分類的算法，當時結合自己通信的業務場景挑了兩個，一個DBSCAN、還有最近鄰。一開始兩個都用，後來優化了，我們結合在一起了。我採用了聚類DBSCAN裡面的EPS鄰域的概念，然後採用最近鄰的概念，把兩個結合在一起做了實時的關聯算法，可以說是兩個結合。
前面這兩部分介紹了距離和算法，有了理論的基礎。其實在以前就算有這個想法也沒用，為什麼？因為我們運營商有這個想法也開發不了，我們的套路是你有想法你有需求你提，會有第三方的廠家幫你開發，會有排期的流程，基本上隨便哪怕一個小的需求可能半年，半年需求出來以後跟你想的完全不一樣，這是沒有辦法的事。可能當時不具備這個條件。
我覺得這一點也是不可或缺的，就是現在移動公司在轉型，在推我們內部做自研開發，相當於推了我們CT的工程師要轉學IT的東西，我們集團要求每個員工都要懂編程，還要考試，我們廣東移動從2016年開始組織自己員工自研的開發大賽。
3. 效果—還不錯現在有了這個條件，自己開發的這種條件，如果是以前的話還是做不出來的。當時2016年，我接觸的IT還相對早一點，我2016年有這個想法以後就開始學。當時學語言就寫Python，JAVA我不會，寫不來，寫Pyhton因為它簡單。
特別現在很多腳本都是Python寫的，所以2016年底的時候，很簡單，我們就是一臺伺服器單機的，用Python的思路把距離、算法實現了，然後存到庫裡面去，看起來不友好，看起來不爽，又開始自學前端，當然前端那種界面做出來了，效果能看出來。
基本是上這樣，基本上從2016年有想法，到2017年有了可以看的前端，基本上一年多的時間，後來集團公司發現還可以，覺得這個想法可以做，然後全國挑了5個省來試點，試點了半年確實可以，那就做。
所以說我剛才說的辦法這部分有算法，有模型是一方面，但是趕上這個DevOps好時代，自己能開發的，什麼東西掌握在自己手上，其實我們現在內部開發人員開始學Python，學的東西越來越多。
總結一下我們整個為了解決之前的困難的辦法，我們也不算發明，有了一套新的理論，我們自己現在去實現它，然後慢慢優化它，這個優化的過程現在一直在運行的，今天我們集團公司內部開這個討論會，只是會議通知比這個晚，我沒辦法，所以優化還是在一直優化的，這個掌握在自己手上。
簡單看一下效果，效果我覺得還是不錯的。看四個方面，第一，大家可以感受一下，右邊（圖）夜班的時候，值班人員發現剛才那個窗口少了，一個告警出來，我們基本上是DSC、RNC、MME、DRA、CE、ISBG等不同系統的，我們列出來的系統有7種設備類型，35種告警標題，總共是5000多條告警，我們的系統是自關聯為一類，會自動定位網圓EC77，事後還有一些專家。
後面專家分析就是CE77和CE03，因為他們的傳輸還是最底層的，傳輸的節點有問題，另外一個問題就是有一定的依賴資源，你想知道底層傳輸的東西，你拓撲信息了解得越多，它的的定位關聯越準確。
再舉一個例子，我們叫做精細化的變更管控，變更就是我們說的功能操作，我們的網絡不僅大，變更非常多，每天都在做操作，日均兩百起以上，我們主要的功能操作在夜間做。從12點經常做到4點，這段時間做。
變更的影響也是非常大的，70%都是變更告警，變更導致的。我們影響大的故障都是夜間告警。有了新的架構我們是怎麼做的？我們現在把變更當成普遍的異常事件了，它有變更操作時間和變更操作位置，所以說會自動告警進行關聯，反正套路是一樣的，沒有更多的調整。
關聯以後的效果，我們發現和過去的方式有提升，提升了25%。還有一個提到精細化，精細化是什麼意思呢？以前變更或者變更管理是比較粗放的，只要這個網聯有操作，那個時間段產生所有的關聯都打上這個標籤，但是這個是不合理的，有可能這個操作只是很小的這種調整，但是由於工程人員的失誤或者其他原因，可能會遭到投訴。
以前的話，這種工程處理可能不及時，因為大家知道夜間的時候人相對少一點，告警會多一些，工程告警我們既然知道有人在操作，所以相對處理的不是很及時。
有了這種標點以後，我們做進一步分析，就是這一類工程會導致哪些告警，不會導致哪些告警，我會學習後臺一些規則我會分類的，比如說一類工程會導致1234，而不會導致3456，就是更精細化了。
這是第三個應用，建立了一個智能研判系統核心算法，也是平時故障處理的時候用的，故障處理更多的用在批量投訴，超過10個用戶以上投訴的時候，我們會串聯這些東西。當然以前案例的分析也可以做，只是現在把算法作為其中一個核心算法，就是說你一旦創建了這個故障的這種案例，會把這些故障期間相關的警告點全部收上來，算法自動把它關聯成若干類，相對來說以前可能關注5000條，現在已經幫你關聯好了，三類，定位的力度、範圍是多少，這是我們研發系統這塊。
這個是我們集團開發的界面，就是我們現在在做的，到時候和各個省級推廣的就是這個。底層架構比我們更全一些，只是說這些算法，我們廣東公司最開始做的基本上今年在全國開始通用了。
4. 未來—值得期待簡單講一下未來，從我個人成長曆程回顧一下，我覺得因為我站在最底層運維這種有代表性，我參加工作應該比較早了，2009年進移動開始做運維，其實到2016年的時候我很迷茫了，為什麼？在那個環境裡面該掌握的都掌握了，後面不知道該幹什麼。
2016年中的時候有了算法的靈感，開始學習IT的知識，覺得可能是推開了一個新的大門，那個時候有點後悔當時為什麼不學計算機。2017年基本上省內應用，第一次接觸DevOps這個名詞，當時邀請專家給我們做一個講座，我們才知道有了這種很標準的東西，2018年全國應用範圍相對廣一些，學的東西更多一些。從這個角度看，對運維現在稍微有些想法，覺得其實很多東西還是可以做的。
我一直覺得其實整體處理的思路的轉變，從定性到定量，我一直覺得不僅僅是用於通訊行業。我之前寫這個材料的時候，我始終擔心我舉的網際網路的例子，到時候你們看起來根本不是這麼回事，今天早上我想了一個新的例子。我昨天晚上在這邊酒店睡覺的時候，空調沒關，早上起來流鼻血有點感冒的症狀，其實事後想一下，這兩個事件是有關係的。
我再拓展一樣，怎麼能夠把這個應用到醫療行業呢？比如說現在的穿戴設備越來越多，大家手環各種東西，如果在將來穿戴設備特別多的時候能夠進行全身的檢測包括周邊環境的檢測，就拿昨天晚上來說，我戴著手環溫度低於10度，有一個告警的信息，第二天有異常的流鼻血的信息，後臺自動關聯你今天流鼻血因為昨天晚上某一個點溫度低了有關係。更近一步的，三甲醫院的醫療資源，大數據的平臺有了支撐，第二天有不舒服的症狀，可以跟周邊環境的變化數據自動關聯在一起。
更多的可以實現預測，像昨天晚上一樣一旦溫度低了，可能就會來提醒溫度調高，這是展望。
不展開提了，剛才提到了標題因子，其實我們也在優化，更多的東西也是在嘗試著在做，包括算法方面的，包括定位出來或者自動的處理，時間關係就不講了。
本文為廣東移動朱鋒老師在 GOPS 2018 · 上海站的分享。
外包模式下的 DevOps 流水線怎麼做？廣東移動曾海劍老師 會在 GOPS 2019 · 深圳站帶來「外包模式下的 DevOps 流水線進化史」精彩議題
更多精彩議題敬請期待…
點擊閱讀原文，立即訂票