规则写完直接上线，是动态调度最常见的事故来源。规则里的数字看着合理，放到实际环境里却可能因为量的规模不同而效果完全不同，代理IP的阈值尤其如此。上线前做一轮验证，能把大部分问题挡在正式环境之外。
先做单规则的干跑
干跑的意思是让规则正常判断，但不真正执行动作，只把判断结果记下来。跑一天之后看记录，就能知道这条规则在真实数据下会触发几次。触发次数过多说明代理IP的阈值定得太低，一次都不触发说明阈值定得太高。无尽冬日的用量有明确的早晚节律，干跑一天覆盖不了夜间的低峰，代理IP的规则至少跑两天。
三步的顺序不能颠倒，跳过干跑直接实跑，会把判断逻辑的问题和动作执行的问题混在一起，事后分不清是哪一层的毛病。
| 步骤 | 做什么 | 看什么 |
|---|---|---|
| 单规则干跑 | 只判断不执行，跑两天 | 触发次数是否合理 |
| 小范围实跑 | 挑三个号真跑，跑一周 | 有没有反复来回切换 |
| 全量上线 | 分批放开，先放一半 | 配置生效范围是否完整 |
再做小范围实跑
干跑确认了判断逻辑，接下来要让动作真的执行。挑三个号实跑一周，重点看有没有反复来回切换的情况。反复切换说明触发和恢复的阈值挨得太近，需要把两者拉开。这一步的范围小，出问题的代价可控。
- 干跑看判断，实跑看动作
- 反复切换要拉开触发与恢复的差距
- 全量上线分两批，先放一半观察
最后分批放开
全量上线不要一次放完。先放一半，观察一天再放另一半。分批的好处是能把配置生效范围的问题暴露出来：如果第一批的号规则生效了，第二批没生效，问题就出在配置加载的环节，跟规则本身无关。
验证通过的标准
通过的标准有三条：触发次数落在预期范围内、没有出现反复切换、配置在所有号上都生效了。三条都满足才算通过，缺一条就要回到对应的步骤重新调。代理IP的调度规则上线前的验证，花的是两天时间，省下的可能是上线后一周的排查。
验证走过一遍，上线才踏实。
无尽冬日多开的动态调度上线，按干跑、实跑、分批放开三步验证。三步都用记录说话，不靠感觉判断。走完这三步再上线，代理IP的调度规则出问题的概率会低很多。