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

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

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

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

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

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

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

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

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

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

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

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

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

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

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