作者簡介：

朱世翔，北京移動信息系統部技術運維中臺產品經理、系統運維組主管。

具備較豐富的運營上部域系統一線運維管理經驗，今年帶領團隊進行技術運營能力的建設，初步完成了北京移動業務支撐系統運維能力自動化、智能化轉型。目前致力于AIOps和運維中臺體系實踐、運維開發團隊構建和管理。

文章目錄：

• 背景介紹
• 技術運營中臺
• 技術運營實踐
• AIOps 探索
• 未來展望

一、背景介紹

5G商用啟動開始，三大運營商正式推出了5G套餐，5G是下一代通信技術，那么5G時代來了之后同樣需要下一代運維。

我們就對下一代運維是怎么理解呢？其實當 5G 來了之后，我們理解是有兩個新的要求：第一，我們面臨的一些場景會變得復雜化，對原有運維能力的要求也更高了。第二，5G 來了之后運維邊界也是不斷拓展的。

第一點怎么理解呢？大家可以思考一個問題，我們運營商和互聯網行業、金融行業核心提供業務形態是不一樣的。

比如，一個電商企業提供了業務形態把產品賣好，可以在網站上完成購物，金融行業是圍繞錢提供一些服務，我們的運營商核心服務形態是資源，包括語音、流量等，這個業務形態有什么樣的特點呢？流量和資源服務每時每刻都在不斷變化的，所以在這個過程當中給客戶提供一些什么樣的運營服務呢？會有例如流量提醒等。

我們的團隊會做一些流量及時性保障，這是我們的運維核心工作之一。我們原來的東西是在變化的，因為 5G 已經變化更快了，要保障客戶進行實時提醒的難度在增大，要求更高。

第二，運維的邊界要進行拓展。那么，拓展方面的是什么挑戰呢？

 

 

第一個挑戰，傳統的運維系統是按照煙囪式進行建設的，按域來劃分有業支運維（B域運維）、網絡運維（O域運維）。

業務運維就是業務支撐系統運維，就是平時訂購流量包的套餐計費完成，是基于傳統的IT 系統技術棧來完成這個過程。

而網絡運維，是圍繞網絡設備的運行狀態進行，保障的是我的基站是不是有信號等，這是網絡設備的運維。不同域的運維，甚至同一個域內不同的運維系統，在系統能力建設上也是隔離的過程。

第二個挑戰是提供端到端服務時，沒有辦法提供端到端的運維保障服務。舉個例子，有一天用戶手機正常時沒有辦法上網是什么情況呢？有可能是IT系統的計費出錯了，導致停機了沒有辦法上網了，有可能是網絡設備故障導致沒有網絡信號了，導致無法上網。

我們傳統運維響應特點就是各查各的，整個核查過程是比較長的，同時效率是比較低的，反映不及時，就會帶來不好的用戶體驗感。

第三個挑戰，我們是如何看待運維技術的發展和升級呢？實際上我們理解運維能力升級更新圍繞運維對象的技術變化而發生變化的，隨著運維對象引入云計算、容器等，導致運維技術和要求需要隨之迭代升級。 

 

第四個挑戰，網絡運維開始引入了IT技術，CT領域開始跟IT融合，所以會導致運維模式、生態圈發生一個比較大的變化。

 

 

那么，5G時代 ICT 融合的背景下，運維能力是可以進行賦能的。第一，網絡運維軟件化之后可以隨著技術引入，可以向 IT 領域進行發展。

同時5G時代的網絡切片更加靈活，可以對不同行業不同場景提供支撐，所以對網絡需求的交付速度提出了更高敏捷要求。所以網絡域運維需要有一個持續交付以及一個敏捷的過程。

因此搞 IT 運維的發現網絡運維開始需要IT運維能力，因為系統架構和5G網絡特點導致他們需要IT運維的能力，這時候發現我們的IT運維是可以賦能的。因為在業支運維這邊從一開始的建設就在緊跟 IT 變化，所以說從移動成立開始就做了基于IT的技術棧演進。

 

 

基于這個切入點，我們可以看到 ICT 融合進行過程。我們的IT運維有之前的ITOA、ITOM等，我們是從業務網管到 DevOps 平臺，以前的網絡管理系統特點是電子工單流。

在5G時代技術開始進入了軟件化時代，這兩個可以逐步融合了，可以建設一個靈活可用的平臺，來賦能促使CT和IT平臺進行融合。

基于 5G 時代到來這么一個很好的切入點和我們傳統運維面臨的挑戰，最后匯總到一起可以讓技術運營中臺，打通整個全領域的運維能力。

二、技術運營中臺

什么是技術運營中臺？其實分為技術運營+中臺。 

 

首先說我們怎么理解技術運營？技術運營與傳統運維的區別是什么？

簡單來說，技術運營不僅關注傳統運營團體理解的系統穩定、系統安全等指標，還會從運營角度去關注效率、客戶體驗等指標。

那么我們對中臺理解是什么的呢？

第一，企業級是很關鍵的，如果你是一個小的團隊，你自己做一個中臺是沒有意義的。前臺是比較輕，中臺比較重，后臺是賦能的，所以企業級是很重要的，你現在是給企業里面的所有的應用團隊和業務團隊使用你的中臺。

在5G時代條件下，我們的中臺要面向B域、M域和O域，就是我們的網絡、IT系統等全局來考慮問題。

第二，能力是中臺主要承載的的對象，要從業務中抽離出來，梳理技術運營的公共能力。

第三，復用是中臺的核心價值，要去重早復用對比平臺更細粒度的抽離。

 

 

我們講一下設計中臺時的關鍵點，這是從架構方面做的簡單分享。其實你要做一個中臺，你要把各個團隊場景的重復建設能力和重復用的場景抽象出來，做成一個統一的公共組建能力。

舉個簡單例子，其實我們的能力是不止這些的，在以前流程有一個業務平臺，用戶管理有一個平臺，流量管理有一個，他們都在不同平臺對數據進行采集、傳輸、檢測、管理，這些冗余都是重復的。 

 

第一步，我們要把各個運維建設能力要做一個邏輯上的抽象，做一個技術上的傳輸，這個其實可能跟微服務治理有一些類似的理念。

 

 

第二步，能力復用。我們建設一個運維能力開放平臺，首先抽象出來的能力把做好之后，需要注冊在能力平臺上實現開放，比如說B域、M域不同場景是通過能力平臺做一個統一的轉換來帶動后端能力。

同時這個也會帶來運維團隊職責和技能的一個轉型，當前端不管是哪一個領域有需求時，團隊治理能力需要看的是中臺有哪些能力支撐你的場景，我要做對運維能力做一個管控。

第二，他們在能力開放平臺去做一些場景運維分析，比如說這個能力時長、調動量、成功率是不是滿足要求，如果不能滿足要求要及時提出，去通知后端系統和能力去進行改進。 

 

這樣你的組織架構就會變化點，你要有一個特定的能力技術團隊，會基于技術平臺做一些服務治理的事，所以必須對服務進行管控。

 

 

第三步，做了中臺之后，需要給第三方和其他團隊進行開放，你要有一些柔性的服務能力。比如說，對其進行限流隔離、熔斷，這個是中臺能力管控過程。

我們確定出來了一個技術框架，這塊還是體現在中臺分配邏輯，我們分成了各種管理操作，我們在里面不斷補充我們的原子化、公共化能力做復用。

 

 

這塊（見上圖）講的是技術運營中臺怎么做設計思路的過程，每個團隊做中臺設計時里面的東西分類不一定是這樣的，或者組件不一定這么設計，原理是相通的，因為你是給前臺去提供賦能和運營能力，所以你同時要進行管控，這是一個核心原則。

 

三、技術運營實踐

我們基于生態能力做了很多實踐場景，這些都基于中臺能力做了場景化。  

 

 

 

 

這個技術運營藍圖是我們團隊在2016年提出來的，是從集團規范戰略到省公司落地全畫房子，前面是愿景核心，同時達到愿景做什么事情，要做這些事情需要做什么樣的保障。

其實運營團隊傳統里面、企業里面或者自己本身認知里面是一個后端成本部門，是在不斷花錢保障不出事。

我們團隊在不斷思考，技術運維和運營的區別是什么呢？運營就是可以創造社會價值，就是信息部團隊在2016年提出的藍圖，這中間也在不斷優化，我們不是在去替別人背鍋，不是給別人補漏。

基于這個愿景提出了核心，就是要保障業務滿意，要進行一個風險防控?；谶@些核心做了分解，這些是能力的分解。從標準化到自動化、可視化、智能化，這樣是我們一個藍圖設計，我們的崗位設置都是圍繞這張圖不斷滿足愿景的目標。

 

 

 

第一塊講一下CMDB。我們現在分享兩個點，CMDB設計時想得比較全面，我們做了一個靈活自定義。比如說屬性自定義、模型自定義，其實這兩個場景是不一樣的，而你做業務模型管理也是不一樣的，里面主要就是IaaS和PaaS的東西。

假如說做一個軟件版本管理時，你的模型分層是根據軟件開發流程有分支的，那我們的模型是可以自定義的，包括模型里面的屬性關系都是自定義比較靈活的。

我們現在做了一些簡單場景的東西，因為拓撲是從資源盤點來進行研究的。如果你想用好CMDB必須要流量和數據支撐，怎么保障數據是準確和穩定的呢？CMDB有兩個來源渠道：第一，我們每個月變更次數是在1萬次，你沒有辦法靠人工去做準確性，我們后面會講到監控，這是基于監控平臺做的，我們都會抓過來同步過來。

第二，CMDB自己有自發現平臺能力這個也會獨立采集到系統運行的數據，我們會對不同信源進行一個稽核，基于稽核結果有一個分析和更新算法，來保證數據是更新的。

第二塊講一下系統穩定性保障，這塊其實是核心，在每個核心環節都有自己的痛點和思考。穩定性保障圍繞核心就是 CMDB，也就是要做好異常發現、分析定位、操作恢復。

在異常發現做了一個監控體系，就是運營對象、規范指標定義和指標體系落地。我們的指標有內存運用率、處理時長等指標，這樣的對于加指標是一個標準化清單。比如說，請求總量的屬性包括采集頻率、采集數據值是什么單位。

還有一個是閾值，我們把所有傳統的指標基于自己的理解來做，像服務器CPU的值，我們定了一個標準化的東西，形成了一個清單。 

 

我們做這個事之后有什么好處呢？第一，把監控能力規范化，是指監控平臺，把其變成標準化之后，給后端自動化操作、時間扭轉進行了全局編碼，后面是要知道監控了哪些能力，只需要看清單就知道怎么回事了，這是把能力進行了規范化輸出。

第二，數據質量治理精細化。我們會發現系統里面哪些對象沒有進行監控，我們在運維生產過程當中發現100臺主機可能監控上了，但是其中80臺可能沒有完整的監控指標，那么其中一臺主機的內存率高的時候是沒有辦法發現異常的，所以從對象細化到了指標級別。我不僅僅要看每臺主機是不是上去了，還要是不是黃金指標，如果差一個就是不完整的，把我們監控點集合的顆粒度精細變成了指標級別。

監控是有體系、編碼、閾值的，你所有監控動作都是圍繞運行數據來做的，如果數據采集之后就是原數據的組成部分，就會形成很標準的運維數據，我們都是基于這個數據來做細分。

第三，團隊轉型賦能化。以前監控團隊是一個被動響應過程，我也不知道你是不是全了呢？當做了監控體系之后就會變成主控團隊，你上線時提出說要95臺，我要基于CMDB看是不是這么多？如果不是的話就不讓你上線。 

 

我們還可以做運行風險的分析和輸出，以前監控平臺是做不到這塊的，我只管建，你告訴我監控什么我就可以給你做，但是沒有介入業務，也不知道在系統運維的風險。基于這一點使我們的團隊進行轉型做賦能，就會達到這么一個好處。

第四，全鏈路監控。傳統的開源的APM產品是基于后端鏈路抓出來的，我們實現了業務端到端的全鏈路監控，既然到了業務就到用戶體驗的頁面，其實這個技術復雜性不難，但是是一個問題管理場景的思路體現。這樣做完之后形成什么好處呢？我能看到業務從最開始的環節到最后環節的流轉過程，這樣就會帶來一些運維改造。

你怎么讓開發配合改造呢？ 

 

第一個，如果運維團隊是架構管控型團隊，必須要埋點。我有一個標準化規范方法，你必須按這個埋點做這樣的識別，是把我們的流程和技術實現了一個打通。

第二個，我們有三個下鉆，并且它們分別對應了不同人員：第一個下鉆對應業務管理人員，可以知道每個業務流程的節點是什么；第二個下鉆到集群實力和具體指標，這些對應的是平臺應用人員，需要看集群業務下面的實力，甚至他現在的數據和狀態是不是完好的；

第三個，下鉆看每個單筆訂單的業務鏈，這塊是對應的開發人員，當你看到有問題時是某一個方法有問題，這樣就可以方便開發人員進行處理，我們三個下鉆是滿足了不同的管理者，基于不同角色的需要去做了這么一個設計。

 

 

第五，應急響應的閉環管理。我們比傳統做了一個更橫向的拓展這塊關聯了知識庫和自動化操作平臺。我們的技術運營標準提出了一個更清晰化的管理，要對責任部門原因、整改措施是否落實有了細化要求，這些要求也需要在系統上進行實踐，你會提出一些整改措施，這些措施后續流程也需要覆蓋在節點上進行打通。

第六，運維小秘賦能。我們在處理故障時會有一個故障應急響應微信群，領導、業務人員和不同故障人員會把好多信息發進去。我們會把一個小秘機器人實現了同步，當突發故障報時需要收集信息，運維小秘會自動匯總信息，它只要判斷有故障就可以直接匯總。當一二三線處理時會涉及到流轉問題，那時運維小秘就會直接進行處理，然后在復盤環節就會形成報告了。   

 

 

 

 

第七，分析定位是鏈路分析。這個也是基于業務全鏈路監控來實現的。

 

第八，智能根因分析。之前看過一個廣發證券分享的主題，你的數據很多，但是你數據組合形式、展示內容對故障處理效率是有很大影響的。

這張圖左邊統計分析都不是AI過程，不是智能過程，這樣展現之后從故障影響范圍、故障的原因層層遞進，就可以很清楚直觀看到故障的原因是什么，現在是什么情況。這張圖把傳統信息和智能分析過程放在一起形成一個完整的視圖，就會帶來一個“1+1大于2”的結果。

第九，操作恢復是平臺級的支撐。我們變成了原子化組件來支撐場景，我們在故障分析、復盤時軌跡恢復是非常重要的。   

 

 

 

 

第十，自動化化預案策略。我們這個中心的核心價值就是實現應急策略的配置化，那么什么是策略呢？策略就是基于什么樣的異常場景，去執行什么的規則，這個規則就是策略。比如說，限流熔斷里面的算法都是有規則的，我們現在已經實現了界面化配置了。

四、AIOps 探索 

 

首先說一下功能架構，如果大家對大數據比較熟悉的話就是處理層和基礎組建。我們從去年年底到今年引入了AIOps 來做。我們現在離線和在線都是用 Flink 來做的。

 

 

再說一下學件概念，學件的概念大家應該都聽過，在我們北京移動是如何理解學件和它的實踐價值呢？就是參照以前的 API 做了標準化接口，學件就是把數據和算法合在一起，合成了完整的學件，在下一次同樣場景、同指標類型數據來的時候，就可以調動同樣的學件。

你要想達到使用技術效果時，你要根據值做大量的調優，我們怎么把其沉淀下來，就會變成學件。

比如說，我們在做第一次調適時，把算法調優了，指標就會很好。如果下次有新的指標就可以直接復用，因為你根據周期性做了調優，所以就會直接有比較好的效果。如果同樣的算法用原始算法做了指標，你算的指標和復用指標是不一樣的。

今天上午浙江移動提出了學件可視化過程，在我們這邊整個學件制作過程也是有可視化的，你要有一個數據員源，你還要配置指標，再進行算法訓練、最終實現復用。

異常檢測分析。我們在這里面做了算法應用、實踐效果、根因分析。我們首先會基于拓撲拿到異常現象先做一個確定范圍再做系統分析，同時把一些非告警的資源指標做多元分析，最后匯總之后計算出來一個列表。

五、未來展望

5G時代，5G本身技術的生態圈在不斷拓展，對于我們的運維團隊在5G時代，當5G給傳統行業或者創造新生行業時，新覆蓋行業同樣需要系統運維和技術運營。

盡管這些行業的商業和運行模式可能是千差萬別的，但是核心能力永遠不變，所以還是說中臺如果是在適配過程當中，基于中臺所有的不同行業進行賦能，把最核心不變的東西保持下來進行支撐。

這是我們今年剛剛建立起來的中臺，我們對未來的演進模式有一些思考。

第一，服務運營。隨著生態圈的擴大，可以提供更多場景，場景是可以千變萬化，中臺是以不變應萬變的過程，需要去沉淀更多共性的運維能力。第二，中臺運營。

參照主流技術的發展，當我們的容器技術出現之后，K8S等容器管控平臺逐步發展起來，這些平臺本身有自己的管理、調度等節點，就可以實現對容器和資源的靈活調動。 

 

因此，中臺的未來，應該是具備和加強這樣的管控和調度能力，甚至是達到智能編排適配的程度，也就是用智能技術來自動分析場景需要什么運維能力，怎么組合等。