说白了，这套斗篷系统上线检查项，我是按时间轴来拆的——上线前、运行中、异常后，三段。每一段你别贪多，盯住三五个真会炸的点就行，剩下的交给日志和告警去兜。上个月有个做教育投放的团队来问我，说服务器买好了、LNMP 也跑通了、跳转插件自己写完了，那上线前到底还得盯哪几项才敢放量？我当时就是这么回他的。这篇我尽量把每个检查动作背后的原因讲清楚，而不是甩一堆看着热闹、实际没人执行的条目出来。
上线前：配置核验与回滚点
上线前这一段，最容易走过场。环境刚搭好嘛，看着哪儿都正常。但恰恰是这一段，决定了后面出问题的时候你能不能五分钟内退回去。我的习惯是，先把 PHP、Nginx，还有跳转插件依赖的那些扩展版本，统统抄进一份文档里，顺便标上锁定时间。这事儿跟好不好看没关系，主要是异常之后回溯的时候，你得能确定"当时跑的是哪一版"。我见过太多团队，出事第一句话就是"我没改过啊"，结果一查，某次顺手升级了个扩展。版本冻结之后，任何变更都走单独的记录，别混在业务配置里，混在一起你根本翻不出来。
回滚点与配置快照
回滚点这东西，不只是备份代码那么简单。规则库、页面版本映射表、Nginx 站点配置，这三样得一起打快照，而且还要记下快照对应的规则库版本号。原因很直接：分流失效往往不是代码的锅，是某条规则被改坏了。你只回滚代码不回滚规则，等于没回滚。快照存两处，本地一份、对象存储一份，别偷懒只放同一台机器上。
正式切流量之前，拿历史请求日志做一次回放，看看判定结果跟预期对不对得上。这一步的价值在哪儿？它能在真实流量进来之前，就把规则短路、条件顺序错误这类问题给暴露出来。回放不通过，那就先别急着上线。具体怎么做，可以参考跳转插件日志回放验证里那套空跑思路。
运行中：巡检节奏与观察指标
上线之后的检查重点，就一句话：别让问题悄悄积累。这一段不需要你天天盯着看，但得有固定的观察窗口。
日志轮转与容量基线
先确认日志是按大小轮转还是按天轮转，磁盘占用有没有告警阈值。为什么这么强调这个？因为分流系统的日志量，往往比你想的大得多，尤其是开了全量记录之后，几天就能把磁盘写满。写满之后 Nginx 直接写不进去，请求就开始报错。轮转策略和保留天数，上线前就定好，运行期只做确认，别临时调整。
回源占比与决策延迟
每天固定看两个指标：回源流量占比，还有判定到响应的耗时。回源占比突然升高，通常意味着判定链路里有分支没命中、退到兜底逻辑去了；决策延迟升高呢，可能是规则集膨胀，或者缓存失效了。这两个指标我一般放同一张看板上，异常的时候能互相印证。如果回源占比持续偏高，可以按斗篷系统回源流量里的排查顺序走一遍。
规则命中分布
每隔几天拉一次规则命中分布，看看有没有哪条规则长期零命中。零命中不一定是坏事，也可能是流量结构变了。但如果一条本该承接主要流量的规则，突然掉到接近零，那就是信号了，当天就得查一次。
异常后：回滚与恢复次序
异常发生时的检查项，跟前面两段不太一样。这时候要的是次序感，不是全面性。发现分流失效，第一件事不是改配置，而是判断影响面：是所有访客都错，还是某个渠道、某个地区的访客错。影响面决定了你是回滚还是局部修。全量错就回滚到上一个快照，局部错就定位到具体规则分支去调。顺序反了，很容易把小问题改成大问题。
如果确定要回滚，先回滚规则库，观察一两分钟，再决定要不要回滚代码。为什么？因为多数分流失效来自规则改动，规则库回滚成本低、见效快，而且不会牵动依赖插件的其他服务。代码回滚放到第二步，它影响面更大，能不动就不动。
恢复后的复核
回滚完成后别立刻关掉现场。把回滚前后的判定日志各留一段，对比同一批请求的判定结果，确认真的恢复了。同时记下这次异常的时间点和触发动作，更新到回滚点文档里。下一次再出类似问题，这份记录能省掉一半排查时间。
小结
这套三阶段清单，核心逻辑其实就是：上线前把"退路"准备好，运行中把"趋势"看清楚，异常后把"次序"守住。检查项本身不复杂，难的是每个动作都对应一个具体原因，执行的人知道自己为什么查这一项，才不会漏。对投放团队来说，放量之前把这三段走一遍，比事后救火划算得多。
常见问题
上线前空跑日志回放要跑多久才够？
这个要看你的流量结构复杂度。一般来说跑到能覆盖主要渠道和主要页面版本各若干次请求就差不多，通常一两个小时的回放量够用了。如果规则分支特别多、地区维度也分得细，就多跑半天。说白了，回放的目的不是跑满多少条，而是让你看到每种分支都走通过一次。
运行期巡检每天要花多少时间？
固定看板上的两三个指标，每天扫一眼，五分钟以内。规则命中分布可以隔两三天拉一次，不用天天看。顺带说一句，我一般会把告警阈值调得偏保守一点，宁可多收几条通知，也别等磁盘写满了才发现。
回滚点多久更新一次？
每次规则库有正式变更、或者页面版本映射表调整之后，就重新打一次快照。没有变更就不用动。关键是快照要和规则库版本号绑定，不然回滚之后你也不知道退到了哪一版。
异常后回滚了，还要不要继续观察？
要。回滚只是止血，恢复之后至少盯一个完整的流量高峰周期，确认判定结果稳定。有时候回滚解决了表象，但触发原因还在，过几个小时又会冒出来。把回滚前后的日志留档，是下一次排查最省事的做法。
延伸阅读
如果你对跳转链路本身的技术选型还想再补一层，这篇讲页面跳转技术的文章把几种跳转方式的参数影响讲得比较细，可以和本文的检查项配合着看。
