1. 程式人生 > >AI在運維中的應用

AI在運維中的應用

輸入 空間使用率 存在 aio alt roc 統架構 影響 夠快

?

要:隨著X86分布式技術應用,服務器數量越來越多,網絡拓撲結構越來越復雜,運維越來越辛苦,風險越來越高。智能化運維AIOPS將AI技術應用在運維場景,是DevOps的運維部分,是“開發運維一體化雲中心”的重要基礎設施之一,其最大的價值在於縮短故障恢復時間,提高IT服務連續性。

本文描述一個運維及在這個場景下對AI的需求,目標是嘗試將AI引入運維過程,提高運維效率、縮短故障恢復時間。

關鍵字:機器學習;DEVOPS、AIOPS、流量預測

隨著X86分布式架構應用,服務器規模越來越大,一個交易經過的服務數量,一個請求的可能路徑以笛卡爾乘積方式增加,一個節點異常往往會引起網絡上多個服務器告警。這給故障定位、故障應急處理、系統瓶頸預測帶來巨大的挑戰。針對這種情況業內把人工智能引入到分布式系統運維管理中,以期通過人工智能提高運維效率,縮短故障恢復時間。業內稱加入人工智能的運維為AIOPS。根據 Gartner Report,智能運維相關的技術產業處於上升期。2016 年,AIOPS 的部署率低於 5%,Gartner 預計 2019 年 AIOPS 的全球部署率可以達到 25%。隨著人工智能的成熟,運維工程師將逐漸轉型為大數據工程師,主要負責開發數據采集程序以及自動化執行腳本,負責搭建大數據基礎架構,同時高效實現基於機器學習的算法。

AIOPS代表結合人工智能的IT運維。它是指利用機器學習從各種IT運營工具和設備收集的大數據並訓練模型,實時自動發現問題、分析問題、響應問題的多層技術平臺。Gartner通過圖1解釋了AIOPS平臺如何工作。AIOPS有兩個主要組件:大數據和機器學習。為了將大數據平臺中的參與數據(通常在票據、事件和事件記錄中找到)與觀測數據(如監控系統和作業日誌中的觀測數據)結合起來,AIOPS需要從傳統IT數據中移除。 AIOPS針對合並的IT數據實施全面的分析和機器學習(ML)策略,找到故障模式和故障處理的關系,AIOPS可以被認為是核心IT功能的持續集成和部署(CI / CD)。現階段網絡性能管理的難點在於缺少業務視角,同時缺少覆蓋全局和第三方的視圖。Gartner提出了AIOps的概念,並預測到2020年,AIOps的采用率將會達到50%。(部分論述來自Gartner Report)

技術分享圖片? ? ? ??

從外部看,分為感知、分析和處置三部分.如圖2所示,在AIOPS前端是傳統的監控系統——稱為感知部分,主要負責現實物理狀態的獲取,它是整個AIOPS的前提,只有準確、及時、全面的了解系統當前運行狀況,後面的處理才可能實現。在AIOPS後端是IT運維管理系統、自動部署系統、通知告警系統——統稱為處置類系統,這類系統根據AIOPS指令轉換為操作具體服務器等IT設備的批量作業流,並通過執行作業流響應AIOPS指令。

從內部看AIOPS內部主要是平臺資源管理、大數據管理、機器學習和模型應用幾個部分。平臺資源管理主要是計算資源管理、存儲資源管理、任務調度等,可以基於現有的雲平臺實現;大數據管理主要包括數據介入、管理ETL、數據檢索等大數據平臺功能;模型應用主要是運用訓練好的模型,根據感知輸入,決定處置動作。

機器學習是AIOPS的核心,機器學習用來識別感知數據中的模式。雖然限制機器學習算法很健全,開源庫也很多,截止目前真正在運維中使用AIOPS的才5%,清華大學裴丹教授總結說“智能運維落地的核心挑戰是:從工業界的角度,我們有數據、有應用,但是缺乏一些算法和經驗;從學術界的角度,我們有不少理論算法,但是缺乏實際的數據以支持科學研究,也不熟悉運維的場景。”基於這個思路,業內一部分同仁通過收集了很多的數據,數據的形式有KPI時間序列、日誌等。假如打開首頁的響應時間是我們的KPI,當首屏時間不理想、不滿意時,我們希望能夠找出哪些條件的組合導致了首屏時間不理想。這個方案有三個困難,第一打開首頁設計的網絡節點的日誌必須全部收集,不僅僅是主機的,還包括相關網絡設備等。第二,每個節點采集的指標要和“首頁打開”這個動作相關,比如存儲空間使用率監控指標對“首頁打開”沒有意義的,實際情況是做AI的人並不知道感知給他的數據是否決定了現在的現象,為了避免依賴不得不擴大指標采集範圍,這不僅增加了成本,還會因為指標相關性引起模型訓練困難。第三,機械學習需要很長實際的數據積累,這裏不僅包括監控數據,還要包括故障數據——告訴機器什麽情況是故障,這需要大量的數據標記工作。由於數據不足等原因,我了解的情況是自動化運維系統更多的是在預測、分析、告警信息篩選等方面,直接對服務器執行重啟、擴容等動作的很少。

當你成功在運維場景和人工智能之間找到結合點的時候,你會發現拓撲結構、系統架構、操作系統特性、中間件特性、數據庫等都會對AIOPS的決策產生本質的影響。更為困窘的是市場變化導致IT服務的頻繁變化,以實施敏捷、DevOps的團隊為例,軟件發布周期普遍在幾天到幾周之間,而這種變化要經過一定的時間、一定的數據積累才能反饋到模型中去。

這讓我想起裴丹教授說一般有“前景光明”、“前途光明”這些詞的時候,下面跟著的就是“道路曲折”。實際上,智能運維是一個門檻很高的工作。實施AIOPS需要對銀行系統、運維知識、機器學習都有深入的了解,才能取得成效。幸運的是,這三方面技能在中國銀行軟件中心都能找到。對銀行系統的了解,首推總體部,總體部架構師隊伍設計了中行系統,並且通過接口管理系統記錄銀行業務系統之間的調用關系;軟件中心有專門的運維隊伍,他們運維經驗豐富,不僅熟悉系統狀況,而且詳細記錄了各個產品部署關系;隨著DevOps的實施,部署關系已經很好的管理起來,提供了精確的部署系統,而且為自動化處置提供了必要的條件。這些軟件中心獨特的有利條件,使我們不需要從零開始,而是結合決策樹、知識圖譜等已知的知識進行模型訓練。主要工作思路如下:

  1. 建立運維知識圖譜
  1. 選圖的節點: 服務/接口?? 進程?? 容器?? VM? 模塊 ?產品。
  2. 設置屬性:給每個節點設置屬性。比如CPU數量;歷史TPS峰值等
  3. 建立圖中節點關系:首先建立靜態關系,通過自動部署中的CMDB內容,建立節點/節點組中的關系。通過總體部接口管理文檔建立調用關系圖,此時已經標記了可能路徑。靜態關系有可以分為啟動依賴關系;運行時依賴關系;分類關系(見擴展分類)。
  4. 建立動態引用關系:通過監控發現的彼此之間的調用關系,這裏主要指全路徑跟蹤發現的關系。
  5. 路徑學習:由於負載均衡、SOA等策略,一些路徑可能不存在,但隨時會建立。這部分需要機器學習自動識別補充
  1. 選擇典型場景應用AIOPS

AIOPS運維場景有十幾種,由於篇幅所限,本次主要分享根本原因分析這個運維場景。在中國銀行的IT系統中,完成一個業務交易需要經歷多個產品、多個節點、多個進程、會調用多個接口。一旦交易鏈路上某個節點異常,會導致上遊所有節點表現異常,此時監控系統上會表現為多個產品同時告警。理想狀態下故障點及之前的節點交易堵塞,故障點之後的節點沒有請求,此時只需將交易路徑上的負載及情況可視化就能夠快速定位問題。不過實際情況是一個接口往往被很多交易使用;一個節點上一般提供多個接口服務;負載均衡器等分流設備後有多個同類型節點。這些因素構成了一個復雜的IT服務網絡,在復雜網絡下,幾筆交易異常,很難在監控系統上引起明顯特征。這種場景適合應用人工智能,人工智能系統能夠很好的捕捉這個特征,在故障發生且還沒有引起大規模業務堵塞的時候通知處置系統采取動作。這不僅降低了運維人員應急處置壓力,更為重要的是提升了系統連續性。基於運維知識圖譜選取數據,訓練模型可以有效降低模型訓練時數據範圍,去除服務網絡上無關數據幹擾,使模型訓練更快速準確。在訓練根本原因分析模型時,主要是找出交易異常發生位置與交易路徑上各種監控指標的關系。

大道至簡,模型訓練過程方法很好說清楚,但實際訓練過程很復雜,如特征選擇、降維、共線性等都需要非常專業的數據處理知識。筆者僅以此拋磚引玉,借助軟件中心架構師隊伍的知識理論降低人工智能在運維場景的應用難度。謬誤之處,請批評指點!

AI在運維中的應用