前言

根本原因分析Root Cause Analysis (RCA) 是用來定位出問題點與不正常情形的分析方法，簡而言之就是利用有系統的分析方式找出問題點的根本原因，避免該問題再重覆發生。

RCA在網路管理系統上 (NMS) 也是必需的，因為在網管系統上單純反應出目前設備的異常狀態對網管人員來說這樣的資訊是不夠的，因為這樣的異常狀態可能處於十分離散的狀態，網管人員可能要花相當多的時間才能找出真正問題點發生在那裡。

以圖一的scenario為例，當NMS監控到分別在三台switch上共六個logical port的異常狀態時，若NMS沒有RCA的功能，網管人員必須檢查全部異常switch上breakdown port的狀態才能追縱出真正的問題是出在那。

以圖一來說，因為switch1的card0 breakdown，導致card0上的port0、port1也breakdown，而bind在這些port上的logical port也跟著breakdown，進而導致與這些logical port相連接的switch0與switch2上的相關聯的logical port也跟著breakdown，若NMS沒有RCA功能，則網管人員則必須檢視全部異常switch上breakdown port的狀態才能追縱出真正的根本原因是發生在switch1上的card0 breakdown。

如何達到RCA有許多的做法，不同的做法會反應在分析效能與事件反應速度的差異上，在後面的章節會介紹EMC SMARTS的做法。

RCA Challenges

在深入探討RCA的做法之前必須先了解一些在實做RCA時必須面對到的問題與挑戰。

◎在網路環境中，問題點可能發生在任何邏輯或實體的網路元件上，而所謂的網路元件不單是指硬體設備，也可能是其上的系統或應用程式等。

◎一個單一的問題點發生時通常會引發多個symptoms(病徵)在與其相關聯的網路元件中，因此多個問題點發生時，可能會引發多個重覆的病徵發生，造成分析時的困難。

◎由第二點可以得知，symptoms是會增殖且傳播到相關聯的網路元件上，因此檢視所有相關元件上的病徵以鑑別出根本原因發生在何處是必須的。

◎發生於元件上的異常有時並不會產生任何顯著的事件，例如與這個異常相關聯的trap訊息等，這時就必需透過主動監控的方式來獲取這些病徵。

由此可以得知，檢視所有相關元件上的病徵以鑑別出根本原因發生在何處是必須的一個程序，而附有RCA功能的NMS只是將這個程序自動化，而不需網管人員參與到如此複雜的檢視流程。

既然檢視所有相關元件上的病徵以鑑別出根本原因的發生點是必然的程序，那麼如何將這個程序自動化就成了RCA實做的重點，直覺的想法是我們可以將一個根本原因與其病徵的比對用rules的方式去判斷，以圖一的scenario為例，我們可以將這個scenario轉換成下列的rules:



這樣的比對方式雖然方便，但在維護數量眾多的rules上，似乎並不是聰明的做法，因為擁有新病徵的問題點沒有辦法在第一時間被比對到，必須事後再新增rule，更麻煩的是，如果今天網路環境中新增了一個網路元件，例如新card，那麼與這個新card有所關聯的元件相對應的rule就必須全面改寫，新增與這個新card相連接的rule，在如今網路環境如此龐大複雜的情況下，很難用write rules這樣的方式來實做RCA。

EMC SMARTS

這裡我們將介紹EMC SMARTS的RCA方式，SMARTS是利用Code Book的方式來比對問題點的病徵，但是Code Book並不是一個可以獨立運作的模組，它必須與其它模組配合才能發揮出RCA的功效，因此在介紹Code Book之前我們必須先了解SMRATS的模組架構及整體運作流程。

一、模組架構



SMARTS的架構上分為三個層面、五個模組:

◎collection層：包含discovery模組用來搜尋網路元件及polling/pinging模組用來監控這些元件的狀態並主動或被動取得事件告警

◎context層：包含ICIM(The In charge Common Information Model) Library模組，這是系統中用來表現各個網路元件的information model，這些information不僅包含network、systems、applications、services、business entities還有一些複雜的relationships，context層還包含了一個ICIM Repository模組，用來顯示真實的網路環境。

◎Analysis層：包含Codebook模組用來實做RCA。

二、SMARTS運作流程

第一步:在ICIM Library Model中，定義我們想要納管的網路元件甚至是運作的protocol等，並將之模組化。

第二步:利用discover模組自動搜尋真實的網路環境。

第三步:利用discover搜尋出來的網路元件再配合ICIM Library，將抽象的網路環境實體化在ICIM Repository中，做一個視覺上的呈現。

第四步:根據ICIM Repository所呈現的網路元件、之間的關聯性及運作的通訊協定，Codebook模組會自動統計出所有病徵symptoms的總集合，並計算出那些病徵的出現會對應到那個問題點(如device、services、application…)。

第五步:polling/pinging監控系統會monitor網路環境，並收集所偵測到的病徵，並送到Codebook模組中比對出問題點，並利用ICIM Repository來顯示問題點所在。

Codebook

由前章節EMC SMARTS運作流程中可以看出，Codebook要能夠運作，還必須配合discovery模組、ICIM元件模組及監控模組，利用discovery收集元件資訊再配合ICIM讓Codebook能將病徵與問題點模組化成table型式。

有了問題點與病徵的對應關係後，監控模組會從網路環境中收集異常狀態的病徵，因為有Codebook做問題點的比對，因此異常狀態將不再會是離散的狀態，而且收攏到特定的問題點上，再經由ICIM Repository將問題點以使用者介面的方式呈現出來，可以讓網管人員快速的找出根本原因所在。



圖三說明了Codebook的比對方式，當監控模組收集到了網路環境中的病徵時會到Codebook中去比對這些病徵所對應到的問題點為何，注意，這裡的比對並不會是完全match的比對方式，因為在整個SMARTS的運作流程中，如果網路環境有異動時，因為discover模組與監控模組是並行運作，此時監控到的病徵並不一定來的及反應到ICIM Repository中，因此Codebook中的比對會自動計算最接近的問題點為何。

結語

雖然Codebook的運作方式是smart的，但是仍有許多問題要去克服，比如當網路元件增加時，問題點與病徵也會增多，此時就會增加比對的時間，而網路環境異動時，也必須update整個Codebook更新問題點與病徵的關聯性。
　　　　　　

參考資料

Root Cause Analysis (投影片資料)-Dr.Yuri Rabover EMC Smarts

High Speed and Robust Event Correlation
Shaula Alexander Yemini, Shmuel Kliger, and Eyal Mozes, System Management Arts (SMARTS)
Yechiam Yemini andDavid Ohsie, Columbia University