搜尋意圖： 如果你在找「金絲雀部署 是什麼」或「金絲雀部署 和相近概念差在哪」，先看這頁的短定義、完整說明與延伸比較。
TL;DR： 金絲雀部署是將新版本軟體或模型逐步發布給少數使用者，以便在全面推廣前偵測問題，有效降低風險並確保系統穩定性。
實用情境： 適合用在閱讀 AI 文章、產品文件或和同事討論時，先用一頁快速對齊概念。
下一步： 先讀完定義，再往下看延伸比較與對應工具，把概念轉成實際應用。
你想讓新版本先只給少數使用者試跑時，你會怎麼判斷它真正的作用？
你可以把它想成 金絲雀部署是將新版本軟體或模型逐步發布給少數使用者，以便在全面推廣前偵測問題，有效降低風險並確保系統穩定性。
在 你想讓新版本先只給少數使用者試跑時 這種情境裡，這個概念會直接影響你怎麼設計、怎麼評估、怎麼上線。
容易混淆
金絲雀部署 vs 藍綠部署 金絲雀先放少量流量，藍綠是兩套環境整批切換。
金絲雀部署 vs 滾動部署 滾動部署是逐批替換節點，金絲雀更強調先觀察小流量。
金絲雀部署 vs A/B 測試 A/B 測試偏實驗比較，金絲雀偏上線風險控制。
記住這句就好
先看它要解決的是什麼問題，再看它是不是最合適的方法。
實際案例
案例 1：新模型上線 先讓 1% 使用者看到新版本，觀察錯誤率和延遲是否正常。
案例 2：API 改版 先在小流量下跑一段時間，確認不穩定再立刻回滾。
深入了解
面向 重點 核心 把新版本先給少量流量，確認健康再逐步擴大。 監控 要看錯誤率、延遲、轉換率、資源使用率。 注意 如果觀察指標設錯，金絲雀就只是在慢慢放大風險。
中英對照與常見說法
| 說法 | 出現場合 |
|---|---|
| 金絲雀部署 | 台灣正式用語 |
| 金丝雀部署、金丝雀发布 | 簡體寫法 |
| Canary Deployment / Canary Release | 英文原名 |
| 金絲雀發布、金絲雀測試 | 常見變體，意思相同 |
| 灰度發布 | 中國大陸常用的近義說法，涵蓋範圍略廣 |
名稱來自礦工帶金絲雀下坑的做法：金絲雀對有毒氣體比人敏感，牠先出事就代表該撤了。用一小部分流量先承受風險，正是這個比喻。
跟其他部署策略的差別
| 策略 | 做法 | 回滾速度 | 資源成本 |
|---|---|---|---|
| 滾動更新（rolling） | 一批一批換掉舊版本 | 中等，要滾回去 | 低 |
| 藍綠部署（blue-green） | 兩套完整環境，一次全部切換 | 最快，切回去就好 | 高，要兩倍資源 |
| 金絲雀部署 | 新版本先接一小部分流量，逐步放大 | 快，把流量切回 0 即可 | 中等 |
| 功能旗標（feature flag） | 程式碼已上線，用開關控制誰看得到 | 最快，改設定即可 | 低，但程式複雜度上升 |
金絲雀與功能旗標常常一起用：用金絲雀控制基礎設施層的流量比例，用功能旗標控制應用層的功能可見度。
執行時的四個要點
流量比例要階梯式放大。 常見節奏是 1%、5%、25%、50%、100%，每一階觀察一段時間。第一階的重點不是驗證效果，而是驗證「有沒有立刻爆炸」。
一定要先定義好中止條件。 錯誤率超過多少、P95 延遲超過多少毫秒、關鍵業務指標掉多少，這些數字要在上線前寫下來，而不是出事時再討論。沒有事先定義的門檻，人會傾向再等等看。
監控要能分辨新舊版本。 指標必須依版本標籤切開看。混在一起看的話，1% 的流量出問題會被 99% 的正常流量稀釋到看不出來。
注意流量的代表性。 隨機抽 1% 的請求跟「只給內部員工」是不同的金絲雀，後者不會暴露真實使用者才會遇到的問題。同一個使用者也應該固定落在同一個版本，否則體驗會在兩個版本之間跳動。
用在機器學習模型上的差別
模型的金絲雀部署有一個額外難題：新模型的效果不是立刻看得出來的。 系統指標（延遲、錯誤率）幾分鐘就有結論，但推薦準不準、轉換率有沒有提升，往往要等幾天才有統計顯著性。
常見做法是影子模式（shadow mode） 先行：新模型接收全部流量並記錄預測結果，但輸出不影響使用者。這樣可以在零風險下比對兩個模型的預測差異與延遲，確認沒問題後再開始真的分流。
情境判斷
Q1（判斷題）： 如果新版本一上線就給全部使用者，還算金絲雀部署嗎？ → 不算，那已經是直接切換。
Q2（判斷題）： 如果小流量一切正常，就代表可以放心全量嗎？ → 通常可以往前推，但還是要看指標是否穩定一段時間。
常見問題
金絲雀部署最大的目的是什麼？
在正式全面上線前先用小流量驗證風險。
和藍綠部署怎麼選？
如果你想快速整批切換，藍綠簡單；如果你想細緻觀察風險，金絲雀更適合。
金絲雀部署一定要自動回滾嗎？
不一定，但有自動回滾通常會更安全。