本文轉(zhuǎn)載自公眾號(hào)“讀芯術(shù)”(ID：AI_Discovery)

智能運(yùn)維(ArtificialIntelligence-based Operations, AIOps)是AI與傳統(tǒng)即時(shí)通信(Active Messenger, AM, or Instant Messenger, IM)技術(shù)的集合。就如同AI引發(fā)了其他所有領(lǐng)域的革命，AI也將深刻影響運(yùn)營(yíng)管理。當(dāng)AI的力量應(yīng)用于運(yùn)營(yíng)，它將重新定義應(yīng)用程序及支持應(yīng)用程序/基礎(chǔ)結(jié)構(gòu)的管理模式。

[[323666]]

多個(gè)應(yīng)用程序同時(shí)運(yùn)行會(huì)產(chǎn)生大量的數(shù)據(jù)。數(shù)據(jù)在網(wǎng)絡(luò)層生成，經(jīng)隱藏的API接口到達(dá)終端用戶。用戶都期待擁有完美的應(yīng)用體驗(yàn)，容不得一點(diǎn)故障。

從完全不同的層中收集數(shù)據(jù)，使其成為蘊(yùn)含豐富洞見(jiàn)的資源庫(kù)，這樣的做法是可行的。由于操作復(fù)雜，智能運(yùn)維平臺(tái)應(yīng)運(yùn)而生。智能運(yùn)維平臺(tái)運(yùn)用AI及ML技術(shù)，從監(jiān)測(cè)數(shù)據(jù)中獲取洞見(jiàn)，通過(guò)強(qiáng)化人工決策推進(jìn)自動(dòng)化解決方案。

重要應(yīng)用案例及解決方案

1. 定位故障

在軟件開(kāi)發(fā)周期中，管理軟件質(zhì)量是一個(gè)重要的關(guān)注點(diǎn)。幾乎所有的軟件在發(fā)布后都或多或少出現(xiàn)了一些小故障。在進(jìn)入生產(chǎn)環(huán)境之前發(fā)現(xiàn)并修復(fù)故障是很重要的。生產(chǎn)中出現(xiàn)的任何故障都會(huì)大幅增加成本。當(dāng)可用資源有限時(shí)，定位故障被視為最耗時(shí)間的艱巨工作。因此，軟件工程師需要半自動(dòng)/全自動(dòng)技術(shù)來(lái)改善人工調(diào)試過(guò)程。如果開(kāi)發(fā)人員能夠獲得提示，知道故障可能在哪，調(diào)試將變得更為高效。

解決方案

許多圖挖掘算法/技術(shù)能幫助開(kāi)發(fā)人員定位軟件故障。這些技術(shù)依賴于檢測(cè)失敗記錄及通過(guò)記錄之間的判別圖。當(dāng)故障不在罕見(jiàn)的代碼模式中時(shí)，這些方法可能不合適。另一方面，很多方法主要篩選可能有錯(cuò)誤的程序組件(如statements接口和predicates接口)，然后根據(jù)懷疑程度給這些組件排序，根據(jù)控制流圖排列執(zhí)行跟蹤的上下文。

2. 達(dá)到基準(zhǔn)

性能基準(zhǔn)決定了在不同負(fù)載情況下應(yīng)用組件和基礎(chǔ)結(jié)構(gòu)的運(yùn)行方式。負(fù)載情況包括正常負(fù)載、工作負(fù)載、準(zhǔn)負(fù)載、尖峰負(fù)載、斷點(diǎn)負(fù)載等等?；鶞?zhǔn)則是一整套各參數(shù)的規(guī)則和閾值，這些參數(shù)將在一定范圍內(nèi)波動(dòng)。傳統(tǒng)的做法是，收集了一定時(shí)間的性能數(shù)據(jù)后，通過(guò)機(jī)器學(xué)習(xí)算法構(gòu)建以上關(guān)系的模型并即時(shí)部署，以便性能出現(xiàn)偏差時(shí)通報(bào)。這一方法適用于發(fā)展緩慢的組件，卻讓快速的現(xiàn)代發(fā)展方式“失去了意義”。

解決方案

超融合基礎(chǔ)架構(gòu)管理、領(lǐng)域驅(qū)動(dòng)的應(yīng)用程序開(kāi)發(fā)、分布式計(jì)算的興起和多語(yǔ)言編程及維護(hù)改變了軟件組件開(kāi)發(fā)和部署的方式。不斷更新?lián)Q代的軟件組件需要持續(xù)地部署在動(dòng)態(tài)縮放的底層基礎(chǔ)架構(gòu)之上。這一模式的轉(zhuǎn)變要求模型構(gòu)筑使用近實(shí)時(shí)數(shù)據(jù)，與應(yīng)用程序及基礎(chǔ)架構(gòu)組件的最新變化保持同步。這些模型需要實(shí)時(shí)輸入數(shù)據(jù)，從而學(xué)習(xí)新規(guī)則，實(shí)現(xiàn)持續(xù)發(fā)展。

3. 應(yīng)用監(jiān)控

應(yīng)用指標(biāo)追蹤不同時(shí)段的響應(yīng)時(shí)間、每分鐘請(qǐng)求數(shù)量、錯(cuò)誤率并識(shí)別變化趨勢(shì)。另外，CPU利用率、內(nèi)存利用率、負(fù)載等基礎(chǔ)結(jié)構(gòu)參數(shù)能幫助我們理解基礎(chǔ)結(jié)構(gòu)層是如何適應(yīng)應(yīng)用的不同負(fù)荷情況的。隨著應(yīng)用復(fù)雜性提升，從預(yù)期模式中檢測(cè)到異常并非易事。如果無(wú)法檢測(cè)出異常，可能產(chǎn)生潛在的程序中斷風(fēng)險(xiǎn)。

解決方案

我們能在不同的層發(fā)現(xiàn)并分析變化模式，包括應(yīng)用層、服務(wù)層、事務(wù)層和外部依賴。首先，確定正常系統(tǒng)行為的構(gòu)成，然后識(shí)別偏離正常的系統(tǒng)行為。智能運(yùn)維能夠通過(guò)精確搜索資源，準(zhǔn)確標(biāo)識(shí)出異常值，這有助于更好地開(kāi)展實(shí)時(shí)根因分析 (Root Cause Analysis,RCA) ,還能避免潛在中斷及基礎(chǔ)結(jié)構(gòu)故障。

4. 預(yù)警問(wèn)題

應(yīng)用性能監(jiān)測(cè)軟件(ApplicationPerformance Monitor, APM) 中的智能警報(bào)能夠動(dòng)態(tài)檢測(cè)異常。要實(shí)現(xiàn)警報(bào)智能化，檢測(cè)軟件必須是可配置的，這樣它才能理解應(yīng)用程序的特性及行為并檢測(cè)異常。設(shè)置靜態(tài)閾值是很常見(jiàn)的做法，比如設(shè)置在服務(wù)請(qǐng)求的響應(yīng)時(shí)間超過(guò)三秒時(shí)發(fā)出警報(bào)。然而，對(duì)于不同的應(yīng)用使用模式，識(shí)別需要監(jiān)控的重要參數(shù)及其閾值是非常繁重的工作。因此，需要通過(guò)智能的方式來(lái)設(shè)定應(yīng)用程序正常狀態(tài)的基準(zhǔn)，在出現(xiàn)反常行為時(shí)通報(bào)。

解決方案

隨著算法技術(shù)的進(jìn)步，警報(bào)也變得非常智能。它可以進(jìn)行初步的數(shù)據(jù)分析，能夠在標(biāo)準(zhǔn)差、百分比、預(yù)測(cè)分析等預(yù)測(cè)手段的基礎(chǔ)上發(fā)出警報(bào)。今天，檢測(cè)軟件已經(jīng)足夠智能，它可以理解應(yīng)用的行為并設(shè)定基準(zhǔn)，在分析請(qǐng)求與開(kāi)發(fā)人員的基準(zhǔn)有出入時(shí)，允許開(kāi)發(fā)人員自行定義分析策略，在真正出現(xiàn)了需要開(kāi)發(fā)人員關(guān)注的問(wèn)題時(shí)發(fā)出智能警報(bào)。

[[323667]]

來(lái)源：Pexels

5. 事務(wù)跟蹤

從簡(jiǎn)單的應(yīng)用連接間點(diǎn)對(duì)點(diǎn)的信息同步交換到更為復(fù)雜的異步通訊，都屬于商業(yè)事務(wù)的范疇。事務(wù)跟蹤要求精密的跟蹤監(jiān)控方案。長(zhǎng)期的多步驟異步事務(wù)會(huì)傳輸IT基礎(chǔ)結(jié)構(gòu)，要求跨越多種技術(shù)和層級(jí)，等等。

解決方案

復(fù)雜事務(wù)往往多變且分散，其標(biāo)簽和統(tǒng)計(jì)取樣技術(shù)使得標(biāo)準(zhǔn)跟蹤和分析失去了用武之地。智能運(yùn)維通過(guò)檢驗(yàn)方法調(diào)用及單個(gè)信息負(fù)載內(nèi)容，將事務(wù)關(guān)聯(lián)在一起，直觀地視覺(jué)化展示預(yù)期行為和性能中即將出現(xiàn)或已經(jīng)存在的漏洞。