WordPress主机迁移：一次小流量灰度如何暴露全量发布的例外
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /2437f46ad272.html
📄
WordPress主机迁移：一次小流量灰度如何暴露全量发布的例外
灰度发布在 WordPress 主机迁移里通常被当作保险：先切一小部分流量到新主机，观察几天再全量。但小流量灰度验证的是“常规路径”，而全量发布真正会暴露的，往往是灰度阶段根本触发不到的例外——缓存层数不同、计划任务并发、对象缓存连接数、以及被灰度规则排除掉的那部分请求。结论是：灰度值得做，但不能把灰度通过当成全量安全的证据，必须专门为“灰度覆盖不到的例外”补一轮验证。
灰度与全量之间真正变化的是什么
很多团队把灰度理解成“按比例抽样”，于是假设样本足够就能代表整体。迁移场景下这个假设经常不成立，因为灰度和全量的差异不在流量多少，而在请求走的是哪条链路。
- 灰度常按 IP、Cookie 或特定 URL 前缀切分，被排除的往往是登录态、后台、支付回调、订阅接口这类“少数但关键”的请求。
- 新主机初期可能只挂了单层缓存或没开对象缓存，全量后 CDN、页面缓存、对象缓存同时生效，叠加行为才会出现。
- 计划任务、队列消费者、外部回调在灰度期只有零星触发，全量后并发上升，连接池和超时设置才成为瓶颈。
也就是说，灰度通过说明的是“被选中的那部分请求在新主机上没坏”，而不是“所有请求都没坏”。这两句话的差距，就是全量发布后故障的来源。
两种做法成立的条件与代价
面对这个差距，常见两种取舍。
做法一：延长灰度、扩大切分范围
适用条件是站点请求类型集中、登录态与匿名态行为接近、且你能接受更长的双主机并行期。代价是两台主机同时跑，数据库写入、定时任务、缓存失效可能被两边同时触发，反而制造灰度期独有的不一致。如果迁移涉及数据库主从或双向同步，延长灰度会把复杂度推高，而不是降低。
做法二：缩短灰度、改为全量后快速回滚
适用条件是回滚路径已经验证过、DNS 或反向代理切换足够快、且你能承受短暂的错误暴露。代价是全量瞬间把未验证的例外全部放出。若回滚只验证过“切回去”，没验证过“切回去之后数据是否一致”，那这个代价可能不可逆。
选择依据不是哪个更稳，而是你的例外请求是否可枚举。能列出登录、回调、计划任务这些具体入口，就值得针对它们单独做一次定向验证，而不是靠扩大流量比例去碰运气。
一个假设例子：灰度覆盖不到的定时任务
假设某站点灰度按匿名访客的 URL 前缀切分，新主机只承接约一成流量。灰度三天，页面响应正常。全量切换后第二天凌晨，订单对账任务在新旧主机上同时运行，重复写入同一条记录。
这个例子里，灰度没有失败，它只是从未触发过该任务。要提前发现，需要在灰度期就手动在新主机上单独执行一次该任务，并确认旧主机的调度已被停用。动作很具体：把被灰度规则排除的入口逐个在新主机上手动跑一遍，观察结果是否与旧主机一致。如果一致，说明例外已被覆盖，可以推进全量；如果不一致，说明问题在灰度之外，扩大流量比例也不会让它出现。
需要注意，定时任务重复执行、缓存未命中、回调超时这些现象也可能由别的原因造成，比如旧主机本身就在重试、外部服务当时不稳定。把某次异常直接归因于迁移，需要先排除这些解释。
全量发布前应补的动作
- 列出灰度规则排除掉的所有请求类型：后台、登录、支付或订阅回调、站点地图、robots.txt、计划任务、队列消费者。
- 在新主机上对这些入口做一次定向请求或手动触发，记录返回结果与旧主机的差异。
- 确认旧主机的调度、队列和写入路径在全量前已停用或指向新主机，避免双写。
- 验证回滚路径本身，包括回滚后数据是否一致，而不只是“能否切回去”。
这些动作的结果直接决定下一步：定向验证全部一致，才可以把灰度视为通过；只要有一项无法在新主机上复现旧行为，就应先修这一项，再考虑全量。
另外，如果迁移后担心旧地址被继续抓取，用 robots.txt 限制抓取并不等于可靠的索引移除，站点地图也不保证收录，这两件事需要分别处理，不能当作迁移完成的标志。灰度是降低风险的手段，不是证明全量安全的证据；把灰度覆盖不到的例外单独验证一遍，才是这次迁移真正该补的那一步。
