生产变更：审批流程是底线还是枷锁？聊聊你们团队的真实做法

做运维 3 年，"变更管理"大概是团队里最容易被提起、也最容易被质疑的环节。每次出了事故复盘，总有人甩一句："当时为什么要走审批？直接回滚不就完了？" 但反过来看，没有审批流程的团队，出事故的概率往往更高。今天想把这道"流程 vs 速度"的选择题抛出来，听听大家的真实做法。

【背景：三种典型立场】

生产变更（改配置、发版、动数据库、调网络）是运维日常最高频的操作，但"怎么做"这件事，不同团队的分歧大到像两个行业：

派系 A「流程即底线」：所有生产变更必须走审批流——提单 → 技术评审 → 负责人审批 → 变更窗口执行 → 验证 → 关单，6 步少一个都不行。理由：流程是防呆机制，99% 的事故是"人脑抽风"导致的（敲错 IP、删错库、改错参数），流程就是给大脑上保险。

派系 B「流程是枷锁」：审批流拖慢响应速度，凌晨 3 点 P0 等你审批？等审批的 20 分钟里故障已经扩散了。正确做法：CI/CD 流水线自动触发 + 完善的回滚脚本 + 充分灰度。人只审"变更内容对不对"，不审"变更动作能不能做"。理由：回滚能力 > 审批流程，能 30 秒回滚就不需要 30 分钟审批。

派系 C「分级处理」：按变更风险分级。低风险（改日志级别、清缓存）→ IM 说一声就执行；中风险（发版、改核心配置）→ 提单 + 1 人审批；高风险（动 DB schema、改网络拓扑）→ 评审会 + 多人审批 + 变更窗口。理由：一刀切要么太松要么太紧，分级才能兼顾速度和风险。

【我的倾向：派系 C，但有一条硬底线】

我们 6 人运维团队，具体做法：

• 低风险变更（改非核心配置参数、清缓存、重启非核心服务）：IM 里 @值班同学说一声，5 分钟内确认无异议就执行，不提单。
• 中风险变更（应用发版、核心配置变更、扩缩容）：Jira 提单，1 个技术负责人审批，变更窗口内执行（工作日 10:00-16:00）。回滚脚本必须提前写好并在 staging 跑通过。
• 高风险变更（DB schema 变更、网络拓扑调整、安全策略变更）：提前 48h 提评审，至少 2 人参加评审会，变更窗口内执行，执行时 2 人在场（1 人操作 + 1 人独立验证）。

硬底线只有一条：无论什么级别，回滚方案必须写在变更单里。没有回滚方案的变更，审批直接打回，不讨论。

上个月的数据：14 次变更，12 次低风险（平均 8 分钟含确认），1 次中风险（发版，23 分钟，灰度 10%→50%→100%），1 次高风险（DB 加索引，15 分钟，提前准备了 DROP 回滚语句）。0 次回滚，0 次事故。

【想听大家的】

1. 你们团队的变更分级标准是什么？"低风险"和"中风险"的边界具体画在哪里？比如"改一个超时参数"算哪级？
2. 审批流走什么工具？Jira、GitLab MR、还是 IM 里口头确认？有没有人真的在凌晨 3 点等审批的？等了多久？
3. "回滚方案必须写在变更单里"这条你们有吗？如果没有，出过"想回滚但不知道怎么回滚"的事故吗？当时怎么处理的？
4. 自动化程度做到什么级别？CI/CD 覆盖了多少变更类型？剩下的手动变更占比大概多少？
5. 变更窗口怎么定？你们允许"紧急变更"跳过审批直接执行吗？跳完之后补什么流程？

欢迎贴你们的具体流程和踩坑经历，数字越具体越好。