事故管理流程圖 — Excel
事故管理流程是服務團隊為復原一項被中斷的 IT 服務所依循的次序：偵測並登記事故、判定優先次序、診斷與升級、修復並復原、與用戶確認，最後結案。
喺 Excel 每行記錄一個步驟，填寫獨立編號、說明、下一步同負責人。 事故管理流程是服務團隊為復原一項被中斷的 IT 服務所依循的次序：偵測並登記事故、判定優先次序、診斷與升級、修復並復原、與用戶確認，最後結案。
簡而言之
- 四條泳道，每一個步驟都有具名負責人：報告人／用戶、服務台、事故經理，以及二線／三線支援，橫跨由偵測到結案的五個階段。
- 偵測與登記：偵測到或收到事故報告先進入登記事故並記錄影響詳情，然後才開始分流，因此工單本身就帶有受影響服務、波及範圍和徵狀。
- 分類與優先次序判定，隨後是是否為重大事故？決策，其是分支在事故經理泳道中執行宣佈重大事故和開啟應急會議並通知持份者，然後才匯回技術工作。
來源資料表: 事故管理流程圖
喺 Excel 每行記錄一個步驟，填寫獨立編號、說明、下一步同負責人。 事故管理是在出現故障之後盡快恢復正常服務的流程。它的目標被刻意收窄：讓用戶重新開始工作。找出並永久消除底層原因屬於問題管理，本流程把這部分工作移交出去，而不是把它吸收進來。正是把這條界線維持清晰，才令服務台不會為了讓工程師追查根本原因而把工單一掛就是好幾個星期。
將說明對應 Box text、目的地對應 Line to、分支名稱對應 Line text、負責人對應 Vertical lane。 多數事故流程失敗在交接處，而不是在技術工作上。工單被登記時缺少足夠的影響資訊，無法據此判定優先次序。重大事故遲了二十分鐘才被識別，因為沒有人事先約定觸發條件。升級到二線的工單無人認領。SLA 目標被錯過，而客戶是在事後而不是事前才聽說。工單憑工程師一句話就被結案，用戶並沒有確認服務確實可用。把流程畫成泳道，能令每一處交接都可見，並為它指定一位負責人。 對照資料表，逐一檢查圖中所有分支同負責人。 亦可參閱 /yue/guides/點樣整理-excel-流程圖資料.
運作方式
把泳道改成你們真實的角色
喺 Excel 每行記錄一個步驟，填寫獨立編號、說明、下一步同負責人。 把報告人／用戶、服務台、事故經理和二線／三線支援換成你們機構中真實存在的角色。小團隊常把事故經理併入服務台泳道；設有 NOC 的團隊會在報告人之上增加一條監察泳道。
界定你們的優先次序矩陣
將說明對應 Box text、目的地對應 Line to、分支名稱對應 Line text、負責人對應 Vertical lane。 把你們對影響程度和緊急程度的定義附在分類並設定優先次序步驟上。寫清楚 P1 到 P4 分別在受影響用戶數和業務影響上意味著甚麼，令優先次序是推導出來的，而不是每張工單都要重新商議。
訂定重大事故的觸發條件
分享前沿住一般路徑、拒絕路徑同迴圈逐一檢查圖表。 決定甚麼情況會令是否為重大事故？得到是：某項影響收入的服務中斷、某個具名的關鍵系統、某個客戶數量門檻。指明誰有權宣佈，以及宣佈之後隨即會發生甚麼，例如開啟應急會議並展開固定頻率的通報。
應避免的錯誤
缺少連線
每一步有清楚目的地、每個決定有命名結果，工作清單先會成為流程圖。 編寫或更新服務台操作手冊，令新入職的前線人員一眼看到工單會走向哪裡、每個階段由誰負責。
常見問題
可唔可以用自己嘅 Excel 檔案？
可以。將欄位對應 QueryChart 工作表編輯器，改動資料列之後再核對目的地。 事故管理復原服務。問題管理消除原因，令事故不再復發。兩者運行在不同的時鐘上：事故按分鐘或小時對照 SLA 量度，而一份問題記錄可以為了調查而開放數星期。在本圖中，兩者在結案處連接——根本原因是否仍未知？提出一份問題記錄，同時並不令事故繼續掛著。把兩者混在一起是最常見的失敗，其表現就是用戶早已恢復工作、工單卻仍然長期開放。
甚麼時候應當把一次事故宣佈為重大事故？
當影響大到值得打破正常隊列時：某項業務關鍵服務不可用、一大批用戶被阻塞，或者存在安全、財務或聲譽方面的暴露。觸發條件應當在你需要用到它之前就寫下來，並且客觀到一線人員在凌晨兩點也能套用。一經宣佈，流程會改變形態，而不只是加快速度。一位具名的事故經理接過責任，應急會議開啟，並且不論是否有新進展，都按固定節奏向持份者發出通報。
當一次事故即將違反 SLA 時會發生甚麼？
違約分支是一次層級升級，而不是技術升級。工作仍在繼續，但事故經理被拉進來重新調整與客戶的預期、在必要時重新調配資源，並記錄目標為何未能達成。關鍵細節在於時機：這條分支應當在時限過去之前觸發，依據的是諸如剩餘時間已用掉百分之七十五這樣的門檻，好令與客戶的溝通發生在違約之前，而不是事後的一句道歉。