金流場景的 canary deploy 核心責任是讓每一批放量都能用交易指標判斷是否安全。progressive rollout 的節奏由交易成功率、duplicate charge 偵測與退款異常等金流特有指標驅動。本文從金流場景的通用壓力推導 progressive rollout 設計，以 Stripe 公開的 deploy 與 idempotency 實踐作為背景脈絡。

問題場景

金流變更的風險帶有延遲性。交易失敗可能在結帳時才被發現，退款申請可能在數天後才出現，對帳差異可能在日終結算才暴露。若 canary 只觀察幾分鐘的 error rate，延遲暴露的問題會在全量放行後才浮現。

這種延遲特性讓金流場景需要比一般功能更長的觀察窗與更多元的判讀指標。放行決策要等交易生命週期的關鍵階段都走過，才能確認變更安全。

決策機制

機制核心問題控制方式
Canary traffic control每批流量比例與觀察窗如何設定1% → 5% → 25% → 100%，觀察窗依交易確認延遲調整
Transaction-specific checks交易指標是否涵蓋結帳到對帳的完整鏈路checkout success rate、capture rate、duplicate、refund anomaly
Automatic rollback trigger交易異常時是否能即時回退指標超門檻自動回退，不等人工判斷
Staged config vs codeconfig 變更與 code 變更的風險是否相同timeout / retry 等 config 變更走獨立且更短的 rollout 節奏

Canary traffic 的觀察窗設計是這個機制的關鍵。1% 階段至少觀察到一個完整的交易確認週期（通常 30 分鐘到數小時），5% 階段需要覆蓋一個對帳週期，25% 階段需要確認退款率無異常。每批之間的 go/no-go 判斷依據是全部交易指標都在 baseline 範圍內，任一指標偏離即暫停擴批。

Config 變更（如 provider timeout 或 retry 次數）與 code 變更走不同 rollout 路線。config 變更影響面通常更可預測、回退更快（秒級生效），但風險在於小幅調整也可能放大 retry storm 或觸發 cascade timeout。

可觀測訊號

訊號判讀重點對應章節
checkout success ratecanary 批次是否維持交易承諾6.8
canary vs baseline latency延遲偏移是否超過可接受範圍6.13
payment duplicate rate重試是否產生重複扣款6.12
rollback trigger count自動回退是否頻繁觸發6.23
refund anomaly rate退款比率是否偏離歷史 baseline8.19

常見陷阱

把金流 canary 跟一般 feature rollout 用同一套觀察窗，會漏掉延遲暴露的問題。金流的 feedback loop 從結帳到退款可能跨越數天，短窗觀察拿到的 pass 訊號只代表即時指標正常，無法涵蓋對帳與退款階段的風險。

另一個常見問題是 config 變更被視為低風險而跳過 canary。timeout 或 retry 設定的微幅調整看似無害，但在高流量下可能觸發 retry storm 或改變 provider 端的行為，影響幅度可能大於 code 變更。

下一步路由

先回到 6.8 Release Gate 定義金流場景的放行政策，再到 6.17 Feature Flag Governance 設計 progressive rollout 的 flag lifecycle。實作示範見 6.25 Provider Dependency Release Gate。

引用源

本文的 progressive rollout 機制（觀察窗設計、交易指標門檻、自動回退）從金流場景的通用壓力推導，並非 Stripe 公開的具體 deploy pipeline 描述。