事故管理流程圖
跨職能的事故管理流程圖，涵蓋事故登記、優先次序判定、重大事故升級、SLA 違約預警、修復復原、用戶確認結案與問題記錄移交。
甚麼是事故管理流程
事故管理是在出現故障之後盡快恢復正常服務的流程。它的目標被刻意收窄：讓用戶重新開始工作。找出並永久消除底層原因屬於問題管理，本流程把這部分工作移交出去，而不是把它吸收進來。正是把這條界線維持清晰，才令服務台不會為了讓工程師追查根本原因而把工單一掛就是好幾個星期。
多數事故流程失敗在交接處，而不是在技術工作上。工單被登記時缺少足夠的影響資訊，無法據此判定優先次序。重大事故遲了二十分鐘才被識別，因為沒有人事先約定觸發條件。升級到二線的工單無人認領。SLA 目標被錯過，而客戶是在事後而不是事前才聽說。工單憑工程師一句話就被結案，用戶並沒有確認服務確實可用。把流程畫成泳道，能令每一處交接都可見，並為它指定一位負責人。
本範本把流程畫在四條泳道上：報告人／用戶、服務台、事故經理，以及二線／三線支援。它包含了團隊在自身文件中最常遺漏的兩條分支——重大事故宣佈和 SLA 違約升級——還有一條在用戶表示問題依舊存在時使用的重開迴路，以及一條在原因仍然未知時提出問題記錄的結案分支。
本流程圖涵蓋的內容
本範本包含
- 四條泳道，每一個步驟都有具名負責人：報告人／用戶、服務台、事故經理，以及二線／三線支援，橫跨由偵測到結案的五個階段。
- 偵測與登記：「偵測到或收到事故報告」先進入「登記事故並記錄影響詳情」，然後才開始分流，因此工單本身就帶有受影響服務、波及範圍和徵狀。
- 分類與優先次序判定，隨後是「是否為重大事故？」決策，其「是」分支在事故經理泳道中執行「宣佈重大事故」和「開啟應急會議並通知持份者」，然後才匯回技術工作。
- 一線與升級的分岔：「一線是否已解決？」要麼走向「實施一線修復」，要麼把工單交給二線／三線進行「調查與診斷」。
- SLA 違約路徑：「是否在 SLA 目標之內解決？」的「否」分支通向「升級違約並向持份者通報」，令客戶在時限耗盡之前得知，然後返回「實施修復並復原服務」。
- 用戶確認與結案，包括由「用戶是否確認已解決？」回到初步診斷的重開迴路，以及一條在「根本原因是否仍未知？」時提出問題記錄、再進入「事故結案」的分支。
何時使用本範本
- 編寫或更新服務台操作手冊，令新入職的前線人員一眼看到工單會走向哪裡、每個階段由誰負責。
- 提前約定重大事故的觸發條件和升級時限，而不是在故障發生時臨場發揮。
- 設定 ITSM 工具：圖中的分類、優先次序矩陣、SLA 計時器和升級規則，可以直接對應到你需要設定的欄位。
- 令小團隊與 ITIL 實務對齊，而不必全盤採用它的術語，改用人們真正會說出口的步驟名稱。
- 對流程本身做事後檢討，對照預期路徑追查某一張具體工單究竟是在哪裡卡住的。
運作方式
把泳道改成你們真實的角色
把報告人／用戶、服務台、事故經理和二線／三線支援換成你們機構中真實存在的角色。小團隊常把事故經理併入服務台泳道；設有 NOC 的團隊會在報告人之上增加一條監察泳道。
界定你們的優先次序矩陣
把你們對影響程度和緊急程度的定義附在「分類並設定優先次序」步驟上。寫清楚 P1 到 P4 分別在受影響用戶數和業務影響上意味著甚麼，令優先次序是推導出來的，而不是每張工單都要重新商議。
訂定重大事故的觸發條件
決定甚麼情況會令「是否為重大事故？」得到「是」：某項影響收入的服務中斷、某個具名的關鍵系統、某個客戶數量門檻。指明誰有權宣佈，以及宣佈之後隨即會發生甚麼，例如開啟應急會議並展開固定頻率的通報。
接上你們的 SLA 目標與違約升級
把你們的應答和解決目標放在「是否在 SLA 目標之內解決？」決策上，並寫明違約分支上通知誰、提前多久通知。這條分支的意義在於提前預警，而不是事後報告。
約定結案與問題管理的規則
界定甚麼算作用戶已確認、工單在「已解決」狀態下多久之後自動結案，以及「根本原因是否仍未知？」上把事故推入問題管理的判定準則。反覆出現的徵狀和每一次重大事故是常見的觸發條件。
與每條泳道走一次，然後發佈附版本的副本
與每條泳道中的人一起檢視這張圖，修正他們實際執行的步驟。達成一致之後，把它作為當前版本發佈並附上簽署確認，這樣日後讀到它的人就知道當時生效的是哪一版。
常見問題
事故管理和問題管理有甚麼分別？
事故管理復原服務。問題管理消除原因，令事故不再復發。兩者運行在不同的時鐘上：事故按分鐘或小時對照 SLA 量度，而一份問題記錄可以為了調查而開放數星期。在本圖中，兩者在結案處連接——「根本原因是否仍未知？」提出一份問題記錄，同時並不令事故繼續掛著。把兩者混在一起是最常見的失敗，其表現就是用戶早已恢復工作、工單卻仍然長期開放。
甚麼時候應當把一次事故宣佈為重大事故？
當影響大到值得打破正常隊列時：某項業務關鍵服務不可用、一大批用戶被阻塞，或者存在安全、財務或聲譽方面的暴露。觸發條件應當在你需要用到它之前就寫下來，並且客觀到一線人員在凌晨兩點也能套用。一經宣佈，流程會改變形態，而不只是加快速度。一位具名的事故經理接過責任，應急會議開啟，並且不論是否有新進展，都按固定節奏向持份者發出通報。
當一次事故即將違反 SLA 時會發生甚麼？
違約分支是一次層級升級，而不是技術升級。工作仍在繼續，但事故經理被拉進來重新調整與客戶的預期、在必要時重新調配資源，並記錄目標為何未能達成。關鍵細節在於時機：這條分支應當在時限過去之前觸發，依據的是諸如剩餘時間已用掉百分之七十五這樣的門檻，好令與客戶的溝通發生在違約之前，而不是事後的一句道歉。
由誰結案，甚麼才算已解決？
解決和結案是兩種不同的狀態。工程師在修復實施完畢、服務復原時把事故標記為已解決。只有當報告人確認服務對他們確實可用之後，事故才被結案——這正是本圖在結案之前要經過報告人泳道中的「確認服務已復原」和「用戶是否確認已解決？」決策的原因。如果用戶表示問題依舊存在，工單會重開回到初步診斷，而不是新開一張。多數團隊還會設定一個自動結案窗口，通常是三至五個工作天沒有回覆。