事故嚴重等級分級流程圖

甚麼是事故嚴重等級分級流程

事故嚴重等級分級，是把一份報告轉化為一個等級的那一步。有人讀取證據，套用一組事先約定的判定，得出 P1、P2、P3 或 P4，而下游的一切都以這個答案為準。一開始就把它與優先次序區分開是值得的，因為這兩個詞經常被混用，然後在事故當中被拿來爭論。嚴重等級描述的是影響，因而亦決定了你所欠的應變：誰被傳呼、是否開啟應急會議、多久向持份者通報一次。優先次序描述的是排序：團隊接下來拿起哪一件。嚴重等級依據證據評定，只有在證據變化時才變化；優先次序則可以每天早上重設一次，而不必有人重新打開影響評估。

本頁是一棵決策樹，而不是一張流程圖，這亦正是它單獨存在的理由。它回答一個問題：這次事故該定為哪個等級，以及誰有權決定——辦法是把七道判定串連起來，直到每條路徑都抵達一個具名的結果。它刻意止於等級被確定的那一刻。如果你需要的是那之後的端到端流程——工單如何在服務台、事故經理和各級支援之間被診斷、升級、解決、與用戶確認並結案——請使用 /yue/templates/事故管理流程 上的事故管理流程圖。用本圖來決定等級；用那一張來推進工作。

這裡的泳道命名的是決策權，而不是部門，而這恰恰是多數嚴重等級矩陣留作不言而喻的部分。服務台回答由報告中就能觀察到的內容：服務是不可用還是降級，以及有多少用戶或站點受到影響。服務負責人回答某項關鍵業務職能或收入路徑是否真的被阻塞。事故經理負責替代方案的判定、宣佈本身以及檢討。法律部門與合規只負責兩個問題，別無其他：是否存在資料或安全外露，以及是否有監管或合約的時鐘正在走。四條泳道足以了結「誰來決定」的爭論，而不必畫出一張組織架構圖。

本流程圖涵蓋的內容

本範本包含

• 四條決策權泳道，而不是一張部門圖（服務台、服務負責人、事故經理、法律部門與合規），橫跨五個評估階段：接報、影響範圍、業務影響、嚴重等級判定，以及結果與檢討。
• 開場的判定「服務是不可用還是降級？」有三個答案：「不可用」和「降級」繼續進入決策樹，而「無影響」隨即終止於「作為服務要求結案」，因此一項要求或查詢永遠不會被貼上嚴重等級。
• 範圍在業務影響之前評估：「受影響的用戶或站點有多少？」分為「多個站點」，直接走向宣佈 P1；「一個團隊」，交給服務負責人；以及「單一用戶」，仍然要檢查是否存在外露。
• 兩條獨立通往關鍵級的升級路徑：「關鍵職能或收入是否被阻塞？」接入「是否有可行的替代方案？」，其中「無替代方案」宣佈 P1，「有替代方案」定為 P2；以及「是否存在資料或安全外露？」，其中「存在外露」不論受影響用戶多麼少都宣佈 P1。
• 矩陣的低端由一個問題決定：「是否已啟動 SLA 或監管時鐘？」，把「P3 中等，追蹤期限」與「P4 低，排期處理」分開，而不是留給個人判斷；連同「P1 關鍵，應急會議進行中」「P2 高，修復進行中」以及作為服務要求結案的出口，全圖共有五個終點，另有一條明確的重新分級路徑——「下一次通報時影響是否變化？」把「影響擴大」送回宣佈 P1。
• 在關鍵決策上寫明的書面準則：不可用意味著甚麼、用戶數和站點數的門檻定在哪裡、甚麼才算可行的替代方案，以及為甚麼一次外露無論範圍大小都按關鍵級處理。

何時使用本範本

• 把團隊目前還在爭論的嚴重等級定義寫下來，好令凌晨三點分流同一次事故的兩個人，不必商議就能得出同一個等級。
• 設定一套把嚴重等級列為必填欄位的 ITSM 或當值工具，而你需要的是每個等級背後的判定，而不是一個只有四個選項、毫無指引的下拉選單。
• 在故障發生之前而不是在故障當中約定決策權：誰可以宣佈 P1、誰來確認資料或安全外露，以及誰有權重新分級。
• 檢討一次過去的事故，查核所定的等級是否與當時可得的證據相符——這與應變做得好不好是兩個不同的問題。
• 帶當值工程師和新的服務台前線人員入門，他們需要一頁紙看清那些問題、門檻，以及每個答案的落點。

運作方式

1. 把泳道改成你們真實的決策權

   把服務台、服務負責人、事故經理、法律部門與合規換成你們機構中真正握有每一項判定的角色。如果非辦公時間沒有人負責資料或安全這個問題，那是一個需要在重畫泳道之前先補上的更表缺口。

2. 把你們的範圍門檻寫到圖上

   打開「受影響的用戶或站點有多少？」，把說明換成你們自己對多個站點、一個團隊和單一用戶的定義：一個地區、一個客戶級別、活躍用戶的一個百分比、一份具名客戶名單。沒有寫下來的門檻，每次事故都會被重新商量一遍。

3. 為你們的服務界定不可用與降級

   逐個服務約定「不可用」意味著甚麼，包括部分可用的情況，例如唯讀模式、某個地區故障，或者隊列仍在接收工作但沒有在處理。這裡的含糊會令整棵樹整體偏移一個等級。

4. 誠實地訂定替代方案的判定

   決定甚麼樣的替代方案才算可行：有書面記錄、獲准使用、在產能之內，並且受影響的用戶今天就用得上。一個需要培訓、額外人手或政策豁免的人手做法不算替代方案，而把它當作替代方案，是 P1 被記成 P2 最常見的方式。

5. 為每個結果附上各不相同的應變承諾

   「P1 關鍵，應急會議進行中」「P2 高，修復進行中」「P3 中等，追蹤期限」和「P4 低，排期處理」每一個都應當帶有自己的傳呼規則、通報頻率和目標時間。如果兩個等級產生的行為完全相同，就把它們合併，而不是留著一個誰也分不清的等級。

6. 約定誰可以重新分級，並記錄理由

   「下一次通報時影響是否變化？」這一決策是更改等級唯一獲認可的途徑。指明誰可以走這條路，要求把各項判定重新跑一遍，而不是把等級拿來重新商議，並記錄新的證據和時間，好令事後檢討看得出情況是在甚麼時候改變的。

7. 把圖分發簽署並保留版本

   嚴重等級準則只有在是大家共同認可的那一套時才有用。把這張圖交給服務管理、各服務負責人和法律部門簽署確認，然後保留獲批版本，好令你們演練的定義就是你們發佈的定義。

常見問題

事故嚴重等級和事故優先次序有甚麼分別？

嚴重等級是一項關於影響的陳述：服務壞掉了多少、影響多少人、這擋住了甚麼。優先次序是一項關於排序的陳述：團隊接下來拿起哪一件。ITIL 其實並不把「嚴重等級」當作正式術語，它由影響程度和緊急程度推導出優先次序。許多工程和 SRE 團隊把嚴重等級當作影響那一半的簡稱，本圖亦是這樣使用它的。可操作的規則是：嚴重等級驅動你所欠的應變（傳呼、應急會議、通報頻率），而且只在證據變化時才變化；優先次序則驅動隊列，可以每天重設。為兩者各保留一個欄位，可以避免有人為了得到更快的服務而去重新商議影響評估。

這與事故管理流程圖有甚麼分別？

它們就同一個主題回答不同的問題。本圖是一棵決策樹：這次事故該定為哪個嚴重等級，以及誰有權決定。它是一串以具名結果結尾的判定，並在等級確定的那一刻立即停止。事故管理流程圖則是一張跨職能流程圖：接下來會發生甚麼、由誰來做，由登記一直到診斷、升級、解決和結案。多數團隊兩者都需要，而它們恰好只在一個點上連接，就是分派等級的那一步。流程版本位於 /yue/templates/事故管理流程。

我們應當設多少個嚴重等級？

四個是常見的預設做法，亦是本圖採用的數量，有些機構會在其上再加一個 P0 或 SEV0 用於生死攸關的事件。數量本身不及每個等級是否帶有各不相同的書面應變來得重要。如果 P3 和 P4 導致相同的傳呼規則、相同的目標時間和相同的通報頻率，那你實際上只有三個等級和一個用不上的標籤。少而一致地執行，勝過多而鬆散地執行，因為分級的價值就在於下游所有人都能據此行動而不必再問。

誰有權宣佈 P1？

提前指名角色，並把名單保持簡短。在本圖中，宣佈落在事故經理泳道，有三條分支匯入其中：多站點中斷、關鍵職能被阻塞而且沒有可行的替代方案，以及已確認的資料或安全外露。這個結構是刻意的，因為 P1 應當可以由多個方向的證據抵達，但應當由一個同時能夠調動應變的角色來宣佈。任何人都應當可以要求 P1；由一個具名角色來確認它。

資料或安全外露是否自動令一次事故成為 P1？

在本圖中是的，而且外露分支會完全繞過用戶數量判定。原因在於，一次外露啟動的時鐘是按知悉時刻而不是按解決時刻計算的，因此一次很小的事故亦可能承載很大的責任。在英國和歐盟 GDPR 之下，個人資料外洩必須在不當延誤的情況下、並在可行時於知悉後 72 小時之內通報監管機構，而通知受影響的個人是另一項與高風險掛鈎的判定。其他制度和合約各有自己的時限，客戶通知期限往往比法定期限更短，因此請把適用於你們的那些寫在決策方格上。許多機構還會把外露完全引出這棵樹，轉入保安事故應變流程。

嚴重等級確定之後，甚麼時候才應當更改它？

在證據變化時，而不是在壓力變化時。本圖為此只留了一條路徑，即「下一次通報時影響是否變化？」決策，其「影響擴大」分支把一個 P2 送回宣佈 P1。把各項判定重新跑一遍，而不是重新挑起爭論，並記錄新到的證據是甚麼、在甚麼時候到的。降級依循同樣的規則，亦值得明確處理，因為一次在影響已經消退之後仍停留在 P1 的事故，會悄悄訓練人們無視等級。