守門的本質#

守門（gatekeeping）就是攔住「會搞壞 production 的程式碼」。

守門不是「把每筆變更交給工程師審查」，那會嚴重拖慢交付。守門是建構自動化把關工具，把規則內建到管線。

兩種守門模式#

人工審查的流程#

開發寫碼 → 測試 → CI/CD 驗證 → SRE 工程師人工審查 → 核可後部署

問題：每筆變更都得 SRE 來回，是速度殺手。

自動化守門的流程#

開發寫碼 → 測試 → CI/CD 驗證 → 內嵌驗證與審核 → 自動核可 → 部署

優點：守門被自動化、開發節奏不受影響。

案例：旅遊軟體的守門啟動#

延續前述案例。在指標、角色定義、缺陷流程都改善後，新需求引發更多變更，每次變更都是潛在故障源。

問題#

• 數月內出現多次 production 中斷
• 90% 與當期變更直接相關（例：程式變更引入 OOM）

解法#

1. SRE 把所有事故做 RCA，找出與變更的對應
2. 重審變更管理流程，確認 SRE 沒有介入發布前審查
3. 與 DevOps 合作，在 CI/CD 管線新增驗證步驟：
   • 回歸測試結果
   • 全域設定正確性
   • 底層基礎設施配置
4. 通過驗證後才允許進入 production
5. 中斷次數明顯下降；多數問題在使用者察覺前就被攔住

守門不是設置障礙，而是把品質檢查由人腦轉到機器腦。一旦做對，可靠性與交付速度可以同步成長。

守門適合誰#

• 適合：大型專案、變更頻繁、衝擊面廣
• 不適合：早期、變化快但規模小、團隊還在摸索

守門邏輯的設計需要技能。不是把任意檢查塞進管線就好——錯的守門會反過來拖慢交付。

教訓#

• 變更是大多數事故的根源：守住變更，就守住了一大塊可靠性
• 守門價值不在「人」，在「規則」：把人類審查變成可自動執行的規則
• 守門不該封閉：必要時保留人工 override 通道，避免守門本身成為瓶頸