重大事件管理：流程、角色與溝通方案

先說結論： 重大事件是業務影響大到不能按普通工單排隊處理、需要單獨的、更快的流程的事件。流程是：宣佈、在一位事件經理統一指揮下組隊、按固定節奏溝通、先恢復服務、事後檢討。找出並消除根因是另一件事，由事後的問題管理負責。

IT 事件絕大多數是例行的：用戶打不了印、筆記本太慢、密碼要重置。少數不是：全公司郵件癱瘓、總部辦公室斷網、支付系統停擺。這類事件需要另一套工作方式。本文說明什麼是重大事件、如何一步步處置、誰負責什麼、怎樣溝通，以及事件管理與問題管理的分界線。

術語參考了 Atlassian 的 IT 事件管理指南和問題管理指南。Atlassian 指出，遵循 ITIL 或 ITSM 實踐的團隊會用「重大事件」來稱呼需要緊急響應的事件；並引用 ITIL 對已知錯誤的定義：已有記錄在案的根因和臨時解決辦法的問題。我們於 2026 年 10 月 28 日閱讀這兩篇（查證日期：2026-10-28）。下文的閾值和時間只是可供調整的示例，並非行業標準。

什麼是重大事件？

Atlassian 把事件描述為任何中斷或降低服務質素（或有此威脅）的情況。重大事件則是業務影響高到普通的排隊式處理已經不夠用的那種。沒有放之四海而皆準的數字，因為「影響高」取決於每家企業，所以必須事先定義。

典型觸發情形有：

• 核心服務對大量用戶或整個站點中斷：郵件、網絡、帳號登入系統、ERP、客戶門戶。
• 創造收入或關係安全的系統停了。
• 後果嚴重的安全事件，例如勒索軟件或管理員帳號疑似被接管。
• 同時影響多個客戶或多個地點的故障。
• 較小的故障，但持續時間已超過其優先級所允許的範圍。

重大事件並不等於 P1。很多機構同時有好幾張 P1 工單，卻沒有啟動重大事件流程。區別在於，重大事件需要多個團隊的人在一位協調人統一指揮下協同工作，並持續向管理層通報。

優先級本身由影響度和緊急度決定。我們的嚴重程度與優先級的區別一文講了怎麼定，P1 至 P4 說明則展示了各級別的實際含義。

什麼時候該宣佈重大事件？

把宣佈標準寫下來，並且要在壓力下也容易套用。一張簡短的清單比一份長長的制度好用。

1. 受影響的服務在關鍵服務清單上，或受影響的用戶、站點數量超過規定值。
2. 用戶沒有合理的臨時辦法可用。
3. 預期影響嚴重：營收損失、安全、法律或合約後果，或聲譽受損。
4. 第一位工程師在較短的時限內（例如 30 分鐘）無法修好，或根本無法估計何時修好。

服務檯的任何人都應該可以提出重大事件，並由一位指定的人（通常是當班的事件經理）確認。宣佈了一起後來證明規模較小的重大事件，代價很低；真正的重大事件晚宣佈一個小時，代價就大了。

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

下面是適合中小型 IT 團隊的一套流程，按順序進行。

1. 發現並記錄。 監控告警、電話或多張類似工單暴露了問題。記錄開始時間、受影響範圍和報告人。
2. 宣佈。 套用標準，給事件命名，並建立唯一的事件記錄，所有資訊都掛在這條記錄上。使用一個共享的通道或會議，例如電話會議橋加一個聊天羣。
3. 指定事件經理。 由一個人負責協調，他不做技術操作。
4. 組建響應團隊。 拉入受影響領域的技術負責人，以及能聯絡供應商、網絡營運商或業務方的人。
5. 評估影響。 誰無法工作？哪個業務流程停了？業務上的截止時間是什麼？
6. 先恢復服務。 選擇最快、最安全的回到可用狀態的辦法：回滾變更、切換、重啟、採用臨時辦法。不要在停機期間追求完美的解釋。
7. 按計劃溝通。 按約定的間隔發出通報，無論有沒有新進展。下文詳述。
8. 確認恢復。 請真實用戶或業務負責人驗證，而不是只看儀表盤上一片綠色。
9. 關閉事件並交接。 記錄時間線、臨時辦法和未解決的疑問，把根因調查移交給問題管理。
10. 檢討。 在幾個工作日內召開事後檢討，趁大家記憶還清楚。

關鍵原則：恢復服務和查明原因是兩件不同的事。混在一起只會拉長停機時間。

重大事件中各角色分別做什麼？

角色要少而清晰。小團隊裡一個人可以身兼兩職，但事件經理不應該同時去修故障。

• 事件經理： 主持會議橋，決定優先級，維護時間線，確保技術團隊沒有被任何事情卡住。
• 技術負責人： 指揮診斷和修復工作，向事件經理說明已知、未知和正在嘗試的內容。
• 溝通負責人： 撰寫併發送通報，讓工程師不用分心。小團隊裡可以由事件經理兼任。
• 專業工程師： 負責具體系統、網絡、安全或應用的工程師。
• 業務或客戶代表： 確認影響、業務截止時間，以及服務恢復到什麼程度算可以接受。
• 記錄員： 記錄時間點、決定和行動，這是檢討的原始材料。

如果你的 IT 是外判的，應事先與服務商商定這些角色，包括你這邊誰有權批准切換或緊急變更。誰會被叫來、什麼時候叫，可參考我們的L1、L2、L3 支援級別和升級矩陣。

重大事件期間如何溝通？

沉默造成的傷害比壞消息更大。聽不到任何消息，人們會以為沒人在處理，於是不斷打電話、層層上報，反而把工程師從修復工作中拉走。

1. 儘快發出第一條通知。 說明受影響的內容、開始時間、正在調查，以及下一次通報的時間。不要等到知道原因再說。
2. 設定固定節奏。 例如緊急故障每 30 分鐘一次，可視情況調整。即使內容是「無變化，仍在調查」，也要準時發。
3. 用平實的語言。 說明用戶現在能做什麼、不能做什麼，以及臨時辦法。避免內部工單號和術語。
4. 只有一個資訊來源。 一個通道，一條狀態資訊，一位負責人。不要讓三個人發三個不同的預計時間。
5. 謹慎給出預估。 除非很有把握，否則給出的應是下次通報的時間，而不是承諾修復的時間。
6. 發出恢復通知。 說明恢復了什麼、用戶應該檢查什麼，並告知之後會有檢討。
7. 檢討之後跟進。 用一份簡短總結說明發生了什麼、將會改變什麼。

按受眾調整內容：管理層需要影響和業務後果，用戶需要知道現在能做什麼，技術團隊需要細節。

事件管理和問題管理有什麼區別？

這是最常見的混淆，答案在於各自的目標。

• 事件管理要儘快恢復正常的服務運行，追求速度，把影響降到最低。用臨時辦法恢復服務就是成功。
• 問題管理要找出並處理事件背後的根本原因，防止再次發生，追求深度和預防。臨時辦法只是中間步驟。

Atlassian 把問題管理描述為識別和管理 IT 服務上事件成因的過程。已知錯誤則是已有記錄在案的根因和臨時辦法的問題。

用一個具體例子對比。某個週一早上，文件伺服器磁碟寫滿，沒有人能打開共享文件。

• 事件響應： 騰出空間或擴容，確認用戶能打開文件，然後關閉事件。
• 問題調查： 查明磁碟為什麼滿了，是備份任務、失控的日誌，還是有人拷貝了大文件；以及為什麼監控沒有提前提醒。然後補上告警、配額或容量，防止再次發生。

兩者互相銜接。一起重大事件通常會引出一條問題記錄，多起相似的事件也可以關聯到同一個問題。如果根因暫時找不到，就應把臨時辦法寫入已知錯誤記錄，讓下一位工程師能更快恢復服務。

事後檢討怎麼做？

檢討應當不追究個人：目的是改進體系，而不是找人批評。內容包括：

1. 從第一個症狀到完全恢復的時間線，含發現、宣佈、關鍵決定和恢復的時間點。
2. 哪些做得好，哪些拖慢了響應，哪些純屬運氣。
3. 用平實的語言描述業務影響。
4. 目前所知的原因，以及仍不清楚的部分。
5. 行動項，每項有明確負責人和到期日，登記為問題記錄、變更申請或監控改進。
6. 宣佈標準、角色分工和聯絡人清單是否需要更新。

這份時間線同時為MTTR、MTBF 和 MTTA這些平均指標提供真實的測量數據。如果事件涉及數據丟失或恢復時間很長，請對照RTO 與 RPO中的目標看看結果。

在第一起重大事件之前應該做哪些準備？

大部分收益來自事前準備。

1. 定義什麼算重大事件，以及誰有權宣佈。
2. 保管一份最新的聯絡人清單，涵蓋團隊、供應商、網絡營運商和關鍵業務負責人，並保證系統宕機時也能拿到（例如紙質版或存在手機裡）。
3. 為首次通知、進展通報和恢復通知準備好模板。
4. 設立固定的溝通通道或會議橋號碼，別讓人在壓力下現想。
5. 記錄關鍵服務、其負責人和依賴關係。
6. 事先約定緊急變更規則，別讓修復卡在審批上。
7. 每年至少做一次簡短演練。

如果你的 IT 是外判的，請向服務商索要其書面的重大事件流程和聯絡路徑。博迅的 SLA 頁面按優先級公開了響應目標，管理型IT外判服務方案與按用戶收費展示了管理型IT外判服務的公開價目，並標明合約訂明的服務時段內緊急事件 15 分鐘首次響應。如果想討論適合你自身環境的重大事件流程，歡迎聯絡我們。

常見問題

ITIL 裡的重大事件是什麼？

在 ITIL 和 ITSM 實踐中，重大事件指業務影響顯著偏高、需要用有別於普通事件的更快流程來處理的事件。具體門檻由各機構自行定義，而不是由 ITIL 規定。

重大事件和 P1 有什麼區別？

P1 是單張工單的優先級；重大事件是一種響應方式：多個團隊、一位協調人、有結構的溝通。很多 P1 工單按常規流程就能處理，重大事件流程用於那些需要跨團隊協調的事件。

重大事件經理做什麼？

重大事件經理負責協調響應：主持會議橋、分配任務、維護時間線、處理升級，並確保通報按時發出。他通常不親手做技術修復。

事件管理和問題管理有什麼區別？

事件管理的目標是快速恢復服務，哪怕靠臨時辦法；問題管理則調查根因並消除它，防止事件再來。一起重大事件通常以一條問題記錄收尾。

重大事件期間多久通報一次？

一開始就約定節奏，例如緊急故障每 30 分鐘一次，即使沒有新消息也要照做。合適的間隔取決於事件的嚴重程度和變化的快慢。

小企業需要重大事件流程嗎？

需要，只是可以更輕量。一頁紙就夠起步：宣佈標準、一位指定的協調人、一份聯絡人清單和幾份消息模板。小團隊更需要它，因為同樣幾個人既要修故障，又要負責溝通。

重大事件之後應由誰主持檢討？

最好是不屬於主要修復人員的人，通常是事件經理或服務負責人。中立的主持人更容易開成不追究個人的討論，也能讓焦點留在行動項上。

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