发布审批门是什么
发布审批门（Approval Gate）是发布流水线中的人工确认点，设计目标只有一个：让审批人「看得懂、判得动」。做法上，审批界面要附齐三样信息——变更清单（含 MR 链接）、验证结果（测试与扫描）、回滚步骤；机制上可用 GitLab 手动作业/受保护环境、GitHub required reviewers、外部变更系统联动。信息不充分的审批等于盖章：审批人只能看绿灯，出了问题既挡不住也不增值。审批与自动化不冲突——构建、测试、预发全自动，人只在「上生产」这一步判断时机与风险。
基本信息
| 信息 | 变更清单、MR 链接、测试与扫描结果、回滚步骤 |
|---|---|
| 人员 | 独立于提交者的审批人；重大变更双人 |
| 机制 | GitLab 手动作业 / GitHub required reviewers / 外部变更系统联动 |
| 超时策略 | 自动取消或继续等待，写进流程并让值班人知晓 |
典型使用场景
- 生产发布门：验证通过后等待人工确认时机，避开业务高峰。
- 合规场景：变更审批记录留痕，满足审计对职责分离的要求。
- 高危操作（数据库迁移等）：双人确认，降低单人误操作概率。
- 跨团队发布：外部系统（变更单）联动，审批与工单状态一致。
- 紧急通道：事故时允许 break-glass 快速放行，事后补审并复盘。
审批信息模板
审批信息模板
版本：app 1.8.0（digest 已确认）
变更：3 个 MR（逐个列出链接）
验证：单测通过 / 集成回归通过 / 无高危漏洞
影响：涉及订单读取路径, 灰度 10% -> 100%
回滚：切换 Helm revision 3（预计 2 分钟, 已演练）审批要素对照
| 要素 | 常见反例 | 正确做法 |
|---|---|---|
| 信息 | 只见绿灯不见内容 | 变更+验证+回滚三件套 |
| 人员 | 固定单人 | 独立审批人加后备 |
| 记录 | 口头确认 | 平台内留痕可审计 |
| 超时 | 无限等待 | 明确超时策略 |
审批超时策略（自动取消或继续等待）写进流程并让值班人知晓，避免发布卡在下班时间无人处理。
预留紧急变更通道：没有 break-glass 流程时，事故中人人都会绕过门禁，事后补审加复盘比临时破例更可控。