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

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

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

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

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

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

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

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

另外一部分是CPU使用率異?？赡芤l(fā)的現(xiàn)象，這些現(xiàn)象是我們能夠用各種觀察的方法觀察到的，也是很容易通過監(jiān)控數(shù)據(jù)采集與異常檢測分析到的。當CPU使用率異常的時候，這些現(xiàn)象中的一個或者多個會出現(xiàn)。這時候我們就很容易總結(jié)出一個方法，首先CPU使用率異?？梢酝ㄟ^異常檢測算法較為準確的算出來，然后我們可以通過現(xiàn)象來驗算這個異常發(fā)現(xiàn)，同時也為問題分析提供大致的方向，再去源頭發(fā)現(xiàn)可能存在的問題。

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

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

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

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