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

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

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

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

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

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

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

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

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

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

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

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

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