從DevOps到AIOps，阿里如何實現智能化運維？

摘要： AIOps英文全稱是Algorithmic IT Operations，是基於算法的IT運維。AIOps是運維領域上的熱點，然而在知足業務SLA的前提下，如何提高平臺效率和穩定性及下降資源成本成爲AIOps面臨的問題和挑戰。

背景

隨着搜索業務的快速發展，搜索系統都在走向平臺化，運維方式在經歷人肉運維，腳本自動化運維後最終演變成DevOps。但隨着大數據及人工智能的快速發展，傳統的運維方式及解決方案已不能知足需求。

基於如何提高平臺效率和穩定性及下降資源，咱們實現了在線服務優化大師hawkeye及容量規劃平臺torch。通過幾年的沉澱後，咱們在配置合理性、資源合理性設置、性能瓶頸、部署合理性等4個方面作了比較好的實踐。下面具體介紹下hawkeye和torch系統架構及實現。

AIOps實踐及實現

hawkeye——智能診斷及優化

系統簡介

hawkeye是一個智能診斷及優化系統，平臺大致分爲三部分：

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

1） 底層分析工程hawkeye-blink：基於Blink完成數據處理的工做，重點是訪問日誌分析、全量數據分析等，該工程側重底層的數據分析，藉助Blink強大的數據處理能力，天天對於搜索平臺全部Ha3應用的訪問日誌以及全量數據進行分析。

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

hawkeye-experience工程的定位是作一個引擎診斷規則中臺，將平時運維人員優化維護引擎的寶貴經驗沉澱到系統中來，讓每個新接入的應用能夠快速享受這樣的寶貴經驗，而不是經過一次次的踩坑以後得到，讓每位用戶擁有一個相似智能診斷專家的角色來優化本身的引擎是咱們的目標，也是咱們持續奮鬥的動力，其中hawkeye-experience的數據處理流程圖以下所示：

2.web層：提供hawkeye分析結果的各類api以及可視化的監控圖表輸出。

3.service層：提供hawkeye分析與優化api的輸出。

基於上述架構咱們落地的診斷及優化功能有：

• 資源優化：引擎Lock內存優化（無效字段分析）、實時內存優化等；

• 性能優化：TopN慢query優化、buildservice資源設置優化等；

• 智能診斷：平常化巡檢、智能問答等。

引擎Lock內存優化

對於Ha3引擎，引擎字段是分爲倒排（index）索引、正排（attribute）索引和摘要（summary）索引的。引擎的Lock策略能夠針對這三類索引進行Lock或者不Lock內存的設置，Lock內存好處不言而喻，加速訪問，下降rt，可是試想100個字段中，若是兩個月只有50個訪問到了，其餘字段在索引中壓根沒訪問，這樣會帶來寶貴內存的較大浪費，爲此hawkeye進行了以下分析與優化，針對頭部應用進行了針對性的索引瘦身。下圖爲Lock內存優化的過程，累計節省約數百萬元。

慢query分析

慢query數據來自應用的訪問日誌，query數量和應用的訪問量有關，一般在千萬甚至億級別。從海量日誌中獲取TopN慢query屬於大數據分析範疇。咱們藉助Blink的大數據分析能力，採用分治+hash+小頂堆的方式進行獲取，即先將query格式進行解析，獲取其查詢時間，將解析後的k-v數據取md5值，而後根據md5值作分片，在每個分片中計算TopN慢query，最後在全部的TopN中求出最終的TopN。對於分析出的TopN慢query提供個性化的優化建議給用戶，從而幫助用戶提高引擎查詢性能，間接提升引擎容量。

一鍵診斷

咱們經過健康分衡量引擎健康狀態，用戶經過健康分能夠明確知道本身的服務健康狀況，診斷報告給出診斷時間，配置不合理的簡要描述以及詳情，優化的收益，診斷邏輯及一鍵診斷以後有問題的結果頁面以下圖所示，其中診斷詳情頁面因篇幅問題暫未列出。

智能問答

隨着應用的增多，平臺遇到的答疑問題也在不斷攀升，但在答疑的過程當中不難發現不少重複性的問題，相似增量中止、常見資源報警的諮詢，對於這些有固定處理方式的問題其實是能夠提供chatOps的能力，藉助答疑機器人處理。目前hawkeye結合kmon的指標和可定製的告警消息模板，經過在報警正文中添加診斷的方式進行這類問題的智能問答，用戶在答疑羣粘貼診斷正文，at機器人便可獲取這次報警的緣由。

torch-容量治理優化

hawkeye主要從智能診斷和優化的視角來提高效率加強穩定性，torch專一從容量治理的視角來下降成本，隨着搜索平臺應用的增多面臨諸如如下問題，極易形成資源使用率低下，機器資源的嚴重浪費。

1）業務方申請容器資源隨意，形成資源成本浪費嚴重，須要基於容器成本耗費最小化明確指導業務方應該合理申請多少資源（包括cpu，內存及磁盤）或者資源管理對用戶屏蔽。

2）業務變動不斷，線上真實容量（到底能扛多少qps）你們都不得而知，當業務須要增大流量（譬如各類大促）時是否須要擴容？若是擴容是擴行仍是增大單個容器cpu規格？當業務須要增大數據量時是拆列合適仍是擴大單個容器的內存大小合適？ 如此多的問號隨便一個都會讓業務方蒙圈。

解決方案

以下圖所示，作容量評估擁有的現有資源，是kmon數據，線上系統的狀態彙報到kmon，那直接拿kmon數據來分析進行容量評估可不能夠呢？

實際實驗發現是不夠的，由於線上有不少應用水位都比較低，擬合出來高水位狀況下的容量也是不夠客觀的，因此須要個壓測服務來真實摸底性能容量，有了壓測接下來須要解決的問題是壓哪？壓線上風險比較大，壓預發預發的資源有限機器配置差無法真實摸底線上，因此須要克隆仿真，真實克隆線上的一個單例而後進行壓測，這樣既能精準又安全。有了壓測數據，接下來就是要經過算法分析找到最低成本下的資源配置，有了上面的幾個核心支撐，經過任務管理模塊將每一個任務管理起來進行自動化的容量評估。

以上是咱們的解決方案，接下來會優先介紹下總體架構，而後再介紹各核心模塊的具體實現。

系統架構

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

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

最上面是應用層，考慮到torch容量治理不只僅是爲tisplus定製的，應用層提供容量大盤，容量評估，容量報表及收益大盤，以便其它平臺接入嵌用，另外還提供容量API供其它系統調用。

容量評估也依賴了搜索不少其它系統，maat, kmon, hawkeye，drogo,成本系統等整個造成了一道閉環。

架構實現

克隆仿真

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

克隆目前分爲淺克隆和深度克隆，淺克隆主要針對ha3應用經過影子表的方式直接拉取主應用的索引，省掉build環節加快克隆速度，深度克隆就是克隆出來的應用須要進行離線build。

克隆的優點明顯：

1. 服務隔離，經過壓測克隆環境能夠間接摸底線上的真實容量。
2. 資源優化建議能夠直接在克隆環境上進行壓測驗證。
3. 克隆環境使用完，直接自動釋放，不會對線上資源形成浪費。

壓測服務

考慮到平常的kmon數據大部分應用缺乏高水位的metrics指標，而且引擎的真實容量也只有經過實際壓測才能得到，所以須要壓測服務，前期調研了公司的亞馬遜壓測平臺及阿里媽媽壓測平臺，發現不能知足自動壓測的需求，因而基於hippo咱們開發了自適應增長施壓woker的分佈式壓測服務。

算法服務

容量評估的目標就最小化資源成本提升資源利用率，因此有個先決條件，資源得可被成本量化，成本也是搜索走向平臺化衡量平臺價值的一個重要維度，因而咱們搜索這邊跟財務制定了價格公式，也就擁有了這個先決條件，和算法同窗通過大量的實驗分析發現這個問題能夠轉換成帶約束條件的規劃問題，優化的目標函數就是價格公式（裏面有內存 cpu磁盤幾個變量）約束條件就是提供的容器規格和容器數必定要知足最低的qps 內存和磁盤的須要。

AIOps展望

經過hawkeye診斷優化和torch容量治理在tisplus搜索平臺上的落地大大下降了成本提升了效率和穩定性，爲將AIOps應用到其它在線系統樹立了信心，所以下一步目標就是將hawkeye和torch整合進行AIOps平臺化建設，讓其它在線服務也都能享受到AIOps帶來的福利。所以，開放性，易用性是平臺設計首要考慮的兩個問題。

爲此，接下來會重點進行四大基礎庫的建設：

運維指標庫：將在線系統的日誌，監控指標，event和應用信息進行規範整合，讓策略實現過程當中方便獲取各類運維指標。

運維知識庫：經過ES沉澱平常答疑積累的問題集及經驗，提供檢索及計算功能，便於對線上相似問題進行自動診斷及自愈。

運維組件庫：將克隆仿真 壓測 及算法模型組件化，便於用戶靈活選擇算法進行策略實現，並輕鬆使用克隆仿真及壓測對優化建議進行有效驗證。

運維策略庫：經過畫布讓用戶拖拽及寫UDP來快速實現本身系統的運維策略，運維指標庫，運維知識庫及運維組 件庫提供了豐富多樣的數據及組件，使得運維策略的實現變得足夠簡單。

基於上述基礎設施的建設結合策略即可產出各類運維場景下的數據，全面進行故障處理，智能問答，容量管理及性能優化各類場景的應用。

本文是阿里搜索中臺技術系列AIOps實踐的分享，搜索中臺從0到1建設已經走過了3年，但它離咱們心目中讓天下沒有難用的搜索的遠大願景還離的很是遠。在這個前行的道路上必定會充滿挑戰，不管是業務視角的SaaS化能力、搜索算法產品化、雲端DevOps&AIOps，仍是業務建站等都將遇到世界級的難題等着咱們去挑戰。

本文做者：雲鐳

閱讀原文

本文來自雲棲社區合做夥伴「阿里技術」，如需轉載請聯繫原做者。