[[239574]]

背景

隨著搜索業(yè)務(wù)的快速發(fā)展，搜索系統(tǒng)都在走向平臺(tái)化，運(yùn)維方式在經(jīng)歷人肉運(yùn)維，腳本自動(dòng)化運(yùn)維后最終演變成DevOps。但隨著大數(shù)據(jù)及人工智能的快速發(fā)展，傳統(tǒng)的運(yùn)維方式及解決方案已不能滿(mǎn)足需求。

基于如何提升平臺(tái)效率和穩(wěn)定性及降低資源，我們實(shí)現(xiàn)了在線服務(wù)優(yōu)化大師hawkeye及容量規(guī)劃平臺(tái)torch。經(jīng)過(guò)幾年的沉淀后，我們?cè)谂渲煤侠硇?、資源合理性設(shè)置、性能瓶頸、部署合理性等4個(gè)方面做了比較好的實(shí)踐。下面具體介紹下hawkeye和torch系統(tǒng)架構(gòu)及實(shí)現(xiàn)。

AIOps實(shí)踐及實(shí)現(xiàn)

hawkeye——智能診斷及優(yōu)化

系統(tǒng)簡(jiǎn)介

hawkeye是一個(gè)智能診斷及優(yōu)化系統(tǒng)，平臺(tái)大體分為三部分：

1.分析層，包括兩部分：

1） 底層分析工程hawkeye-blink：基于Blink完成數(shù)據(jù)處理的工作，重點(diǎn)是訪問(wèn)日志分析、全量數(shù)據(jù)分析等，該工程側(cè)重底層的數(shù)據(jù)分析，借助Blink強(qiáng)大的數(shù)據(jù)處理能力，每天對(duì)于搜索平臺(tái)所有Ha3應(yīng)用的訪問(wèn)日志以及全量數(shù)據(jù)進(jìn)行分析。

2） 一鍵診斷工程hawkeye-experience：基于hawkeye-blink的分析結(jié)果進(jìn)行更加貼近用戶(hù)的分析，比如字段信息監(jiān)測(cè)，包括字段類(lèi)型合理性，字段值單調(diào)性監(jiān)測(cè)等，除此之外還包括但不限于kmon無(wú)效報(bào)警、冒煙case錄入情況、引擎降級(jí)配置、內(nèi)存相關(guān)配置、推薦行列數(shù)配置以及切換時(shí)最小服務(wù)行比例等檢測(cè)。

hawkeye-experience工程的定位是做一個(gè)引擎診斷規(guī)則中臺(tái)，將平時(shí)運(yùn)維人員優(yōu)化維護(hù)引擎的寶貴經(jīng)驗(yàn)沉淀到系統(tǒng)中來(lái)，讓每一個(gè)新接入的應(yīng)用可以快速享受這樣的寶貴經(jīng)驗(yàn)，而不是通過(guò)一次次的踩坑之后獲得，讓每位用戶(hù)擁有一個(gè)類(lèi)似智能診斷專(zhuān)家的角色來(lái)優(yōu)化自己的引擎是我們的目標(biāo)，也是我們持續(xù)奮斗的動(dòng)力，其中hawkeye-experience的數(shù)據(jù)處理流程圖如下所示：

2.web層：提供hawkeye分析結(jié)果的各種api以及可視化的監(jiān)控圖表輸出。

3.service層：提供hawkeye分析與優(yōu)化api的輸出。

基于上述架構(gòu)我們落地的診斷及優(yōu)化功能有：

• 資源優(yōu)化：引擎Lock內(nèi)存優(yōu)化（無(wú)效字段分析）、實(shí)時(shí)內(nèi)存優(yōu)化等；
• 性能優(yōu)化：TopN慢query優(yōu)化、buildservice資源設(shè)置優(yōu)化等；
• 智能診斷：日常化巡檢、智能問(wèn)答等。

引擎Lock內(nèi)存優(yōu)化

 對(duì)于Ha3引擎，引擎字段是分為倒排（index）索引、正排（attribute）索引和摘要（summary）索引的。引擎的Lock策略可以針對(duì)這三類(lèi)索引進(jìn)行Lock或者不Lock內(nèi)存的設(shè)置，Lock內(nèi)存好處不言而喻，加速訪問(wèn)，降低rt，但是試想100個(gè)字段中，如果兩個(gè)月只有50個(gè)訪問(wèn)到了，其他字段在索引中壓根沒(méi)訪問(wèn)，這樣會(huì)帶來(lái)寶貴內(nèi)存的較大浪費(fèi)，為此hawkeye進(jìn)行了如下分析與優(yōu)化，針對(duì)頭部應(yīng)用進(jìn)行了針對(duì)性的索引瘦身。下圖為L(zhǎng)ock內(nèi)存優(yōu)化的過(guò)程，累計(jì)節(jié)省約數(shù)百萬(wàn)元。

慢query分析

慢query數(shù)據(jù)來(lái)自應(yīng)用的訪問(wèn)日志，query數(shù)量和應(yīng)用的訪問(wèn)量有關(guān)，通常在千萬(wàn)甚至億級(jí)別。從海量日志中獲取TopN慢query屬于大數(shù)據(jù)分析范疇。我們借助Blink的大數(shù)據(jù)分析能力，采用分治+hash+小頂堆的方式進(jìn)行獲取，即先將query格式進(jìn)行解析，獲取其查詢(xún)時(shí)間，將解析后的k-v數(shù)據(jù)取md5值，然后根據(jù)md5值做分片，在每一個(gè)分片中計(jì)算TopN慢query，***在所有的TopN中求出最終的TopN。對(duì)于分析出的TopN慢query提供個(gè)性化的優(yōu)化建議給用戶(hù)，從而幫助用戶(hù)提升引擎查詢(xún)性能，間接提高引擎容量。

一鍵診斷

我們通過(guò)健康分衡量引擎健康狀態(tài)，用戶(hù)通過(guò)健康分可以明確知道自己的服務(wù)健康情況，診斷報(bào)告給出診斷時(shí)間，配置不合理的簡(jiǎn)要描述以及詳情，優(yōu)化的收益，診斷邏輯及一鍵診斷之后有問(wèn)題的結(jié)果頁(yè)面如下圖所示，其中診斷詳情頁(yè)面因篇幅問(wèn)題暫未列出。

智能問(wèn)答

隨著應(yīng)用的增多，平臺(tái)遇到的答疑問(wèn)題也在不斷攀升，但在答疑的過(guò)程中不難發(fā)現(xiàn)很多重復(fù)性的問(wèn)題，類(lèi)似增量停止、常見(jiàn)資源報(bào)警的咨詢(xún)，對(duì)于這些有固定處理方式的問(wèn)題實(shí)際上是可以提供chatOps的能力，借助答疑機(jī)器人處理。目前hawkeye結(jié)合kmon的指標(biāo)和可定制的告警消息模板，通過(guò)在報(bào)警正文中添加診斷的方式進(jìn)行這類(lèi)問(wèn)題的智能問(wèn)答，用戶(hù)在答疑群粘貼診斷正文，at機(jī)器人即可獲取此次報(bào)警的原因。

torch-容量治理優(yōu)化

hawkeye主要從智能診斷和優(yōu)化的視角來(lái)提升效率增強(qiáng)穩(wěn)定性，torch專(zhuān)注從容量治理的視角來(lái)降低成本，隨著搜索平臺(tái)應(yīng)用的增多面臨諸如以下問(wèn)題，極易造成資源使用率低下，機(jī)器資源的嚴(yán)重浪費(fèi)。

1）業(yè)務(wù)方申請(qǐng)容器資源隨意，造成資源成本浪費(fèi)嚴(yán)重，需要基于容器成本耗費(fèi)最小化明確指導(dǎo)業(yè)務(wù)方應(yīng)該合理申請(qǐng)多少資源（包括cpu，內(nèi)存及磁盤(pán)）或者資源管理對(duì)用戶(hù)屏蔽。

2）業(yè)務(wù)變更不斷，線上真實(shí)容量（到底能扛多少qps）大家都不得而知，當(dāng)業(yè)務(wù)需要增大流量（譬如各種大促）時(shí)是否需要擴(kuò)容？如果擴(kuò)容是擴(kuò)行還是增大單個(gè)容器cpu規(guī)格？當(dāng)業(yè)務(wù)需要增大數(shù)據(jù)量時(shí)是拆列合適還是擴(kuò)大單個(gè)容器的內(nèi)存大小合適？ 如此多的問(wèn)號(hào)隨便一個(gè)都會(huì)讓業(yè)務(wù)方蒙圈。

解決方案

如下圖所示，做容量評(píng)估擁有的現(xiàn)有資源，是kmon數(shù)據(jù)，線上系統(tǒng)的狀態(tài)匯報(bào)到kmon，那直接拿kmon數(shù)據(jù)來(lái)分析進(jìn)行容量評(píng)估可不可以呢？

實(shí)際實(shí)驗(yàn)發(fā)現(xiàn)是不夠的，因?yàn)榫€上有很多應(yīng)用水位都比較低，擬合出來(lái)高水位情況下的容量也是不夠客觀的，所以需要個(gè)壓測(cè)服務(wù)來(lái)真實(shí)摸底性能容量，有了壓測(cè)接下來(lái)需要解決的問(wèn)題是壓哪？壓線上風(fēng)險(xiǎn)比較大，壓預(yù)發(fā)預(yù)發(fā)的資源有限機(jī)器配置差沒(méi)法真實(shí)摸底線上，所以需要克隆仿真，真實(shí)克隆線上的一個(gè)單例然后進(jìn)行壓測(cè)，這樣既能精準(zhǔn)又安全。有了壓測(cè)數(shù)據(jù)，接下來(lái)就是要通過(guò)算法分析找到***成本下的資源配置，有了上面的幾個(gè)核心支撐，通過(guò)任務(wù)管理模塊將每個(gè)任務(wù)管理起來(lái)進(jìn)行自動(dòng)化的容量評(píng)估。

以上是我們的解決方案，接下來(lái)會(huì)優(yōu)先介紹下整體架構(gòu)，然后再介紹各核心模塊的具體實(shí)現(xiàn)。

系統(tǒng)架構(gòu)

如圖，從下往上看，首先是接入層。平臺(tái)要接入只需要提供平臺(tái)下各應(yīng)用的應(yīng)用信息及機(jī)群信息（目前接入的有tisplus下的ha3和sp），應(yīng)用管理模塊會(huì)對(duì)應(yīng)用信息進(jìn)行整合，接下來(lái)任務(wù)管理模塊會(huì)對(duì)每個(gè)應(yīng)用抽象成一個(gè)個(gè)的容量評(píng)估任務(wù)。

一次完整的容量評(píng)估任務(wù)的大概流程是：首先克隆一個(gè)單例，然后對(duì)克隆單例進(jìn)行自動(dòng)化壓測(cè)壓到極限容量，壓測(cè)數(shù)據(jù)和日常數(shù)據(jù)經(jīng)過(guò)數(shù)據(jù)工廠加工將格式化后的數(shù)據(jù)交由決策中心，決策中心會(huì)先用壓測(cè)數(shù)據(jù)和日常數(shù)據(jù)通過(guò)算法服務(wù)進(jìn)行容量評(píng)估，然后判斷收益，如果收益高會(huì)結(jié)合算法容量?jī)?yōu)化建議進(jìn)行克隆壓測(cè)驗(yàn)證，驗(yàn)證通過(guò)將結(jié)果持久化保存，驗(yàn)證失敗會(huì)進(jìn)行簡(jiǎn)單的容量評(píng)估（結(jié)合壓測(cè)出的極限性能簡(jiǎn)單評(píng)估容量），容量評(píng)估完成以及失敗決策中心都會(huì)將克隆及壓測(cè)申請(qǐng)的臨時(shí)資源清理不至于造成資源浪費(fèi)。

最上面是應(yīng)用層，考慮到torch容量治理不僅僅是為tisplus定制的，應(yīng)用層提供容量大盤(pán)，容量評(píng)估，容量報(bào)表及收益大盤(pán)，以便其它平臺(tái)接入嵌用，另外還提供容量API供其它系統(tǒng)調(diào)用。

容量評(píng)估也依賴(lài)了搜索很多其它系統(tǒng)，maat, kmon, hawkeye，drogo,成本系統(tǒng)等整個(gè)形成了一道閉環(huán)。

架構(gòu)實(shí)現(xiàn)

克隆仿真

克隆仿真簡(jiǎn)單地理解就是克隆線上應(yīng)用的一個(gè)單例，ha3應(yīng)用就是克隆完整一行，sp就是克隆出一個(gè)獨(dú)立服務(wù)。隨著搜索hippo這大利器的誕生，資源都以容器的方式使用，再加上suez ops及sophon這些DevOps的發(fā)展，使得快速克隆一個(gè)應(yīng)用成為可能，下面給出克隆管控模塊的具體實(shí)現(xiàn)：

克隆目前分為淺克隆和深度克隆，淺克隆主要針對(duì)ha3應(yīng)用通過(guò)影子表的方式直接拉取主應(yīng)用的索引，省掉build環(huán)節(jié)加快克隆速度，深度克隆就是克隆出來(lái)的應(yīng)用需要進(jìn)行離線build。

克隆的優(yōu)勢(shì)明顯：

服務(wù)隔離，通過(guò)壓測(cè)克隆環(huán)境可以間接摸底線上的真實(shí)容量。

資源優(yōu)化建議可以直接在克隆環(huán)境上進(jìn)行壓測(cè)驗(yàn)證。

克隆環(huán)境使用完，直接自動(dòng)釋放，不會(huì)對(duì)線上資源造成浪費(fèi)。   

壓測(cè)服務(wù)

考慮到日常的kmon數(shù)據(jù)大部分應(yīng)用缺少高水位的metrics指標(biāo)，并且引擎的真實(shí)容量也只有通過(guò)實(shí)際壓測(cè)才能獲得，因此需要壓測(cè)服務(wù)，前期調(diào)研了公司的亞馬遜壓測(cè)平臺(tái)及阿里媽媽壓測(cè)平臺(tái)，發(fā)現(xiàn)不能滿(mǎn)足自動(dòng)壓測(cè)的需求，于是基于hippo我們開(kāi)發(fā)了自適應(yīng)增加施壓woker的分布式壓測(cè)服務(wù)。

算法服務(wù)

容量評(píng)估的目標(biāo)就最小化資源成本提高資源利用率，所以有個(gè)先決條件，資源得可被成本量化，成本也是搜索走向平臺(tái)化衡量平臺(tái)價(jià)值的一個(gè)重要維度，于是我們搜索這邊跟財(cái)務(wù)制定了價(jià)格公式，也就擁有了這個(gè)先決條件，和算法同學(xué)經(jīng)過(guò)大量的實(shí)驗(yàn)分析發(fā)現(xiàn)這個(gè)問(wèn)題可以轉(zhuǎn)換成帶約束條件的規(guī)劃問(wèn)題，優(yōu)化的目標(biāo)函數(shù)就是價(jià)格公式（里面有內(nèi)存 cpu磁盤(pán)幾個(gè)變量）約束條件就是提供的容器規(guī)格和容器數(shù)一定要滿(mǎn)足***的qps 內(nèi)存和磁盤(pán)的需要。

AIOps展望

通過(guò)hawkeye診斷優(yōu)化和torch容量治理在tisplus搜索平臺(tái)上的落地大大降低了成本提高了效率和穩(wěn)定性，為將AIOps應(yīng)用到其它在線系統(tǒng)樹(shù)立了信心，因此下一步目標(biāo)就是將hawkeye和torch整合進(jìn)行AIOps平臺(tái)化建設(shè)，讓其它在線服務(wù)也都能享受到AIOps帶來(lái)的福利。因此，開(kāi)放性，易用性是平臺(tái)設(shè)計(jì)首要考慮的兩個(gè)問(wèn)題。

為此，接下來(lái)會(huì)重點(diǎn)進(jìn)行四大基礎(chǔ)庫(kù)的建設(shè)：

運(yùn)維指標(biāo)庫(kù)：將在線系統(tǒng)的日志，監(jiān)控指標(biāo)，event和應(yīng)用信息進(jìn)行規(guī)范整合，讓策略實(shí)現(xiàn)過(guò)程中方便獲取各種運(yùn)維指標(biāo)。

運(yùn)維知識(shí)庫(kù)：通過(guò)ES沉淀日常答疑積累的問(wèn)題集及經(jīng)驗(yàn)，提供檢索及計(jì)算功能，便于對(duì)線上類(lèi)似問(wèn)題進(jìn)行自動(dòng)診斷及自愈。

運(yùn)維組件庫(kù)：將克隆仿真 壓測(cè) 及算法模型組件化，便于用戶(hù)靈活選擇算法進(jìn)行策略實(shí)現(xiàn)，并輕松使用克隆仿真及壓測(cè)對(duì)優(yōu)化建議進(jìn)行有效驗(yàn)證。

運(yùn)維策略庫(kù)：通過(guò)畫(huà)布讓用戶(hù)拖拽及寫(xiě)UDP來(lái)快速實(shí)現(xiàn)自己系統(tǒng)的運(yùn)維策略，運(yùn)維指標(biāo)庫(kù)，運(yùn)維知識(shí)庫(kù)及運(yùn)維組 件庫(kù)提供了豐富多樣的數(shù)據(jù)及組件，使得運(yùn)維策略的實(shí)現(xiàn)變得足夠簡(jiǎn)單。

基于上述基礎(chǔ)設(shè)施的建設(shè)結(jié)合策略便可產(chǎn)出各種運(yùn)維場(chǎng)景下的數(shù)據(jù)，全面進(jìn)行故障處理，智能問(wèn)答，容量管理及性能優(yōu)化各種場(chǎng)景的應(yīng)用。