本文系统性拆解部署自检的完整实操要点。
上个月一个客户的团队问：为什么我们明明部署好了斗篷系统，上线后头两天看着正常，第三天却出现分流规则不生效、日志里一堆PHP告警？他们卡在“部署完成”和“稳定运行”之间，缺的是一份把上线当作工程节点来验收的自检清单。这篇文章就从上线前、运行中、异常后三个阶段，把每个检查项背后的原因和具体做法拆开讲清楚，供独立部署的团队直接对照执行。
上线前：核验配置不是“看一眼”，而是按依赖顺序走
部署完成后最容易犯的错，是打开页面看一眼能跳转就宣布上线。实际上，斗篷系统的配置项之间有依赖关系，前一项没核验就查后一项，很容易把问题带到生产流量里。
1. 先核验进程与端口，再查Nginx转发
很多团队习惯先测页面跳转，但页面能访问只说明Nginx把请求转到了PHP-FPM，不代表PHP-FPM进程池状态健康。上线前应先用ps aux | grep php-fpm确认master进程和worker进程都在，再检查监听端口与Nginx配置中的fastcgi_pass是否一致。端口不一致时，Nginx会返回502，但如果你只测了首页跳转，可能因为静态资源缓存而没触发到动态分流逻辑，问题就被掩盖了。
2. 配置分支要“空跑”一遍再开真实流量
规则库刚配完时，条件短路和兜底页选择很容易出现“看起来对，跑起来错”的情况。上线前用几组模拟请求参数打一遍分流节点，观察日志里命中的规则分支是否符合预期。这里可以参考站内关于分流节点日志回放配置的说明，先做空跑验证，避免把配置错误直接暴露给真实访客。
3. 回滚点必须在放量前确认
部署后自检最容易忽略的是“如果出问题，退到哪一步”。上线前至少保留上一版可用的Nginx配置文件和规则库快照，并确认回滚命令能在五分钟内完成。没有回滚点的上线，等于把流量恢复寄托在临时排查上。
运行中：日志和资源监控要同时看
系统进入运行状态后，检查重点从“配置对不对”转向“行为是否符合预期”。这个阶段的误区是只盯业务指标，比如跳转成功率，却忽略了底层资源变化。
1. 日志不是越多越好，关键字段要能定位到请求
运行中应重点观察两类日志：Nginx访问日志和PHP错误日志。访问日志里要能看到每个请求带进来的分流参数和最终返回的页面版本标识；PHP错误日志里要过滤掉无关的deprecated告警，只关注与分流逻辑相关的notice和warning。如果日志里没有记录规则命中结果，一旦出现版本错配，你只能靠猜。
2. 资源指标要按“峰值而非均值”来评估
斗篷系统的分流逻辑会在请求进来时做条件判断和指纹验证，CPU和内存消耗有明显的波峰。运行中监控要关注峰值是否接近上限，特别是PHP-FPM的进程数和单进程内存占用。如果峰值时出现排队，落地页响应延迟会直接拉低转化，这比均值数据更有参考价值。
3. 检查规则库是否有“静默失效”
规则库热更新后，有时会出现新规则没生效但系统不报错的情况。运行中应定期抽查几条核心规则，用测试参数验证是否按预期命中。这种静默失效如果拖到审核环节才暴露，恢复成本会高很多。
异常后：先止损再定位，回滚要分层次
异常发生后，团队容易陷入“马上找到原因”的冲动，但正确的顺序是先让流量回到可用状态，再慢慢查根因。
1. 判断异常影响范围，决定是整体回滚还是局部关闭
如果异常集中在某一条规则分支或某一个页面版本，优先考虑在规则库里临时禁用该分支，而不是整体回滚。只有出现系统级错误，比如PHP-FPM反复崩溃、Nginx配置加载失败，才考虑整体回滚。分层止损能保住大部分流量的正常分发。
2. 回滚后要做“差异核验”
回滚完成不代表问题结束。回滚后要把当前生效的配置与异常发生前的配置做差异对比，确认没有遗漏的改动点。这个差异核验过程，也可以参考部署上线验收里关，把回滚当作一次正式的变更来管理。
3. 异常复盘要落到“检查项更新”
每次异常处理完，团队应该把这次暴露出来的盲区补进自检清单。比如这次是日志里缺了某个字段导致定位慢，下次上线前就把这个字段加入核验范围。清单的价值在于持续迭代，而不是一次写完就束之高阁。
小结
部署后自检不是上线前的一次性动作，而是一条贯穿上线前、运行中、异常后的连续链条。上线前核验依赖顺序和回滚点，运行中同时看日志与资源峰值，异常后先分层止损再定位根因——每个阶段的检查项背后，都是为了防止小问题蔓延成流量事故。
常见问题
部署后自检一般需要多长时间
这个要看系统规模和规则复杂度。一个日均几千请求的独立部署环境，上线前核验加上运行中首轮观察，通常两到三个小时能走完核心项。顺带说一句，我一般会把回滚演练单独留半小时，因为真出问题时再熟悉回滚命令会手忙脚乱。
运行中日志出现PHP warning需要立即处理吗
不用看到warning就紧张。先看它是不是来自分流逻辑本身，如果只是某个扩展的deprecated提示，可以记录下来但不必中断运行。说白了，关键是判断这个warning会不会影响规则命中结果或页面返回顺序，不影响就可以排到下一个维护窗口。
异常后多久内必须完成回滚
没有统一的时间标准，但建议团队提前定一个“最大可容忍异常时长”。如果异常导致落地页无法打开或广告流量被浪费，通常十到十五分钟内要完成分层止损。回滚本身不难，难的是在压力下记住先禁用哪个分支、再执行哪条命令，所以提前演练比临时决策更可靠。
延伸阅读
如果对斗篷系统中跳转环节的具体技术实现还有疑问，这篇关于页面跳转技术的完整指南可以补充跳转选型与实现细节的内容，和本文的部署自检正好形成互补。
