集中式防火墙回滚演练设计

说实话，我见过最吓人的一次故障，不是策略写错了五元组，而是一条默认路由被指向了还没就绪的检查实例。路由收敛那几秒，几十个业务VPC的东西向流量同时丢了下一跳。集中式防火墙就是这样——你把检查能力收拢到一处，也把故障影响面收拢到了一处。一次误操作，影响面从“一个VPC”放大到“整个网络平面”。

所以我自己做回滚演练的时候，核心就盯一件事：出错后能不能在一分钟内回到已知良好状态。做不到，这个演练就没过关。

回滚要分层，顺序不能搞反

误阻断发生的时候，第一反应往往是“赶紧把策略改回去”。但如果引流本身就有问题，改策略是没用的。我按四个层级来组织回滚动作，演练时每层都要跑通：

• L1 路由层：撤销引流，把下一跳改回原网关。秒级完成，但会有路由收敛抖动。这是最快的止血手段，但代价是这段时间没有检查。所以我要求旁路不能静默，必须触发高优告警，15分钟内有人确认，事后补流量回溯。
• L2 策略层：回退到上一版策略快照。秒到分钟级，但要确认快照的时间点正确。
• L3 规则集层：回退单个规则组。分钟级，可能引入规则间的新冲突。
• L4 端点与DNS：切回备用出口或备用端点。受TTL影响，DNS缓存会延长恢复时间。

演练怎么设计才不流于形式

我见过太多团队的回滚演练就是“跑一遍脚本，没报错，通过”。这没用。真正有用的演练，要设计真实的故障场景：

场景一：策略误阻断。比如新规则把探针源地址所在的网段整体拒绝了。这时负载均衡判定后端全部不健康，业务全挂。演练要验证：探针路径是否从检查范围中排除了？逃生路由是否独立可用？

场景二：路由收敛异常。引流时路由收敛超过预期的1-2秒，或者某些VPC的路由没被正确改写。演练要验证：路由变更审计是否实时告警？能否快速定位是哪个VPC的路由出了问题？

场景三：容量打满。流量突增时集群自动扩容，但会话表打满导致随机丢包。演练要验证：容量监控是否到位？回滚脚本是否幂等，避免重复执行把状态改乱？

演练后的复盘比演练本身更重要

每次演练结束，我要求团队输出三样东西：时间线复盘（触发信号、判定依据、执行耗时、旁路时长）、资产清单更新（本次引流关系记录在案）、以及回滚方案的改进点。

说实话，集中式防火墙真正的门槛，不在于买多贵的设备，而在于让“改错”这件事变得可发现、可拦截、可逆。把引流写成代码、把规则放进流水线、把回滚做成一条命令——这套治理动作的价值，在第一次误阻断发生的那天才会真正体现。没有演练过的回滚方案，和没有方案差别不大。