建立訂單的監控圖上，超過三秒的操作比例從平常的2%升到20%。資料持續收集，儀表板也畫出了變化，但如果沒有人正在看，團隊可能還是等客服打電話才知道。

有數據可以觀察，和系統會主動通知，是兩件事。接下來要聊的是：什麼情況值得發出告警、通知誰，以及對方收到後能做什麼？

超過門檻之前，先想通知要促成什麼行動

延續建立訂單的案例，偶爾一筆超過三秒，可以先留下紀錄；如果一段時間內有大量操作變慢，已經影響客服接單，就值得通知負責服務的人員。

假設團隊依平常流量與操作影響，訂出一條示意規則：「最近五分鐘至少完成 100 次建立訂單，其中超過三秒的比例達 20%，而且這個條件持續兩分鐘，就發出提醒。」

這裡有三種不同的設定：五分鐘是統計範圍，20%是觸發門檻，兩分鐘則是條件必須持續成立的時間。加上持續時間，可以減少短暫波動造成的誤報，但也會讓發現問題的時間稍微延後。不能只想著避免誤報，就無限制地把時間往上加。

最低筆數則能避免總共只有兩次操作、其中一次較慢，就因為50%而觸發告警。不過在低流量時，可能始終湊不到100次；若少量操作延遲也有重大影響，就需要另外設計適合的條件。這些數字都要跟著業務用途與實際流量決定。

這條規則觀察的是已完成操作的耗時。若請求全卡住、完全沒有完成資料，這條規則可能不會觸發，也不能因此判定系統正常；仍要考慮由未完成請求的等待時間等其他訊號來涵蓋。

值得注意，不一定都要立刻打電話

建立訂單稍微變慢，但業務仍能運作，可以先送到團隊的日常溝通頻道；若大量操作持續延遲，已經嚴重妨礙營運，就需要依值班安排，通知能立即處理的人。

兩者的核心差別，在於影響層級與處理時效：

• 需要立即介入的緊急告警，若只寄到隔天才看的Email信箱，完全發揮不了作用。
• 可以排程改善的非緊急問題，若每次都打電話把人叫醒，只會引發告警疲勞，讓真正重要的通知被忽略。

當同一事件持續發生時，系統應該更新既有告警、合併重複通知，並依約定間隔提醒；若超過接手時限仍無人回應，可以考慮自動觸發升級流程通知下一位負責人。問題恢復後也要同步更新狀態，讓相關人員知道是否仍需處理。

告警內容，要讓接手的人有地方查

如果只收到「正式環境訂單服務異常」這類抽象的簡訊，接手的人還得先回頭問是哪個功能、什麼時間發生的，以及影響有多大。

一則能真正引導行動的告警通知，必須清楚交代時間、地點、狀況與影響範圍。以這次的案例來說，訊息應該直接點出是「正式環境的客服後台建立訂單流程」，並載明首次符合條件與通知發出的確切時間。

觸發原因也要明確寫出數據，例如「最近五分鐘完成120次，其中30次超過三秒，比例達 25%，已超過20%的門檻並持續兩分鐘」。這裡的30次是操作次數，不一定代表 30 位真實使用者。告警呈現的是已觀察到的現象與事實，不能把未經證實的推測，變成接手者的預設立場。

最重要的，是附上對應的服務團隊、初步處置說明，以及直接帶好環境與時間範圍的儀表板連結。接手人員點開連結，就能在一秒內對齊事發當時的現場。

從數據變成告警，關鍵在於精準的門檻設定、合理的通知分級，以及讓接手者能立刻行動的現場資訊

「為什麼你們告警信箱有幾萬封未讀？」
「因為我們把告警分成了兩種：『不用理會的告警』，和『已經來不及理會的告警』。」