故障管理的步驟
- 編輯：admin -ITIL定義了故障管理流程中的關(guān)鍵活動，如下所示:
ITIL定義了故障管理流程中的關(guān)鍵活動，如下所示:●故障識別和記錄
●分類和最初支持
●調(diào)查和診斷
●解決和恢復(fù)
●故障關(guān)閉
●故障所有權(quán)、監(jiān)控、跟蹤和溝通
這個列表是有序的，在故障識別之前，什么都做不了，故障分類要在調(diào)查和診斷之前，只有經(jīng)過最初調(diào)查之后，才可以執(zhí)行解決和恢復(fù)，以此類推。我們完全同意，這個列表中列出的行動都是必需的，但如果你的組織不是由OGC嚴格管控的組織，而你也不需要OGC認證的證書，那么可以對這些活動的順序進行一些調(diào)整，這樣可以加速事件的恢復(fù)。首先，我們希望對上述活動提供一個簡化的定義。
所謂故障識別和記錄，就是識別出一個影響用戶或系統(tǒng)運營的故障，然后把它記錄在案。這兩個行動都非常重要，許多公司都有很多方法讓這兩個行動完成得又快又好。故障識別就是監(jiān)控系統(tǒng)。你是否對客戶行為有監(jiān)控，以便在發(fā)生第-一起客戶投訴之前就識別出問題?你衡量事情的方法是否與客戶采用的一樣?根據(jù)我們的經(jīng)驗，在系統(tǒng)中試驗執(zhí)行真正的客戶交易，并衡量一段時間內(nèi)交易的結(jié)果和交易的響應(yīng)時間是否符合預(yù)期(它們返回的數(shù)據(jù)對嗎?它們的操作時間是否像你預(yù)期的那樣快?)，這樣做非常重要。
成熟的監(jiān)控框架 我們見過太多的客戶，實施的監(jiān)控方案是為了告訴他們所面對的所有潛在問題的根本原因。這種實施方案聽起來很好，但很少是有效的。監(jiān)控失 敗在很大程度上是由兩個問題造成的:
●他們嘗試監(jiān)控的系統(tǒng)并未被設(shè)計為能夠監(jiān)控的。
●公司并沒有以有計劃、有條理的方式實施監(jiān)控。如果沒有把平臺設(shè)計為能夠監(jiān)控的，那么就不應(yīng)該期望能夠通過監(jiān)控系統(tǒng)(或故障識別系統(tǒng))正確地識別故障，設(shè)計良好的系統(tǒng)，會在代碼和系統(tǒng)中內(nèi)置監(jiān)控和故障通知的功能。例如，世界一流的實時監(jiān)控解決方案具有把每個內(nèi)部調(diào)用服務(wù)的時間和錯誤記錄在案的功能。這里所說的服務(wù)可能是調(diào)用數(shù)據(jù)存儲或另一個Web服務(wù)來顯示賬戶信息，等等。它還可以在控制面板上把所花費的時間、頻率和錯誤類型用一個統(tǒng)計性的進程控制圖實時地繪制出來，并突出顯示超出控制上限或控制下限的數(shù)據(jù)作為警告。
把系統(tǒng)設(shè)計為能夠監(jiān)控的，雖然必要，但對于迅速地識別和解決故障還不夠。你還需要一個系統(tǒng)，能夠從客戶的角度識別事件，并識別出造成問題的背后系統(tǒng)。
可惜的是，太多公司都省略了從客戶角度監(jiān)控系統(tǒng)這一步驟。需要構(gòu)建或者組成一個能夠以與客戶同樣的方式與平臺進行交互的實時系統(tǒng)，執(zhí)行最關(guān)鍵的交易。當系統(tǒng)的響應(yīng)時間和可用性超出了內(nèi)部制定的服務(wù)水平時，要給出警告。
接下來，要做的是幫助識別造成故障的系統(tǒng)。在理想狀況下，你設(shè)計的是一個故障隔離的架構(gòu)，會創(chuàng)造出故障域，把故障隔離起來，這樣有助于你確認哪里發(fā)生了故障。如果沒有做到這一點，就需要一個監(jiān)控系統(tǒng)，能夠指示大概要查看的區(qū)域。通常這是一個統(tǒng)計匯總系統(tǒng)，會統(tǒng)計負載、CPU或內(nèi)存的使用情況。
要注意，我們的第一步不僅僅是識別故障，還要記錄故障。許多公司正確識別了故障后，在采取其他行動之前，卻沒有立即把它們記錄下來，或者根本沒有記錄問題的系統(tǒng)。最好的方法是有一個自動的系統(tǒng)，能夠立即記錄故障和它發(fā)生的時間，這樣可以讓操作員有時間執(zhí)行流程剩下的操作。
在ITIL中，接下來的行動是對故障進行分類并提供最初的支持，但我們認為在許多公司中，這一步只不過是“讓正確的人參與進來”。據(jù)我們看，分類這一活動可以在故障解決之后再進行。調(diào)查和診斷之后是解決和恢復(fù)。簡而言之，這些步驟所做的就是識別什么服務(wù)發(fā)生了故障，沒有響應(yīng)(調(diào)查和診斷)，于是我們立刻重啟了該服務(wù)器(解抉)，系統(tǒng)就恢復(fù)了(恢復(fù))然后采取正確的步驟把該服務(wù)恢復(fù)回正常的運轉(zhuǎn)狀態(tài)。例如，這些步驟可能是確定了應(yīng)用服務(wù)器跟進、溝通、跟蹤以及監(jiān)控。故障關(guān)閉是把所有與故障相關(guān)的信息都記錄到日志中。最后的步驟包括指派個負責人繼續(xù)跟進。
對于小公同來說，不論有沒有采用ITIL.都可以采用它。在實施故障管理時，我們通常推薦采用一種易于記住的縮寫.雖然ITIL并不支持我這一縮寫是DRIER，它代表的是:
●通過監(jiān)控或客戶反饋來識別(Delce)故障
●報告(Report)故障，或者把它錄入負責跟蹤所有故障和失敗等的系統(tǒng)中
●調(diào)查(Investigate)故障，決定應(yīng)該做什么
●如果沒有及時解決故障，就是把它升級(Escalate)
●通過恢復(fù)最終用戶使用的功能并把所有信息記人日志以便跟進，從而解決(Resolve)故障決
在制定DRIER時，我們嘗試著讓客戶更容易理解如何才能有效地實施事件管理。需要注意的是，雖然我們在DRIER中刪除了故障分類這一步，但我們?nèi)匀幌Ｍ軌驁?zhí)行這些操作，以便從系統(tǒng)中獲取網(wǎng)站建設(shè)數(shù)據(jù)，有助于通知其他的流程。我們建議在故障管理每天的例會上進行這一分類操作。