摘要：持续可用不能只看定时任务有没有成功，还要观察请求异常后能否自动切换、多久恢复、恢复后是否再次波动。测试时应把正常运行、异常触发、恢复确认和长时间复测连成一条链。在舆情监测场景中，真正影响连续采集的往往不是某次请求失败，而是失败后业务没有及时恢复。定时探针可以发现问题，却不能单独证明代理链路具备持续可用性；只有把异常恢复放进测试，结果才接近真实运行状态。
为什么定时跑通不能证明持续可用？
很多企业测试舆情监测代理IP时，会设置一个定时任务，每隔几分钟访问一次目标页面。连续运行一段时间后，只要大部分任务返回成功，就把这组结果当成可用性结论。
这种方法测到的只是“采样时刻能否访问”，没有覆盖采样间隔内发生了什么。如果某个出口在两次探针之间失效，又在下一次探针前恢复，报表里可能看不出异常；如果任务失败后依赖人工重启，整体成功率也可能不低，但这不属于持续可用。
舆情监测还有一个容易被忽略的特点：任务通常按固定时间抓取新内容。一次短暂中断如果恰好发生在重要发布时间窗口，损失的不是几个请求，而是一段无法补回的时间线。因此，测试重点不能只放在成功请求占比，还要看异常发生后是否影响数据连续性。
持续可用应该拆成哪些指标？
持续可用至少要拆成正常可用、异常发现、恢复速度和恢复质量四层。只给出一个总成功率，会把完全不同的问题混在一起，也无法判断应该调整代理服务、任务调度还是重试逻辑。
其中，代理IP可用率不等于舆情监测业务成功率。目标站点返回异常状态、内容结构变化、解析程序报错或入库失败，都会影响最终结果，但不一定是代理链路的问题。测试报告必须保留错误分层，不能把所有失败都算到代理服务上。
为了让恢复结果可比较，可以在测试前约定统一口径。例如，把“连续3次探针成功且内容校验通过”定义为稳定恢复，而不是第一次重新返回响应就结束计时。具体次数应根据监测频率调整，不能脱离业务周期套用固定阈值。
定时监测怎么搭，才能看见恢复过程？
一套有效的定时监测需要同时保留业务探针和恢复探针。业务探针按照生产计划运行，用来判断真实任务是否完成；恢复探针在检测到异常后提高检查频率，用来捕捉恢复过程。两者混成一个定时任务，往往只能看到失败和成功两个状态，看不到中间发生了几次重试与切换。
测试目标也不宜只放一个。建议同时准备自有或已获授权的固定探针页，以及实际舆情任务使用的目标页面。固定探针页用于判断网络链路是否正常，实际页面用于验证真实任务适配；两者同时失败时再排查代理链路，只有实际页面失败时则优先检查站点访问规则、请求节奏和内容解析。
每次请求至少记录以下字段：
- 请求时间、任务编号、目标地址和当前代理入口。
- 响应状态、首字节时间、总耗时和内容校验结果。
- 错误发生层级，包括代理连接、目标响应、内容解析和数据入库。
- 重试次数、出口变化、恢复时间和恢复后的连续成功次数。
- 数据是否补采、是否重复，以及异常窗口内是否出现内容缺口。
如果服务支持统一入口和自动切换，还要把“连接重新建立”与“出口真正恢复”分开记录。前者说明客户端重新发出了请求，后者才说明新请求已经获得有效响应。只记录重试成功，无法证明恢复动作来自代理侧切换还是业务程序自身重连。
异常恢复怎么验证才算有效？
异常恢复测试不应等着线上偶然出问题，而要在自有或授权测试环境中设置可控异常。测试目的不是制造复杂故障，而是确认链路在不同失败位置上会采取什么动作。
第一类是客户端连接异常，例如主动关闭连接、重启测试工作进程或触发连接超时。它主要验证业务程序是否能释放旧连接、重新建立请求，以及重试是否造成重复采集。
第二类是目标响应异常。可以让自有探针页在测试窗口内返回超时或指定错误状态，检查系统能否识别“目标异常”和“代理连接异常”的区别。目标端异常不应被直接记为代理不可用，否则长期报表会高估代理故障。
第三类是代理节点异常。若服务商能够提供可控测试条件，应记录异常节点被识别、出口发生变化以及新请求成功返回的完整时间线。如果没有可控条件，只能根据连续运行中真实发生的事件验证，并把这一项标为“尚未完成主动验证”，不能用普通重连代替。
恢复完成后还要继续运行多个监测周期。第一次请求成功可能只是短暂恢复，真正需要确认的是响应时间是否回到正常区间、错误是否再次出现、漏采数据是否补齐。异常消失不等于业务已经恢复，舆情任务最终要以数据连续性作为收口指标。
测试结果怎么判断，才不会被平均数误导？
平均成功率最容易掩盖集中异常。两个方案的总成功率可能相同，但一个方案每天随机失败少量请求，另一个方案在固定时段连续中断十分钟。对企业舆情监测来说，后者更可能形成完整的数据缺口，风险也更高。
因此，报告需要同时看总体结果和最差窗口。除了总成功率，还应单独展示最长连续失败时间、异常集中时段、恢复时延分布，以及每次异常影响了多少个定时任务。只有这样，技术团队才能判断问题是偶发波动，还是与任务高峰、请求频率或出口切换相关。
还要区分“代理恢复”和“业务恢复”。代理请求重新成功后，解析、去重和入库环节可能仍有积压。如果恢复时间只计算到HTTP响应成功，报告会低估实际影响。更稳妥的口径是同时记录网络恢复时间和数据链路恢复时间，并分别设定内部目标。
测试周期应覆盖企业实际的高峰与低谷，而不是只在低负载时运行几个小时。舆情任务若需要全天执行，验证窗口也应覆盖完整业务周期；如果目标站点在不同时段有不同访问频次要求，还要分别观察，不把某个时段的结果外推到全部时段。
这套测试怎么落到国内隧道代理？
持续舆情监测需要固定入口、连续发起请求并在异常后重新获得可用出口，这类需求可以评估极安代理的国内隧道代理。该产品通过统一隧道入口接入，支持异常IP自动切换、毫秒级更换IP，默认5M带宽和每秒5个请求（来源：极安代理官网）。
这些参数只能说明产品机制与基础规格，不能直接等同于舆情业务的恢复时间或最终成功率。实际测试仍要按目标站点的访问规则设置请求节奏，并分别记录切换发生、请求恢复和数据补齐三个时间点。选型真正要验证的不是“有没有自动切换”这几个字，而是切换后业务是否在可接受的时间内恢复完整。
常见问题
Q1：测试代理持续可用，运行几个小时够吗？
不一定。测试窗口至少要覆盖真实业务中的高峰、低谷和定时任务集中时段。若舆情监测需要全天运行，只测低负载的几个小时无法代表完整周期。时间长短不是唯一标准，是否覆盖关键运行状态更重要。
Q2：恢复时延应该从什么时候开始计算？
建议从第一次确认失败的时间开始，计算到连续多次探针成功且内容校验通过。还可以再记录一个数据链路恢复时间，直到异常窗口内的任务完成补采或被明确标记为缺失。
Q3：使用自动切换后，还需要业务程序重试吗？
需要，但两者职责不同。代理侧切换负责更换不可用出口，业务程序重试负责重新提交失败请求。我们极安代理在舆情监测场景中的判断是，两层机制要分别记录，否则很难确认恢复来自哪一层，也无法定位重复采集问题。
Q4：总成功率很高，为什么还要看最长连续失败？
因为舆情监测关注时间线完整性。零散失败可能通过后续补采处理，连续失败却容易形成整段数据空白。总成功率回答“整体完成了多少”，最长连续失败回答“最严重的一次影响有多大”，两项不能互相替代。
