-
故障管理
鎖定
- 中文名
- 故障管理
- 外文名
- Incident Management
- 簡 稱
- IM
故障管理目標
故障管理的目標是儘快恢復正常的服務運營,將組件失敗對業務所造成的負面影響降到最低,從而確保滿足事先與業務客户之間所約定的服務級別的目標和服務級別質量。
實踐中需要基於業務的戰略,來制定IT的服務級別的目標和服務質量要求。許多服務商基於自身的資源配置和交付能力來制定服務級別目標,這樣做的結果是這些服務並不滿足業務的需求,最終導致的結果就是業務與IT矛盾劇增。所以服務的價值需要從客户的角度出發來進行定義。這些質量要求可以是與服務相關的任何要素,通過服務級別管理在服務級別協議(Service Level Agreement,SLA)中進行約定。
[2]
故障管理內容
故障管理的內容包括故障發現和歸一化處理、故障呈現、故障隔離、故障修復和故障的存儲與查詢。
根據告警的嚴重程度可以將告警等級分為以下級別:
①嚴重故障:急待解決的故障,否則子網或設備將無法運行。
②重要故障:設備不能完成其主要功能,影響到部分業務的提供。
③次要故障:設備不能完成其主要功能,但未對其他子網或設備造成影響。
④警告:設備發生局部故障,使其性能降低,但未影響主要業務功能。
⑤已清除。
⑥不確定。
(2)故障呈現:應有圖形、故障列表、聲音等多種呈現方式。對於不同的故障級別能以不同的顏色顯示。一般情況下,以綠色表示正常,淡藍色表示已清除,深藍色表示不確定,黃色表示警告,橙色表示次要故障,粉紅色表示重要故障,紅色表示嚴重故障,灰色表示脱離管理。應支持管理人員對故障顏色的定製。
(3)故障隔離:應提供故障診斷和綜合分析功能,根據採集到的告警信息,進行故障的診斷和綜合,確定最終故障點或故障的原因。最後通過遠程參數設置進行故障隔離。
(4)故障修復:對可修復的故障,進行人工修復;對不可修復的故障,可重新分配該故障區域的參數設置。
故障管理體系結構
目前多個組織都在對故障管理體系結構進行積極開拓研究,並開發相關標準用於規範故障管理系統的設計和開發工作。例如,北大兩洋公約組織(NATO)在其2005年發佈的標準STANAG 4626“模塊化開放式航空電子結構”,從宏觀和微觀兩個層面規範了故障管理,在宏觀層面,由頂層體系結構ASAAC(00—78)提出了一體化的故障管理需求、原則和框架,在微觀層面,ASAAC(00—76)規範了通用功能模塊(CFM)的可測試設計,ASAAC(00—74)規範了層次化的健康管理軟件結構。ARINC653標準在應用程序接口方面規範了一套健康監控接口。
[4]
故障管理使用工具
開發或選擇什麼樣的工具,依賴於網絡管理的需求和具體的網絡環境。
1.簡單工具
最簡單的工具可以指出故障的存在但不能指明其發生的原因。例如,一個簡單的工具可以將ICMP Echo消息發送給計算機網絡上的每一個主機和設備以測試其IP網絡層的連通性。如果網絡沒有使用TIP/IP,可以使用一個程序反覆試圖連接每一個主機和設備的方法來完成同樣的測試。工具可以標出每一個失敗的連接,併為進一步的查詢提供了依據。
2.複雜工具
如果網絡上的主機和設備足夠複雜到可以報告網絡事件,就應該開發一個複雜的工具來利用這種能力。當通過記錄網絡事件或通過查詢檢測到一個故障時,這個工具將及時通知給你。同時,通過關鍵網絡事件也可以幫助分離故障發生的原因。
3.高級工具