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

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

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

我想可能有這樣想法的人都沒做過復雜系統的運維，或者來自于運維數據質量已經相當好的大型互聯網企業吧，在這些企業里上游數據質量問題根本不需要做AIOPS的人去考慮。因此他們對算法充滿了迷一樣的自信，而對運維經驗不屑一顧，認為那是傳統運維時代的產物。

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

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

在IT運維領域，將運維經驗做成標準件難度極高，成本巨大，因此大家對能夠不需要這種積累，天生具有普適泛化能力的AIOPS寄予厚望，認為這才是運維的未來。

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

圖片

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

目前大家已經十分認可智能化算法在普適場景的泛化分析上的有效性，但是對于其問題收斂的程度與收斂結果的準確性存在一定的疑問。而基于大模型的推理也天生具有泛化推理的能力，在推理結果的有效性方面，基于大模型的推理甚至會高于很多AIOPS的算法模型。

圖片

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

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

圖片

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