問題管理

基礎要點

通過調查分析，以確定事故的根本原因，通過制定變通方法，或是找到長期有效的解決方案，來減少事故的數量和影響。

變通方法：是一種為了減少事故發生的可能性與影響，在未找到完全解決方案事前的方法。變通方法需清晰地定義其適用的癥狀。

管理的三個階段：問題識別，問題控制和錯誤控制。

問題識別階段包括：根據記錄進行趨勢分析，檢查是否屬于重復或重現，識別重現的風險，從外部供應商與合作伙伴處收集信息并進行分析，從內部開發、測試、項目團隊處收集信息并分析。

問題控制階段包括：基于風險的潛在影響與可能性，進行優先級分析，文檔化變通方法與已知錯誤（經由分析尚未解決的問題）。

錯誤控制階段包括：定期評估已知錯誤的狀態，以及變通方法的有效性，根據成本、風險和收益觸發變更請求。

問題管理與其他管理實踐的關系：

問題管理是風險管理的特定案例；

問題管理可利用知識管理系統中的信息來開展調查、診斷和解決；

問題管理不包括實施，需要通過變更控制來啟動解決方案；

問題管理可被視為持續改進的一種實踐。

解讀

至此，ITIL 中有關事件、事故、問題三種管理的最佳實踐都已出現，為了理清它們之間的關系，我們一起對照著日常工作實際來比較一下：

1.事件（Event）

一般是指某種IT 服務或是被監控項到達了門限值，而引發的警告；或者是伴隨著某項操作所觸發的通知等。

例如，數據存儲的剩余空間小于已設定的百分比數值，對某個賬號的權限變更，或是用戶組的成員調整等。當然，正如我們在上面事件管理實踐中所討論過的那樣，事故也包括一些尚未產生影響的監控項異常。例如，在做了RAID 5 的磁盤組，有一顆磁盤出現了故障，但整體所提供的服務尚未中斷。

2.事故（Incident）

是指計劃外的IT 服務中斷，或是服務質量的驟降。

例如，由于專線出現問題，某個分公司失去了與總公司的網絡連接；或是某用戶利用公司內網觀看在線視頻，而拖慢了整體的內、外網訪問速度。

通常情況下，對于處理人員來說，能夠快速找到那些能夠所謂“能治標不治本”處置方法，可能會比花費更多的時間去研究癥結，更容易被用戶所接受和認可。

可見，對于事故的管理，我們主要是以止損、抑制不良影響、以及快速恢復為目標。

表4 問題跟蹤表格

3.問題（Problem）

如果說處理事故是利用應急措施，去盡快地恢復IT服務的話，那么解決問題則是通過查找根源，預防中斷的再次發生，以及對于那些經過分析仍無法解決的問題，通過變通方法來控制其影響的程度與范圍。相對于事故管理而言，它往往會涉及到更多的人員角色，也會耗費更長的時間。

例如，軟件開發部門協同運維部門一起，對其所發布的產品中所出現代碼的漏洞、以及不正確的配置進行安全加固，以消除攻擊隱患等。

因此，我們需要通過跟蹤那樣已知故障、診斷根本原因，引入變更控制，來防止同類問題在整個系統中的復發。

一般而言，由于問題管理主要致力于“治本”，因此企業可設立問題管理委員會來對問題的整個生命周期進行跟蹤與評估，其中涉及到的關鍵績效指標包括：

問題處置過程的平均耗時；

已確定根源、已解決、以及未關閉問題的占比；

問題解決所消耗的綜合成本；

管理前的數量與解決之后復發數量的對比。

實務

在本企業，為了留存在問題處理過程中產生的記錄，我們根據業界的處置標準，采用了如表4 所示的問題跟蹤表格。

根據上表，我們還制定了如圖2 所示問題管理的相關流程。

從管理的角度來說，上述流程的重點在于評估問題和分派問題：

1.在問題產生相關的通知之后，問題管理委員會根據該問題的特征和本團隊的經驗，對需要人工干預的問題進行二次判斷與評估。他們往往會參考我們在變更管理中提到的矩陣列表，對問題的影響范圍與程度，進行審查或修正。當然，他們也會參考技術人員的工作量和實際處理能力。

圖2 問題管理的相關流程

2.為了將合適的問題分派給合適的處置人員，我們會直接讀取系統目錄（如：Active Dictionary）里IT角色和相關的組群信息，甚至會在必要時，引入各部門進行聯動“會診”。另外，為了保證始終有人去接手問題，問題管理委員會通過自動化跟蹤，來確保如果被分派到的處理人員不在崗，或是無法勝任時，能夠升級到其所在的技術團隊。而如果某個問題超出了企業內部現有的處理能力，則需要添置相應的專業技術與工具，或是及時轉呈給外部資源，以尋求援助。