發布批準過程
1）目標及責任範圍
發布批準過程可實現可預測且安全的平臺更改，而無需違反SLO，收入和合規性。它涵蓋了整個過程：從拉力請求到完全晉升到prod和後監視。
2）原則
1.SLO-first：只允許在綠色SLI/無燃燒率的情況下發布。
2.小批量和可逆性：金絲雀/漸進式交付，快速回滾。
3.Policy-as-Code：網關、SoD、免費窗口和風險類-自動驗證。
4.真相的單一來源：文物/偽像/標誌-在Git中，星期三由GitOps重新配置器給出。
5.審核和可證明性：WORM日誌，決策足跡，清晰的所有者。
6.默認安全性：單獨的秘密、最低權限、地理門。
7.無意外通信：準備好的內部/外部更新模板。
3）角色和RACI
Release Manager （RM）-流水線、日歷、門的所有者。A/R
服務所有者（SO）-域所有者,承擔風險,準備工件。A/R
SRE/Platform-SLO門、滾動、自動回滾。R
QA Lead-檢查策略，測試結果。R
Security/Compliance-掃描、SoD、監管。C/A
CAB（更改咨詢委員會）是Normal Class的解決方案。A
呼叫上IC/CL-事件準備和通信。R/C
Stakeholders （Biz/Support/Partners）-通知。I
4）更改類和匹配路徑
升級-跨越風險邊界（付款，RG，PII，限制）。
5）發布和門管道（直通流）
第0階段。計劃和日歷
Freeze窗口（假期/比賽），on call插槽和CL，狀態模板的準備。
階段1。PR → Build
Linters/許可證，SBOM，單位/合同測試，秘密掃描。
階段2。整合/安全
E2E（虛擬化PSP/KYC）、SAST/DAST、dependency評論。
階段3。Staging/排練
銷售平價，可逆遷移，ficheflagi 5-25％，「發行鉆頭」支票單。
Gate A-質量和安全（必要）
+所有測試/掃描綠色
+電路/configs驗證,沒有「紅色」SLI staging
+SoD/4-eyes用於高風險更改
階段4。主辦項目（金絲雀送貨）
1-5％的流量按細分市場（tenant/geo/bank），runtime驗證器，guardrails。
Gate B-SLO/商業門
+沒有SLO/KRI降解（潛在性/錯誤/付款）
+實驗度量中沒有SRM/異常
+Comms準備就緒： 狀態/合作夥伴草稿
階段5。坡道→ 25% → 100% （區域/tenant）
帶有後監視計時器的分步促銷。
階段6。後期監測（30-60分鐘）
發布dashboard，burn-rate，投訴/滴答聲，自動關閉/違規時滾回。
6）自動化解決方案（策略引擎）
偽規則：- SLO-гейт: `deny promote if slo_red in {auth_success, bet_settle_p99}`
- PII-export: `require dual_control if config.affects == "PII_EXPORT"`
- Freeze: `deny deploy if calendar.freeze && not emergency`
- Rollback: `auto if auth_success_drop > 10% for 10m in geo=TR`
7）發布文物
發行聲明（強制）：目標，風險等級，區域（tenant/region），標誌，遷移，推出計劃，回滾計劃，所有者，聯系人。
Evidence Pack：測試/掃描結果,dashbords staging, dry-run遷移截圖。
Comms Kit：狀態模板（內部/外部/合作夥伴）,ETA/ETR。
Backout Plan：準確的回滾步驟及其觸發的標準。
yaml release:
id: "2025. 11. 01-payments-v42"
owner: "Payments SO"
risk_class: "normal"
scope: { tenants: ["brandA","brandB"], regions: ["EU"] }
rollout:
steps:
- { coverage: "5%", duration: "20m" }
- { coverage: "25%", duration: "40m" }
- { coverage: "100%" }
migrations:
- id: "ledger_ddl_0042"
reversible: true flags:
- id: "deposit. flow. v3"
guardrails: ["api_error_rate<1. 5%","latency_p99<2s"]
rollback:
autoIf:
- metric: "auth_success_rate"
where: "geo=TR"
condition: "drop>10% for 10m"8）金絲雀/藍綠色/特色旗
金絲雀-安全違約：覆蓋率低，GEO/tenant/BIN細分。
Blue-Green-用於重大更改：切換路線,快速回滾。
標誌用於行為場景：TTL，kill-switch，guardrails，SoD。
9）管理秘密和秘密
Configi作為數據，方案和驗證者；GitOps促銷帶有漂流檢測器。
秘密-在KMS/Secret Manager、JIT訪問、審核和掩碼中。
10）通訊和狀態頁面
內部：var-rum/聊天，on-colls警告，升級模式。
外部：僅通過CL發布的出版物，預先準備的草稿。
合作夥伴（PSP/KYC/工作室）：在影響集成時發出目標通知。
狀態：發布不是事件,但具有帶有度量的監視窗口。
11）緊急發布（緊急）
觸發因素：P1降解，漏洞，PII/RG風險。
路徑：IC+RM解決方案→最小門集（linter/組裝） → canary 1-2% →監控→推廣。
必然：CAB事後文件，後面文件≤ D+5，記錄妥協。
12）審計，SoD和合規性
SoD/4-eyes：PSP路由、獎金限額、數據出口的變化。
WORM期刊：誰/什麼/何時/為什麼；策略版本；diff 版本/標誌/configs。
Geo/Privacy：所需司法管轄區的數據和記錄；文物中缺乏PII。
13）可觀察性和後期控制
Dashboard發布：SLI （auth-success, bet→settle p99）, error-rate,抱怨,轉換,lagi隊列。
Alerts： burn-rate、SRM、5xx增長、PSP 在銀行/GEO上的退化。
報告：CFR，MTTR發布事件，平均後監測時間，自動回滾率。
14） KPI/KRI過程
Lead Time for Change （PR→prod）, Change Failure Rate, MTTR發布事件。
SLO-gates pass rate, Auto-rollback rate, Freeze compliance.
發布演習（排練），SoD暴力（目標-0）。
Comms SLA（有草稿，遵守時間）。
15）實施路線圖（6-10周）
奈德。1-2：定義更改、門和工件的類別；包括林特，SBOM，秘密掃描；發布和凍結日歷。
奈德。3-4： GitOps for configs、canary/blue-green、SLO門、Comms模板和var room。
奈德。5-6：政策引擎（SoD/4-eyes，風險規則），按指標自動滾動；dashboard發行版。
奈德。7-8：排練（staging drills），與ficheflags/事件機器人集成，KPI/KRI報告。
奈德。9-10：WORM審計，DR發布演習，CFR優化，角色培訓（RM/SO/CL/IC）。
16）反模式
無可逆性發行版和金絲雀→大規模事件。
忽略SLO門「為了截止日期」。
沒有電路和TTL的configs/標誌 →「凍結」狀態。
手動點擊在銷售中,沒有Git/審核。
沒有CL角色和模板的公共升級。
存儲庫中的秘密；沒有JIT和日誌的可用性。
CAB作為無數據制動器：解決方案必須得到發布指標的支持。
底線
發布批準過程是一個工程和管理框架，可連接質量，安全性和速度：策略作為代碼，SLO門，漸進式交付，透明通信和可證明的審計。這種方法可以降低CFR和MTTR，保護收入和合規性，並允許團隊經常安全地釋放價值。