变更审批到底在防什么：效率、安全，还是"出了事有人签字"？

背景

我管网络设备 10 年（核心交换机、BGP 会话、VLAN 规划），变更管控是绕不开的日常。最近帮一个 200 人后端团队做网络侧改造，发现一个很魔幻的现象：网络设备改一条 ACL 要走 3 级审批 + 变更窗口 + 回滚预案文档，但同一个团队的应用发布——改一个 Spring 配置项、发一个灰度包——几乎"点一下就上生产"了。两个动作对用户的爆炸半径可能一样大，管控力度却差了一个数量级。

这件事让我很纠结，所以想抛出来跟大家聊聊。

社区里常见的三种立场

1. 派 A：审批是底线。 每次变更必须有工单、有审批人、有回滚预案。理由很朴素——"出了事有人签字，有人负责"。我理解这个诉求，尤其在金融、电信行业，审计合规是硬约束。但我的经验是：当审批流程太重，人会绕过它。我见过凌晨 3 点直接 SSH 进核心交换机改路由、绕开工单系统的案例——不是人不守规矩，是"正常流程走完要 40 分钟，故障已经扩散了"。

2. 派 B：审批是瓶颈。 90% 的变更是低风险配置（改个端口速率、加条 ACL、调个 MTU），走审批纯属浪费时间。真正的风险集中在 10% 的高危操作（改 BGP 邻居、动 VRF、切主备）。审批一刀切，让低风险变更也背了高危变更的代价。

3. 派 C：分级 + 自动化验证。 低风险自动放行 + 自动回滚，高风险才走人工审批。审批的重点不是"谁签字"，而是"变更前后有没有自动化验证"——改完 ACL 自动跑一遍拨测、改完 BGP 自动确认邻居 UP、改完路由自动对比流量分布。

我的倾向与理由

我站派 C，但有一个前提：自动化验证的覆盖率必须足够高，否则分级就是空话。

具体到网络侧，我做过的一套落地方案（成本量化）：

• 低风险变更（端口配置、ACL 增删、VLAN 调整）：CMDB 工单 → 自动下发 → 自动拨测验证（20 条核心路径 ping + traceroute）→ 通过则放行，失败则 30 秒内自动回滚。全程无人工审批，但有完整审计日志。总工时：2 人 × 3 天搭验证框架，之后每次变更节省 30~40 分钟审批等待。
• 高风险变更（BGP 邻居、VRF、主备切换）：仍走人工审批，但审批人不再是"领导"，而是另一个有同等权限的工程师（peer review），重点审的是"回滚预案能不能在 5 分钟内执行"。

核心逻辑：审批的价值不在于"有人点头"，而在于"有人在变更前想清楚了回滚路径"。如果这个思考可以用自动化验证替代（拨测通过 = 回滚路径可验证），那人工审批就是冗余的。

想听大家

1. 你们团队现在的变更管控流程是什么样的？审批链条多长？有没有"绕过流程"的案例？
2. 如果让你给"低风险变更"定一个自动放行的标准，你的阈值是什么？（哪些操作算低风险？验证指标是什么？）
3. 非网络领域（应用发布、DBA 操作、配置中心推送）的变更管控，你们觉得该不该跟网络侧拉齐标准？
4. 一个更尖锐的问题：如果自动化验证覆盖率只有 60%，剩下的 40% 你愿意用"人工审批"兜底，还是干脆不做？

欢迎从应用、DBA、SRE、网络任何一个角度来聊，我想看看不同角色的视角差异有多大。