深色模式
自动化审批流：生产变更门禁
摘要：自动化跑得越快，出错时影响越大。本文把「人的判断」嵌进流水线：分支保护 + CODEOWNERS 做代码门禁，环境审批做发布门禁，变更窗口与紧急通道兜住特殊情况。
适用环境
- Git 仓库托管于 GitLab / GitHub / Gitea
- 已有 CI/CD 流水线
- 团队规模 ≥ 2 人（能形成互相评审）
操作步骤
1. 代码门禁
bash
mkdir -p .github && cat > .github/CODEOWNERS <<'EOF'
/deploy/prod/ @ops-lead
/terraform/prod/ @ops-lead @sre
* @ops-team
EOF1
2
3
4
5
2
3
4
5
仓库设置里开启：Require a pull request before merging、Required approvals: 1、Require review from Code Owners、Require status checks to pass。
2. 流水线门禁：检查必须真拦得住
yaml
lint:
script: [yamllint ., terraform fmt -check -recursive]
test:
script: [make test]
security_scan:
script: [trivy config .]
allow_failure: false # 关键：不要让它成为可忽略的装饰1
2
3
4
5
6
7
2
3
4
5
6
7
allow_failure: true 会掏空门禁
把安全检查设成允许失败，等于装了个不响的警报器。
3. 环境门禁
yaml
# GitHub Actions
deploy_prod:
needs: [build, test]
environment: production # Settings → Environments 配 Required reviewers
steps: [{ run: ./deploy.sh prod }]1
2
3
4
5
2
3
4
5
yaml
# GitLab CI
deploy_prod:
stage: deploy
rules: [{ if: '$CI_COMMIT_BRANCH == "main"', when: manual }]
environment: { name: production }1
2
3
4
5
2
3
4
5
GitLab 还需在 Settings → CI/CD → Protected environments 指定允许部署的人。
4. 变更窗口控制
bash
cat > /opt/scripts/check-window.sh <<'EOF'
#!/usr/bin/env bash
set -euo pipefail
now_hm=$(date +%H%M); dow=$(date +%u) # 1=周一 ... 7=周日
if (( dow >= 6 )); then echo "BLOCK: 周末禁止生产发布"; exit 1; fi
if (( dow == 5 && now_hm > 1600 )); then echo "BLOCK: 周五 16:00 后禁止发布"; exit 1; fi
if (( now_hm < 1000 || now_hm > 1800 )); then echo "BLOCK: 仅允许 10:00-18:00 发布"; exit 1; fi
echo "OK: within change window"
EOF
chmod +x /opt/scripts/check-window.sh1
2
3
4
5
6
7
8
9
10
2
3
4
5
6
7
8
9
10
5. 紧急通道（Break Glass）
预先定义 2-3 名紧急角色可跳过审批；紧急发布自动记录审计（谁、何时、改了什么）；事后 24 小时内补齐评审与代码回写；每月统计使用次数，用得多说明流程有问题。
危险
紧急通道权限必须定期复核（建议每季度）。人员变动后遗留的「幽灵权限」是最常见的安全缺口。
验证
bash
/opt/scripts/check-window.sh; echo "exit=$?"
git push origin main # 直接向受保护分支 push 应被拒绝1
2
2
- [ ] 未评审的 MR 无法合并到主分支
- [ ] 生产部署 job 等待指定审批人确认
- [ ] 非变更窗口时发布被脚本拦截
常见坑
审批人就是提交人
自己提自己审等于没审批。开启「禁止作者批准自己」或在 CODEOWNERS 指定不同人。
门禁太多导致绕过
低风险变更自动化放行，只有真正影响生产的才设人工门禁。
审批的内容和执行的内容不一致
审批后到执行期间代码又变了。必须用 plan 存档或固定 commit SHA 发布。