审批与窗口各管什么
审批解决授权与影响面：变更对象、风险等级、回滚方案、验证口径、审批人，本质是「谁有权改、改了要担什么责」。窗口解决时机与条件：允许执行的时间段、冻结期、在位值班人力、监控与告警是否处于可观测状态。两者不能互相替代——审批过的变更放到业务高峰执行，风险依然不可控；在无人值守的凌晨批准一项需要人工验证的变更，同样会扩大故障时间。
基本信息
| 适用场景 | 生产系统、网络与安全设备、数据库、Kubernetes 集群的配置与批量操作 |
|---|---|
| 审批要素 | 变更单号、对象与影响面、风险等级、回滚方案、验证口径、审批人 |
| 窗口要素 | 低峰时段、冻结期、窗口时长、在位人力、告警与静默安排 |
| 关键约束 | 审批与执行分离，同一人不应既批准又实施 |
典型使用场景
- 高危变更：重启数据库实例、改防火墙策略、批量重装组件，必须二次确认
- 业务冻结期：大促、结算、财报窗口内只放行紧急修复
- 跨团队联合变更：需要网络、系统、应用三方同时在线时统一开窗
- 合规行业：变更有留痕与可追溯要求，审批记录是审计证据的一部分
- 批量自动化作业：脚本执行前先校验当前是否在允许窗口内
变更单与窗口校验示例
变更单与窗口校验示例
# 变更单关键字段（字段名按自家平台调整，此处仅示结构）
id: CHG-2317
target: 订单库主从 10.20.1.0/24
risk: 高
window: 2026-10-18 02:00-04:00
rollback: 还原 my.cnf 并重启实例，预计 5 分钟
verify: 主从延迟小于 1 秒、连接数回落、告警消警
approver: 数据库组负责人
# 窗口外自动阻断（流水线前置检查或包装脚本）
hour=$(date +%H)
case "$hour" in
02|03) echo "在窗口内，允许执行" ;;
*) echo "窗口外，拒绝执行" >&2; exit 1 ;;
esac
# 冻结期名单同样应做成可读配置，而不是记在某人脑子里
grep -q "$(date +%F)" freeze-dates.txt && { echo "冻结期，需走紧急通道"; exit 1; }变更分级与闸门对照
| 变更等级 | 审批要求 | 窗口要求 | 回滚要求 |
|---|---|---|---|
| 低 | 值班负责人知会 | 常规工作时间 | 可人工改回 |
| 中 | 组件负责人批准 | 避开业务高峰 | 备好回滚脚本 |
| 高 | 负责人加业务方批准 | 固定维护窗口并通知 | 预演过的回滚方案 |
| 紧急 | 口头授权后补单 | 立即执行，事后复盘 | 优先止血，后续补齐配置 |
紧急变更需要一条明确的快速通道：谁能批、批完多久内必须补单、复盘在多久内完成。通道缺失的后果是大家绕开流程直接改，流程与事实两张皮。
批准的对象必须与实际执行的对象一致。审批时写「两台数据库」，执行脚本里却是整个网段，这类漂移比没有审批更危险，因为团队误以为风险已被评估。