聊聊智慧診斷模型的構建

談到智慧化運維，談智慧檢測或者智慧發現的比較多，談智慧診斷的比較少。智慧診斷不好做，因為診斷涉及到複雜的分析與推理。檢測與發現可以基於資料的統計學規律，透過訓練與建模來不斷提升效能，而複雜問題的診斷推理，還是很難透過簡單的統計學方法來實現的。

前陣子我寫過一篇關於莫拉維克悖論的文章，說的是在幾十年前，採用知識推理的方法很容易解決一些比較複雜的問題，而一些類似模擬人類的視覺、行動等較為簡單的問題反而很難解決。事實上，最近這些年的基於資料分析與統計學的演算法讓這些當你困擾莫拉維克們的問題變得十分簡單了，深度學習可以很好的解決這些問題了。透過統計學的方法，透過深度學習，識別異常變得更為容易了，這是構建智慧運維繫統的基礎。以前我們往往需要依靠專家來發現真正的“異常”，這裡說的“異常”不是透過網管系統，透過基線或者日誌採集發現的所謂“不可確定的異常”，而是真正可能威脅系統健康的異常。

透過演算法發現異常僅僅完成了智慧運維的第一步，而下一步就是要透過一系列的現象去推理出現某種異常的原因。我曾經和一個做智慧運維演算法的朋友交流過，他認為這是十分簡單的事情，把系統中的採集資料都計算一遍，把發現的問題進行歸類，不就很容易獲得問題的原因嗎?

事實上，我的這位朋友並不是做運維出身，而是純粹的演算法工程師，他比較難以理解資料庫系統這樣的複雜系統，其問題根因歸類是十分困難的。另外他也不清楚系統在實際的生產環境，某個資料庫系統總是處於亞健康狀態。除了引發這個問題的內因外，這個系統可能還存在多種問題，將所有的指標都進行一次異常檢測，再透過收斂演算法歸納根因，並不能實現真正的根因發現。

這些年，如何做智慧運維演算法的問題也一直在困擾著我，前陣子和一個客戶交流的時候，就提起你如何才能透過演算法精確的定位資料庫問題的原因，並採取準確的手段去做處置呢?我當時想都沒想，就說，對於大多數場景來說，我們做不到。能做到的僅僅是一些十分簡單的場景。智慧發現和智慧診斷目前還只能做到幫助運維人員定位一個大致的方向，從而減少運維人員分析問題的工作量，而無法真正替代人工，最後一公里的發現，依然需要人，甚至有時候需要專家才能夠完成，DBAIOPS在目前的階段依然只是配角。

構建智慧分析模型是我這些年一直在探索的，2017年我們開始這個專案的時候是和某高校合作的，他們的演算法能力讓我們耳目一新，原來資料庫的問題分析還能夠讓一群完全不懂資料庫運維的人，透過演算法就能做的這麼好了。我們一起合作做了Oracle資料庫的關鍵指標篩選，健康模型構建，健康指標預測等專案。其中健康模型構建工作的大部分成果目前還在D-SMART系統中應用，不過其他工作的技術方向走下去似乎都很難走通。健康指標預測雖然在當時獲得了比較好的效果，不過在實際應用中被使用者認為價值不大。因為一個資料庫系統在99.9%的時候是表現良好的，指標預測的準確率再高對運維的實際幫助也不不大，誤報的時候才是對運維最為致命的。

2018年，有一次和客戶交流的時候，他對我們的方案十分不滿意，他說：“老白，別和我談什麼智慧化演算法，如果你能把你們團隊專家們分析資料庫問題的方法用自動化的手段實現一部分，能夠在我們的運維現場幫助我們解決一些常見問題，那就比你所謂的智慧演算法要有價值的多了”。他的話讓我如夢方醒，我們的專家腦子裡擁有最寶貴的智慧化分析演算法，為什麼棄之不用，反而拼命去追求一些混沌的數學方法呢?於是我們開始轉向專家知識的梳理，引入知識圖譜，透過構建運維知識圖譜去解決一些複雜的推理與分析問題。

不過梳理專家知識也不是一件容易的事情，而且本身很多問題就像量子糾纏一樣，是比較難以弄清楚的。比如我們來看一個簡單的場景，CPU使用率異常。一般來說，一個運維人員分析CPU使用率異常的時候，會從兩個角度去看這個問題，一個是觸發這個異常的一些主要原因，就是我列在上方的那些，當然這只是運維經驗的一部分，而且也僅僅是某個專家或者某個團隊理解的一部分，並不能覆蓋所有的場景。

另外一部分是CPU使用率異常可能引發的現象，這些現象是我們能夠用各種觀察的方法觀察到的，也是很容易透過監控資料採集與異常檢測分析到的。當CPU使用率異常的時候，這些現象中的一個或者多個會出現。這時候我們就很容易總結出一個方法，首先CPU使用率異常可以透過異常檢測演算法較為準確的算出來，然後我們可以透過現象來驗算這個異常發現，同時也為問題分析提供大致的方向，再去源頭發現可能存在的問題。

似乎很簡單，不過你可能會發現，有些因素既出現在引發現象上，也出現在觸發原因上，也就是說在實際的生產環境中因果關係並不是固定的，有可能會倒置。甚至可能發生類似水塘中的漣漪一樣，多個波會相互干擾，這是系統的複雜性導致的。不過這些問題難不倒演算法專家，透過時序分析，很容易發現多個波動之間的關聯關係以及波動的時序先後，從而區分因果;透過統計學的分析也可以發現這些資料之間的複雜關係;透過深度學習還可以找到一些人類專家比較容易忽略的隱性關係。

只要透過知識圖譜構建，把一個基本圖譜建立起來了，那麼一些複雜性的問題就會變得簡單與清晰了。以往完全依靠深度學習才能完成的，樣本極難覆蓋的問題也就迎刃而解了。不過在實際的生產環境應用中也並不是這麼簡單。這個圖譜需要不斷地積累與不斷地完善。而要完善這個圖譜，資料又是極其關鍵的。只有透過不斷地積累資料樣本，才能不斷地去完善上面的這張圖。最近我一直號召社群的朋友能夠分享SQL SERVER的監控資料，就是這個道理。我們見識過的運維場景十分有限，必須透過大量的，分佈在各行各業的實際生產案例，才能更好地提煉出知識。

而如果我們有了豐富的資料，分析這些資料的工作量又極大，如何解決這個問題呢?演算法這時候就能夠發揮巨大的作用了，透過強大的演算法發現異常，透過專家來分析異常，提煉知識圖譜是這個生態體系中十分關鍵的一環。以往我們做智慧化運維繫統的時候，往往把運維專家與演算法工程師割裂開來了。二者沒有很好地融合，從而導致二者的優勢無法形成合力。

每次寫這個話題的時候，總是覺得寫的比較費勁，而且寫到最後發現很多問題還是沒講清楚，確實也是的，AIOPS，我們還剛剛上路，很多工作都是嘗試性的，雖然有些成果，但是僅僅是起步而已。也希望在這個領域有興趣的朋友不吝賜教，同時加強交流與合作，為了一個共同的理想做些事情。