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

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

對于一些互聯(lián)網(wǎng)架構(gòu)的系統(tǒng)，數(shù)據(jù)庫本身不會出現(xiàn)復(fù)雜的故障，大部分故障都可以通過擴容、限流或者重啟來完成。對于這樣的場景，AIOPS的智能化程度是夠用的。而對于一些傳統(tǒng)行業(yè)場景，AI還是不堪一用的。

比如有一個案例，某天凌晨00:12-00:15，用戶的一個業(yè)務(wù)系統(tǒng)出現(xiàn)了三分鐘的卡頓，這個業(yè)務(wù)跑了很多年了，這幾天業(yè)務(wù)變化也不大，那個時段發(fā)現(xiàn)sga_resize_ops中shared_pool有增長，能定位是sga resize導(dǎo)致了問題還是其他什么原因?qū)е铝藛栴}？還是其他什么問題？如果是sga resize導(dǎo)致的問題，如何讓此類問題不再發(fā)生呢？

圖片

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

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

事實上，要想通過自動化工具分析出此類問題的原因，需要對歷史的指標(biāo)數(shù)據(jù)有十分精準(zhǔn)和周全地采集。不過僅有歷史數(shù)據(jù)還是不夠的，雖然我們能夠通過算法發(fā)現(xiàn)某些指標(biāo)是正常的，某些指標(biāo)是異常的，并且能夠?qū)Ξ惓０凑諘r間序列去排序，但是我們還是缺乏足夠的知識庫，從這些異常中直接定位問題。有經(jīng)驗的運維專家可以發(fā)現(xiàn)一些問題，并且逐步排除一些可能性，從而讓問題收斂，而AI算法在這方面的能力依然不足。

圖片

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

要定位此類問題，如果是專家進行分析，還會考慮一種排除方法，那就是找出當(dāng)天可以確定的異常情況。比如當(dāng)天是否有特殊的操作，發(fā)生問題的時間是1號，因此我們也懷疑是否因為新的表分區(qū)缺乏統(tǒng)計數(shù)據(jù)引起了動態(tài)采樣?；蛘哒f有一些新的分區(qū)創(chuàng)建操作等。這些問題也被一一排除了。

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

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

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

圖片

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

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