作者｜宜信

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

UAVStack 是智能化服務(wù)技術(shù)棧，是研發(fā)運(yùn)維一體化的解決方案。UAV 是無(wú)人機(jī)的縮寫，寓意無(wú)人機(jī)翱翔藍(lán)天，智能的，透明的完成任務(wù)。它包括任務(wù)機(jī)器人（代號(hào) HIT），全維監(jiān)控（代號(hào) UAV.Monitor）, 應(yīng)用性能管理（代號(hào) UAV.APM）, 服務(wù)治理（代號(hào) UAV.ServiceGovern）, 微服務(wù)計(jì)算（代號(hào) UAV.MSCP），用戶體驗(yàn)管理（代號(hào) UAV.UEM）等。其中，UAV.Monitor+APM 為不但為智能運(yùn)維采集全維監(jiān)控?cái)?shù)據(jù)，也提供了實(shí)時(shí)監(jiān)控，自動(dòng)化問題診斷的工具，是一站式的全維監(jiān)控 + 應(yīng)用運(yùn)維解決方案。

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

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

目前 UAVStack 開源系列包括：

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

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

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

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

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

初始加載和獨(dú)立加載

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

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

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

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

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

痛點(diǎn)是技術(shù)升級(jí)的驅(qū)動(dòng)力

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

1、自動(dòng)化運(yùn)維確實(shí)提升了運(yùn)維時(shí)效，大幅度減少人工，提高了精細(xì)度。但自動(dòng)化的執(zhí)行流程是由人工定義的、明確的執(zhí)行過程。隨著對(duì)系統(tǒng)的適應(yīng)力，決策力和時(shí)效性要求持續(xù)地提升，自動(dòng)化運(yùn)維也出現(xiàn)了邊際效應(yīng)。

沒有“判斷力”，不能決策。存在多種可能性的運(yùn)維事件，需要 SRE 介入判斷和分析，才能明確是什么，然后才能對(duì)系統(tǒng)下達(dá)指令。例如：當(dāng)發(fā)現(xiàn)高 CPU 報(bào)警時(shí)，服務(wù)該不該降級(jí)，應(yīng)用該不該重啟。而事實(shí)上，讓人人都成為運(yùn)維專家是難以達(dá)成的，如果 SRE 不在，問題就搞不定。

適應(yīng)力不足，人工介入的滯后性。比較典型的情況是報(bào)警，通常報(bào)警是由運(yùn)維人員根據(jù)經(jīng)驗(yàn)來(lái)設(shè)置的策略，但是市場(chǎng)和業(yè)務(wù)發(fā)展的快速變化會(huì)使得預(yù)先設(shè)置的策略過時(shí)，不是出現(xiàn)頻繁報(bào)警，就是出現(xiàn)該報(bào)的沒報(bào)。

2、傳統(tǒng) IT 協(xié)作模式越來(lái)越“玩不轉(zhuǎn)”了。傳統(tǒng)模式是業(yè)務(wù)找研發(fā)，研發(fā)找運(yùn)維，運(yùn)維找系統(tǒng)的“線條”模式。同時(shí)，IT 的語(yǔ)言與業(yè)務(wù)語(yǔ)言時(shí)常“雞同鴨講”，誤讀時(shí)有發(fā)生，也造成效率低。

業(yè)務(wù)團(tuán)隊(duì)希望隨時(shí)隨地，簡(jiǎn)單，快速的了解系統(tǒng)運(yùn)行狀況，業(yè)務(wù)運(yùn)行情況，當(dāng)然他們也看不懂 IT 術(shù)語(yǔ)，他們希望能聽到“人類”的語(yǔ)言。

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

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

3、業(yè)務(wù)團(tuán)隊(duì)需要更多運(yùn)營(yíng)支持，移動(dòng)化，多交互渠道，從而解放人的眼睛。

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

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

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

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

協(xié)作類問題：人類的生產(chǎn)離不開協(xié)作。盡管有了自動(dòng)化運(yùn)維平臺(tái)或工具鏈，運(yùn)維很多場(chǎng)景還是需要許多人工協(xié)作。

智能運(yùn)維的自研之路

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

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

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

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

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

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

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

目標(biāo)是從實(shí)際痛點(diǎn)入手，找到適合場(chǎng)景以及正確的問題來(lái)試點(diǎn)，而不是“大而全”的 AIOps 解決方案。

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

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

之所以這樣考慮的原因：

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

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

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

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

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

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

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

Think：決策。這是與自動(dòng)化的核心區(qū)別，它需要通過理解人類的意圖，同時(shí)收集執(zhí)行環(huán)境的上下文，根據(jù)意圖來(lái)安排執(zhí)行計(jì)劃，以及對(duì)執(zhí)行計(jì)劃做出調(diào)整。同時(shí)，在實(shí)際執(zhí)行過程中通過對(duì) Interaction 的反饋，將執(zhí)行計(jì)劃以及執(zhí)行過程信息以類人化方式描述（自然語(yǔ)言）。它使用的核心技術(shù)包括自然語(yǔ)言處理，知識(shí)圖譜，機(jī)器學(xué)習(xí)，搜索技術(shù)。

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

落地方案

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

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

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

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

另一個(gè)例子，服務(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ù)，可以及時(shí)地與現(xiàn)實(shí)世界同步。HIT 也只需要?dú)w集服務(wù)圖譜，按照服務(wù)拓?fù)涞恼J(rèn)知模型來(lái)構(gòu)建知識(shí)圖譜即可。

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

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

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

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

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

應(yīng)用性能指標(biāo)：包括應(yīng)用集群，應(yīng)用實(shí)例，應(yīng)用中間件 /JVM，服務(wù)組件，客戶端組件，URL，數(shù)據(jù)庫(kù)連接池等性能指標(biāo)

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

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

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

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

調(diào)用鏈：包含服務(wù) / 客戶端 / 方法級(jí)，所在類 / 方法，耗時(shí)，狀態(tài)，請(qǐng)求報(bào)文，響應(yīng)報(bào)文等

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

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

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

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

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

Web 瀏覽器客戶端體驗(yàn)數(shù)據(jù)：頁(yè)面加載，離開頁(yè)面，JS 錯(cuò)誤，Ajax 請(qǐng)求，地理信息，客戶端 IP 等

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

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

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

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

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

被存儲(chǔ)在不同的存儲(chǔ)源中，例如服務(wù)畫像數(shù)據(jù)存儲(chǔ)在 MongoDB，應(yīng)用日志和調(diào)用鏈存儲(chǔ)在 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)用升級(jí)不定期變化的，日志數(shù)據(jù)也可能是這樣。

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

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

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

DBus 能夠?qū)⒉煌母袷睫D(zhuǎn)換成標(biāo)準(zhǔn)格式（UMS 格式）。它會(huì)根據(jù)不同的格式和對(duì)數(shù)據(jù)轉(zhuǎn)換和抽取的相關(guān)配置，對(duì)數(shù)據(jù)進(jìn)行實(shí)時(shí)解析和計(jì)算。以應(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 日志對(duì)應(yīng)的多條 UMS 數(shù)據(jù)。

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

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

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

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

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

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

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

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

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

組合指標(biāo)的異常點(diǎn)識(shí)別模型：組合指標(biāo)在時(shí)序上異常點(diǎn)的自動(dòng)判別。

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

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

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

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

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

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

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

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

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

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

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

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

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

對(duì)運(yùn)維領(lǐng)域的場(chǎng)景是熟悉的，明白運(yùn)維的標(biāo)準(zhǔn)，邏輯，原則

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

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

服務(wù)后臺(tái)工程師：掌握服務(wù)化技術(shù)，對(duì) AI 技術(shù)有一定了解，熟悉研發(fā) / 測(cè)試 / 運(yùn)維，具備運(yùn)維經(jīng)驗(yàn)

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

宜信開源技術(shù)

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

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

宜信開源軟件系列