每種訊號配一個處理方法
| 訊號 | 交給誰 | 先查甚麼 | 何時可結束 |
|---|---|---|---|
| 客戶無法確認預約 | 當值處理人 | 測試流程及影響範圍 | 流程恢復，未明申請已有人跟進 |
| 覆核隊列增加 | 業務流程負責人 | 等候時間、分類及覆核人手 | 已有積壓處理安排 |
| 儲存使用趨勢 | 排入營運工作 | 增長及安全擴容方法 | 容量工作完成並核實 |
| 一筆錯誤測試資料 | 測試結果紀錄 | 是否預期被拒？ | 符合該測試要求 |
Google 的監察指引區分用戶遇到的症狀與內部原因，並強調通知須能帶來行動。以上分流只是例子，並非通用嚴重程度。門檻須按工作量、支援時段和容忍範圍設定，不是數值一超過便一定要叫醒同事。
偵測到之外，也要測試通知是否到人
受控測試要確認指定同事收得到、看得到證據，也知道下一步。測試無人接手時怎樣升級處理，以及問題消失後有沒有恢復資訊。重複而無需處理的警報，應先調整，不要只加更多通知渠道。
CPU 警報觸發，但指定客戶操作都正常，下一步怎樣決定？
查看參考答案
查看趨勢及風險，按已定政策決定排入營運工作還是立即處理。不憑空寫成客戶受影響，保留觀察供檢討門檻。