🎯 什麼情境該想到我
當你「要把新版推上生產，但想先在一小群人身上驗證沒問題，再一級一級擴大範圍」的時候。
⚙️ 怎麼用（步驟 / 公式）
意圖：把發布流程自動化成「逐級晉升到越來越大、越來越關鍵的環境」，每一級都先確認程式如設計般運作，才往下一級推。
做法要點：
- 名稱來自礦工把金絲雀關在籠子裡帶進礦坑，用來提早偵測一氧化碳——毒氣先殺死金絲雀，礦工才知道要撤離。
- 發布時監控每一級環境裡軟體的表現：看起來不對就 roll back，沒問題才部署到下一級環境。
- 這是藍綠部署的變體，用自動化進一步提升安全性與縮短部署前置時間，代價是額外的複雜度。
Facebook 為此模式建立的三群組結構（書中圖 21）：
- A1 群組：只服務內部員工的生產伺服器。
- A2 群組：只服務一小部分客戶的生產伺服器，在**滿足特定驗收標準（自動或人工皆可）**後才部署。
- A3 群組：其餘所有生產伺服器，在 A2 叢集上跑的軟體滿足特定驗收標準之後才部署。
叢集免疫系統（Cluster Immune System）——金絲雀的延伸：
- 做法是把生產監控系統與發布流程串接起來，當生產系統面向使用者的表現偏離預先定義的期望範圍時，自動 roll back 程式碼。
- 書中給的具體判準例子：新使用者的轉換率跌破歷史常態的 15%–20% 時。
- 兩個顯著好處：
- 防住自動化測試很難抓到的缺陷，例如某個 CSS 變更害關鍵頁面元素變成看不見；
- 縮短偵測與回應「效能被自己的變更弄壞」所需的時間。
原文：「The canary release pattern automates the release process of promoting to」（L6652，接 L6653–6654「successively larger and more critical environments as we confirm that the code is operating as designed.」）
原文：「rates for new users drops below our historical norms of 15%–20%.」（L6687）
🧪 我實際套用的紀錄
- （待填）
⚠️ 注意 / 什麼時候不適用
- 相對於藍綠部署，這個模式多了自動化與複雜度的代價，書中明白點出這是 trade-off。
- 叢集免疫系統要能運作，前提是你已經有面向使用者的生產遙測與預先定義好的期望範圍——沒有基準線就沒有自動 roll back。
- 與藍綠部署一樣屬於 environment-based release pattern，通常不必改應用程式碼，但也管不到「單一功能」的粒度。