昨天在機場候機的時候，突然有了一些感想，寫了一些讓人莫名其妙的文字。實際上也不是莫名其妙，對于從事運維知識圖譜工作的朋友來說，可能還是明白我在說什么的。

專家分析故障的時候，是根據(jù)經(jīng)驗與掌握的知識去做問題發(fā)現(xiàn)的，發(fā)現(xiàn)的依據(jù)是系統(tǒng)運行狀態(tài)，指標(biāo)，日志等數(shù)據(jù)。因為人既具有記憶思維，又具有邏輯推理能力，因此大部分問題的解決來自于對以往案例的積累與基于知識的邏輯推理。這些年，Oracle RAC的性能問題和故障已經(jīng)被大家研究的比較透了，下面是一個RAC常見問題分析的思維導(dǎo)圖。

上面的思維導(dǎo)圖是專家梳理出來的RAC性能分析的一些常見分析路徑，根據(jù)專家腦子中的類似的思維導(dǎo)圖，人的思維可以根據(jù)現(xiàn)實的實際情況進行發(fā)散和收斂，靈活度很大，而且不同的專家的思路不一樣，其發(fā)散與收斂的方法也不一致。不管怎么樣，只要專家對RAC問題分析的功力足夠，要想定位我說的那個用戶RAC故障還是比較容易的。

從事后分析來看，當(dāng)時的故障模型告警中我們可以看到明確的RAC性能方面的告警，因為問題出現(xiàn)后如果沒有解決，系統(tǒng)會對嚴重告警事件重復(fù)告警，因此上圖的告警時間只是記錄了最后一次告警的時間，不能根據(jù)時間來作為判斷告警出現(xiàn)先后的依據(jù)。針對gc block lost告警，通過診斷工具也可以就這個問題進行下鉆分析。

通過點擊“診斷分析”按鈕，就可以逐條去做相應(yīng)的分析了。用戶當(dāng)時急迫想要獲得的就是一個結(jié)論。

D-SMART也提供了一系列診斷工具用于分析，現(xiàn)場的DBA點擊了其中幾個工具，從中也發(fā)現(xiàn)了系統(tǒng)中存在的一些問題，包括TOP SQL，全局熱塊沖突，私網(wǎng)流量過大，PING延時過高等問題。不過以他的經(jīng)驗，無法判斷是SQL引起了問題還是系統(tǒng)出了其他問題。實際上領(lǐng)導(dǎo)等待的并不是這些問題分析，而是做一個決策，是不是重啟一下應(yīng)用，就能夠解決問題。要想很明確的回答這個YES OR NO，確實是需要一定的經(jīng)驗的，因此現(xiàn)場DBA根據(jù)這些分析結(jié)論并不能直接回答這個問題。

實際上，專家在從某一個診斷路徑往下下鉆分析的時候，并不一定是按照這張腦圖去遍歷問題的可能路徑的，會在中間產(chǎn)生跳轉(zhuǎn)，甚至重新啟動一個新的腦圖。而自動化運維工具要么通過籠統(tǒng)的異常檢測去做分析，要么就只能沿著知識圖譜，不斷通過臨近發(fā)現(xiàn)去掃描各種可能性。

如果分析工具寫的很死，那么覆蓋整個分析的邏輯就會十分復(fù)雜，而且缺乏靈活性，一旦系統(tǒng)狀態(tài)有些略微不同，就可能無法完成完美的分析。而如果考慮到充分的靈活性，將分析過程拆分為多個知識點，通過知識點之間的關(guān)聯(lián)發(fā)現(xiàn)來自動發(fā)現(xiàn)下鉆路徑，實現(xiàn)遍歷，就會把整個分析過程完全打亂，很難做到最終實現(xiàn)準(zhǔn)確的根因歸納。

這是因為我們最終要定位根因，從而輔助決策，而不是找到問題點。如果現(xiàn)場有專家支撐，或者有專家可以隨時快速響應(yīng)，那么找到問題點就足以定位根因了，而如果僅僅依靠現(xiàn)場運維人員，那么工具就需要有更準(zhǔn)確的結(jié)論。

解決這個問題的方法有二，最簡單的就是我前幾天說過的，把智能運維的最后一公里交給專家，這會大大降低智能運維工具的技術(shù)難度。只要我們能夠統(tǒng)一指標(biāo)標(biāo)準(zhǔn)，讓遠程的專家可以和現(xiàn)場運維人員，以及被運維的數(shù)據(jù)庫系統(tǒng)都用同一種語言進行對話，就可以構(gòu)建一個完美的運維體系。

專家不需要到現(xiàn)場采集和分析數(shù)據(jù)，僅僅利用智能化運維工具產(chǎn)生的報告就可以十分快速的幫助現(xiàn)場人員定位問題，這樣可以實現(xiàn)7*24的專家快速介入，并實現(xiàn)高質(zhì)量低成本的分析定位。

當(dāng)然我們有更高的目標(biāo)，那就是提升運維診斷工具的智能化分析能力。要想實現(xiàn)通過靈活組合的知識點分析，同時確保問題收斂與推理獲得合理的結(jié)論。在軟件實現(xiàn)上，我們就不能完全采用樹狀的發(fā)散結(jié)構(gòu)了。必須首先把影響RAC性能的因素進行扁平化分解，將其分解為多個同一級別的檢測點。如果運維知識分解到了這個粒度，那么每個檢測點都會發(fā)現(xiàn)一些標(biāo)準(zhǔn)的狀態(tài)異常，比如熱塊沖突，比如網(wǎng)絡(luò)故障等。

最終根據(jù)這些異常的匯總，就可以得到一個問題發(fā)現(xiàn)的組合體。再根據(jù)這個組合體進行問題收斂與歸類，進一步定位問題根因。目前D-SMART中的智能指標(biāo)分析的實現(xiàn)方式與此類似，不過智能指標(biāo)分析面向的范圍太廣，因此根因收斂只能到達一個范圍，而無法十分精準(zhǔn)。而針對某個具體問題的根因歸類要簡單的多，發(fā)現(xiàn)的問題類目也會比較集中，也會更加具體，因此根因定位也可以做到更為精準(zhǔn)。比如今天這個RAC問題，無外乎網(wǎng)絡(luò)過載、網(wǎng)絡(luò)故障、TOP SQL、事務(wù)與鎖沖突、數(shù)據(jù)維護、數(shù)據(jù)庫參數(shù)配置等幾個方面。

采用這個方法必須對某個問題的分析十分透徹，主要分析要素都已經(jīng)被很好的歸納了。相當(dāng)于把一個專家腦子里的分析模型都已經(jīng)做了高度抽樣，這樣再輔助一些驗證算法，讓最終的診斷結(jié)論接近于專家分析就有可能了。要實現(xiàn)這樣的分析，首先需要構(gòu)建一個分析某個問題的指標(biāo)集，然后構(gòu)建分析問題的知識點集合，同時定義出問題發(fā)現(xiàn)的類型集合。以及根因收斂的規(guī)則圖譜。有了這些基礎(chǔ)，自動化根因定位就具備條件了。

采用上面的方法實現(xiàn)精準(zhǔn)分析，針對某些關(guān)鍵問題還是可以實現(xiàn)的。不過需要有運維專家參與算法的設(shè)計，而且一個專家不可能覆蓋很廣泛的知識面，因此要想建成一個覆蓋面廣的，能夠精準(zhǔn)分析的運維自動化系統(tǒng)，必須依賴生態(tài)。通過生態(tài)，發(fā)現(xiàn)更多的故障模型，通過生態(tài)，更快速的完成知識圖譜的建設(shè)，依靠生態(tài)，可以對工具進行驗證，從而更快速的迭代提升工具的能力。