WordPress更换服务器：一次小流量灰度如何暴露全量发布的例外
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /d31327e8987e.html
📄
WordPress更换服务器：一次小流量灰度如何暴露全量发布的例外
灰度只覆盖一小部分访问者时，WordPress更换服务器看起来平稳；一旦全量切换，例外往往集中在灰度样本里根本不存在的那类请求上。原因不是“灰度没用”，而是灰度验证的是被选中的样本，而全量发布验证的是全部请求特征。要判断能否放量，必须先把灰度样本和全量流量之间的差异列清楚，再针对差异补一轮定向验证。
先确认灰度样本漏掉了哪些请求特征
小流量灰度通常按固定比例随机放量，这会让样本在统计上接近整体，但在“类型覆盖”上并不完整。以下几类请求在随机抽样中极易被稀释，却常在全量后暴露问题：
- 带查询参数的动态 URL，例如分页、筛选、追踪参数组合。
- 后台任务与计划任务触发的请求，它们不来自真实访客，随机比例很难命中。
- 移动端或特定 UA 下的差异化输出。
- 需要回源到旧服务器才能命中的缓存未命中请求。
- 上传目录、静态资源目录等非页面路径。
实际操作是：从灰度期间的服务端访问日志中，按路径、状态码、UA 三个维度各取一份去重清单，再与全量预估的请求类型对照。哪一类在灰度日志里几乎没有记录，它就是放量后最可能出问题的候选。这个动作的结果直接决定下一步是“补测”还是“可以直接放量”。
用一条真实请求验证配置是否按预期生效
不要只看首页是否返回 200。取一个读者手上真实存在的页面，例如带参数的分类页，依次核对：
- 响应头里的缓存标记是否与预期一致，是否仍指向旧节点。
- 页面正文是否包含该 URL 应有的动态内容，而不是被缓存成另一个页面的内容。
- 站内链接和资源链接指向的域名是否为新环境地址。
- 重定向链是否只有一跳，而不是旧域名与新域名来回跳。
假设一个场景：灰度时首页与文章页都正常，但分类分页在放量后出现旧内容。可区分的原因有三类——缓存键没有包含查询参数、对象缓存仍连接旧库、应用层把分页参数丢弃。要区分它们，可以临时对同一路径加一个随机参数请求两次，若两次返回相同且与预期不符，更偏向缓存键问题；若两次结果不同，更偏向回源或数据库连接问题。这一步的结论决定你改缓存配置还是改数据库连接，而不是盲目重启服务。
把索引与抓取相关设置当作独立验证项
服务器更换常伴随域名、路径或响应头的变动，抓取侧的表现不能靠页面正常来推断。需要单独确认：
robots.txt是否仍可访问，内容是否与迁移前一致。抓取限制不等于可靠的索引移除，反过来，放开抓取也不保证收录。- 站点地图是否返回正确内容且指向新环境的 URL。站点地图不保证收录，它只是发现入口。
- HTTPS 证书链是否完整。HTTPS 不保证安全无漏洞或排名，它只解决传输加密与身份校验。
- 不同搜索引擎对同一指令的支持情况须分别核查，不要用一家的表现推断另一家。
可执行动作是：在灰度阶段就用真实抓取工具（或搜索引擎的抓取测试能力）请求几个代表性 URL，记录状态码与最终 URL。若这里出现重定向异常，放量后影响面远大于单个页面，应优先修复再继续放量。
放量前设定可回退的判断条件
灰度到全量之间需要一个明确的放量门槛，而不是“看起来没问题就切”。建议在放量前写下三个条件，并注明假设：
- 代表性 URL 类型全部返回预期状态码与内容。
- 错误率与迁移前同一时段相比没有超出你设定的容忍范围。
- 回退路径可用，且回退后旧环境仍能正常服务。
需要提醒的是，请求量、抓取量或某项统计归零，不能单独证明处理正确。它也可能是缓存命中变化、抓取工具被限流、日志采集中断等合理解释。判断时要结合多个信号，而不是只看一个数字。如果某个信号异常但其他信号正常，先排查采集与缓存链路，再决定是否回退。
放量后如何定位灰度未覆盖的例外
全量后若出现问题，优先按“灰度日志中没有出现过的请求特征”去筛。具体做法是：把故障时段日志按路径前缀分组，找出错误集中的前缀，再回看灰度期间该前缀的请求量。如果灰度期间该前缀请求量极低甚至为零，说明它是样本盲区，而不是灰度失效。此时的处理顺序是：先对新暴露的请求类型做定向验证，确认是配置问题还是数据问题，再决定局部修复还是整体回退。这个顺序能避免把局部例外当成全局故障，从而做出过度回退。
