如何建立事故管理流程
如何設計一條由嚴重程度決定其後一切的事故管理流程：先分類後診斷，把重新定級畫成一條路徑，並把成因交給另一份紀錄。
事故管理流程沿着一條按事故嚴重程度而定的路徑恢復服務，然後在服務回復之後，把成因這個仍未有答案的問題，交給一份獨立的問題紀錄。
簡而言之
- 優先級由登記時填的欄位算出來，而不是由事故給人的感覺定出來。
- 所有事故走同一條路徑，對小事太重，對大事又太靜。
- 事故中途調升或調低嚴重程度，需要自己的一條路徑，而大多數圖表都漏了它。
- 恢復服務與解釋成因是兩條流程，中間有一次交接。
- 結案需要的是報告人的確認，而不是工程師的自信。
嚴重程度不是一個欄位，它就是流程
事故管理先恢復服務，然後交代發生過甚麼。大多數機構第一次畫出來的版本是一條單線——登記、診斷、修復、結案——而它同時在兩個方向上失效。對於那台沒有人接得通的打印機，它太隆重，於是大家索性不開工單，直接打電話給同事；而對於那次本該把三個人叫醒的服務中斷，它又安靜得太過分。
優先級是在任何人知道哪裡壞了之前，由影響與緊急程度定出來的，而其後一切的規模都由這一個判斷決定：誰會被叫起身、相關方多久聽到一次消息、修復要對着哪一個時鐘計算。分類因此是承重的一步，而它是在資料不齊全的情況下作出的——所以它有時會錯，這也意味着重新定級應該以一條畫出來的路徑出現在圖上，而不是悄悄改一個欄位。
示例把一宗事故分佈在五個階段、四條泳道之中，而最值得盯着看的一列是「調查並診斷」：一宗已宣告的重大事故，和一張一線修不好的工單，都會落進同一個方框。嚴重程度決定的是誰被召集、哪個時鐘在跑，而不是最終由誰去做診斷——這是這張圖在比例上誠實的界線。另外請留意，「根本原因是否仍未明？」對每一個嚴重程度都只在同一個地方問一次，這正是 P1 與 P4 留下同樣證據的原因。
一個嚴重程度判斷，決定其後一切
留意「是否重大事故？」在任何人開始診斷之前就已經定下多少事：一條指揮通話線、一次相關方通報，以及擁有權換了一條泳道。
工單太單薄就會定錯級
登記只有兩列：「發現或報告事故」和「登記事故並記錄影響」。優先級所依據的一切都在第二列採集——受影響的服務、影響多少人、何時開始、有甚麼徵狀——所以一張單薄的工單不是拖慢分類，而是令分類失真。
嚴重程度決定其後的規模
「是否重大事故？」的「是」出口，並不是同一條路徑的加大音量版：「宣告重大事故」和「開通指揮通話並通知相關方」都發生在任何人開始診斷之前，擁有權亦由服務台移交到事故經理那條泳道。「否」那一臂在下一階段接上。
兩條通往恢復的路徑
「一線是否已解決？」令小事保持簡短：它的「是」出口通往「執行一線修復」。其餘的匯入二線／三線支援泳道，那裡的「是否在 SLA 目標內解決？」是在診斷之後才問的——所以「升級逾時並向相關方通報」所報的逾時，已經來不及預防。
重開會略過分類
「用戶是否確認已解決？」的「重開」出口，重新進入「進行初步診斷」，而那一列在嚴重程度判斷之下——所以一宗重開的事故會被再診斷一次，卻永遠不會重新定級，無論第二次失效到此為止已經付出多少代價。「建立問題紀錄」是成因離場的地方。
運作方式
先寫優先級矩陣，後畫圖
優先級是影響對緊急程度，而兩者都需要訂明等級：影響多少用戶、屬於哪一級服務、是否牽涉金錢或安全、損害擴大得多快、有沒有可用的替代做法。這些要先議定，因為一份在畫圖過程中臨時發明的矩陣，描述的是上一宗事故，而不是下一宗。
決定重大事故到底改變了甚麼
列出這項宣告換來甚麼：一位指定負責人、一條指揮通話線、按固定時鐘發出的更新、繞過正常變更審批的授權。如果除了標籤之外甚麼都沒有改變，這條分支就只是裝飾。示例在它上面花了整整兩個步驟，而這正是它實際牽涉的工作量。
把登記與分類輸入成列
在 QueryChart 裡每一列就是一個方框。把觸發事件填進「方框文字」欄，然後是登記那一步、分類那一步，再在「連線至」欄裡讓每一列指向下一列。三列之內，這張圖已經把它的論點講完了：第 3 列的優先級，是由第 2 列採集到的東西算出來的，而這令第 2 列成為一項設計決定，不是一張表格。
把嚴重程度判斷分叉，兩個出口都加標籤
把分類那一列的「形狀」欄改成「決策」，在「連線至」列出兩個去處，然後在「連線文字」裡為每個號碼填上它的答案。這張圖只分叉一次，就在「是否重大事故？」，儘管矩陣有四至五級——而這兩個標籤所做的事，比這裡任何一對標籤都多，因為它們是路徑唯一改變的地方。
把重開路徑指向一個較小的列號
一次被報告人否決的修復會回到診斷：第 15 列的「重開」出口指向第 7 列。定錯了的嚴重程度需要同樣的處理，而示例並沒有畫出來——請由診斷那幾列加一條分支回到「分類並設定優先級」。兩者都是「連線至」欄裡一個較小的號碼。
校準矩陣，然後指名由誰宣告
把矩陣放在開工單的人看得到的地方，然後測試它：把同樣三段描述交給輪不同更份的兩個人，比較他們定出來的級別。不一致代表少了一個等級，而不是同事馬虎。然後為每一更指名一個人，讓他在事故經理還未睡醒之前，可以在「是否重大事故？」回答是。
應避免的錯誤
診斷之後才分類
到那個時候，本來重要的那次升級已經沒有發生，而優先級欄位記下的只是事情最終有多嚴重。影響與緊急程度在成因之前就答得出，這正是分類那一列排在第三的原因。
一出世定下的嚴重程度
影響會擴大，優先級卻不會。它在服務台那條泳道裡定下一次，就固定了召集名單和時鐘，而這張圖唯一那條回頭路，重新進入的位置又在它之下。請把重新定級畫成一條路徑，並指名誰可以走。
用開新工單來重開
原本那張在目標之內結案，第二張開始跑一個全新的時鐘，於是報表上顯示的是兩次快速修復，而不是一次失敗的修復。請把重開畫成在同一份紀錄上回到診斷。
沒有負責人的問題紀錄
「建立問題紀錄」是一列，不是一個結果。一份沒有負責人、沒有日期、也沒有連回產生它的那些事故的紀錄，只是結案文書，到下一次清理時就會在沒有人讀過的情況下被關掉。開立時請把兩者都指名。
建立你們自己的事故流程
把事故示例開啟為你們自己的圖表，把你們的嚴重程度門檻放上分類那一列，並把候命角色填進泳道。
相關指南
常見問題
事故與問題有甚麼分別？
事故是服務的一次中斷；問題則是一宗或多宗事故背後的成因。兩者被保持為獨立的流程，是因為它們跑着不同的時鐘——事故管理量度的是恢復所需的時間，問題管理量度的是成因究竟有沒有被清除，而那可能要花上幾個星期。把兩者合併，成因這部分工作就會繼承事故的緊急程度，並在服務一回復的那一刻被放棄。
怎樣決定事故的優先級？
由公布過的矩陣上的影響與緊急程度決定，而不是由誰在問決定。影響是機構受波及的範圍：多少用戶、多少地點、屬於哪一級服務、是否牽涉金錢或安全。緊急程度是損害擴大得多快，以及有沒有可用的替代做法。矩陣把這一對轉換成一個優先級，而它要站得住腳，前提是判斷背後的數字與它一併記錄下來——一個沒有人重構得出來的優先級，在事後證明定錯了的時候也無從質疑。
甚麼時候應該把一宗事故宣告為重大事故？
當它越過一條事先議定的門檻——一級服務中斷、訂明數目的人無法工作、有監管或安全上的風險敞口、懷疑發生資料外洩。這項宣告要站得住腳，前提是它改變行為：一位指定的事故經理、一條指揮通話線、按固定節奏發出的更新。宣告得太遲是常見的失誤，而宣告之後再解除的代價，遠低於一小時安靜的代價。
重開的事故應該另開一張工單嗎？
不應該——請重開原本那一張，因為兩份紀錄回答的是不同的問題。新開一張工單會重設解決時鐘，並把一次失敗的修復報成兩次成功的修復，而這正正是掩蓋服務不穩定的那種失真。在同一份紀錄上重開，可以把歷史保存在一個地方，並令重開率變得可以量度；而重開率是事故流程所能產出的、最誠實的品質訊號。
