生产网络变更的「回滚预案」，你团队是真有还是靠重启祈祷？

【背景】

做了 15 年网络工程，从运营商核心网到互联网数据中心，再到现在帮业务侧做网络运维，一个观察越来越强烈：应用侧的变更管理（灰度、金丝雀、一键回滚）已经相当成熟，但网络侧的变更管理在很多团队还停留在"凌晨三点割接 + 祈祷"的阶段。

上周帮一个团队做 BGP 路由策略调整，变更窗口定在周日凌晨 2 点。我问了一句"如果新策略推上去流量全被吸到错误出口，怎么回？"对方想了想说："再执行一次旧配置呗。"我追问"如果旧配置和中间状态冲突，路由震荡超过 30 秒，下游有会话保持的业务呢？"对方沉默了。

这件事让我意识到，"回滚"在网络侧不是一个技术问题，而是一个组织习惯问题——大多数团队从来没有认真想过"改坏了怎么办"，因为历史上"改坏了"的概率确实不高，直到那一天。

【常见分歧 / 几种做法】

我观察下来，团队大致分三种：

1. "重启即回滚"派：网络变更 = 改配置 → 验证 → 有问题就 reload / reboot。成本低、上手快，但回滚窗口可能是分钟级甚至更长，期间业务是裸奔的。很多中小团队实际就是这套。
2. "双配置热切换"派：维护两套配置，通过 VRF / 策略路由 / BGP community 切换。回滚快（秒级），但配置维护成本翻倍，而且两套配置长期不同步本身就是风险源——我见过因为"双配置漂移"导致切换后反而比变更前更糟的案例。
3. "网络侧也搞灰度"派：按节点 / 按 AS / 按流量比例逐步推策略，类似应用侧 canary。最安全，但对网络工程师的自动化能力要求高，很多中小团队没有这个基础，硬上反而把"灰度"变成了"灰度地手敲"。

【我的倾向与理由】

我偏向**"第 2 种做到 80 分 + 第 3 种做到 30 分"**的组合，理由：

• 纯靠"重启即回滚"，你在赌 MTBF 和 MTTR 的比值。网络故障不像应用 bug，它往往有级联效应：一条 BGP 策略错误 → 流量黑洞 → 上游超时重试 → 下游雪崩。回滚 30 秒和 5 分钟，对下游业务的伤害不是线性的，是指数级的。
• 但"双配置热切换"的维护成本是刚性的：每次变更都要同步两套，配置漂移是时间问题。所以我不建议无脑双活，而是对核心出口和骨干路由做双配置，对边缘接入和终端侧允许单配置 + 快速 reload。
• "网络侧灰度"方向是对的，但落地前提是自动化。如果你们的变更流程还是"登录设备 → 手敲命令 → 截图存档"，那灰度只会放大风险。

一句话：回滚预案的粒度应该和该链路承载的业务爆炸半径成正比，而不是一刀切。

【想听大家在什么场景下怎么选】

1. 你团队的网络变更（BGP 策略、ACL、VLAN、路由表）有正式的回滚预案吗？还是"改之前截图、改坏了 reload"？
2. 你们怎么判断一条链路"需要双配置热切换"、哪些"单配置 + reload 就够了"？有没有一个明确的判据？
3. 有没有人真的在核心网路上做过"按流量比例灰度推策略"？具体怎么做的，踩了什么坑？
4. 变更窗口（凌晨 vs 业务低峰 vs 随时）你们怎么选？有没有因为"必须凌晨"而错过白天验证机会的案例？

欢迎带具体场景来聊，越具体越好。