CI安全门禁例外到期后如何平稳恢复阻断

门禁刚上线那阵子，我特别有安全感：每次合并被拦下来，规则编号、扫描路径、修复建议都写得明明白白。可三个月后我打开例外配置，心里咯噔一下——路径排除加了好几行，理由栏写着“已和安全同学口头确认”，审批记录散落在聊天窗口里。门禁没坏，但它对一个又一个活跃分支已经不痛不痒了。例外到期那天，我真正要面对的问题是：怎么在不把发布节奏搞崩的前提下，把阻断平稳地找回来。

我踩过的第一个坑，是以为到期就会自动恢复。实际上，例外记录里如果没有明确的到期日，或者平台把过期状态处理成“软放行”，门禁看起来回来了，实际只回来了半条命。所以恢复阻断前，我会先确认三件事：这条例外是不是已经过期或被标记为拒绝；门禁当前的动作到底是阻断还是记录；以及有没有别的例外或降级策略把它盖住。

接着别直接往主分支上撞。我会先在一个测试分支跑完整流水线，专门盯着这条规则对应的检查项，确认它真的会拦。这个动作看起来笨，但能省掉发布窗口里的惊吓。

如果阻断确实上线了，而某个正在进行的发布被卡住，我会先问：这次变更能不能顺手把问题修掉再合并？原文里那句话我特别认同——恢复阻断的目的是让修复发生，不是制造新的紧急例外。不到万不得已，我不会当场再开一条放行。真的开，也得带上到期日和责任人，否则只是把今天的麻烦往后推。

还有一层容易忽略：多级门禁。提交时、CI 阶段、注册表准入、部署准入，每个执行点上的例外状态得对齐。我遇到过流水线放行了、准入却拒绝的情况，排查起来比单点阻断还难受，因为阻断看着生效了，其实只在某一层生效。恢复时我会逐层确认一遍，别嫌麻烦。

最后是回滚。例外配置写错范围、审批给错对象、到期时间盖住了一批不该放行的规则，这些都得能撤回。配置在仓库里就反向提交，走合并请求重新评审；放在平台变量或集中式策略里，先留变更前快照，在非生产分支验一遍再回滚。回滚完还要显式清掉残余的例外标记，不然阻断像是恢复了，实际上并没有覆盖到每个分支。

说到底，风险接受不是问题，没有边界的风险接受才是。恢复阻断不是跟业务对着干，而是让每一次“可以”都知道自己到哪天结束。