數年前，AIOPS強勢崛起的時候，大家認為AIOPS是替代專家運維的最佳實現途徑。當時的愿景是無需專家知識，無需十分精準的可觀測性分析，僅僅利用現象和規律，利用AI算法就能夠解決困擾運維工作數十年的難題。

數年過去了，曾經狂熱于AIOPS的我有所感悟，現在我覺得當前的數據庫 AIOPS頂多算是智能輔助運維，無法稱之為真正的智能運維，主要是數據庫運維的場景太復雜了，很多場景專家都很難定位問題，僅僅依靠沒有專家知識的算法，就想有所突破，真的太難了。搞 AIOPS的朋友可能會不大服氣，認為AI的能力已經足夠了，完全可以勝任復雜的故障定位，并舉出他們的案例來。有時候你列舉的場景可能是OK的，但是泛化到其他的場景或者用戶那邊就不見得有效了。這也是很多上了AIOPS項目的客戶抱怨當時做實驗時候覺得效果還行，一實戰就不行了。

對于一些互聯網架構的系統，數據庫本身不會出現復雜的故障，大部分故障都可以通過擴容、限流或者重啟來完成。對于這樣的場景，AIOPS的智能化程度是夠用的。而對于一些傳統行業場景，AI還是不堪一用的。

比如有一個案例，某天凌晨00:12-00:15，用戶的一個業務系統出現了三分鐘的卡頓，這個業務跑了很多年了，這幾天業務變化也不大，那個時段發現sga_resize_ops中shared_pool有增長，能定位是sga resize導致了問題還是其他什么原因導致了問題？還是其他什么問題？如果是sga resize導致的問題，如何讓此類問題不再發生呢？

圖片

從AWR報告上看，確實Mutex X等待十分嚴重，SGA RESIZE HANG導致3分鐘的卡頓的可能性很大，但是并非唯一的可能性。這需要看卡頓起始時間與SGA RESIZE在時間上的先后順序。本案例最后分析結果是卡頓先于SGA RESIZE數秒鐘，因此SGA RESIZE只是結果而已。哪怕SGA RESIZE先于卡頓，引發SGA不足的原因還是更接近于根源的原因。要想找出共享池使用量突然增大的原因才是根本性解決問題的關鍵。

如果僅僅從上面的數據上看，每秒5.2W+的執行可能是個疑點，不過從歷史上看，這套系統的每秒執行數一直就這么高。通過歷史數據的比對分析，找出異常與正常的關鍵點是深入解析此類問題的關鍵?；诖竽Ｐ突蛘咝∧Ｐ退惴ㄏ胍鉀Q此類問題目前能力還不足。

事實上，要想通過自動化工具分析出此類問題的原因，需要對歷史的指標數據有十分精準和周全地采集。不過僅有歷史數據還是不夠的，雖然我們能夠通過算法發現某些指標是正常的，某些指標是異常的，并且能夠對異常按照時間序列去排序，但是我們還是缺乏足夠的知識庫，從這些異常中直接定位問題。有經驗的運維專家可以發現一些問題，并且逐步排除一些可能性，從而讓問題收斂，而AI算法在這方面的能力依然不足。

圖片

剛開始的時候我發現了這些異常，解析后0次之行的SQL，很可能是這些SQL存在語法問題。后來用戶那邊確認是自己的應用框架存在BUG，此類問題一直存在，在沒有卡頓的時段里也會存在這樣的情況。

要定位此類問題，如果是專家進行分析，還會考慮一種排除方法，那就是找出當天可以確定的異常情況。比如當天是否有特殊的操作，發生問題的時間是1號，因此我們也懷疑是否因為新的表分區缺乏統計數據引起了動態采樣。或者說有一些新的分區創建操作等。這些問題也被一一排除了。

最后我還是把焦點定位在1號這個疑點上，讓用戶檢查之前幾個月1號的應用日志，發現雖然前幾個月沒有觸發應用告警，但是在類似的時點應用都出現了類似的卡頓現象。通過這個疑點，我懷疑卡頓來自于一個周期性的任務，但是在定期任務中確實找不到相關的定時任務。而且卡頓出現的時點又不是嚴格意義上的0點，而是0點之后的數秒到數十秒內，時間并不一致。于是分析只能從數據庫基本原理入手，最終發現了一個疑點，就是分區表的延時段創建。因為分區表延時段創建導致的CURSOR失效引發了一系列的共享池相關的問題，最終導致了卡頓。

對于如此復雜的故障場景，專家要排除大量的非關聯因素，需要與現場的DBA進行充分的溝通才能達成目標，因為很多現象并沒有被指標化，因此也無法通過自動化采集形成指標，更不要說去做自動化分析了。在缺乏基礎數據的基礎上，AIOPS根本無法捕獲到與此類理論相關的知識點和數據，因此怎么可能將分析指向此診斷路徑？

從上面的那個案例來看，目前AIOPS的理論基礎是有的，無論是小模型還是大模型，都是能夠輔助專家進行分析的。其中最為缺乏的還是高質量的專家知識，對于此類問題，需要由專家參與才能構建出來。專家需要構建出一系列的圖譜，才能讓知識數字化，利用這些數字化的知識，才能知道想要走通這些圖譜需要什么樣的數據，然后我們才能把數據庫的現象數字化表示出來，這樣AI算法才能覆蓋這個場景。

圖片

比如上面的一個關于direct path read temp/direct path write temp過多引發系統問題的知識就需要理解Oracle直接路徑讀寫原理的專家經過梳理才能夠比較清晰地呈現出來。有了這張圖，才能夠編制出有價值的算法來分析此類問題，雖然說這張圖還只是很初級，還只是把一些常見的問題包含在內。在構建算法之前，首先要把分析要素都指標化了，否則算法也是巧婦難為無米之炊。

在數據庫領域，AIOPS是未來必然的方向，不過在實現的路徑上，還有很多爭議，我覺得，任何智能背后都必然有更為艱苦的人工，想要繞過專家，繞過知識去構建AIOPS，只能是空中樓閣。