部署不是單純覆蓋二進位檔，而是控制「程式碼置換」與「真實流量放行」的時間差。

在單機時代，發佈新版本意味著停機、替換執行檔、重啟程序；一旦新版本存在記憶體洩漏或查詢退化，所有線上使用者會在同一秒同時撞上故障。在分散式系統中，部署策略（Deployment Strategies）的核心命題只有一個：如何讓新版本（v2）在不中斷服務的前提下接手流量，並且在發現缺陷時，把受影響的使用者比例（Blast Radius）與恢復時間（MTTR）壓到最低。

現代持續交付將「部署（把程式放到機器上）」與「發佈（讓使用者看見新功能）」拆成獨立步驟，使回滾不再依賴漫長的重新編譯。

工程團隊在選擇部署策略時，本質上是在四個無法同時拉滿的維度之間做折衷：

• 爆炸半徑（Blast Radius）：若 v2 帶有嚴重臭蟲，第一時間會有多少比例的線上請求受損（1%、25% 還是 100%）？
• 回滾速度（Rollback Speed）：發現異常後，將流量完全撤回 v1 需要幾秒？是改一條路由規則，還是要等整批容器重新拉取映像檔並通過健康檢查？
• 額外容量成本（Capacity Overhead）：發佈期間需要多準備多少台機器？是僅多開 10% 的過渡節點，還是必須同時維持兩套 100% 規模的生產環境？
• 多版本並存複雜度（Coexistence Complexity）：當 v1 與 v2 在線上同時讀寫同一個資料庫與快取時，網路協定與資料表 Schema 是否會發生衝突？

從原位分批替換的 Rolling，到雙環境切換的 Blue-Green、按比例試水的 Canary，再到應用層的 Feature Flag。

1. Rolling Update（滾動更新）

Rolling Update 是最普及的預設策略。系統將現有叢集分成多個批次（Batch），每次停掉一小批 v1 實例、換上 v2 實例，待新實例通過 Readiness Probe 後再推進下一批。在容器編排篇（container-orchestration）中談過 Kubernetes Deployment 透過 maxSurge 與 maxUnavailable 控制滾動步調；在 AWS EC2 Auto Scaling 或 ECS 中，則對應 Rolling update with additional batch。

• 優勢：額外容量成本極低（僅需 10%～25% 的 Surge 緩衝），不需要額外的 L7 權重路由控制面。
• 致命傷：回滾也是滾動的。當部署推進到 60% 才發現異常，回滾必須反向執行另一輪滾動替換，期間必須等待連線排空（Connection Draining）與容器冷啟動，耗時往往長達數分鐘。

2. Blue-Green Deployment（藍綠部署）

藍綠部署直接避開「原位替換」的混亂：線上正在服務 100% 流量的舊環境稱為 Blue（v1）；發佈時，平行建立一套規模完全相同（100% 容量）的全新環境 Green（v2）。工程師可以在 Green 環境上先跑合成測試（Synthetic Testing）與預熱，確認無誤後，在負載平衡器或 DNS 層將流量一次性從 Blue 切往 Green。

• 優勢：零新舊版本混跑窗口（若一次性切流），且回滾速度極快——只要原來的 Blue 環境還沒銷毀，切回舊 Target Group 只需毫秒到數秒。
• 致命傷：發佈與觀察期間需要 200% 的運算容量；若服務本身帶有龐大的本機狀態或需要維持數百萬條長連線（如 WebSocket 篇談到的有狀態閘道），一次性全量切換會引發連線瞬間重連風暴。

3. Canary Deployment（金絲雀發佈）

礦工下坑時會帶一隻對瓦斯極為敏感的金絲雀來預警危險。Canary 發佈只先部署極少數的 v2 實例（或利用 L7 路由權重切出 1%～5% 的真實流量），讓極小部分真實請求替全體使用者「踩雷」。待觀察一段時間（Baking Period）確認錯誤率與延遲沒有劣化，才按 5% → 25% → 50% → 100% 階梯推進。

• 優勢：爆炸半徑被嚴格限制在首波比例（例如 2%），同時只需額外準備極少量的金絲雀實例容量。
• 致命傷：新舊版本並存時間最長（可能持續數十分鐘至數小時），對資料庫 Schema 與 API 向後相容的要求最嚴苛；且必須搭配細粒度的 L7 流量控制與自動化指標觀測。

4. Feature Flag（功能旗標 / 暗發佈）

前三種策略都在「基礎設施或路由層」切換實例，而 Feature Flag 則把切換點搬進應用程式碼內部（if (flags.isEnabled("new-checkout", userContext))）。v2 程式碼可以透過 Rolling 或 Canary 先部署到所有機器上（此時新功能預設關閉，稱為 Dark Launch），之後再透過遠端組態中心（如 AWS AppConfig、LaunchDarkly）針對特定內部員工、特定地區或 1% 付費戶動態打開。

四大策略並無絕對優劣：Blue-Green 用雙倍機器買「零並存與秒級回滾」，Canary 用長並存期與控制面複雜度買「極小爆炸半徑與低機器成本」。

只要線上同時存在 v1 與 v2 實例，任何破壞性 Schema 變更都會讓「秒級回滾」變成災難。

在面試中，許多候選人談完「用 Canary 切 5% 流量，出事就秒切回 v1」便以為萬無一失，卻忽略了背後的狀態層：運算實例是無狀態且可並存的，但底層資料庫通常只有一份。

假設你要將使用者資料表的 full_name 欄位拆成 first_name 與 last_name。若在部署 v2 前直接執行 ALTER TABLE DROP COLUMN full_name，線上仍在處理 95% 流量的 v1 實例會立刻因為找不到欄位而全面崩潰；反之，若 v2 寫入了只有 v2 看得懂的格式，當 Canary 失敗回滾到 v1 時，v1 讀到這批新資料也會反序列化失敗。

平行演進模式：Expand and Contract（擴張與收縮）

為了讓 Rolling 與 Canary 在任意時刻都能安全推進或無損回滾，資料庫與有狀態 Schema 必須遵循 Expand → Migrate (Dual-Write) → Contract 三階段演進，將一次破壞性變更拆成多次向後相容（Backward-compatible）與向前相容（Forward-compatible）的小步部署：

Expand / Contract 的核心紀律：永遠不在同一次應用程式部署中「同時新增新欄位並刪除舊欄位」；刪除動作必須留到所有舊版實例徹底退場且不再需要回滾之後。

不用人眼盯大盤：用黃金訊號、最小樣本數門檻與雙基線比對，讓部署管線自動推進或熔斷回滾。

如果 Canary 發佈後需要工程師守在螢幕前肉眼盯著 Grafana 儀表板 30 分鐘，那它既無法規模化，也容易因人為疲勞而漏看尾端延遲（Tail Latency）劣化。現代漸進式交付（Progressive Delivery）將流量切換與自動指標分析（Automated Canary Analysis, ACA）綁成閉環控制系統。

sequenceDiagram
    participant CD as 部署控制面
    participant LB as L7 路由器
    participant Can as Canary (v2)
    participant Met as 指標分析引擎
    CD->>LB: 1. 設定權重 v1=95%, v2=5%
    LB->>Can: 2. 導流 5% 真實請求
    Can-->>Met: 3. 上報 5xx / p99 延遲 / 飽和度
    Met->>CD: 4a. 指標異常 (超越閾值)
    CD->>LB: 4b. 緊急回滾：v2 權重歸 0%
    Met->>CD: 5a. 觀察期通過且樣本充足
    CD->>LB: 5b. 推進下一階：v2=25% -> 50% -> 100%
  

漸進式交付閉環：每一階權重提升後都必須通過「最小樣本數」與「觀察期（Baking Period）」雙重驗證，任一指標違規即自動將 v2 權重歸零。

自動判定時的三個工程細節

1. 拿什麼比：絕對閾值 vs 對照基線（Baseline vs Canary）：單純設定「5xx 錯誤率 < 1%」很容易在離峰或外部第三方故障時誤判。標準作法是同時建立一個與 Canary 同規模、同時間啟動的 v1 對照組（Baseline），計算 Canary 與 Baseline 之間的統計差異（如 Mann-Whitney U 檢定或相對退化比例）。這樣既能排除「剛啟動時的快取冷卻效應」，也能濾掉「全站外部依賴抖動」造成的假警報。
2. 看哪些指標：四大黃金訊號 + 業務漏斗指標：除了 HTTP 5xx 錯誤率與 p95/p99 延遲，還必須納入業務層轉換率（例如結帳成功率、發文成功數）。因為如果 v2 把原本該正常處理的請求錯誤地直接回傳 200 OK 空陣列，基礎設施指標會看起來「又快又沒錯」，只有業務指標驟降才能抓出這類靜默壞死（Silent Failure）。（關於黃金訊號、SLO 與 Error Budget 的嚴格定義，由 slo-sli-alerting 負責）。
3. 何時才算數：最小樣本數（Minimum Sample Size）與觀察期：在低流量時段，5% 的金絲雀可能在 5 分鐘內只收到 8 個請求，其中 1 個偶發逾時就會讓錯誤率飆到 12.5% 觸發假回滾；反之，記憶體洩漏（Memory Leak）或連線池耗盡往往需要累積數十分鐘才會顯現。因此 ACA 必須同時要求「Baking 時間達標」且「累積請求樣本數 N 足夠」。

上式揭示了 Canary 的真實保護力：即便把回滾時間 RollbackSec 壓到 3 秒，如果偵測窗口 DetectionWindowSec 需要 300 秒才湊得齊統計顯著樣本，期間仍會有 TotalQPS × CanaryWeight × 303 筆請求受損。這也是為什麼高風險變更常先用 Shadow Traffic（流量鏡像 / Dark Traffic）將真實請求複製一份非同步打向 v2（丟棄 v2 回應、不影響真實用戶），或者先用 Feature Flag 限縮在內部帳號驗證，確認無誤後才進入 Canary 權重切流。

不同運算層的流量切換原語：從 L7 Target Group 權重、Lambda Alias 到 Cloud Run Revision 流量分割。

在系統設計面試中，考官常追問：「你說用 Canary 切 10% 流量，在雲端架構上到底是哪一個元件在切？」不同運算模型（EC2/ECS、Kubernetes、Serverless）對應的流量控制點截然不同：

容器與無伺服器平台的不可變版本（ECS Task Set、Lambda Version、Cloud Run Revision）讓權重切流與秒級回滾成為內建原語，不再需要手動搬移機器。

設定回滾時間要求、額外容量預算、Schema 變更性質與觀測成熟度，即時推導最佳部署組合並量化各方案的受影響請求數。