嚴重程度和優先級有什麼區別？IT 事件的影響度×緊急度矩陣怎麼用

先說結論： 嚴重程度（severity）描述一個事件有多嚴重；優先級（priority）決定事件處理的先後順序和響應速度。嚴重程度基本是對損害的事實判斷，優先級則是綜合影響度、緊急度和業務背景後的一個決定。大多數服務台用「影響度×緊急度矩陣」算出優先級，再允許指定的人在特殊情況下人工調整。

IT 服務台上有兩個詞，常常引起不必要的摩擦。客戶說問題「很嚴重」，工程師說「嚴重程度不高」，工單就在隊列裡躺著，而兩邊按各自的標準都沒說錯。原因是把嚴重程度和優先級當成了同一個旋鈕。它們回答的是兩個不同的問題，一套好的支援流程會把兩個問題都問一遍，並且都記錄下來。

本文用平實的話講清兩者的區別，說明影響度和緊急度矩陣怎樣把兩個簡單判斷變成優先級，並用一個公開的矩陣做示範。這個矩陣來自 博迅（Brocent）自己的 SLA 頁面，我們在 2026 年 10 月 28 日核對過。文中還有幾個情景實例、矩陣容易出錯的地方，以及一份可以直接改用的落地步驟，無論你是自建 IT 團隊，還是在評估管理型IT外判服務供應商，都用得上。

嚴重程度和優先級到底有什麼區別？

嚴重程度回答「有多嚴重」，優先級回答「先做什麼、多快做」。

嚴重程度描述問題本身的大小：什麼壞了，影響多少人或多少系統，數據、安全或收入有沒有風險。它通常在事件剛被弄清楚時確定，只有事實變了才會改，比如工程師發現故障範圍比最初看到的更大。

優先級描述處理的順序。它從同樣的事實出發，再加上時間和背景：有沒有截止時間，臨時辦法能不能接受，是不是月末，受影響的是一個人還是整個財務部。優先級在事件過程中可以升高或降低，而嚴重程度完全沒變。

可以這樣區分：

• 嚴重程度是診斷。 醫生可以說一處傷很重，卻還不知道候診室排了多少人。
• 優先級是分診順序。 順序取決於診斷，也取決於誰在等、有多少人手、每個病例有多急。

這兩個詞行業裡都在用，但用法並不完全一致。Atlassian 的事件管理指南（嚴重等級一頁，我們在 2026 年 10 月 28 日讀過）用 SEV 等級表示事件的嚴重程度：SEV 1 是影響非常大的嚴重事件，SEV 3 是影響較小的輕微事件；它同時強調，關鍵是理解自己的業務，選擇適合自己的嚴重等級和優先級定義。採用 ITIL 做法的服務台，則通常把「優先級」作為主字段，由影響度和緊急度推算出來。兩種用法都不算錯，要緊的是團隊把每個詞的含義寫下來，並且每次都用同一種方式。

為什麼要把嚴重程度和優先級分開？

如果兩者永遠一樣，就沒必要留兩個字段。但實際中它們經常不一致，合併後會出現真實的錯誤。

1. 嚴重的問題可以是低優先級。 一個可能擴散、但目前已被控制、有可用的臨時辦法、且要下週才會用到的系統故障，可以排進計劃變更窗口。
2. 輕微的問題可以是高優先級。 一個人登入不了只是小故障，但如果他一小時後要向客戶做演示，截止時間會改變處理順序，儘管故障本身沒有變嚴重。
3. 兩個字段的負責人不同。 懂故障的工程師通常判斷嚴重程度；懂業務期限的服務負責人或業務方判斷緊急度。只有一個字段，就等於讓一個人去猜另一半。
4. 報表需要兩者。 只記優先級，你分不清 P1 工單增多是基礎設施真的在出問題，還是大家學會了「喊急」。同時記錄嚴重程度，就能把這兩種情況分開。

什麼是影響度和緊急度？

影響度×緊急度矩陣由兩個輸入組成，它們都是對業務的判斷，而不是對技術的判斷。

影響度是影響的範圍：多少人、系統、辦公點或業務流程受到影響，受影響的程度如何。常見的寫法從「全公司」一直到「單個用戶，有臨時辦法」。

緊急度是時間壓力：影響會多快惡化，或業務多快需要服務恢復。同一個壞掉的系統，有明顯的臨時辦法時緊急度較低，在發薪日當天則很高。

ITIL 是最知名的一套 IT 服務管理實踐，業內普遍把優先級理解為這兩項的組合。我們這次沒有重新閱讀 ITIL 的付費出版物，所以這裡只當作通行做法來介紹，不作為原文引用。如果你的組織要圍繞 ITIL 建立正式流程，請以官方 ITIL 指南的措辭為準。

影響度分幾級、怎麼寫？

對大多數中小型組織，四級就夠了。措辭要讓服務台一分鐘內能判斷。

1. 關鍵影響： 全公司範圍或面向客戶的服務中斷，或者正在發生安全事件、數據丟失事件。
2. 嚴重影響： 一個部門、一個辦公點或一個重要系統不可用或嚴重降級。
3. 中等影響： 一組用戶或一個非關鍵系統受影響，工作可以降級繼續。
4. 輕微影響： 單個用戶，或只是外觀、低價值功能受影響。

緊急度分幾級、怎麼寫？

緊急度更難寫，因為它取決於時間。同樣用四級。

1. 關鍵： 工作現在已經停了，或一小時內會停，且沒有臨時辦法。
2. 高： 影響會在當天工作時間內惡化，或今天就有截止時間。
3. 中： 影響可以等幾天，或者有可用的臨時辦法。
4. 低： 沒有截止時間，影響也不會惡化。

影響度緊急度矩陣怎樣得出優先級？

矩陣就是一次查表：選定影響度，選定緊急度，讀出優先級。培訓教材通常把它畫成網格，所以很多人以為矩陣必須用表格。其實不必。它就是一組簡單規則，完全可以用標題和編號列表寫出來，本文就是這樣做的。

方法分三步：

1. 按上面的定義確定影響度。
2. 按上面的定義確定緊急度。
3. 查出交叉點，填入優先級字段。如果指定的人認為結果不對，可以人工調整，但必須記錄理由。

不少團隊還會加一條規則：提交工單的人不直接設定優先級，只描述影響和截止時間，由服務台套用矩陣。這樣就不會出現每張工單都標成「緊急」的情況。

公開的事件優先級矩陣長什麼樣？

博迅 把矩陣公佈在 SLA 頁面上，所以你能看到真實的矩陣，而不是編出來的例子。該頁面（我們在 2026 年 10 月 28 日核對）說明，優先級由業務影響度和緊急度組合決定，服務台在受理每張工單時套用這個矩陣。業務影響度分為關鍵（Critical）、嚴重（Serious）、中等（Medium）和輕微（Minor），緊急度分為關鍵（Critical）、高（High）、中（Medium）和低（Low）。

下面按影響度逐級寫出這份公開矩陣。

業務影響度為「關鍵」時

1. 緊急度關鍵，優先級 P1。
2. 緊急度高，優先級 P1。
3. 緊急度中，優先級 P2。
4. 緊急度低，優先級 P4。

業務影響度為「嚴重」時

1. 緊急度關鍵，優先級 P1。
2. 緊急度高，優先級 P2。
3. 緊急度中，優先級 P3。
4. 緊急度低，優先級 P4。

業務影響度為「中等」時

1. 緊急度關鍵，優先級 P2。
2. 緊急度高，優先級 P2。
3. 緊急度中，優先級 P3。
4. 緊急度低，優先級 P4。

業務影響度為「輕微」時

1. 緊急度關鍵，優先級 P2。
2. 緊急度高，優先級 P3。
3. 緊急度中，優先級 P3。
4. 緊急度低，優先級 P4。

有兩點值得注意。第一，緊急度可以在影響很小時把優先級拉上去：影響輕微但緊急度關鍵的事件是 P2，而不是 P4。第二，在這份矩陣裡，緊急度低就把一切封頂在 P4，因為沒有時間壓力，工作就可以排期。

同一個 SLA 頁面還列出了第五級 P5，用於根本不是故障的例行請求，比如新裝設備、離職處理或重置密碼。這些是服務請求而不是故障，所以不在影響度緊急度矩陣之內。

每個優先級對應什麼響應時間？

優先級只有帶著承諾才有用。同一個 SLA 頁面公佈了每一級的首次響應、遠程支援和上門或解決目標：P1 和 P2 的首次響應是 15 分鐘，P3 是 30 分鐘，P4 和 P5 是 60 分鐘。這些是首次響應時間，不是修復時間，而且取決於服務時段：標準的 8×5 時段是週一至週五、每天九個工作小時，高級的 24×7 時段則全天候。頁面也註明，響應時間以合約條款為準。

我們的 P1 響應時間是公開的，你在和任何人溝通之前，就可以在 SLA 頁面和管理型IT外判服務方案與按用戶收費上核對。想用大白話了解四個級別各自承諾什麼，可以讀我們的配套文章：IT 支援 SLA 裡的 P1 到 P4 優先級。

實例：嚴重程度和優先級並排看

下面的場景是示意，不是真實客戶案例。它們展示同一個矩陣怎樣處理不同情況，以及每種情況下嚴重程度和優先級怎樣不同。

1. 週一早上全公司電郵不可用。 影響度關鍵，緊急度關鍵，矩陣給出 P1。嚴重程度也在你所用等級的最高檔。所有人先處理它。
2. 月末前兩天，財務系統對財務部非常慢。 影響度嚴重，緊急度高，矩陣給出 P2。工程師可能把嚴重程度評為中等，因為系統還能用，但月末的截止時間把優先級抬高了。
3. 一位用戶在明天開會前打印不了。 影響度輕微，緊急度高，矩陣給出 P3。嚴重程度低，優先級處於中間位置。
4. 一個軟件許可下個季度要續期。 影響度輕微，緊急度低，矩陣給出 P4，工單排期處理。
5. 一台備用伺服器出了故障，但故障轉移正常。 工程師的記錄裡可能把嚴重程度評為嚴重，因為如果故障轉移也失效，問題會擴大。但今天的影響度是輕微、緊急度是低，矩陣給出 P4。於是預約一個變更窗口，嚴重程度仍然留在記錄裡。

第 5 個場景最能說明為什麼兩個字段都有價值。如果團隊只有優先級字段，記錄上只會寫「低」，風險就被忘掉了。

什麼時候應該人工調整矩陣的結果？

沒有矩陣能覆蓋所有情況。好的流程允許指定角色調整計算出的優先級，並要求寫明原因。合理的調整理由包括：

1. 安全信號。 一個行為像被入侵的帳號，可能值得比表面影響更高的優先級。
2. 固定的外部期限。 業務必須在某個時間前申報或交付時，要提高緊急度。
3. 重複出現的故障。 同一原因導致的五張 P4 工單，其實是一個更大的問題，應按問題記錄處理，而不是當作五個小事。
4. 臨時辦法失效。 臨時辦法不再管用，緊急度就變了，即使其他方面沒變。
5. 敏感崗位。 有些崗位，比如按固定時間處理付款的人，能容忍的中斷比單看人數要少。

人工調整要保持少見。如果有相當比例的工單被調整，說明定義本身有問題，應該重寫定義，而不是逐個修補。

怎樣落地一套優先級矩陣？

一個下午可以搭好，第一個月裡再慢慢改進。這套步驟適合任何規模的內部 IT 團隊，也是你應該要求管理型IT外判服務供應商展示的內容。

1. 用自己的話寫出四級影響度和四級緊急度的定義，每級配一個例子。
2. 把矩陣寫成列表，每個影響度一個標題，放在所有服務台人員都看得到的一頁上。
3. 給每個優先級配上響應目標，並寫明按工作小時還是按自然小時計算。
4. 確定誰可以人工調整，並要求在工單中寫明理由。
5. 如果想統計事件的嚴重程度，另設一個嚴重程度字段，並定義它的等級（例如三級或四級）。
6. 一個月後覆盤。查看被調整過或被重新打開的工單，修正定義。
7. 教提交人描述，而不是打分。給他們一份簡短的表單，問清楚什麼受到了影響、有什麼截止時間。

向 IT 服務商了解嚴重程度和優先級時該問什麼？

如果你採購管理型IT外判服務，合約裡會有優先級定義，而這些定義寫得好不好，能說明服務運作得怎麼樣。可以問：

1. 合約用的是哪些詞，嚴重程度和優先級是否分開？
2. 優先級由誰來設定，是提交人還是服務台？
3. 矩陣是否公開，簽約之前能不能看到？
4. 每一級的首次響應和解決目標是多少，適用哪些時段？
5. 誰可以調整優先級，理由是否記錄？
6. 每月怎樣把各優先級的情況彙報給你？

想了解怎樣把這些寫進合約，可以看我們的 24×7 服務台 IT 支援概述，或者聯絡我們聊聊你自己的服務級別。

常見問題

一句話說，嚴重程度和優先級有什麼區別？

嚴重程度衡量事件有多嚴重；優先級根據影響度、緊急度和背景，決定響應的順序和速度。

P1 就是 SEV 1 嗎？

不一定。兩者通常都代表各自等級的最高檔，但 SEV 等級一般描述嚴重程度，P 等級一般描述處理順序。有些團隊兩者共用一套等級。如果這樣做，要定義清楚並始終一致地使用。

什麼是影響度緊急度矩陣？

它是一條查表規則，把兩個判斷，即業務影響的範圍和時間壓力，合成一個優先級。可以畫成表格，也可以像本文這樣，用標題和編號列表寫出來。

工單的優先級應該由誰來定？

由服務台按約定的矩陣來定。提交人描述影響和截止時間。指定角色可以調整結果，理由要寫進工單。

需要幾個優先級？

四個事件級別，加上一個單獨的例行請求級別，對大多數組織已經夠用。級別太多會讓人猶豫，選擇也會不一致。

事件處理過程中優先級會變嗎？

會。影響擴大、臨時辦法失效或出現截止時間時，應當提高優先級並記錄變更。找到了臨時辦法，則可以降低。

ITIL 要求必須用影響度緊急度矩陣嗎？

ITIL 的指導通常把優先級描述為影響度和緊急度的函數，但它是一套實踐框架，不是必須原樣照抄的規則。請按自己的業務調整等級。

接下來讀什麼

想了解嚴重程度和優先級怎樣融入整個支援流程，可以讀我們關於 L1、L2、L3 支援分級和 IT 升級矩陣模板的文章。合約方面，請看 IT 支援裡的 SLA 是什麼意思。

*2026 年 10 月 28 日核對的來源：博迅 SLA 頁面（brocent.com/sla）；Atlassian 事件管理指南嚴重等級一頁（atlassian.com/incident-management/kpis/severity-levels）。*

想把這些指標寫進合約，而不是停留在簡報上？ 博迅的管理型IT外判服務方案把 SLA 和按用戶的月費並排公開，覆蓋香港、新加坡、中國大陸和美國。查看方案與收費，或聯絡顧問。