事件管理流程：從報障到關閉的完整步驟、角色和處理時限

簡短回答： 事件管理流程把一次服務中斷從報障到關閉按固定順序走完：發現並登記、分類、定優先級、診斷、解決、關閉。目標是盡快恢復正常服務，並把對業務的影響降到最低。每一步都要有負責人、轉入下一步的規則和時限，每張工單都要留下足夠的記錄，讓下一個接手的人不必再問一遍用戶。

本文寫給想建立或理順日常事件流程的中小企業 IT 負責人和服務台主管。讀完後，你可以寫出步驟、定好角色、設定時限，並使用工單模板。重大事件（少見的大範圍故障）有單獨的流程，見重大事件管理；本文講的是普通事件的完整生命週期。

甚麼是事件？

據維基百科對事件管理的概述（2026 年 10 月 28 日核對），ITIL 2011 把事件定義為：IT 服務的計劃外中斷、服務質素的下降，或尚未影響服務的配置項故障。同一篇文章說，該流程的目的是盡快恢復正常的服務運作，並把業務影響降到最低。

ITIL 4 於 2019 年 2 月發佈，把指引組織為實踐（practice）而不是流程，所以在 ITIL 4 裡你可能會看到它被稱為事件管理實踐；下面的步驟是服務台的常見做法，不聲稱與 ITIL 一致（2026 年 10 月 28 日核對）。

由此得出兩點：

1. 先恢復服務。 找出根本原因是另一個流程（問題管理）。事件可以用臨時解決辦法關閉。
2. 請求不是事件。 新員工電腦、權限申請屬於服務請求，走自己的流程。服務請求和事件的分別一文劃清了界線。

六個步驟

不同數據對步驟的數法不同，有五步、六步、七步，分別在於怎樣合併發現、登記和分類。實際順序是一樣的。選團隊記得住的那種分法即可。

第一步：發現並登記

目標： 每個事件都成為一張有編號的工單。

1. 接受所有渠道的報告：門戶、電郵、電話、聊天，以及監控的自動警報。
2. 首次聯絡時就建單，先建單再動手修。
3. 記錄誰受影響、甚麼服務、看到了甚麼（附準確的報錯文字或截圖）、何時開始、怎樣聯絡到對方。
4. 檢查是否重複或已知問題。如果已有故障工單，把新工單關聯上去。

負責人： 服務台（L1）。時限示例： 聯絡後數分鐘內登記。

第二步：分類

目標： 放進正確的類別，讓它到達合適的人手裡。

1. 從一份簡短固定的清單裡選類別和子類別，例如電郵、網絡、設備、應用、帳戶存取、安全。
2. 如果你管理配置項，關聯受影響的服務和配置項（設備或系統）。
3. 此時標記疑似安全事件，立即轉入安全處理路線。

負責人： 服務台。類別清單要短；清單太長，填的人會亂填。

第三步：定優先級

目標： 決定它需要多快得到處理。

1. 設定影響度（多少人或多大範圍的業務受影響）和緊急度（業務多快需要修好）。
2. 按你的影響度和緊急度矩陣得出優先級。嚴重程度和優先級不是一回事，P1 到 P4 優先級說明各級怎樣對應回應目標。
3. 事實變化時，容許服務台調整優先級，並寫明原因。

負責人： 服務台，最高級別由事件經理參與。時限： 首次回應目標開始計時之前，優先級就要定好。

第四步：診斷與調查

目標： 找到修復辦法或臨時解決辦法。

1. L1 初步診斷。 使用知識庫和腳本。問工單裡還沒有答案的問題。如果是已知修復辦法，直接執行。
2. 升級： 問題超出 L1 範圍、超過時限，或出現風險（數據遺失、安全、大範圍影響）時升級。用 L1、L2、L3 分級說明誰做甚麼，聯絡人見升級矩陣模板。
3. 每次升級寫交接記錄： 影響了甚麼、試過甚麼、下一步需要甚麼。
4. 按該優先級約定的間隔向用戶通報, 即使沒有新進展也要通報，並說明下次更新時間。
5. 廠商： 原因看似產品故障時，向廠商開案例，並把案例編號記在工單上。

負責人： 先是 L1，然後是 L2、L3 或處理小組。時限示例： 到該優先級的升級時間仍無進展，就往上轉。

第五步：解決與恢復

目標： 用戶那邊的服務重新可用。

1. 實施修復或臨時解決辦法。超出標準範圍的改動走變更控制，緊急變更走緊急通道。
2. 向用戶確認確實可用，而不是只看系統顯示正常。
3. 記錄解決辦法：做了甚麼、為甚麼有效、是臨時辦法還是永久修復。
4. 原因不明或只是臨時辦法時，建立問題記錄，以便日後調查原因。
5. 把工單設為「已解決」，並告知用戶。

負責人： 修復的人。時限： 該優先級的解決目標。

第六步：關閉

目標： 一條乾淨、可檢索的記錄。

1. 向用戶確認， 或在設定時間內無回覆就自動關閉。起點可以是幾個工作天，自行設定並告知用戶。
2. 檢查記錄： 類別正確、已寫解決辦法、已記錄工時、關聯記錄已掛上。
3. 如果這張工單帶來了經驗，更新知識庫。
4. 關閉。 已關閉工單通過新工單，或在約定期限內的跟進來重開。

負責人： 服務台。很多團隊每月還會抽查已關閉的工單質素。

角色

小團隊會一人兼多角色。關鍵是每個角色都有人負責。

1. 報障人或用戶： 報告事件、回答問題、確認修復。
2. 服務台人員（L1）： 登記、分類、定優先級、執行已知修復、讓用戶知情。
3. 處理人員（L2、L3 或專門小組）： 處理 L1 以外的診斷和修復。
4. 事件經理（或服務台主管）： 盯隊列和時限，接手卡住或高優先級的工單，負責升級。重大事件中的這個角色見另一篇指南。
5. 問題經理： 原因需要調查時接手。
6. 變更經理或審批人： 批准需要變更的修復。
7. 服務負責人和廠商： 為其服務或產品提供決定和支援。

時限示例

以下只是示意目標，不是標準。真正的數值由你的 SLA 決定。博迅（Brocent）公佈的回應目標見 SLA 頁面。

1. P1（嚴重），例如： 數分鐘內回應，頻繁向用戶通報，沒有進展立即升級，持續處理直到恢復。
2. P2（高）： 一小時內回應，在設定的較短時間後仍未解決就升級。
3. P3（中）： 同一個工作天內回應，數天內解決。
4. P4（低）： 一兩天內回應，按人手在較長的期限內解決。

定義三個計時：回應時間、升級時間、解決時間。只有在定義好的情況下（例如等用戶回覆）才暫停解決計時。

工單模板

好的工單包含以下欄位，可複製到你的工具裡。

摘要:        一行，現象 + 服務
報障人:      姓名、聯絡方式、位置
受影響:      多少用戶，哪個服務/設備
現象:        用戶原話、準確報錯、截圖
開始時間:    日期/時間，之前有何改動
類別:        類別 / 子類別
影響/緊急:   各 高/中/低 -> 優先級
已採取行動:  步驟、結果、誰、時間
升級給:      小組/個人、原因、時間
下次更新:    日期/時間
解決辦法:    怎樣修好的，臨時還是永久
問題記錄:    是/否，編號

常見錯誤

1. 先修後登記。 沒有工單的快速修復，會從報表和知識庫中消失。
2. 按嗓門定優先級，再加沉默。 不要讓誰叫得響誰優先，用影響度和緊急度規則；並按計劃通報，因為用戶更容易原諒延遲，而不是沒有消息。
3. 未經確認就關閉， 導致工單被重開、用戶不滿。
4. 沒有交接記錄， 用戶在每一級都要回答同樣的問題。
5. 把臨時辦法當最終辦法。 原因不明時建立問題記錄。
6. 把請求和事件混在一起， 扭曲數據和 SLA。

如何確認流程有效

1. 隨機抽五張已關閉工單。每張都應顯示誰、甚麼、何時、採取的步驟、解決辦法和時間。
2. 沒有任何未關閉工單超過升級時間卻沒有備註。
3. 用戶按你設定的計劃得到通報。
4. 每月數字合理：按類別的事件量、按優先級的回應和解決時間、重開率。指標定義見 MTTR、MTBF 和 MTTA。
5. 重複發生的事件帶來了問題記錄和知識庫文章。

常見問題

甚麼是事件管理流程？

它是一組步驟，把一次 IT 中斷從報障帶到關閉，使服務得以迅速恢復、業務影響得到控制：登記、分類、定優先級、診斷、解決、關閉。

事件管理流程有哪些步驟？

發現並登記、分類、定優先級、診斷與調查、解決與恢復，最後關閉。不同框架會拆分或合併步驟，所以不同數據裡會看到五步、六步或七步。

五步事件管理流程是甚麼？

常見的五步分法是：識別並登記、分類並定優先級、調查並診斷、解決並恢復、關閉。它與六步順序相同，只是合併了其中兩步。

事件管理流程的六個步驟是甚麼？

登記、分類、定優先級、診斷、解決、關閉。不同來源分法不同，選團隊能一致執行的版本。

下一步

想了解我們對各優先級公佈的回應目標，請閱讀我們的 SLA 頁面。

2026 年 10 月 28 日核對的來源：維基百科「Incident management」條目（en.wikipedia.org/wiki/Incident_management），其中引用了 ITIL 2011 的定義。