「沒有量測就沒有改進」#
這條金句是 SRE 的支柱。但選錯指標比沒指標還危險，因為它會誤導決策。
案例：100% 可用率的迷思#
延續旅遊軟體案例。守門上線後表現提升，新功能持續加入。一年後 leadership 想看績效報表，SRE 從 production 提供：
- 可用率（%）
- SLA 違反率
- MTTR、MTBF、MTTD
報表顯示 100% 可用率，但客戶端反映只有 95%。leadership 因「系統夠穩」而砍預算。
問題分析#
- 100% 可用率的定義是「即便有錯，自動修復後系統未中斷」——但客戶仍看到失敗
- MTBF 顯示 70% 改善，因為計算邏輯只看「同類失敗再次發生」，忽略了多數新型故障
- 可用性工具把「客戶有沒有反映」當條件之一——如果客戶沒打電話，就當沒事
解法：重新校準量測#
- 從可用性指標移除「客戶反映」這一條件
- SRE 與開發合作把 MTTD 寫進開發流程
- 檢視底層錯誤碼邏輯，補齊原本被略過的故障
- 開發在開發階段就用 MTTD 抓錯誤
- 重新發布後，leadership 終於看到「系統還在 nascent 階段」這個實情
量測的目的是反映現實，不是讓報告好看。指標走偏時，第一個被誤導的就是決策層。
指標怎麼選#
- 跨團隊共同設計：SRE、開發、測試一起決定衡量方式
- 依服務特性調整：同一系統內不同服務量測標準可能不同
- 例：服務 1 觸發其他工作後即關閉，把「服務健康度」當 MTTD 條件就會誤報
常用指標#
- MTTR：恢復時間
- MTTD：偵測時間
- MTBF：故障間隔
- 可用率（%）：直接反映可靠性
- 變更上線前置時間（lead time for changes）：反映工具與流程效率
SRE 四黃金指標#
- 延遲（latency）
- 飽和（saturation）
- 流量（traffic）
- 錯誤（error）
指標選擇後請定期校準。每年都該重新審視「我們在量測什麼？這個量測還反映現實嗎？」