🎯 什麼情境該想到我
當你「等到故障發生後才被告警轟炸，而不是在故障前就被提醒」的時候。
⚙️ 怎麼用（步驟 / 公式）
意圖：讓監控系統裡只剩下能預防故障的告警，而不是一堆在事故發生後才響的噪音。
理想做法（Tom Limoncelli，《The Practice of Cloud System Administration》共同作者、前 Google SRE）：
- 把監控系統裡現有的告警全部刪掉。
- 每一次使用者可見的故障（user-visible outage）之後，問：「哪些指標本來可以預測這次故障？」
- 只把那些指標加進監控系統，需要時才設告警。
- 重複。結果是你只會剩下能預防故障的告警，而不是在事故已經發生後被告警轟炸。
實務替代做法（書中說這是最容易複製上述成果的方式之一）：
- 分析最近一段期間（例如 30 天）最嚴重的事故。
- 為每一件事故列出一份遙測清單：當時若有這些遙測，就能更早更快地偵測與診斷問題，也能更容易更快地確認修復真的有效。
書中的具體範例——NGINX web server 停止回應請求，回頭找的前導指標（leading indicators）分四層：
- Application level：網頁載入時間上升。
- OS level：伺服器可用記憶體變低、磁碟空間變低。
- Database level：資料庫交易時間比平常久。
- Network level：負載平衡器後方正常運作的伺服器數量下降。
接著：
- 這每一項都是生產事故的潛在前兆（precursor）；對每一項設定告警，在它們充分偏離均值時通知，好讓人及時採取矯正措施。
- 對越來越微弱的失效訊號（ever-weaker failure signals）重複這個流程——問題會在生命週期中被越來越早發現，影響客戶的事故與 near miss 也就越來越少。換句話說，這同時在預防問題與加快偵測與修正。
原文：「ideal world, we would delete all the alerts we currently have in our monitoring」（L8254，接 L8255「system. Then, after each user-visible outage, we’d ask what indicators would」）
原文：「easiest ways to do this is to analyze our most severe incidents in the recent past」（L8261，接 L8262「(e.g., 30 days) and create a list of telemetry that could have enabled earlier and」）
原文：「By repeating this process on ever-weaker failure signals, we find problems ever」（L8284）
🧪 我實際套用的紀錄
- （待填）
⚠️ 注意 / 什麼時候不適用
- 「刪光所有告警」是 Limoncelli 自己說的玩笑式理想（I joke that in an ideal world），實務上請從「最近 30 天最嚴重事故」這條替代路徑起手。
- 這個流程吃事故品質：如果事後檢討做得草率、沒有誠實的時序重建，就回推不出前導指標——先把 工具-無指責事後檢討 做對。
- 加進來的指標仍要決定門檻怎麼設：資料常態就用 均值與標準差告警，不常態就用 非高斯資料的異常偵測。
- 每加一個告警都在增加噪音預算，「偏離均值就通知」不等於「值得半夜叫醒人」；分級判準見 日誌分級。
🔗 相關工具
- 工具-遙測與監控（本條是它在「告警清單怎麼重置」上的操作流程）
- 均值與標準差告警（回推出的每個前導指標要設偏離均值的告警）
- 非高斯資料的異常偵測（前導指標的資料若非常態就得換方法）
- 五層遙測覆蓋（NGINX 範例的四層前導指標正對應到遙測分層）
- 工具-無指責事後檢討（回推的原料就來自每次事故的檢討）
- 廣泛公開事後檢討（把回推出的缺口與學習擴散到全組織）
- DevOps手冊