同IP网站影响：一次小流量灰度如何暴露全量发布的例外
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /6704715c1415.html
📄
同IP网站影响：一次小流量灰度如何暴露全量发布的例外
灰度发布通常只让一小部分流量进入新版本，用来提前发现故障。但在同IP网站影响这个场景里，灰度可能反过来暴露一个被全量发布掩盖的例外：同IP上其他站点的抓取、缓存或访问行为，会因灰度流量的路由方式而与全量发布时不同。要判断这是真实风险还是观测偏差，关键是区分“灰度本身触发了例外”与“灰度只是让原本存在的例外变得可见”。
矛盾现象：灰度正常，全量反而异常
假设同一台服务器或同一出口IP下运行多个站点，灰度只把新版本分配给少量路径或少量访问者。常见的矛盾是：灰度期间日志显示抓取正常、返回码稳定，但切到全量后，同一批URL开始出现抓取频率下降或返回异常。
一个合理解释是路由差异：灰度可能只让部分请求走新逻辑，其余请求仍走旧逻辑，因此同IP上其他站点的请求没有被新逻辑影响；全量后所有请求都走新逻辑，原本被旧逻辑吸收的例外才暴露出来。另一个合理解释是观测窗口差异：灰度流量小、持续时间短，日志样本不足以覆盖同IP上其他站点的抓取高峰，全量后样本变多，异常才被记录到。
两种解释各自成立的条件
路由差异成立的条件：灰度按路径、参数或用户分组放量，而不是按IP或机房整体放量；新逻辑改变了同IP下多个站点共享的响应头、缓存键或限流规则。此时灰度没有覆盖到共享层，全量才会触发例外。
观测窗口差异成立的条件：新逻辑本身没有改变共享层行为，只是灰度期间样本太少，未命中同IP上其他站点的抓取时段。此时全量后的异常可能一直存在，只是此前没有被记录。
两种解释都成立时，不能只凭“灰度没问题”就认定全量安全，也不能只凭“全量异常”就认定新逻辑有缺陷。
用可核对的证据区分解释
要区分上述两种解释，可以按下面顺序核对，每一步的结果都会决定下一步动作：
- 比对灰度与全量的请求分布：按IP、User-Agent、路径分别统计请求量。如果灰度期间同IP其他站点的请求占比明显低于全量，说明观测窗口差异更可能成立，下一步应延长灰度或扩大放量范围，而不是直接回滚。
- 检查共享层配置是否在灰度中被绕过：查看灰度规则是否只作用于部分路径，而缓存、限流、响应头仍由旧逻辑处理。如果共享层在灰度中未被新逻辑覆盖，说明路由差异成立，下一步应把共享层纳入灰度范围再验证。
- 对比同一URL在灰度与全量下的响应头：重点看缓存指令、内容类型和状态码是否一致。若不一致，且变化与同IP其他站点的抓取下降同时出现，则路由差异的解释更强。
- 记录抓取量下降前后的时间点：抓取量归零或下降本身不能单独证明新逻辑有问题，也可能是对方调整了抓取预算、站点地图更新或临时限流。需要结合同IP其他站点是否同时变化来判断。
一个注明假设的短例子
假设同一IP下有A、B两个站点，灰度只对A的/new路径放量，B完全不参与。灰度期间A的抓取正常，B也正常。全量后A和B的抓取同时下降。若检查发现新逻辑修改了该IP共用的robots.txt响应或缓存键，那么最可能的解释是共享层在灰度中被绕过，全量才暴露例外。此时应先把共享层改动回退或纳入灰度，再观察A、B是否同步恢复；如果只有A恢复而B仍下降，则还要排查B自身的配置或外部因素。
灰度设计上要提前留出的检查点
要让灰度真正暴露全量发布的例外，灰度范围不能只按页面路径划分，还应覆盖同IP下多个站点共用的部分。具体动作包括：在灰度规则中显式包含共享的响应头、缓存策略和限流配置；在灰度期间同时记录同IP其他站点的抓取日志；把灰度持续时间拉到能覆盖至少一个完整抓取周期。这样做的结果会直接影响下一步：如果共享层在灰度中已被覆盖且未出现异常，全量风险更低；如果共享层未被覆盖，则全量前应先补一次针对共享层的灰度验证，而不是直接放量。
