概念定位

Release gate 是把放行決策從「看起來可以」變成「條件已經達成」的控制面。它的責任是把哪些變更可以進、哪些變更要等、哪些變更必須先補證據說清楚，擋住所有變更從來不是目標。當 gate 被寫成政策，團隊就能用同一套條件判斷 CI、SLO、migration、相容性與高風險時段。

這個節點先處理節奏，再處理工具。先問變更是否應該放行，再問這次放行需要哪些訊號與檢查。當 gate 被看成節奏控制，讀者就會明白為什麼 freeze 是可靠性政策的一部分，視為例外會弱化整套節奏控制。

大綱

• release gate 的核心責任：把放行決策從個人判斷變成可驗證條件
• gate 類別：CI 通過、SLO 健康、error budget 餘額、migration 可逆、相容性檢查
• 變更節奏：deploy frequency、batch size、change failure rate（DORA 四指標）
• freeze 條件：error budget 耗盡、事故進行中、高風險時段
• 跟 6.6 SLO 的耦合：error budget 是 gate 的一個條件
• 跟 05 部署 的交接：gate 通過後 rollout 策略接手
• 反模式：gate 流於形式、freeze 無 owner、緊急修復繞過 gate 變常態

核心判讀

gate 的責任是把放行條件具體化。CI green 只代表測試通過，不代表服務可以安全進 production；SLO 健康只代表目前風險可接受，不代表任何變更都能繼續推；migration 可逆只代表退路存在，不代表已經證明回退完全無害。這些條件要一起看，才知道 gate 有沒有真的在做事。

資料庫 migration 的 gate 要把 evidence 放回 rollout 階段判讀。Expand、backfill、cutover 與 contract 需要不同 checks：compatibility result、validation query、mismatch rate、replication lag、rollback window 與 owner。完整欄位形狀可接到 1.7 Schema Migration Rollout 證據。

freeze 的責任是把風險攔住。當 error budget 耗盡、事故正在進行、或高風險時段已到時，freeze 不應該被視為拖延，而應該被視為維持可靠性的一種放行決策。這樣的政策，會比只看 CI 更接近真實的部署世界。

判讀訊號

• gate 只看 CI green、不看 SLO / error budget / migration 可逆性
• emergency bypass 從例外變週常
• freeze 條件無 owner、沒人知道誰能解凍
• change failure rate 沒量、無法評估 gate 是否有效
• migration 沒做向後相容檢查、rollback 後資料不一致

案例對照

Google 很適合用來看 gate 需要什麼政策語言，因為它把 SLO、error budget 與 post-incident review 連成一套治理系統。Stripe 則適合用來看交易場景下的 gate，因為 idempotency、canary 與 migration safety 會把放行和交易正確性綁在一起。Shopify 可以補峰值節奏，因為 BFCM 前的 gate 不只是測試通過，而是要確定高峰時仍能守住容量與隔離。

Amazon 和 Meta 則提供更偏架構層的 gate 視角。前者告訴我們隔離邊界與 blast radius 會直接影響哪些變更可以放行，後者則顯示 control plane 變更如果沒有足夠的 gate，可能直接把整個區域或整個公司拖進事故。把這些案例一起看，gate 就不再只是 CI 的最後一步，而是整個變更節奏的控制面。

Stripe 的 canary deploy 實踐把金流場景的 progressive rollout 跟交易指標綁在一起：每一批放量用 checkout success rate、duplicate charge、退款率判斷是否安全。金流的 feedback loop 比一般功能長（結帳 → 確認 → 對帳 → 退款），觀察窗必須對齊這個延遲。

gate 類別

這張表的重點是每一類都要對應 owner 與回退條件，分類只是組織方式。沒有回退條件的 gate，只是心理安慰。

變更分層跟 gate 政策

變更分層是把變更依失敗代價跟回退成本切成不同 gate 政策的控制面。讓高風險變更承受高 gate 成本、低風險變更不被高成本拖累、是分層治理的核心責任。可重複套用的做法是先做變更分層、再對應分層 gate 政策。

對應 MS1 Microsoft 變更治理與可靠性門檻：揭露「變更分層 + 漸進發布 + 復盤回寫」三個機制、適用大型 SaaS 高頻變更累積回歸的場景。對應 G2 Google Postmortem AI Closure：揭露 P0/P1 action item 必須綁定 release gate、未完成不得放行關聯變更（這層綁定讓 gate 從 release 工具升級為事故治理工具）。詳見 6.21 Action Item 分級跟 Release Gate 綁定。

可操作的分層方法：

• 低風險變更（配置微調、文案、UI 細節）：CI green + SLO 健康 即可放行
• 中風險變更（新 feature、依賴升級）：加 canary + per-version SLI 偏差檢查
• 高風險變更（schema migration、payment / auth 路徑、跨 region rollout）：加 evidence package + 高風險時段 freeze + P0 action item closure 檢查

高風險層的三類變更要拆開治理、彼此 gate 機制不同：schema migration 的 gate 重點是 expand/contract 階段對齊跟 rollback 路徑（詳見 6.11 migration-safety）；跨 region rollout 的 gate 重點是 ordered failover 跟 blast radius 限制（詳見 6.14 dependency-reliability-budget）；payment / auth 路徑的 gate 重點在交易一致性跟 idempotency（詳見後段「交易類變更的 gate 設計」跟 6.12 idempotency-replay）。三者皆屬高風險、但失敗模式跟回退路徑完全不同。

分層後高風險變更得到匹配的 gate 強度、低風險變更不被拖累、整體交付節奏跟可靠性同步提升。

交易類變更的 gate 設計

交易類變更的 gate 同時承擔可用性跟正確性兩條軸。除了服務健康（一般 gate 已覆蓋）、還要守住交易結果一致性；回退條件也要多看一層：rollback 是否會觸發資料不一致。

對應 S1 Stripe Idempotency 與零停機遷移：揭露 idempotency key + expand/contract migration + canary + rollback gate + transaction observability 四機制組合、適用支付類「可用性 + 正確性同時守住」的場景。

交易類變更的 gate 跟一般 release gate 差別在：

• 一般 release gate 看「服務是否健康」、交易類 gate 還要看「交易結果是否一致」
• 一般 release gate 看「回退是否可行」、交易類 gate 要看「回退是否會引發資料不一致」
• 一般 release gate 看「per-version SLI 偏差」、交易類 gate 要看「duplicate request collapse ratio」「migration phase error drift」「canary transaction anomaly」這類交易專屬訊號

把交易類變更的 gate 從一般 release gate 分出來、寫進獨立 checklist、由 6.12 idempotency-replay 跟 6.11 migration-safety 提供具體欄位。

產業情境：金融科技

金融服務的 release gate 需要把交易正確性放在跟可用性同等的位置。一般 SaaS 的 gate 主要看 error rate 和 latency；金融服務的 gate 需要加上 duplicate detection、settlement 一致性與 compliance audit trail。

變更風險分層跟交易路徑綁定。碰到 payment path 的變更（provider 切換、timeout 調整、retry 策略、settlement 流程）自動升級到高風險 gate，不論變更看起來多小。payment path 的變更即使只改一個 timeout 值，也可能影響交易成功率、重試行為與對帳結果。

Gate 通過條件需要包含交易專屬欄位。idempotency 驗證確認重試不會產生重複扣款；reconciliation 通過確認結算數字一致；audit trail 完整確認每個決策都可追溯。這三項跟一般的 CI green / SLO healthy 是不同維度的檢查，需要獨立 checklist。

高風險變更的 canary 觀察窗需要涵蓋結算週期。一般 feature rollout 的觀察窗是分鐘到小時級；金融變更的觀察窗需要涵蓋 T+1（隔日結算）甚至 T+2，因為交易確認延遲、退款申請與對帳差異可能在數小時到數天後才暴露。觀察窗太短會讓問題在全量放行後才被發現。

Rollback 決策需要考慮已完成交易的一致性。當新版已處理交易且交易已進入結算流程，rollback 可能比繼續 roll-forward 更危險 — 退回舊版的 schema / 邏輯可能無法正確處理新版產生的交易紀錄。這個判斷跟 6.7 rollback vs roll-forward 的判斷條件 對齊，但金融場景的資料不可逆性更高。

產業情境：IoT 與製造系統

IoT 的 release gate 需要處理「一旦推出就難以全面回收」的不可逆壓力。雲端服務的 deploy 可以秒級 rollback；IoT firmware 一旦推送到裝置，回收需要每台裝置個別 OTA，受限於連線狀態與頻寬。

裝置碎片化要求 gate 按硬體版本分群驗證。同一產品線可能有多個硬體版本（rev A / B / C），每個版本的 firmware 相容性不同。release gate 需要按硬體版本群組各自跑 checks，通過的群組才放行推送，不能全域一次放行。

IoT 的 canary 是按裝置群組分批推送，而非按流量百分比分流。推送順序通常是：內部測試裝置 → beta 用戶 → 特定區域 → 全域。每批的觀察窗需要比雲端更長（天到週），因為裝置的 failure mode 可能在特定環境條件下才觸發 — 溫度、濕度、網路品質、電力穩定度都是變數。

OTA 推送一旦開始，中途停止意味著部分裝置已更新、部分未更新。stop condition 需要同時監控「已更新裝置的健康度」和「混合版本之間的相容性」。若新舊版本的通訊協議不相容，部分更新的裝置群可能會觸發新的 failure mode。

安全關鍵系統（車載、醫療設備、工業控制）的 gate 需要額外的功能安全驗證（IEC 61508 / ISO 26262 等），通過合規驗證是放行的前置條件。這類 gate 的 owner 通常跨越工程與合規兩個團隊。

Amazon A2 的 static stability 跟 IoT 的離線運作需求對齊 — 裝置在控制面（OTA server）不可用時，用本地快取的配置繼續運作，回復路徑不依賴已故障的控制面。

交接路由

• 6.1 CI pipeline：CI evidence 是 release gate 的主要輸入
• 05 部署：canary / progressive delivery 實作
• 06.6 SLO：error budget 餘額查詢
• 06.10 contract testing：契約通過作為放行條件
• 06.11 migration safety：可逆性檢查
• 01.7 Schema Migration Rollout 證據：把 migration evidence 轉成 gate decision、checks、stop condition 與 rollback window
• 06.13 perf regression gate：退化作為 freeze 條件
• 07 資安：高風險變更的權限約束
• 08 事故閉環：事故進行中 freeze 觸發
• 06.17 feature flag：rollout 的細粒度控制層
• 06.18 reliability metrics：CFR 是 gate 健康度