AIOPS概念被提出的時候，人們對此是寄予厚望的，因為傳統(tǒng)運維已經(jīng)進(jìn)了死胡同，走不通也無法掉頭。智能化運維的愿景被設(shè)計出來了，似乎是無所不能的，可以解決幾乎所有的傳統(tǒng)運維問題。不過在AIOPS落地的時候發(fā)現(xiàn)實際場景的復(fù)雜性遠(yuǎn)遠(yuǎn)超出預(yù)期，很多看似很高大上的算法與智能化系統(tǒng)都很難解決用戶遇到的問題。

最近和一個客戶討論AIOPS在大型數(shù)據(jù)庫這種復(fù)雜度很高的IT基礎(chǔ)設(shè)施上如何能真正實現(xiàn)，因為他也覺得他所見的AIOPS場景都是十分簡單的，肉眼都可見的問題，而對于復(fù)雜一些的數(shù)據(jù)庫問題，并沒有見到特別有效的AIOPS解決方案。一些AIOPS表現(xiàn)出不錯效果的場景，即使不使用AIOPS，以他們傳統(tǒng)的技術(shù)手段可以輕松解決，而那些傳統(tǒng)手段解決不了的問題，AIOPS似乎也束手無策。這就帶來一個問題，AIOPS不是完全沒用，在某些場景確實可以適當(dāng)減少人力投入，但是又不明顯，實施起來投入也很大。在這種情況下，是不是要投入巨資去實施AIOPS呢？對此我也一直在思考，今天和大家一起來探討一下這個問題。

這些年做運維自動化的感受是，AIOPS的上游是數(shù)據(jù)與指標(biāo)，下游是定位到具體原因的運維知識。做AIOPS的人往往都不大看得起指標(biāo)，他們認(rèn)為算法可以解決一切數(shù)據(jù)質(zhì)量的問題，因此沒有必要在指標(biāo)的質(zhì)量上去花太多工夫，實際上目前做AIOPS的企業(yè)也缺乏做運維數(shù)據(jù)質(zhì)量方面的專家，在這方面是天然存在缺陷的。

我想可能有這樣想法的人都沒做過復(fù)雜系統(tǒng)的運維，或者來自于運維數(shù)據(jù)質(zhì)量已經(jīng)相當(dāng)好的大型互聯(lián)網(wǎng)企業(yè)吧，在這些企業(yè)里上游數(shù)據(jù)質(zhì)量問題根本不需要做AIOPS的人去考慮。因此他們對算法充滿了迷一樣的自信，而對運維經(jīng)驗不屑一顧，認(rèn)為那是傳統(tǒng)運維時代的產(chǎn)物。

實際上指標(biāo)與運維經(jīng)驗是運維知識中的精華，上周四與一些電網(wǎng)自動化的朋友相遇，他們的觀點是數(shù)據(jù)，指標(biāo)，規(guī)則，自動處置，故障自愈是一條十分優(yōu)秀的流程鏈。把問題的內(nèi)在原因分析清楚了，就可以知道該如何自動處置，實現(xiàn)自愈。然后再往前推，找到定位問題的方法以及所依賴的指標(biāo)集，再把這些指標(biāo)精準(zhǔn)地采集回來，那么一個復(fù)雜的問題就用自動化的方法解決掉了。再對這些方法做適度的泛化，就可以將一個自動化控制的方法適配到更廣泛的場景中了。

這個工作方法對于做AIOPS的人來說似乎很LOW，似乎已經(jīng)過時了。確實，這種方法在自動化領(lǐng)域也全無新意，已經(jīng)有上百年的歷史了，在很多工業(yè)控制領(lǐng)域都被廣泛應(yīng)用。與信息化不同的是，自動化專業(yè)這些年里一直在把這些知識變成自動化裝置，已經(jīng)形成了體系化的行業(yè)解決方案和理論體系。在這種積累下，做什么項目都可以充分利用幾十年來積累下來的標(biāo)準(zhǔn)件，從而實現(xiàn)穩(wěn)定的技術(shù)迭代。而在信息化領(lǐng)域，這些知識往往只能不完整地沉淀在一些書籍中，能夠開箱即用的標(biāo)準(zhǔn)件少之又少，無法廣泛覆蓋運維的常用場景。

在IT運維領(lǐng)域，將運維經(jīng)驗做成標(biāo)準(zhǔn)件難度極高，成本巨大，因此大家對能夠不需要這種積累，天生具有普適泛化能力的AIOPS寄予厚望，認(rèn)為這才是運維的未來。

可惜的是，這種完全依賴算法的泛化分析能力并不一定適合用于在復(fù)雜系統(tǒng)中做精準(zhǔn)定位。比如說前幾天我遇到的那個因為expression tracking的采集而引發(fā)的Oracle數(shù)據(jù)庫的library cache pin/lock的問題，如果沒有去采集相關(guān)的指標(biāo)，那么我們?nèi)绾沃绬栴}存在呢？如果采集了library cache pin相關(guān)的指標(biāo)，但是不知道Oracle library cache pin的內(nèi)在原理，如何將指標(biāo)存在的異常與這個問題點關(guān)聯(lián)起來呢？從我們這些年做AIOPS的經(jīng)驗來看，摒棄高質(zhì)量的指標(biāo)是不可取的做法，特別對于復(fù)雜度較高的系統(tǒng)而言，指標(biāo)質(zhì)量越高，對算法的泛化分析而言就越有價值。

圖片

智能化算法在運維自動化中是十分關(guān)鍵的基礎(chǔ)能力，除了泛化分析的算法外，在AIOPS中，指標(biāo)異常檢測更需要智能化的算法加持。通過智能化算法生成“智能指標(biāo)”，再利用這些智能指標(biāo)通過傳統(tǒng)的表達(dá)式構(gòu)建較為精準(zhǔn)的模型，是智能化算法與傳統(tǒng)運維知識極為有效的融合點，這種方法在AIOPS方向上解決了更精準(zhǔn)的推理收斂問題，在運維自動化上解決了規(guī)則無法泛化的問題。

目前大家已經(jīng)十分認(rèn)可智能化算法在普適場景的泛化分析上的有效性，但是對于其問題收斂的程度與收斂結(jié)果的準(zhǔn)確性存在一定的疑問。而基于大模型的推理也天生具有泛化推理的能力，在推理結(jié)果的有效性方面，基于大模型的推理甚至?xí)哂诤芏郃IOPS的算法模型。

圖片

我現(xiàn)在就經(jīng)常使用GPT 4.0來幫我分析一些運維故障，推理問題的根因。對于非ZERO SHOT的問題，大模型推理的能力已經(jīng)相當(dāng)強(qiáng)悍，在很多情況下，已經(jīng)完全能夠替代人類專家了。前陣子我在文章中也介紹過一個利用GPT4.0分析一個十分復(fù)雜的PostgreSQL執(zhí)行計劃的案例。不過基于大模型的推理往往存在幻覺問題，這個問題暫時無解，因此基于大模型的推理也只能用于輔助，不能直接用于運維自動化中的重大決策。

既然使用單一技術(shù)很難解決復(fù)雜場景中的自動化運維的問題，那么結(jié)合這些技術(shù)的長處，使用雞尾酒療法能否解決這個問題呢？似乎這是目前我能夠想到的比較好的解決方案吧。

圖片

上面是我最近一直在思考的智能化分析引擎的未來模型，這個模型會結(jié)合專家系統(tǒng)、智能化運維系統(tǒng)、AIGC三種不同的技術(shù)框架來完成一個具體的分析任務(wù)。為了實現(xiàn)三者能夠協(xié)同工作，指標(biāo)化是核心。整個過程中，需要構(gòu)建一套通用的“國際語言”，讓多種分析引擎能夠綜合利用共同分析的結(jié)果。在這張圖中，我們可以看到，基于知識自動化的“運維知識點診斷”是確認(rèn)診斷結(jié)果的最后一個環(huán)節(jié)。無論前面采用什么方法進(jìn)行泛化、分析、歸納、抽象。最終必須通過十分確定的“自動化診斷”，才能確定問題，得到結(jié)論。AIOPS的最后一公里是“運維知識自動化”。