代理IP失效之后,最快的做法往往是换上备用出口继续跑,把问题先压下去。等到有空回头看时,失效的原因、波及的范围、以后怎么防,这三个问题如果没人回答,同类故障还会再出现一次。
第一个问题:影响到了哪些业务
同一条出口上通常挂着不止一个任务。出口失效时,所有依赖它的任务都会受影响,有的直接失败,有的只是变慢,还有的一直在重试但没有成功。代理IP的失效复盘要先列出挂在这条出口上的全部任务,再逐个确认它们当时的状态,只盯报错最明显的那个任务会漏掉别的。
第二个问题:影响持续了多久
这一段最容易少算。
持续时间不能只看故障本身,要看从故障发生到业务真正恢复正常之间的总时长。这段时间里包含发现、判断、切换、验证几段,最后一段最容易被漏算。代理IP的失效复盘如果把结束时间记成切换完成的那一刻,实际业务恢复的时间就会比记录晚一截,下一次遇到同类问题时,对时长的预期也会偏乐观。
第三个问题:哪些环节本可以更早发现
这一问是复盘里最有价值的部分。把发现方式写下来,看看是监控报出来的,还是任务失败以后才被察觉的。如果是后者,说明监测的覆盖面或者阈值存在问题。代理IP的失效复盘不需要复杂的分析方法,把发现路径照实写一遍,通常就能看出哪一步该提前。
结论要能落到一条规则上
三个问题回答完,通常能落出一两条具体改动,比如加一个出口连通性的定时检测,或者把某个长任务改成可以续跑的形式。代理IP的失效复盘如果不产生任何改动,下一次遇到同类问题时,耗时和这一次不会有多少区别。
- 列出挂在这条出口上的所有任务及其当时状态
- 按发现、判断、切换、验证四段记录时长
- 写清每一段的发现方式,找出最晚的一环
- 把结论变成一条可以加进监测的具体规则

还有一点值得提醒:范围查清之后,不一定每条受影响的业务都要单独改。同一条代理IP出口上的任务往往共用一个失效原因,找到那个共同点,一次调整就能覆盖全部,比逐个任务修要省事。
代理IP的复盘价值不在记下发生了什么,而在把下一次的发现时间提前。三个问题回答完,通常能落到一两条具体的改动上,比如加一个出口连通性的定时检测,或者把某个长任务拆成可以续跑的形式。
