跑金絲雀不難，難的是判讀：這一小撮流量的指標到底是「新版壞了」還是「基礎設施本來就有雜訊」？金絲雀本質是一場 A/B 測試——選錯指標、忽略共享故障域、或用錯比較基準，就會得到會騙人的綠燈。
🧠 Intuition
TIP
金絲雀把爆炸半徑縮小，反而讓訊號更難看見：5% 群體吃 20% 錯誤率，整體監控只看到 1% 錯誤，淹沒在其他雜訊裡。所以必須按版本（canary vs control）分解指標，才看得出差異。
- 指標要能指出問題：以 SLI 為起點，選與服務健康強歸因的指標（HTTP 回應碼、延遲）。CPU 使用率這類較不適合——資源升高不一定影響使用者，還可能製造雜訊。
- 少即是多：選前十幾個關鍵指標就好；過多指標邊際效益遞減、維護成本反而侵蝕對發布流程的信任。
- 指標要可歸因：觀測到的變化要能明確歸給「金絲雀變更本身」，不受外部因素影響——用**絕對度量（如定義好的 SLO）**確保系統真的正常，而非只跟 control 相對比較。
- 對錯誤預算的影響 ∝ 暴露流量：群體越小、時間越短，冒的 budget 風險越小，這正是金絲雀的價值。
⚖️ Tradeoffs
Before/After 比較 — 看似直覺，卻被「時間」汙染
- 把舊系統整個換成新系統，再比較變更前後行為——問題是時間本身是指標變化的最大來源之一。
- 例：週一發布會把「工作日行為」拿去跟「週末行為」比，引入大量雜訊，難以判斷降級是不是金絲雀造成的。
- 正解：金絲雀與 control 同時並存、同期比較，把時間變因消掉；並確保指標聚合間隔 ≤ 金絲雀持續時間（用「每小時錯誤數」評估只跑 30 分鐘的金絲雀，會夾進部署前的無關事件）。
共享故障域與隔離 — 金絲雀不一定是罪魁禍首
- 金絲雀與 control 常共享後端、網路、資料儲存；甚至同一 client 的連續請求會分別命中兩邊。
- 後果：金絲雀流程喊停時，壞的不一定是金絲雀；金絲雀的不良行為也可能反過來拖累 control，讓 A/B 兩邊同時變差。
- 指標要隔離：整體 CPU 飆高可能是別的程序造成，**「服務請求所花的 CPU 時間」**才是更好的訊號。
- 一次只跑一個金絲雀：多個並行會增加心智負擔與訊號汙染。用漸進式多階段（先小群體看最清楚的崩潰／失敗指標，再放大增加信心）兼顧安全與代表性。
🔑 Takeaways
- 金絲雀是 A/B 測試，判讀比部署更難：按版本分解指標才看得見被稀釋的訊號。
- 選與健康強歸因、可歸因、少而精的 SLI（回應碼／延遲優於 CPU）；用絕對 SLO 而非純相對比較。
- 避開 before/after 的時間汙染（同期並比、指標間隔 ≤ 金絲雀時長）、警惕共享故障域、一次只跑一個並漸進放大。
No notes yet — jot your takeaways or Q&A here.