发布批准过程
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，保护收入和合规性，并允许团队经常安全地释放价值。