🎯 什麼情境該想到我
當你「有成千上萬個指標、根本不可能一個個手動訂固定門檻，卻又想知道哪個偏離常態了」的時候。
⚙️ 怎麼用（步驟 / 公式）
意圖：用最簡單的統計（平均值與標準差）做出一個過濾器，自動找出「明顯偏離常態」的指標，不必為每個指標定義靜態門檻。
做法要點：
- 對一個生產指標計算它的 mean（平均值）與 standard deviation（標準差）。
- 建立過濾器：偵測這個指標何時顯著偏離常態，並據此設定告警（例：資料庫查詢明顯比平均慢時，凌晨兩點通知 on-call 人員調查）。
- 常見用法是週期性檢查某指標的資料集，一旦顯著偏離均值就告警。書中的例子是「每日未授權登入嘗試次數超過均值三個標準差時告警」。
- 明確數字：以高斯分佈而言，第一、第二、第三個標準差分別涵蓋 68%、95%、99.7% 的資料。
- 因此，只要資料集是 Gaussian distribution，用 3σ 規則就只有 0.3% 的資料點會觸發告警。
- 這種簡單統計分析的價值在於：沒有人需要去定義靜態門檻值——當你追蹤的是數千甚至數十萬個生產指標時，手動定門檻根本不可行。
為什麼要在乎告警品質：關鍵服務出事時凌晨兩點叫醒人是對的；但不可行動或誤報的告警就是白白把人吵醒。John Vincent（DevOps 運動早期領導者）說 alert fatigue 是「我們現在最大的單一問題」。做法上要提高訊噪比，聚焦在真正重要的變異與離群值。
（書中也說明：後續 telemetry、metric、data set 三個詞互換使用——一個 metric（如 page load times）對應到一個 data set（如 2 ms、8 ms、11 ms……）。）
原文：「first, second, and third standard deviations indicated by the other vertical lines」（L8224，接 L8225「contain 68%, 95%, and 99.7% of the data, respectively.」）
原文：「Gaussian distribution, we would expect that only 0.3% of the data points would」（L8235，接 L8236「trigger the alert.」）
原文：「Alert fatigue is the single biggest problem we have right now…We need to be」（L8216，接 L8217「more intelligent about our alerts or we’ll all go insane.」）
🧪 我實際套用的紀錄
- （待填）
⚠️ 注意 / 什麼時候不適用
- 這一招的前提是資料必須為 Gaussian distribution（常態／鐘形分佈）。書中寫得很明白：「Provided that this data set has Gaussian distribution」才會只有 0.3% 觸發告警。
- 一旦資料不是常態分佈，標準差的那些性質就不成立——結果是同時 over-alert 與 under-alert，這時要改用 非高斯資料的異常偵測 的方法。Ops 的資料集很多都不是常態分佈。
- 告警設得再聰明，也還是要問「這個告警可不可行動」；不可行動或誤報只會加深 alert fatigue。
- 標準差是「偏離常態」的偵測，不是「這件事重不重要」的判斷——重要性要靠 從事故回推告警 從真實故障回推。