ITIL定義了故障管理流程中的關鍵活動，如下所示:

ITIL定義了故障管理流程中的關鍵活動，如下所示:
 
●故障識別和記錄
 
●分類和最初支持
 
●調查和診斷
 
●解決和恢復
 
●故障關閉
 
●故障所有權、監控、跟蹤和溝通



這個列表是有序的，在故障識別之前，什么都做不了，故障分類要在調查和診斷之前，只有經過最初調查之后，才可以執行解決和恢復，以此類推。我們完全同意，這個列表中列出的行動都是必需的，但如果你的組織不是由OGC嚴格管控的組織，而你也不需要OGC認證的證書，那么可以對這些活動的順序進行一些調整，這樣可以加速事件的恢復。首先，我們希望對上述活動提供一個簡化的定義。

所謂故障識別和記錄，就是識別出一個影響用戶或系統運營的故障，然后把它記錄在案。這兩個行動都非常重要，許多公司都有很多方法讓這兩個行動完成得又快又好。故障識別就是監控系統。你是否對客戶行為有監控，以便在發生第-一起客戶投訴之前就識別出問題?你衡量事情的方法是否與客戶采用的一樣?根據我們的經驗，在系統中試驗執行真正的客戶交易，并衡量一段時間內交易的結果和交易的響應時間是否符合預期(它們返回的數據對嗎?它們的操作時間是否像你預期的那樣快?)，這樣做非常重要。
 
成熟的監控框架 我們見過太多的客戶，實施的監控方案是為了告訴他們所面對的所有潛在問題的根本原因。這種實施方案聽起來很好，但很少是有效的。監控失 敗在很大程度上是由兩個問題造成的:
 
●他們嘗試監控的系統并未被設計為能夠監控的。

●公司并沒有以有計劃、有條理的方式實施監控。如果沒有把平臺設計為能夠監控的，那么就不應該期望能夠通過監控系統(或故障識別系統)正確地識別故障，設計良好的系統，會在代碼和系統中內置監控和故障通知的功能。例如，世界一流的實時監控解決方案具有把每個內部調用服務的時間和錯誤記錄在案的功能。這里所說的服務可能是調用數據存儲或另一個Web服務來顯示賬戶信息，等等。它還可以在控制面板上把所花費的時間、頻率和錯誤類型用一個統計性的進程控制圖實時地繪制出來，并突出顯示超出控制上限或控制下限的數據作為警告。

把系統設計為能夠監控的，雖然必要，但對于迅速地識別和解決故障還不夠。你還需要一個系統，能夠從客戶的角度識別事件，并識別出造成問題的背后系統。

可惜的是，太多公司都省略了從客戶角度監控系統這一步驟。需要構建或者組成一個能夠以與客戶同樣的方式與平臺進行交互的實時系統，執行最關鍵的交易。當系統的響應時間和可用性超出了內部制定的服務水平時，要給出警告。

接下來，要做的是幫助識別造成故障的系統。在理想狀況下，你設計的是一個故障隔離的架構，會創造出故障域，把故障隔離起來，這樣有助于你確認哪里發生了故障。如果沒有做到這一點，就需要一個監控系統，能夠指示大概要查看的區域。通常這是一個統計匯總系統，會統計負載、CPU或內存的使用情況。

要注意，我們的第一步不僅僅是識別故障，還要記錄故障。許多公司正確識別了故障后，在采取其他行動之前，卻沒有立即把它們記錄下來，或者根本沒有記錄問題的系統。最好的方法是有一個自動的系統，能夠立即記錄故障和它發生的時間，這樣可以讓操作員有時間執行流程剩下的操作。

在ITIL中，接下來的行動是對故障進行分類并提供最初的支持，但我們認為在許多公司中，這一步只不過是“讓正確的人參與進來”。據我們看，分類這一活動可以在故障解決之后再進行。調查和診斷之后是解決和恢復。簡而言之，這些步驟所做的就是識別什么服務發生了故障，沒有響應(調查和診斷)，于是我們立刻重啟了該服務器(解抉)，系統就恢復了(恢復)然后采取正確的步驟把該服務恢復回正常的運轉狀態。例如，這些步驟可能是確定了應用服務器跟進、溝通、跟蹤以及監控。故障關閉是把所有與故障相關的信息都記錄到日志中。最后的步驟包括指派個負責人繼續跟進。

對于小公同來說，不論有沒有采用ITIL.都可以采用它。在實施故障管理時，我們通常推薦采用一種易于記住的縮寫.雖然ITIL并不支持我這一縮寫是DRIER，它代表的是:

●通過監控或客戶反饋來識別(Delce)故障
 
●報告(Report)故障，或者把它錄入負責跟蹤所有故障和失敗等的系統中
 
●調查(Investigate)故障，決定應該做什么

●如果沒有及時解決故障，就是把它升級(Escalate)

●通過恢復最終用戶使用的功能并把所有信息記人日志以便跟進，從而解決(Resolve)故障決
在制定DRIER時，我們嘗試著讓客戶更容易理解如何才能有效地實施事件管理。需要注意的是，雖然我們在DRIER中刪除了故障分類這一步，但我們仍然希望能夠執行這些操作，以便從系統中獲取網站建設數據，有助于通知其他的流程。我們建議在故障管理每天的例會上進行這一分類操作。