可靠的网页数据并不是由某一次成功请求产生的。它来自对网络、目标网站与提取流程的完整理解，以及准确判断应该修复哪一层的能力。
先确定故障边界
工作流失败时，团队通常只能看到最终症状：空响应、字段变化或超时。仅凭这些信息，很难判断问题来自代理路由、目标网站、解析器，还是使用结果的应用。
有效的系统会保留各层之间的边界。网络事件应与 HTTP 行为区分，二者又应与提取质量区分。这样，一个模糊的数据事故才能转化为明确的运营决策。
值得保留的五类信号
紧凑的事件记录就能解释大多数故障，而不必制造难以管理的日志洪流。为每个任务同时保存路由与会话标识、目标响应类别、延迟、传输字节数和提取结果。
这些数值作为连续变化最有价值。目标报错前先出现延迟上升，与响应成功但提取结果为空，代表的是完全不同的问题。趋势能说明单次请求无法揭示的情况。
路由网关、地区与会话
响应状态与目标类别
时间连接与总延迟
流量上传与下载字节
结果提取记录数或失败类型
把恢复能力设计进工作流
重试应当根据故障类型采取不同策略，而不是盲目重复同一个请求。路由故障可能需要切换端点；限流需要降低频率；页面结构变化则应停止网络重试，并把任务交给提取规则检查。
恢复也必须有边界。清晰的重试预算、幂等任务 ID 和保留完整的失败上下文，可以避免临时问题演变成重复任务或意外流量。
可观测性的价值，在于缩短从发现不可靠结果到采取正确修复行动之间的距离。
实用检查清单
- 为每个任务分配稳定的请求 ID。
- 分别记录网络、响应和提取结果。
- 保留足够的上下文，以便安全复现失败请求。
- 使用针对故障类型的重试规则，并设置清晰的重试预算。
- 按路由、目标和工作流观察趋势，而不只是全局平均值。
目标并不是收集所有可能的指标，而是保留少量真正有用的信号，让团队能够解释结果、有计划地恢复，并持续改进系统。