Deployment rollout with drain and rollback 的核心責任是把版本、流量、連線、設定與回退條件拆成可驗證批次。這篇以 checkout service 為例，示範平台切換如何從 preflight、canary、drain 到事故回退都保留一致證據。

本篇以 5.2 Kubernetes 部署策略 與 5.3 load balancer 合約 為前置知識——rollout 批次、probe 對齊、drain contract 等概念在該兩篇定義，本篇直接操作化。lifecycle 狀態的完整定義見 5.6 Platform Lifecycle Contract。

服務路徑與切換責任

這條路徑是 client -> load balancer -> checkout-api -> payment provider/order db/order event。部署期間新舊版本會同時承接流量，核心風險在流量生命週期是否可收斂，image 替換本身反而是最可預測的部分。

切換責任分三層：

1. 版本可啟動：container/runtime/config 可用。
2. 版本可接流量：readiness 與依賴狀態對齊。
3. 版本可退場：drain 與在途請求可收束。

Preflight：先驗證可服務基線

Preflight 的責任是把「可啟動」與「可服務」拆開驗證。最小檢查包含：

1. image 與 runtime config 版本對齊。
2. secret 已注入且權限正確。
3. startup/readiness probe 能反映真實依賴狀態。
4. load balancer contract 參數與服務期望一致。
5. service discovery 註冊與摘除路徑可用。

Preflight 失敗時不進 canary。先把失敗收斂在控制面，避免切流後才發現版本不可服務。

Preflight 自動化

手動 preflight 在低頻部署時可行，部署頻率上升後會成為瓶頸或被跳過。穩定做法是把 preflight 檢查嵌入 CI/CD pipeline 的 pre-deploy stage：

1. image 與 config 版本對齊檢查：pipeline 比對即將部署的 image tag 與 ConfigMap / Secret 版本是否在相容矩陣內。版本矩陣可維護在 git（如 deploy/compat-matrix.yaml），CI 自動比對。
2. infra drift detection：部署前用 IaC 工具（Terraform plan、Crossplane drift check）掃描目標環境的實際狀態是否跟宣告狀態一致。drift 存在時暫停部署——在已漂移的環境上部署新版本，會把漂移與版本變更的影響混在一起，事故時無法分辨根因。
3. probe 語意驗證：在 staging 環境對新版本觸發 startup → readiness → liveness 全流程，確認 probe 回應與依賴就緒條件吻合。這步抓的是 probe 設定退化（如 readiness endpoint 被改成永遠回 200）。
4. rollback 可行性驗證：確認舊版本 image 仍在 registry 且可拉取、舊版本 config 仍相容。rollback 能力在 preflight 階段驗證，比事故時才發現「舊版拉不到」代價低得多。

Preflight 自動化的產出是一份 go/no-go 報告，進入 6.8 Release Gate 作為放行依據。pipeline 中的 preflight stage 失敗應阻擋部署而非產生警告——可忽略的 preflight 等於沒有 preflight。

Canary Batch 與 Stop Condition

小流量先驗證新版本行為，再決定是否擴批——Canary 回答的是「這個版本值不值得擴大」。

canary 判讀要維持 per-version 視角。只看整體服務平均值會掩蓋新版本局部退化。

Traffic / Drain：把退場變成可驗證流程

Drain 的責任是讓舊版本在下線前完成在途請求，不讓 rollout 把短暫切換放大成用戶錯誤。

退場順序：

1. 舊實例 readiness 先轉 not-ready 停接新流量。
2. 保留 drain 窗口完成 in-flight request。
3. 確認連線數下降到門檻後再終止進程。
4. 驗證無異常 reconnect 尖峰再進下一批。

Drain 條件的完整 workload 分類回到 5.6 Platform Lifecycle Contract，本段以 checkout service 為例：短 API 的 draining 窗口可短，長輪詢與 webhook callback 要更保守。

Rollback Compatibility

舊版本回來時仍可運作，是 rollback 能成立的前提——回退如果變成第二次故障，就失去了回退的工程價值。

要先驗證四個相容面：

1. config 相容：新設定不會讓舊版啟動失敗。
2. schema 相容：資料結構仍可被舊版讀取。
3. cache key 相容：舊版可讀新快取或有 fallback。
4. event schema 相容：舊版 consumer 不會因新事件欄位崩潰。

若這四項未完成，所謂 rollback 只會停在「版本回切」，無法恢復服務正確性。

Evidence Package

每一批切換要可被判讀、可被追責、可被回放——部署 evidence 支撐這三個條件。

這份 evidence 要對齊 4.20 Observability Evidence Package。

Release Gate

Release gate 的責任是決定下一批切換與是否凍結 rollout，不是報告「目前看起來正常」。

這組欄位要對齊 6.8 Release Gate。

Incident Decision Log

freeze rollout、rollback version、隔離 region、延長 drain 都屬事故決策，需寫入 8.19 Incident Decision Log。涉及流量規則 / control plane 設定推送的決策、見 5.7 跟 8.23 Control Plane Decision Log。

 1incident_decision:
 2  timestamp: 2026-05-11T15:06:00Z
 3  decision: "freeze rollout at 25% and rollback one region"
 4  context: "new version timeout to payment provider increased in ap-northeast"
 5  evidence:
 6    - query: checkout_error_rate_by_version_region
 7    - query: payment_timeout_ratio_by_region
 8  owner: release-incident-commander
 9  expected_effect: "contain customer impact and restore baseline success rate"
10  rollback_condition: "timeout ratio does not recover after rollback batch completes"

Case Write-back 與邊界

這篇回寫對齊 5.C9 反例、5.C1 Tradeshift 與 5.C3 Orbitera：前者看切換失序，後兩者看遷移路徑與回退策略。preflight / canary / drain 各階段的生命週期定義回到 5.6 Platform Lifecycle Contract。

這篇不處理 schema migration 本身、cache stampede 或 queue replay。若核心風險在資料正式狀態、快取回源或事件恢復，路由到 1.7 Schema Migration Rollout 證據、2.9 Cache Migration 與 Stampede Rollback 或 3.8 Queue Consumer Retry 與 Replay Handoff。