作者｜宜信

宜信技術(shù)研發(fā)中心在 CNUTCon 全球運維技術(shù)大會上宣布正式開源支撐智能化運維的三大利器：UAVStack, Wormhole, DBus害晦。究竟是怎樣的核心技術(shù)结窘，能造就這樣支撐智能化運維的利器呢？一起來看搂蜓！

UAVStack 是智能化服務(wù)技術(shù)棧回论，是研發(fā)運維一體化的解決方案蹦漠。UAV 是無人機的縮寫，寓意無人機翱翔藍(lán)天雨涛，智能的，透明的完成任務(wù)懦胞。它包括任務(wù)機器人（代號 HIT）替久，全維監(jiān)控（代號 UAV.Monitor）, 應(yīng)用性能管理（代號 UAV.APM）, 服務(wù)治理（代號 UAV.ServiceGovern）, 微服務(wù)計算（代號 UAV.MSCP），用戶體驗管理（代號 UAV.UEM）等医瘫。其中侣肄，UAV.Monitor+APM 為不但為智能運維采集全維監(jiān)控數(shù)據(jù)，也提供了實時監(jiān)控醇份，自動化問題診斷的工具稼锅，是一站式的全維監(jiān)控 + 應(yīng)用運維解決方案。

官方網(wǎng)站：https://uavorg.github.io/main

開源地址：https://github.com/uavorg

目前 UAVStack 開源系列包括：

DBus 專注于數(shù)據(jù)的收集及實時數(shù)據(jù)流計算僚纷，通過簡單靈活的配置矩距，以無侵入的方式對源端數(shù)據(jù)進(jìn)行采集，采用高可用的流式計算框架怖竭，對在業(yè)務(wù)流程中產(chǎn)生的數(shù)據(jù)進(jìn)行匯聚锥债，經(jīng)過轉(zhuǎn)換處理后成為統(tǒng)一 JSON 的數(shù)據(jù)格式（UMS），提供給不同數(shù)據(jù)使用方訂閱和消費。DBus 將 UAV 采集的全維監(jiān)控數(shù)據(jù)以無侵入方式進(jìn)行實時收集哮肚，為下游大數(shù)據(jù)處理平臺 Wormhole 運行統(tǒng)計模型和機器學(xué)習(xí)提供數(shù)據(jù)源登夫。

開源網(wǎng)址：https://github.com/BriData

此外，DBus 還提供以下特性：

多種數(shù)據(jù)源支持允趟，海量數(shù)據(jù)實時傳輸

感知源端 schema 變更恼策，數(shù)據(jù)實時脫敏

初始加載和獨立加載

統(tǒng)一標(biāo)準(zhǔn)化消息傳輸協(xié)議，可靠多路消息訂閱分發(fā)

支持分表數(shù)據(jù)匯集

DBus 技術(shù)架構(gòu)

Wormhole 是一個 SPAAS（Stream Processing as a Service）平臺解決方案潮剪。Wormhole 面向大數(shù)據(jù)項目的開發(fā)涣楷，運維以及管理人員，致力于簡化和統(tǒng)一開發(fā)管理流程抗碰。當(dāng)今運維是典型的大數(shù)據(jù)應(yīng)用領(lǐng)域狮斗，Wormhole 是智能運維機器學(xué)習(xí)的有力支撐，尤其是針對流式實時和流式準(zhǔn)實時數(shù)據(jù)處理場景弧蝇。同時碳褒，提供了可視化的操作界面，極簡的配置流程捍壤，基于 SQL 的業(yè)務(wù)開發(fā)方式骤视，并屏蔽了大數(shù)據(jù)處理底層技術(shù)細(xì)節(jié)，極大的降低了開發(fā)管理門檻鹃觉。Wormhole 的設(shè)計理念是統(tǒng)一流式處理 DAG 高階分形抽象专酗，統(tǒng)一通用流轉(zhuǎn)消息 UMS 協(xié)議抽象，統(tǒng)一通用流轉(zhuǎn)消息 UMS 協(xié)議抽象盗扇。

開源網(wǎng)址：https://github.com/edp963/wormhole祷肯。

痛點是技術(shù)升級的驅(qū)動力

我們是從傳統(tǒng)運維轉(zhuǎn)向自動化運維疗隶，進(jìn)而向智能化運維邁進(jìn)。通過對 DevOps 工具鏈的不斷建設(shè)蒋纬，我們形成了貫穿全維度監(jiān)控，CI/CD坚弱，自動化測試荒叶，應(yīng)用虛擬化的自動化運維體系碾阁。盡管如此，在金融運維 / 運營過程中些楣，我們還是碰到以下痛點：

1、自動化運維確實提升了運維時效亭病，大幅度減少人工命贴，提高了精細(xì)度食听。但自動化的執(zhí)行流程是由人工定義的樱报、明確的執(zhí)行過程迹蛤。隨著對系統(tǒng)的適應(yīng)力盗飒，決策力和時效性要求持續(xù)地提升陋桂，自動化運維也出現(xiàn)了邊際效應(yīng)嗜历。

沒有“判斷力”梨州，不能決策暴匠。存在多種可能性的運維事件每窖，需要 SRE 介入判斷和分析，才能明確是什么旭寿，然后才能對系統(tǒng)下達(dá)指令盅称。例如：當(dāng)發(fā)現(xiàn)高 CPU 報警時缩膝，服務(wù)該不該降級疾层，應(yīng)用該不該重啟痛黎。而事實上湖饱，讓人人都成為運維專家是難以達(dá)成的井厌，如果 SRE 不在仅仆，問題就搞不定墓拜。

適應(yīng)力不足，人工介入的滯后性潘懊。比較典型的情況是報警授舟，通常報警是由運維人員根據(jù)經(jīng)驗來設(shè)置的策略释树，但是市場和業(yè)務(wù)發(fā)展的快速變化會使得預(yù)先設(shè)置的策略過時奢啥，不是出現(xiàn)頻繁報警桩盲，就是出現(xiàn)該報的沒報赌结。

2柬姚、傳統(tǒng) IT 協(xié)作模式越來越“玩不轉(zhuǎn)”了量承。傳統(tǒng)模式是業(yè)務(wù)找研發(fā)撕捍，研發(fā)找運維忧风，運維找系統(tǒng)的“線條”模式阀蒂。同時蚤霞，IT 的語言與業(yè)務(wù)語言時趁列澹“雞同鴨講”夜畴，誤讀時有發(fā)生贪绘，也造成效率低税灌。

業(yè)務(wù)團(tuán)隊希望隨時隨地菱涤，簡單粘秆，快速的了解系統(tǒng)運行狀況攻走，業(yè)務(wù)運行情況陋气，當(dāng)然他們也看不懂 IT 術(shù)語巩趁，他們希望能聽到“人類”的語言议慰。

運維 SRE 變成了關(guān)鍵“瓶頸”别凹，他們的經(jīng)驗沒有被沉淀和共享炉菲。

研發(fā)懂系統(tǒng)拍霜，了解業(yè)務(wù)邏輯祠饺，卻“不敢”在沒有運維 SRE 協(xié)助時（即使有自動化遠(yuǎn)程工具）道偷，快速解決業(yè)務(wù)問題勺鸦。他們?nèi)鄙偃媪私饣A(chǔ)設(shè)施换途、上下游應(yīng)用的幫手怀跛。

3吻谋、業(yè)務(wù)團(tuán)隊需要更多運營支持漓拾，移動化，多交互渠道姜盈，從而解放人的眼睛。

從層級匯報（人圍著人轉(zhuǎn)救拉，人找人）的模式轉(zhuǎn)變?yōu)橐詳?shù)據(jù)為中心亿絮，數(shù)字化運營（人圍著數(shù)據(jù)轉(zhuǎn)派昧，人找數(shù)據(jù)）的模式是大趨勢斗锭。而這種轉(zhuǎn)變的技術(shù)基礎(chǔ)是業(yè)務(wù)團(tuán)隊可以通過各種渠道（不是非得登錄某某系統(tǒng)，也不是非得找到某某領(lǐng)導(dǎo)或聯(lián)絡(luò)人）快速傳播信息实苞，分享數(shù)據(jù)黔牵。

運營措施能夠用“聽得懂”的語言直接、高效地反饋給業(yè)務(wù)團(tuán)隊金赦。例如資金需求上來了夹抗，資金調(diào)撥團(tuán)隊通過資金調(diào)撥跟上資金需求的增長漠烧，但他們并不清楚實際起到了多大效果已脓，當(dāng)然通過業(yè)務(wù)監(jiān)控能夠看到度液，但金融行業(yè)特點恨诱，移動辦公 / 出差是常態(tài)蛇受，并不是時刻具備登錄系統(tǒng)的條件兢仰，但通過微信把将，QQ 等就方便多了察蹲。

以上的痛點歸類起來可以認(rèn)為是兩類問題：

時效類問題：運維的本質(zhì)是提供穩(wěn)定可靠的服務(wù)，而達(dá)成這個目標(biāo)的關(guān)鍵是足夠好的時效亚兄。

協(xié)作類問題：人類的生產(chǎn)離不開協(xié)作审胚。盡管有了自動化運維平臺或工具鏈膳叨，運維很多場景還是需要許多人工協(xié)作懒鉴。

智能運維的自研之路

Gartner 定義了基于算法的運維（ITOA）即是 AIOps璃俗，算法即運維城豁，將算法運用運維領(lǐng)域唱星。實際上我們在自動化運維體系中已經(jīng)將算法落地到 DevOps 工具鏈中，例如在監(jiān)控中服務(wù)圖譜的動態(tài)繪制哎榴，APM 工具箱中的一鍵式線程分析尚蝌，應(yīng)用虛擬化中的彈性容量計算飘言。但我們認(rèn)為這些仍然是“自動化”的范疇，需要更加智能的方案苛预。

日益興盛的人工智能技術(shù)，讓我們意識到賦予系統(tǒng)“智能化”是大趨勢突诬。對 AIOps旺隙，我們更愿意這樣解讀：AIOps 正是將人工智能技術(shù)應(yīng)用到 IT 運維領(lǐng)域，幫助變革運維模式周拐，提升效率和創(chuàng)造現(xiàn)實價值的“工程化”過程妥粟，也是 DevOps 的進(jìn)化方向滩报。

解決上述問題的目標(biāo)歸納起來是脓钾，我們需要 AIOps 系統(tǒng)成為

運維管理的成員：協(xié)調(diào)人與系統(tǒng)，不是被動的工具沉噩，而是直接參與運維的“助手”

業(yè)務(wù)運營支持的成員：協(xié)調(diào)人與業(yè)務(wù)川蒙，參與運營的“助手”

業(yè)務(wù)與系統(tǒng)的“全知”者：協(xié)調(diào)業(yè)務(wù)與系統(tǒng)，管理系統(tǒng)康聂，支撐業(yè)務(wù)

那么應(yīng)該怎么建設(shè) AIOps 系統(tǒng)呢？我們確立了幾點原則：

目標(biāo)是從實際痛點入手氓侧，找到適合場景以及正確的問題來試點，而不是“大而全”的 AIOps 解決方案独郎。

技術(shù)選型上充分利用已經(jīng)比較成熟的開源 AI 技術(shù)氓癌，可以做必要改進(jìn)茁计，但盡量不重復(fù)造輪子星压。

充分使用我們現(xiàn)有的 DevOps 工具鏈，而不是全面推倒重來竣贪。

之所以這樣考慮的原因：

AI 技術(shù)還不是“平民技術(shù)”演怎，盡管已經(jīng)發(fā)展了很長時間，但它的投入產(chǎn)出比可能并不像使用 spring歹叮，tomcat，RabbitMQ 這些開源技術(shù)棧那樣的直接萨螺。所以先做“點”的事情慰技，再考慮“面”。要從適合的場景下切入冯键。

盡管 AIOps 會帶來顛覆性的運維思維和效應(yīng)惹盼，但是否也要對現(xiàn)有系統(tǒng)軟件來一把推倒重來呢庸汗？AIOps 是 DevOps 的進(jìn)化方向惫确，與 DevOps 工具鏈深度集成是必由之路。所以 AIOps 并非是要取代現(xiàn)有的自動化運維體系，而是賦予現(xiàn)有體系智能掩蛤。

復(fù)用現(xiàn)有 IT 優(yōu)良資產(chǎn)，最大化資產(chǎn)價值也是必要的考量塘雳。

值得一提的是懂傀，經(jīng)過實踐證明涝影，自動化運維是智能化運維的構(gòu)建基礎(chǔ)。如果沒有自動化運維的成型技術(shù)和方案阳藻，AIOps 也是空談。用個形象的比喻谈撒，自動化運維體系中腥泥，監(jiān)控系統(tǒng)的數(shù)據(jù)采集好比人的眼睛、耳朵是用來感知現(xiàn)實的啃匿，遠(yuǎn)程執(zhí)行好比人的手腳是用來反饋現(xiàn)實的蛔外。而 AI 系統(tǒng)好比人的大腦，它接收感知溯乒，通過一系列處理形成決策夹厌，這是“認(rèn)知”的過程，然后通過反饋給人或執(zhí)行結(jié)果裆悄，體現(xiàn)“智慧”矛纹。

我們 AI 的實現(xiàn)形態(tài)是任務(wù)機器人（代號 HIT）。它是統(tǒng)領(lǐng)智能運維的“大腦”灯帮，是類人行為的軟件系統(tǒng)崖技。任務(wù)機器人應(yīng)該具備以下能力：

HIT 的設(shè)計理念就是對任務(wù)機器人能力的抽象。它由三種核心服務(wù)構(gòu)成：

Interaction：交互钟哥。實現(xiàn)與人類非 GUI 交互界面迎献，目前實現(xiàn)兩個方面：文字交互 CUI（內(nèi)部系統(tǒng)聊天 / 通知，公共 IM 系統(tǒng)腻贰，比如微信 /QQ）吁恍，語音識別與語音合成（手機終端設(shè)備）。它是人與系統(tǒng)交流的中介播演，起到翻譯信息冀瓦，傳播信息的作用，使得人不再需要被綁定在特定系統(tǒng)界面才能完成相關(guān)工作写烤。

Think：決策翼闽。這是與自動化的核心區(qū)別，它需要通過理解人類的意圖洲炊，同時收集執(zhí)行環(huán)境的上下文感局，根據(jù)意圖來安排執(zhí)行計劃尼啡，以及對執(zhí)行計劃做出調(diào)整。同時询微，在實際執(zhí)行過程中通過對 Interaction 的反饋崖瞭，將執(zhí)行計劃以及執(zhí)行過程信息以類人化方式描述（自然語言）。它使用的核心技術(shù)包括自然語言處理撑毛，知識圖譜书聚，機器學(xué)習(xí)，搜索技術(shù)藻雌。

Handson：執(zhí)行雌续。這是與聊天機器人的核心區(qū)別，根據(jù) Think 提供的執(zhí)行計劃胯杭，適配計劃中相關(guān)系統(tǒng)的 API西雀，完成實際的服務(wù)流程編排以及服務(wù)流程執(zhí)行。同時歉摧，它還需要給 Think 提供反饋艇肴，以實現(xiàn)迭代決策（反饋 + 調(diào)整）；它也將執(zhí)行過程以及執(zhí)行結(jié)果反饋給 Interaction叁温，幫助人了解執(zhí)行狀態(tài)（非自然語言）

落地方案

我們的 AIOps 平臺是以任務(wù)機器人為中心再悼，利用大數(shù)據(jù)平臺實現(xiàn)機器學(xué)習(xí)和統(tǒng)計模型的處理，與 DevOps 工具鏈深度集成實現(xiàn)智能化運維膝但〕寰牛可以從以下幾個層面來解讀這個架構(gòu)：

DevOps 工具鏈為任務(wù)機器人 HIT 的知識圖譜構(gòu)建提供了高質(zhì)量的原始數(shù)據(jù)

任務(wù)機器人 HIT 的核心能力來源于特定領(lǐng)域的知識圖譜和計算模型。目前我們的訓(xùn)練領(lǐng)域包括系統(tǒng) API 模型跟束，個性化交流上下文莺奸，服務(wù)拓?fù)洌瑘?zhí)行計劃冀宴，問題診斷等灭贷。知識圖譜是實現(xiàn)認(rèn)知關(guān)聯(lián)的核心技術(shù)，而如何自動化構(gòu)建知識圖譜是關(guān)鍵的關(guān)鍵略贮。成熟的 DevOps 工具鏈可以為自動化構(gòu)建知識圖譜提供高質(zhì)量的原始數(shù)據(jù)甚疟。

API 模型包括了應(yīng)用 / 服務(wù)的 API 元數(shù)據(jù)信息和實例信息，這些信息必須時刻與現(xiàn)實世界保持同步逃延。而全維監(jiān)控 UAV 提供了應(yīng)用畫像數(shù)據(jù)览妖，由于 UAV 本身采用了微智能（強調(diào)自動發(fā)現(xiàn)，自我維護(hù)揽祥，自動適應(yīng)）的設(shè)計讽膏，使得應(yīng)用畫像數(shù)據(jù)本身就時刻與現(xiàn)實世界保持同步。任務(wù)機器人 HIT 通過直接歸集應(yīng)用服務(wù)畫像數(shù)據(jù)拄丰，按照 API 模型的認(rèn)知關(guān)聯(lián)結(jié)構(gòu)府树，就可以生成 API 模型是嗜。而微智能的特性天然的、高質(zhì)量的保障了自動化 API 模型的知識圖譜構(gòu)建挺尾。

另一個例子，服務(wù)拓?fù)涫欠磻?yīng)服務(wù)之間的關(guān)聯(lián)關(guān)系站绪，在微服務(wù)架構(gòu)下遭铺，這種關(guān)聯(lián)關(guān)系也變得日益復(fù)雜。全維監(jiān)控 UAV 提供了服務(wù)圖譜恢准，它也是基于微智能思想的數(shù)據(jù)魂挂，可以及時地與現(xiàn)實世界同步。HIT 也只需要歸集服務(wù)圖譜馁筐，按照服務(wù)拓?fù)涞恼J(rèn)知模型來構(gòu)建知識圖譜即可涂召。

此外，調(diào)用鏈的數(shù)據(jù)可以幫助自動構(gòu)建時序關(guān)系敏沉，CI/CD 的項目特征和人員關(guān)聯(lián)數(shù)據(jù)可以幫助構(gòu)建應(yīng)用與團(tuán)隊的映射關(guān)聯(lián)（從故障問題到應(yīng)用果正，再到代碼和人員的追溯），測試用例的輸入和輸出可以幫助構(gòu)建 API 模型的參數(shù)關(guān)系盟迟，語義關(guān)聯(lián)和缺省參數(shù)等秋泳。

全維監(jiān)控 UAV 為任務(wù)機器人 HIT 的模型訓(xùn)練提供了全面維度的原始數(shù)據(jù)

UAVStack 中 Monitor+APM 為實時監(jiān)控 + 應(yīng)用深度運維提供了解決方案（如圖）。在智能運維體系中攒菠，它采集的全維度監(jiān)控數(shù)據(jù)是機器學(xué)習(xí)和統(tǒng)計模型的原始數(shù)據(jù)來源迫皱。全維度的監(jiān)控數(shù)據(jù)覆蓋基礎(chǔ)設(shè)施性能，應(yīng)用 / 服務(wù)性能辖众，日志卓起，調(diào)用鏈，線程棧凹炸，客戶端體驗戏阅，業(yè)務(wù)指標(biāo)，應(yīng)用畫像啤它，服務(wù)圖譜饲握。

應(yīng)用 / 服務(wù)畫像：監(jiān)控探針自動對應(yīng)用的技術(shù)棧進(jìn)行分析提取應(yīng)該的元數(shù)據(jù)，其中重要的包括應(yīng)用實例的 URL蚕键，有哪些服務(wù)接口方法以及 URL救欧，使用了哪些客戶端（MQ/DB/Redis/NoSQL/Http/Dubbo 等）以及訪問的 URL。

應(yīng)用 / 服務(wù)畫像數(shù)據(jù)示例

應(yīng)用性能指標(biāo)：包括應(yīng)用集群锣光，應(yīng)用實例笆怠，應(yīng)用中間件 /JVM，服務(wù)組件誊爹，客戶端組件蹬刷，URL瓢捉，數(shù)據(jù)庫連接池等性能指標(biāo)

應(yīng)用日志：應(yīng)用產(chǎn)生的各種日志，支持過濾規(guī)則办成。

應(yīng)用性能指標(biāo) & 日志數(shù)據(jù)示例

應(yīng)用環(huán)境性能指標(biāo)：虛擬機 / 物理機系統(tǒng)級以及進(jìn)程級指標(biāo)泡态，例如 CPU，內(nèi)存迂卢，連接數(shù)某弦，網(wǎng)絡(luò)流量，磁盤 IO 等

應(yīng)用環(huán)境性能指標(biāo)數(shù)據(jù)示例

調(diào)用鏈：包含服務(wù) / 客戶端 / 方法級而克，所在類 / 方法靶壮，耗時，狀態(tài)员萍，請求報文腾降，響應(yīng)報文等

調(diào)用鏈數(shù)據(jù)示例

服務(wù)圖譜：自動生成服務(wù)之間的調(diào)用關(guān)聯(lián)關(guān)系

服務(wù)圖譜數(shù)據(jù)示例

線程棧數(shù)據(jù)：JVM 線程 Dump+ 每個線程的 cpu，內(nèi)存消耗的數(shù)據(jù)

線程棧數(shù)據(jù)示例

Web 瀏覽器客戶端體驗數(shù)據(jù)：頁面加載碎绎，離開頁面螃壤，JS 錯誤，Ajax 請求筋帖，地理信息映穗，客戶端 IP 等

Web 瀏覽器客戶端體驗數(shù)據(jù)（Ajax）示例

業(yè)務(wù)指標(biāo)：應(yīng)用可以通過埋點或日志方式提供自定義指標(biāo)

業(yè)務(wù)指標(biāo)數(shù)據(jù)示例

數(shù)據(jù)總線 DBus 持續(xù)的，自適應(yīng)的將全維監(jiān)控數(shù)據(jù)導(dǎo)入大數(shù)據(jù)存儲

盡管通過 UAV 采集到了全維度的監(jiān)控數(shù)據(jù)幕随，但是還不能直接使用這些數(shù)據(jù)來做機器學(xué)習(xí)和統(tǒng)計模型蚁滋。其原因是由于它們的存儲和查詢需求是根據(jù)實時監(jiān)控領(lǐng)域的需要來定義的，因此它們有以下特點：

被存儲在不同的存儲源中赘淮，例如服務(wù)畫像數(shù)據(jù)存儲在 MongoDB辕录，應(yīng)用日志和調(diào)用鏈存儲在 Elastic Search 中，應(yīng)用性能指標(biāo)和基礎(chǔ)性能指標(biāo)數(shù)據(jù)存在 RocketMQ 中等梢卸；

有著各自不同的 schema 定義走诞，例如 BIN 日志格式，JSON 格式蛤高，Plain 日志格式, 性能指標(biāo)的 schema 與調(diào)用鏈的 schema 是不同的蚣旱。

不同的變更策略，例如服務(wù)畫像數(shù)據(jù)是根據(jù)應(yīng)用升級不定期變化的戴陡，日志數(shù)據(jù)也可能是這樣塞绿。

數(shù)據(jù)總線 DBus 正是解決這三個問題的良方。

DBus 能夠支持多種數(shù)據(jù)源恤批，只需通過配置就可實現(xiàn)無侵入對接异吻。采集端包含了數(shù)據(jù)庫的日志采集端、日志采集端、各種基于 Flume 自定義插件的采集端等诀浪，這些采集端將數(shù)據(jù)實時的同步到 Kafka 中棋返，完成數(shù)據(jù)采集工作。

Dbus 多數(shù)據(jù)源支持

DBus 能夠?qū)⒉煌母袷睫D(zhuǎn)換成標(biāo)準(zhǔn)格式（UMS 格式）雷猪。它會根據(jù)不同的格式和對數(shù)據(jù)轉(zhuǎn)換和抽取的相關(guān)配置睛竣，對數(shù)據(jù)進(jìn)行實時解析和計算。以應(yīng)用性能指標(biāo)和業(yè)務(wù)指標(biāo)為例：數(shù)據(jù)格式是采用 MDF 文件格式（UAV 的一種格式）求摇，它是一種 JSON 格式的層次化數(shù)據(jù)射沟，而 DBus 最終輸出的 UMS 數(shù)據(jù)格式是一種以表為基本單位的數(shù)據(jù)，因此需要將數(shù)據(jù)進(jìn)行扁平化月帝，一條 MDF 日志對應(yīng)的多條 UMS 數(shù)據(jù)。

DBus 支持不同格式的標(biāo)準(zhǔn)化

DBus 有自動適應(yīng)的能力幽污，匹配這些類型和格式的變化嚷辅。它支持指標(biāo)動態(tài)添加，就算每次來自 UAV 的 MDF 數(shù)據(jù)都帶來新的指標(biāo)類型距误，這些新增的指標(biāo)也并不會影響解析本身數(shù)據(jù)本身簸搞；同時，它還支持動態(tài) schema 變更准潭，即自動感知數(shù)據(jù)的列名和數(shù)據(jù)類型趁俊，UMS 格式記錄了數(shù)據(jù)的版本和列信息等，一旦發(fā)現(xiàn)不屬于同一個版本的數(shù)據(jù)就會自動升級版本號刑然，生成新版本的數(shù)據(jù)寺擂。例如如下的新版本比舊版本多了一個字段 RC406（一種應(yīng)用性能指標(biāo)，Http 響應(yīng)碼）泼掠。

DBus 自動適應(yīng)格式版本變更

大數(shù)據(jù)處理 Wormhole 針對目標(biāo)場景怔软，基于全維監(jiān)控數(shù)據(jù)進(jìn)行機器學(xué)習(xí)和統(tǒng)計模型處理

Wormhole 是任務(wù)機器人的計算模型生產(chǎn)者。Wormhole 基于 Spark择镇，既可接入 Kafka 在線實效數(shù)據(jù)進(jìn)行流式處理挡逼，也可接入 HDFS 離線歷史數(shù)據(jù)進(jìn)行批量處理，在 Spark 之上還抽象出一套新的概念和處理模型腻豌，用戶可以通過 UI 進(jìn)行簡單配置來實施和管理流式作業(yè)家坎，用戶只要選擇數(shù)據(jù)從哪里來到哪里去，在流上執(zhí)行什么樣的邏輯即可啟動一個流式作業(yè)吝梅。Wormhole 不光支持落地多 Sink虱疏，還支持流上處理，還可以在落 HBase 之前流上做一些數(shù)據(jù)清洗擴展等操作苏携。

Wormhole 技術(shù)架構(gòu)

目前我們的任務(wù)機器人 HIT 的訓(xùn)練主題“問題診斷”的計算模型都是由 Wormhole 來實施訓(xùn)練订框，實際生產(chǎn)過程中會使用機器學(xué)習(xí)和某些經(jīng)典統(tǒng)計模型，主要的有：

時序數(shù)據(jù)的趨勢預(yù)測模型：可以根據(jù)過去若干天來預(yù)測未來一段時間某重要指標(biāo)的趨勢走向兜叨。

指標(biāo)的關(guān)聯(lián)組合模型：識別出哪些指標(biāo)組合是判斷異常的充分條件穿扳。

組合指標(biāo)的異常點識別模型：組合指標(biāo)在時序上異常點的自動判別衩侥。

問題節(jié)點的根源分析模型：跨多節(jié)點的異常行為關(guān)聯(lián)性識別模型。

舉個例子矛物，任務(wù)機器人 HIT 根據(jù)執(zhí)行計劃驅(qū)動 Wormhole 每十分鐘從 HBase 上提取最近一個短時間窗口的數(shù)據(jù)（若干天）茫死，HIT 通過“問題診斷”知識圖譜選擇［時序數(shù)據(jù)的趨勢預(yù)測模型］和［組合指標(biāo)的異常點識別模型］對十分鐘增量數(shù)據(jù)進(jìn)行異常點識別，并預(yù)測出未來一小時的指標(biāo)趨勢履羞，并做適當(dāng)統(tǒng)計聚合峦萎，可以得到一個延遲 10 分鐘級別的增量監(jiān)控指標(biāo)走向，自動識別的異常點和未來一小時的重要指標(biāo)趨勢預(yù)測圖忆首，同時也可以根據(jù)異常點的嚴(yán)重性級別進(jìn)行預(yù)警爱榔。可以看到整個預(yù)警體系是非人工參與的糙及，基于機器學(xué)習(xí)模型和增量數(shù)據(jù)準(zhǔn)實時的推算出來了详幽，當(dāng)模型準(zhǔn)確率越高，預(yù)警也會更精準(zhǔn)浸锨。

另一個例子唇聘，任務(wù)機器人 HIT 通過“問題診斷”知識圖譜選擇 [指標(biāo)的關(guān)聯(lián)組合模型] 和 [問題節(jié)點的根源分析模型]，通過應(yīng)用性能指標(biāo)發(fā)現(xiàn) CPU 很高柱搜，關(guān)聯(lián)上線程棧數(shù)據(jù)就可以知道是哪些線程引起了高 CPU迟郎，線程棧的代碼棧又可以關(guān)聯(lián)到服務(wù)畫像，從而發(fā)現(xiàn)與哪個服務(wù)的 URL 有關(guān)聪蘸，通過服務(wù) URL 關(guān)聯(lián)服務(wù)性能指標(biāo)可掌握是否是由高并發(fā)訪問引起的宪肖，關(guān)聯(lián)服務(wù)圖譜可以追溯是哪些上游系統(tǒng)在調(diào)用這個服務(wù) URL，哪些下游系統(tǒng)可能會受影響健爬，關(guān)聯(lián)調(diào)用鏈數(shù)據(jù)可以追溯是哪些業(yè)務(wù)請求引起的匈庭，甚至對下一個時段這些業(yè)務(wù)請求峰值進(jìn)行預(yù)測。

任務(wù)機器人 HIT 通過 API 模型實施執(zhí)行計劃

任務(wù)機器人與普通系統(tǒng)的另一個重要區(qū)別是：普通系統(tǒng)可以看成是通過編碼來“機械”的完成某種事浑劳，就系統(tǒng)本身而言阱持，它并不理解“我在做什么”。而任務(wù)機器人是以目標(biāo)驅(qū)動的魔熏，它根據(jù) API 模型以及其他認(rèn)知模型（知識圖譜）來生成執(zhí)行計劃衷咽，并使用 API 模型來實施執(zhí)行計劃，執(zhí)行計劃的本質(zhì)是對 DevOps 系統(tǒng) API 的調(diào)用蒜绽。

以系統(tǒng)上線為例镶骗，我們給任務(wù)機器人一個目標(biāo)“今晚 19：30 電簽網(wǎng)關(guān)上線”。任務(wù)機器人通過“基本意圖理解”知道是要驅(qū)動 CI/CD 系統(tǒng) Hubble 的“一鍵發(fā)布”功能來發(fā)布“電簽網(wǎng)關(guān)”這個系統(tǒng)躲雅。API 模型幫助任務(wù)機器人通過對句型鼎姊，關(guān)鍵詞，相關(guān)性的分析，來關(guān)聯(lián)到 CI/CD 系統(tǒng)相寇，也通過功能與 API 的關(guān)聯(lián)慰于，提取出來需要 buildApp 和 deployApp 兩個 API，還幫助實現(xiàn)了兩個 API 的參數(shù)填充唤衫。最后依靠 API 模型中的時序關(guān)聯(lián)來確定了幾個 API 的執(zhí)行順序婆赠，再加上執(zhí)行時間，最終確定了執(zhí)行計劃佳励。當(dāng)然執(zhí)行計劃執(zhí)行的過程會依賴“問題診斷”的認(rèn)知模型休里。

這種目標(biāo)驅(qū)動的應(yīng)用場景還有很多，例如讓任務(wù)機器人去做線上的智能巡檢赃承，協(xié)助問題處理妙黍，甚至支持運營協(xié)作等。

AIOps 團(tuán)隊建設(shè)

最后來談?wù)勎覀兊膱F(tuán)隊瞧剖。相信在面對 AIOps 的時候拭嫁，大家都會思考團(tuán)隊要如何構(gòu)成。我認(rèn)為 AI 的生態(tài)體系與大數(shù)據(jù)類似筒繁，存在兩種基本角色：AI 科學(xué)家和 AI 領(lǐng)域工程師（FE）噩凹。前者推動 AI 科學(xué)的發(fā)展巴元，創(chuàng)造新的 AI 知識體系毡咏；后者是將 AI 知識運用到生產(chǎn)生活的某個領(lǐng)域，創(chuàng)造現(xiàn)實價值逮刨。

我們團(tuán)隊的定位是 AI FE呕缭，是將 AI 技術(shù)工程化的團(tuán)隊，這樣的團(tuán)隊?wèi)?yīng)該具備幾個特征：

對現(xiàn)有 AI 技術(shù)充分了解和掌握

選擇較成熟的開源 AI 技術(shù)是必由之路

對運維領(lǐng)域的技術(shù) (比如監(jiān)控修己，容器技術(shù)恢总，CI/CD，問題診斷等) 是清楚的睬愤，最好是專家

對運維領(lǐng)域的場景是熟悉的片仿，明白運維的標(biāo)準(zhǔn)，邏輯尤辱，原則

我們的團(tuán)隊主要有兩類角色：

算法數(shù)據(jù)工程師：掌握算法技術(shù)砂豌，AI 技術(shù)，具備一定的工程化能力光督，了解運維領(lǐng)域知識

服務(wù)后臺工程師：掌握服務(wù)化技術(shù)阳距，對 AI 技術(shù)有一定了解，熟悉研發(fā) / 測試 / 運維结借，具備運維經(jīng)驗

任務(wù)機器人團(tuán)隊早期是以虛擬團(tuán)隊的模式成立筐摘。因為面對新的領(lǐng)域在研發(fā) / 運維體系上需要嘗試新的模式，就把算法同學(xué)，后臺服務(wù)同學(xué)咖熟，運維同學(xué)都拉到一塊圃酵。通過知識交互，經(jīng)驗分享等手段球恤，讓大家逐步在認(rèn)識上同步辜昵。并要求所有人掌握整個端到端過程。此外咽斧，隨著智能化運維的開展堪置，UAV，Wormhole张惹，DBus 等團(tuán)隊也逐步在架構(gòu)舀锨，技術(shù)，對接等層面達(dá)成一致宛逗。

宜信開源技術(shù)

宜信技術(shù)社區(qū)是宜信技術(shù)生態(tài)圈建設(shè)的重要組成部分坎匿，是展示宜信技術(shù)、構(gòu)建對外交流的綜合性社區(qū)雷激。旗下?lián)碛幸诵偶夹g(shù)學(xué)院替蔬、宜信技術(shù)天地（微信公眾號）、宜信技術(shù)大會等多種形式屎暇。社區(qū)主要面向宜信內(nèi)部員工承桥、合作伙伴及廣大技術(shù)愛好者。

其中根悼，不斷開放開源技術(shù)凶异，推動技術(shù)共同成長是技術(shù)社區(qū)的核心目標(biāo)之一。包括在今天正式開源的 UAVStack挤巡，Wormhole剩彬，DBus 等在內(nèi)，已經(jīng)開放七個系列的軟件技術(shù)矿卑。更多開源參見技術(shù)學(xué)院官網(wǎng) http://college.creditease.cn喉恋。

宜信開源軟件系列