[[239574]]

背景

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

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

AIOps實踐及實現(xiàn)

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

系統(tǒng)簡介

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

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

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

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

hawkeye-experience工程的定位是做一個引擎診斷規(guī)則中臺，將平時運維人員優(yōu)化維護引擎的寶貴經(jīng)驗沉淀到系統(tǒng)中來，讓每一個新接入的應(yīng)用可以快速享受這樣的寶貴經(jīng)驗，而不是通過一次次的踩坑之后獲得，讓每位用戶擁有一個類似智能診斷專家的角色來優(yōu)化自己的引擎是我們的目標，也是我們持續(xù)奮斗的動力，其中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)化（無效字段分析）、實時內(nèi)存優(yōu)化等；
• 性能優(yōu)化：TopN慢query優(yōu)化、buildservice資源設(shè)置優(yōu)化等；
• 智能診斷：日常化巡檢、智能問答等。

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

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

慢query分析

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

一鍵診斷

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

智能問答

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

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

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

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

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

解決方案

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

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

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

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

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

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

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

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

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

克隆仿真

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

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

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

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

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

克隆環(huán)境使用完，直接自動釋放，不會對線上資源造成浪費。   

壓測服務(wù)

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

算法服務(wù)

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

AIOps展望

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

為此，接下來會重點進行四大基礎(chǔ)庫的建設(shè)：

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

運維知識庫：通過ES沉淀日常答疑積累的問題集及經(jīng)驗，提供檢索及計算功能，便于對線上類似問題進行自動診斷及自愈。

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

運維策略庫：通過畫布讓用戶拖拽及寫UDP來快速實現(xiàn)自己系統(tǒng)的運維策略，運維指標庫，運維知識庫及運維組 件庫提供了豐富多樣的數(shù)據(jù)及組件，使得運維策略的實現(xiàn)變得足夠簡單。

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