Gate 形式

Gate 形式要依控制範圍選擇。PR 合併、job 執行順序、production 發布與 artifact 傳遞是四種不同責任，混在一起會讓紅燈的意義變模糊。

Required checks 適合保護主線。它讓測試結果成為合併條件，避免紅燈變更進入 main 或 release branch（backend 延伸見 CI Pipeline）。

Job needs 適合同一條 workflow 內的發布管線。它讓 deploy 必須等 test、build 或 package 成功後才執行，避免 deploy job 先於驗證結果流動（platform 延伸見 Deployment Contract）。

Environment protection 適合正式環境。即使 build 與測試通過，production 或其他目標環境仍可要求人工審核、特定分支或特定 reviewer 才能部署（治理延伸見 Release Gate）。

Artifact handoff 適合避免「測試一份、發布另一份」的漂移。較嚴謹的流程會讓 build job 產生 artifact，test job 驗證這份 artifact，deploy job 發布同一份 artifact（供應鏈延伸見 Artifact Provenance）。

Workflow 邊界

Workflow 邊界的責任是決定哪些步驟共享同一條執行圖。放在同一條 workflow 裡的 job 可以用 needs 建立顯式依賴；分散在不同 workflow 裡的流程，通常要靠 branch protection 或 environment protection 建立跨 workflow gate。

多 workflow 的關鍵風險是順序假設。GitHub Actions 的 workflow 彼此獨立；跨 workflow 順序需要靠 repository 設定或 API 顯式串接。

發布阻擋判讀

發布阻擋要同時看 YAML 與 GitHub repository 設定。YAML 說明 workflow 或 job 如何執行；跨 workflow 的「測試通過才發布」通常要靠 Branch Protection、required status checks 或 environment protection。

這個判讀順序能避免錯修。若測試紅燈但目標環境仍發布，問題通常在 deploy gate 尚未把測試狀態納入發布條件。

常見反模式

反模式的共同問題是讓 CI 綠燈與發布安全之間失去因果關係。CI 的目標是讓綠燈代表「這次變更在定義好的條件下可進下一階段」。

Tripwire

Tripwire 的責任是提示什麼時候 workflow 結構需要重切，讓團隊從局部 patch 回到 gate 設計。

• 測試紅燈仍發布：把 deploy gate 顯式化，使用 required checks 或同 workflow needs。
• 本機常常重現不出 CI：把命令收斂到 Makefile 或 npm scripts，減少 workflow 專屬命令。
• 測試常因 artifact 缺失失敗：建立 artifact handoff，讓測試與發布使用同一份產物。
• workflow 說明與實作分叉：同步更新 workflow 文件與 YAML，讓維護入口保持可信。

下一步路由

• CI 紅燈處理流程：讀 CI 失敗到修復發布流程。
• 靜態站部署案例：讀 本 blog 專案部署。
• 可靠性層的 release gate：讀 6.8 Release Gate 與變更節奏。

規則推送安全閘門（rule rollout safety gate）的核心責任是防止控制面錯誤快速擴散到資料面。這個閘門是補上「規則與配置類變更」特有風險，跟既有 release gate 互補而非取代：變更體積小、覆蓋範圍大、擴散速度快。

當變更屬於 WAF rule、routing policy、token/policy、或 Addressing API 相關設定時，判讀重點從程式碼正確性轉為擴散控制。這類變更即使 diff 很短，也可能在數十秒內影響跨區域流量與多產品控制面。

適用場景

產業情境：遊戲服務的規則推送安全

遊戲的規則推送（平衡性調整、反作弊規則、賽季設定、經濟系統參數）有特殊的擴散特性：影響面是全體玩家、生效時機即時、且玩家行為會立刻適應規則變更。

規則推送的 blast radius 預設是全體在線玩家。一次平衡性調整會立刻改變所有正在進行的比賽的角色強度、裝備數值或技能效果。跟一般 feature flag 的 percentage rollout 不同，遊戲平衡性需要所有玩家看到相同規則，否則同場比賽的公平性會被破壞。

推送時機需要跟 match lifecycle 對齊。在進行中的比賽套用新規則會造成不公平 — 某隊在舊規則下建立的優勢可能在新規則下消失。安全做法是在 match boundary（比賽開始或結束時）切換，讓新規則只套用到新開始的比賽。這要求規則推送系統能區分「已開始的 match」和「即將開始的 match」。

回退條件需要綁定遊戲特有的 KPI。active player count 下降超過門檻、match completion rate 異常降低（玩家中途離開）、player report rate 上升（玩家回報異常體驗）、in-game economy anomaly（虛擬貨幣或道具流通量異常）都是規則推送出問題的訊號。這些 KPI 的 feedback loop 比一般服務長 — 玩家行為的適應需要數小時到數天才會穩定，短窗觀察可能漏掉延遲暴露的問題。

反作弊規則的推送有額外約束：規則內容本身是機密的，推送失敗後不能在 log 或 alert 中暴露規則細節，回退也必須在不洩漏偵測邏輯的前提下進行。

Gate 檢查層

判讀訊號

• 控制面變更後，多區域同時出現 5xx / timeout / auth 失敗
• 指標在秒級惡化，且與最新規則或 policy 變更高度同時
• 回退後短時間明顯回穩，顯示變更與故障高度關聯
• 部分服務可自助恢復、部分服務需人工修復，代表狀態損壞分層
• 事故中出現「每個產品都在修自己的症狀」，代表 shared dependency 沒被先識別

最低可執行 Gate

1. 變更分類：將規則/配置/控制面 API 變更標為 high-blast-radius change。
2. 語意檢查：對 query 參數、空值與預設行為做拒絕式驗證。
3. 成本檢查：用代表性 payload 跑 rule-level CPU / latency 測試。
4. 分批推送：至少分成小流量群組與全量兩階段，且每階段有回退條件。
5. 撤告保護：對 withdrawal / delete 設速率與數量上限，超限自動中止。
6. 決策紀錄：事故期間保留假設、證據、回退門檻、owner 與狀態差異。

反模式

案例回扣

• Cloudflare 2019 Regex CPU Outage
• Cloudflare 2023 Control Plane Token Incident
• Cloudflare 2026 BYOIP BGP Withdrawal

這三個案例對應同一個上位問題：控制面小變更如何在短時間擴散成全網事故。不同事故只是擴散路徑不同，gate 核心都是「先限制擴散、再修復功能」。

下一步路由

• 04： 4.17 Telemetry Data Quality
• 06： 6.8 Release Gate
• 06： 6.20 Experiment Safety Boundary
• 06： 6.23 Verification Evidence Handoff
• 08： 8.19 Incident Decision Log
• 08： 8.22 Incident Evidence Write-back

服務路徑與風險模型

示範路徑是 checkout API 切換 payment provider timeout/retry 設定。這類變更看起來只改 config，但會直接影響交易成功率、延遲與重試風暴。

gate 應固定五欄：Gate decision、Checks、Stop condition、Rollback window、Owner。欄位先成立，再討論工具落地。

以 payment provider timeout 調整為例，五欄的具體內容：

Checks 欄位的數值來自歷史 baseline，每次變更前從 production 最近 7 天取值。baseline 偏移超過 10% 時，先校準再啟動 canary。

實作步驟

1. 定義放行前檢查：checkout 成功率、provider timeout 比率、duplicate charge 監控、error budget 餘量。
2. 設定 canary 節奏：1% -> 5% -> 25% -> 100%，每批觀察固定時間窗。
3. 為每批設定 stop condition：error rate、latency、provider timeout 任一超門檻即停止擴大。
4. 設定 rollback window：例如 15 分鐘內可無資料格式衝突地回退設定。
5. 把每批結果寫入 6.23 Verification Evidence Handoff 與 8.19 Incident Decision Log。

Canary 節奏與觀察窗

Payment 類變更的觀察窗比一般 config 變更長，原因有兩個。第一，交易確認有延遲 — provider 回傳 settlement 結果可能在數分鐘到數小時後，短觀察窗無法看到完整的交易結果分佈。第二，退款與爭議申請通常在交易後數小時甚至數天才出現，B3 階段需要持續追蹤退款率趨勢，確認新設定沒有引發 provider 層的異常判定。

證據留存格式

每批 canary 結束時留存一筆結構化證據，供 6.23 與 8.19 調用。

這個格式讓事故發生時，8.19 Incident Decision Log 可以直接調用每批的 metrics 與決策紀錄，不需要回溯 dashboard 截圖。

判讀訊號

常見誤區

把 gate 當成 CI 綠燈會漏掉依賴風險。依賴類變更需要觀測窗與停損條件，單靠測試通過不足以放行。

把 rollback window 寫成「可回退」但沒有時限也會失效。沒有時間邊界的回退通常意味著資料與行為已經漂移。

案例回寫

這條路徑可用 Stripe Idempotency and Zero-downtime Migration 回寫。先看交易正確性與變更節奏如何綁定，再回到本章對齊 gate 欄位與停損邏輯。

這個案例主要支撐的是「交易依賴變更放行節奏」判讀，不直接支撐 incident 通訊節奏；對外更新要回到 8.4。

跨模組路由

1. 與 4.22 的交接：證據來源使用 Checkout API Evidence Package。
2. 與 6.8 的交接：策略與制度回到 Release Gate 與變更節奏。
3. 與 6.23 的交接：每批驗證證據進 Verification Evidence Handoff。
4. 與 8.19 的交接：停損與回退決策同步到 incident decision log。

下一步路由

要看控制面事故如何用 decision log 與 write-back 關閉迴圈，接著讀 8.23 Control Plane Decision Log and Write-back 實作示範。

概念位置

Gate decision 位在 confidence、rollback window 與 incident decision log 之間。Checks 描述檢查結果，gate decision 把結果轉成放行、暫停、回退、fail-forward 或補證據。

可觀察訊號

系統需要 gate decision 的訊號是：

• CI、SLO、validation query 都有結果，但沒人知道下一步
• evidence 足以支持部分放行，但不足以支持完整 cutover
• 變更需要逐批 rollout、backfill、warmup 或 replay
• gate 要保留 owner 與 rollback window

接近真實網路服務的例子

資料庫 migration 的 gate decision 可以寫成 allow next 10% backfill; block customer-visible read cutover。這句話比 migration pass 更可操作，因為它同時說明允許前進的範圍與被擋住的風險面。

設計責任

Gate decision 要包含決策內容、支撐 checks、stop condition、rollback window 與 owner。它要能被 incident decision log 承接，讓放行後出現異常時能回放當時依據。

概念位置

Release Gate 位在 migration、schema change、deployment、error budget 與 incident policy 之間。它把驗證結果轉成可執行的放行決策，並常搭配 Rollback Rehearsal 確認放行前後都能回復。

可觀察訊號

系統需要 release gate 的訊號是：

• 變更會影響使用者可用性或資料正確性
• 新舊版本會並存一段時間
• 團隊需要在 release 前確認檢查項都過關
• 發版失敗時要有明確阻擋條件

接近真實網路服務的例子

Schema migration 要先確認相容性與 backfill 結果再放行；高風險設定變更要通過 security review 與 drift check；error budget 快耗盡時，團隊可以暫停高風險變更，直到風險恢復到可接受範圍。

設計責任

Release Gate 要定義檢查項、擁有者、通過條件、阻擋條件與例外流程。它是把風險控制流程標準化的機制，單純的批准按鈕無法達到同等效果。

常見形成條件

• build metadata 與來源提交缺少可回查關聯。
• 產物簽署驗證未納入 release gate。
• 供應鏈事件後缺少受影響 artifact 快速盤點機制。

判讀訊號

• 同版本 artifact 的來源紀錄不一致或不可追溯。
• 發佈關卡通過但缺少簽署驗證證據。
• 事件發生後無法快速定位受影響部署批次，導致 impact scope 判讀延後。

案例觸發參考

• SolarWinds 2020
• 3CX 2023
• XZ 2024

來源主題章節

• 7.12 供應鏈完整性與 Artifact 信任
• 7.R8 控制面失效樣式

下一步路由

本失效樣式對應的實作 chain：

控制面（mitigation 在這裡定義）：

• 7.2 身分與授權邊界

演練 / 控制落地（轉成欄位）：

• Vulnerability response pattern
• Evidence chain pattern

核心論點

資安進入 release gate 的核心概念是讓放行決策可回查。放行條件一旦包含風險與證據，變更速度與風險控制可以共同優化。

Gate 欄位

高風險變更流程

高風險變更流程的責任是讓放行有階段節奏。流程可分成預檢、驗證、審查、放行、回寫五步，並固定記錄風險假設與驗證結果。

例外治理

例外治理的責任是讓例外成為受控狀態。例外紀錄至少包含期限、補償控制、回收條件與 owner，並接到 tripwire。

與部署與可靠性交接

與部署與可靠性交接的責任是把 gate 決策接到執行層。放行結果可直接交接到部署流程、回退策略與 incident readiness。

判讀訊號與路由

從 Gate 通過到 control 實際驗證

Gate 通過代表流程跑完（risk classification + controls + evidence + exception 全填）；control 是否真在生產驗過、要靠兩條 chain：

• Evidence chain：evidence package 列的證據要對應到 control 實際 mechanism、不只填欄位。例：「TLS 已啟用」要附 cipher suite + cert valid + HSTS preload 證據、不只 prod 連得上 https。Mechanism 細節見 7.5 傳輸信任 跟對應 knowledge-card。
• Re-evaluation chain：tripwire 觸發 / 例外到期 / 事件 trigger 接到 7.14 例外治理 跟 7.x 主章節再評估。

Gate 通過 + 兩條 chain 跑通、放行才是 risk reduce 決策。Gate 跟 control 是流程層 vs 實作層、由 evidence 內容對應。

必連章節

• 7.14 資安治理例外與 Tripwire
• 7.B3 資安控制驗證
• 7.18 資安控制面如何交接到部署與事故流程
• 7.23 資安與可靠性的共同控制面

完稿判準

完稿時要讓讀者能為高風險變更建立資安 gate。輸出至少包含風險等級、控制驗證、證據包、例外條件與重評估觸發器。