一次架构调整，让人工介入减少了一半

如果你维护过一段时间的采集系统，大概率会经历这样一个阶段：

一开始一切都很顺利，requests 一跑，数据就回来了。
后来目标站点开始限速，你加了代理。
再后来，403、429、超时轮番出现，报警开始刷屏。

系统并不是完全不可用，但你发现一件很烦的事——
它越来越依赖人工去“盯着”。

这时候，很多人都会隐约意识到一个问题：

问题不在某一次失败，而在系统没有“自救能力”。

这篇文章想聊的，就是采集系统从“失败就报错”，到“失败先尝试修复”的那一步演进。

一点技术背景：为什么现在的爬虫更容易出问题

早些年的采集系统，其实并不需要太复杂的设计。
请求成功率高，限制手段也相对简单，失败更多来自网络抖动。

但这几年情况明显变了：

• 反爬策略开始动态化
• 同一 IP 的可用时间越来越短
• 行为模式比请求参数更重要
• 成功率开始随时间波动，而不是线性下降

在这种环境下，如果采集系统的行为是“固定的”，那它迟早会撞上墙。

于是，一个很现实的问题摆在面前：

我们是继续靠人工救火，还是让系统自己先试着修一修？

从三个常见方案说起

在大多数团队里，采集系统通常会经历三个阶段。

第一阶段：最基础的采集

这一阶段的目标只有一个：能拿到数据。

代码往往很简单，请求一次，失败就重试几次，实在不行就记日志。
在低频、临时任务里，这种方式没有任何问题。

但一旦采集变成长期任务，失败就会慢慢变成常态，而不是例外。

第二阶段：加了一点“防御”的采集

当失败开始增多，大家通常会做几件事：

• 加代理
• 加重试
• 稍微降点速

这套方案能明显延长系统的寿命，也是很多线上系统停留的状态。

但你很快会发现，它有一个问题：
系统并不知道自己为什么失败。

于是你开始反复遇到这样的场景：

• 同样的错误，不停地重试
• 同一批代理，在失效边缘反复使用
• 人工不停调整参数，却很难一劳永逸

第三阶段：让系统具备“自我修复”的能力

所谓自我修复，并不是系统突然变得很智能，而是它开始做一件很简单的事：

先判断发生了什么，再决定怎么应对。

比如：

• 超时了，是不是该等一等
• 返回 403，是不是该慢一点
• 代理异常，是不是该暂时放弃这条线路

当系统开始有这种“分情况处理”的意识时，它的稳定性会出现一个质的变化。

用代码看一下差别

先看一个最常见的请求写法。

importrequestsdeffetch(url):try:resp=requests.get(url,timeout=5)resp.raise_for_status()returnresp.textexceptExceptionase:print("请求失败：",e)returnNone

这种代码本身没有问题，但它的能力边界非常清晰：

• 不关心失败原因
• 不调整行为
• 失败一次，就算一次

这也是为什么它很难支撑长期运行。

再看一个“会尝试自救”的版本

下面这个例子，用的是亿牛云爬虫代理的配置方式，主要想表达一种思路，而不是具体实现细节。

PROXY_HOST="proxy.16yun.cn"PROXY_PORT="31111"PROXY_USER="username"PROXY_PASS="password"proxy_url=f"http://{PROXY_USER}:{PROXY_PASS}@{PROXY_HOST}:{PROXY_PORT}"proxies={"http":proxy_url,"https":proxy_url}

接下来是请求逻辑。

importrequestsimporttimeimportrandomdefsmart_fetch(url,max_retry=5):forattemptinrange(1,max_retry+1):try:headers={"User-Agent":random.choice(["Mozilla/5.0 (Windows NT 10.0; Win64; x64)","Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7)","Mozilla/5.0 (X11; Linux x86_64)"])}timeout=random.uniform(3,8)resp=requests.get(url,headers=headers,proxies=proxies,timeout=timeout)ifresp.status_codein(403,429):time.sleep(attempt*2)continueresp.raise_for_status()returnresp.textexceptrequests.exceptions.Timeout:time.sleep(attempt)exceptrequests.exceptions.ProxyError:time.sleep(2)exceptException:time.sleep(1)returnNone

这段代码并没有做什么“高深”的事情，但它已经具备了一些重要特征：

• 失败不会立刻放大
• 行为会随失败而变化
• 系统会给自己留出缓冲空间

这正是“自我修复雏形”的核心。

什么时候真的有必要做到这一步？

坦白说，并不是所有采集任务都值得上这种复杂度。

如果你只是：

• 临时抓点数据
• 采集频率不高
• 目标站点反爬很弱

那简单方案反而更合适。

但如果你遇到的是：

• 长时间运行的采集任务
• 成本不低的代理资源
• 反爬策略经常变化
• 人工维护已经成负担

那你大概率已经站在“要不要自我修复”的门槛上了。

最后一点个人感受

很多人谈稳定性时，会不自觉地追求“永不失败”。
但真实世界里的系统，很少有这种奢侈条件。

对我来说，更现实的目标是：

失败是允许的，但它不应该失控。

当采集系统开始尝试理解失败、消化失败、缓解失败时，
你会明显感觉到一件事：

系统没那么脆了，人也轻松了。

而这，往往是一个采集系统真正成熟的开始。