系統異常告警自動分級與通報

🎯 這條流程解決什麼

系統監控存在一個天生的矛盾：告警太少，會漏接真正的重大故障；告警太多，又會陷入「狼來了」的麻木。許多公司的值班群每天被上百則低優先警報洗版——某個指標短暫跳一下、某台機器 CPU 偶爾飆高、某個批次慢了幾秒——這些大多無關緊要的訊息，把真正致命的 P1 重大異常淹沒在訊息流裡。結果半夜服務真的掛了，告警明明發出來了，卻沒有任何一個值班人被「有效叫醒」，等到隔天上班或用戶大量投訴才發現，黃金處理時間早已錯過。

這個問題的成本很實際。一方面是「漏接」的代價：核心服務每停擺一小時，可能就是大量訂單流失、客戶信任受損、SLA 違約賠償。另一方面是「噪音」的代價：值班工程師長期被無效告警疲勞轟炸，不但夜間睡眠被打斷影響白天產能，更危險的是逐漸養成「先忽略再說」的習慣，讓告警機制形同虛設。純靠人工去看每一則告警、判斷嚴不嚴重、再決定要不要叫人，根本不可能 24 小時撐得住。

這條流程把告警「自動分級、去噪、精準通報」：監控工具一觸發，系統就依影響範圍與指標嚴重度判定 P1 到 P4 等級，把同源重複的警報合併計數、把維護時段內的已知事件自動靜音，再依等級分流——高等級直接電話呼叫值班人並附上對應的處理 Runbook，低等級進頻道存查即可。每一筆事件自動開單記錄完整時間軸，事後檢討與可用率報表都有現成資料。團隊從「被告警追著跑」變成「只在真正重要時被叫醒」。

導入後的改變

導入前，告警是一場無差別的訊息海嘯：值班群一天上百則、重要的被淹沒、半夜的沒人接，工程師對告警逐漸無感。重大故障的平均反應時間（從發生到有人開始處理）動輒以小時計，因為問題往往不是被告警叫出來的，而是被用戶投訴叫出來的。

導入後，去重與靜音先把噪音砍掉一大截，實務上常能讓進到人眼前的告警量下降七成以上，剩下的幾乎都是值得看的。自動分級加上分流通報，讓 P1 級事件透過電話確實叫醒值班人，重大故障的平均反應時間從數小時壓縮到數分鐘級別。值班工程師不再被無效告警疲勞轟炸，夜間睡眠與白天產能都受益，對告警的信任度也重新建立起來。再加上每筆事件自動開單與完整時間軸，月底的服務可用率報表、事件複盤、SLA 達成率全都有數據可依，IT 主管終於能用事實管理維運品質，而不是靠感覺。

流程怎麼運作

第一步「告警接收」，接收 Prometheus 等監控工具透過 Webhook 推來的告警，解析出服務名稱、觸發的指標與閾值。第二步「自動分級」，依「影響範圍（核心交易服務還是邊緣系統）」與「指標嚴重度」對照預先訂好的規則，標記 P1 到 P4 等級。第三步「去重抑制」，同一來源短時間內的重複告警合併成一則並計數，避免同一個問題噴出幾十則；同時對照維護排程，把已知維護時段內的告警自動靜音，不打擾值班人。第四步「分流通報」，依等級走不同通道——P1、P2 高等級透過 PagerDuty 電話／推播確實叫醒值班人，並附上該服務對應的處理 Runbook 連結；P3、P4 低等級進 Slack 頻道存查即可。第五步「事件登錄」，自動開立事件單記錄從觸發到解除的完整時間軸，供事後根因檢討與可用率報表統計。

需要的工具與串接重點

平台用 n8n 或 Make。Prometheus（或任何能發 Webhook 的監控系統）負責產生告警，Webhook 是進入流程的入口，PagerDuty 負責高等級的電話／值班排程呼叫，Slack 負責低等級的頻道存查與團隊溝通。串接重點有四：第一，分級規則是整條流程的靈魂，要和維運團隊一起把「哪些服務算核心、哪些指標到什麼程度算 P1」明確寫成可判斷的條件；第二，去重的「同源」判定要設計好（通常用服務名＋告警名＋實例做指紋），避免把不同問題誤併；第三，靜音要綁定維護排程，維護一結束自動恢復告警，別忘了解除；第四，每個服務都該準備對應的 Runbook，告警通知直接附上，值班人才能照著快速止血。更多告警與通知自動化做法見 /recipes，整體導入規劃可參考 /automation。

常見錯誤與注意事項

最危險的錯誤是「分級或靜音規則設錯，把重大異常誤判成低優先或被靜音吃掉」。建議規則上線前由維運主管審核，並定期回顧誤判案例持續校正，寧可初期略為保守也不要漏接 P1。第二個常見問題是去重設得太激進，把本該分開處理的不同問題合併，反而掩蓋了真實範圍。第三，靜音時段忘了解除，導致維護結束後告警一直被吞——務必讓靜音自動到期。最關鍵的安全紅線是：凡是涉及「自動執行修復動作」的環節（如自動重啟服務、自動擴容、自動回滾），務必保留人工確認關卡，不要讓系統在沒有人判斷的情況下直接變更正式環境，AI 與自動化負責「叫對的人、給對的資訊」，真正動手改正式環境的決定仍須由人下達。

台灣中小企業情境案例

台北一家做電商平台的新創團隊，只有三位後端工程師輪流兼當值班。早期他們把所有監控告警都丟進同一個 Slack 頻道，結果每天上千則訊息，大家很快就把頻道靜音、眼不見為淨。某個週末凌晨，金流服務因為第三方憑證過期整個中斷，告警其實有發，但淹在訊息海裡完全沒人看到，直到週一上午湧入大量「無法結帳」的客訴，才發現已經漏了一整個週末的訂單。導入這條流程後，他們重新訂出分級規則：金流、下單這類核心服務的中斷一律 P1，透過 PagerDuty 直接打電話叫醒當班的人，其餘雜訊留在頻道。沒多久又遇到一次金流異常，這次值班工程師在三分鐘內就接到電話、照附帶的 Runbook 更新憑證，十幾分鐘就恢復，幾乎沒有訂單損失，團隊也終於敢相信自己的告警系統。

延伸應用

這條流程可以往事前與事後兩端延伸。事後，把「事件檢討與根因記錄」制度化——每張 P1、P2 事件單自動帶出複盤範本，記下根因與改善項目，並追蹤到改善完成，避免同類故障反覆發生。事前，可結合容量趨勢分析，在指標逼近危險閾值「之前」就發出預警，把被動救火轉為主動預防。也可以把事件資料接上儀表板，自動產出每月各服務的可用率、平均修復時間（MTTR）報表，作為向上報告與資源規劃的依據。想把告警、資安通報、備份巡檢、設備報修等 IT 維運流程整合成一套完整體系，可參考 /workflows 裡的其他 IT 自動化流程。

流程圖

用到的工具

更多「企業職能」工作流

瀏覽全部工作流藍圖 → 自動化工作流中心 → AI Skills 食譜庫 →