影刀RPA实操指南：采集任务的断网重试与网络异常兜底

影刀RPA实操指南采集任务的断网重试与网络异常兜底采集流程白天手动跑断网了你肉眼看见、点一下重跑就行。真正要命的是凌晨挂机跑的定时采集跑到一半路由器抽风网页加载超时机器人停在一半早上起来一看数据缺了三分之一日志里躺着一串报错。这篇文章讲的就是怎么用影刀RPA给采集任务装上网络保险丝断网了自动等、自动重试、重试还不行就保存进度、发通知等你早上醒来它已经自己扛过去了。这套兜底方案是我挂机采集被坑了大半年才一点点补齐的按这个框架改一遍你的流程才敢真正离开视线。先把话说在前面网络异常没法消灭只能兜住。所有方案的目标不是不出错而是出错之后流程自己能恢复恢复不了也能留下完整现场。先认识网络异常的四种形态兜底之前得知道敌人长什么样。采集中遇到的网络问题我归成四类。形态典型表现流程反应页面加载超时等待页面加载超时报错指令报错流程中断元素找不到网络慢页面没渲染完定位失败报错或抓到空值请求超时HTTP请求、数据库查询卡住长时间无响应后报错彻底断网打开网页直接失败一连串指令连续报错四种形态的处理优先级不同。前两种最常见靠等待加重试就能解决大半第三种要去检查指令的超时参数设置第四种才是真正需要整套兜底机制的。动手前先跑一轮流程把日志翻一遍看你的报错集中在哪一类别上来就全套堆上去。第一道防线把超时参数设置到位很多网络异常其实是超时参数没设对。影刀RPA里跟时间相关的参数散在各处指令里新手默认不填系统给的默认值不一定适合你的网络环境。重点检查这几个地方打开网页指令页面加载的等待设置网络差的环境适当放宽等待元素出现指令动态渲染的页面给足时间一般设10到30秒HTTP类指令官方文档里HTTP下载的超时时间默认是300秒另有连接超时秒数参数单独设置请求慢的接口要把两个参数都过一遍数据库连接MySQL查询大表超时是另一类坑下面单独讲我自己的原则是宁可多等三十秒不要提前报一次错。挂机任务跑八小时多等的那些时间根本不心疼但一次没兜住的报错就毁了整晚。等待的艺术三种等待指令别混用网页自动化的等待是防网络抖动的第一道墙影刀里有三种等待用法完全不同。固定等待延时指令就是死等几秒只在知道页面固定刷新周期的场景用比如点击翻页后等2秒让列表渲染。等待元素出现是智能等待等到元素出现才继续这是采集流程的主力配合超时时间使用。还有页面加载类的等待用于打开网页后确保文档加载完成。常见的错误用法是全程用固定等待网络好的时候白等网络差的时候等不够。我的组合拳是等待元素出现打底短固定等待微调翻页后的标准序列是点击下一页→等待新列表第一条元素出现超时30秒→固定等待1秒缓冲→开始抓取。等待元素出现指令的超时时间里元素没出现会触发它自己的失败分支或报错这个失败正是下一节重试机制的触发点。核心机制While循环实现的自动重试重试是整个兜底方案的心脏。逻辑很简单把可能因网络失败的操作包起来失败了就等几秒再试试满N次还不行才认输。# 伪代码网络操作的标准重试骨架影刀流程的对应结构# 变量初始化retry_count0# 已重试次数max_retry3# 最大重试次数successFalse# 成功标志# While条件循环没成功且没超次数就继续试while(notsuccess)and(retry_countmax_retry):try:# 这里放可能因网络失败的指令比如# 打开网页 / 点击翻页元素 / 等待列表元素出现successTrueexcept:retry_countretry_count1# 失败后别立刻重试指数退避等 5s、10s、20ssleep(5*(2**(retry_count-1)))print(网络异常第str(retry_count)次重试)# 循环结束后 success 仍为 False → 彻底失败走兜底分支ifnotsuccess:save_progress()# 保存断点后面细讲notify()# 推送告警两个细节决定重试的成败。一是重试间隔要用递增间隔第一次等5秒、第二次10秒失败后立刻重试大概率还是失败还会加重网络和目标站点的负担。二是重试次数别设太大3次是我的上限重试是恢复手段不是死磕死磕会把一次小故障放大成整夜空转。这个骨架做成一个子流程名叫02_网络重试包裹以后每个可能受网络影响的操作都套一层一次编写处处复用。Try-Catch-Finally兜底机制的地基上面的重试骨架里已经用到了Try-Catch这里把影刀RPA异常处理机制讲完整。Try块放可能出错的指令Catch块处理错误Finally块放无论成败都要执行的收尾End Try结束整个结构。Catch块里要做的三件事一件都不能省保存错误信息Catch可以拿到Try里的报错内容存进变量后用打印日志写出来错误截图把当前屏幕截下来存进按时间命名的文件夹网络类报错的截图往往能直接看出是断网、弹窗还是验证页设置失败标志给一个布尔变量赋False让外层逻辑知道这一步失败了Finally块的价值容易被低估不管成功失败都要关掉弹窗、清空临时文件这类动作放这里能避免失败重试时上一轮的残留状态污染下一轮。新手最典型的bug就是第一轮失败的弹窗没关重试时点到的还是那个弹窗越重试越乱。分模块的异常处理粒度也要讲究单条数据的抓取用小颗粒Try坏一条跳一条整个采集任务外层再套一个大颗粒Try保证通知和进度保存一定执行两层各司其职。断点续采断网恢复后从断的地方继续重试解决抖一下断点解决彻底断了。凌晨断网十分钟重试三次全失败这时候流程应该做的事是记住采到哪了然后体面地结束而不是从头再来。断点的实现靠一个游标变量我常用两种游标页码游标翻页采集时记录当前页码写进本地文本文件或配置表数据游标记录最后一条已采数据的ID或时间戳恢复时从这个位置往后采恢复逻辑放在流程开头先读游标文件读到值就从对应位置继续读不到比如首次运行就从第一页开始。每翻一页、每采一批就把新游标写回文件写文件这步不能省我见过有人只在内存里记游标流程一崩全忘光。配合增量采集的设计已采ID去重断点续采的可靠性还能再提一层就算游标丢了导致重复抓了几个页面ID去重也能拦住重复数据进表。两套机制叠着用才叫真正的兜底。数据库写入的网络坑2013报错与read_timeout数据入库环节的网络问题很隐蔽值得单独拎出来。用Python节点连MySQL写入采集数据时跑大查询或写入大批量数据可能遇到报错2013, Lost connection to MySQL server during query本质是连接超时被服务器掐断了。官方文档给的办法很直接调整pymysql连接的read_timeout参数给足等待时间。# 连接MySQLread_timeout防止大查询被掐断importpymysqldefmain(args):connpymysql.connect(host127.0.0.1,port3306,useryour_user,passwordyour_pwd,dbyour_db,charsetutf8,read_timeout600)# 读写超时600秒returnconn除了超时写入侧还有两个稳定习惯一是分批提交一千条一批commit别攒十万条一次写网络一抖整批重来二是写入操作也套重试骨架数据库和网页一样会抖。批量插入时遇到Duplicate entry唯一值冲突报错说明有重复主键要么写入前先查重要么用容错的插入写法这个报错在官方报错文档里有专门条目。如果写入的是飞书多维表格这类云端存储API调用本身也要套重试云端服务的限流比本地数据库更常见收到限流响应就退避等待再发。无人值守的报警链路日志、截图、消息推送流程半夜自己扛不住的时候必须能把消息递出来。我的一套报警链路是三层。第一层是运行日志关键节点都打印日志开始采集、翻到第N页、重试第2次、保存断点日志要简洁有信息量。这里有个小坑打印日志对超长字符串有截断想把完整的报错堆栈或网页内容留下写进文本文件更可靠。第二层是错误截图所有Catch块里都带截图按日期_时间_模块名命名早上排查问题先翻截图文件夹比读日志快。第三层是消息推送彻底失败时发飞书或企业微信通知。飞书群机器人配置好Webhook后用HTTP请求指令把错误摘要推到群里几行指令的事。通知内容要写清三件事哪个流程、卡在哪一步、已保存的断点位置收到消息的人不用打开电脑就知道要不要紧急处理。定时任务的错峰与环境保障挂机采集的稳定性一半在流程一半在环境。定时任务配置上有几条实测经验。机器所在电脑要关掉自动睡眠不然凌晨流程跑一半电脑睡了什么兜底都救不了。多个采集任务别设同一个时间点错峰排队不然机器人挤在一起单个任务变慢超时报错成倍增加——很多网络异常其实是自己堵的。影刀的机器人调度模式支持云端控制台下发计划任务企业环境可以看机器人状态是空闲、运行中还是离线离线状态的机器人不会执行任何计划任务定时采集前确认在线很重要。另外计划任务执行时不能断点调试所有兜底逻辑必须在编辑器里手动验证过再上线这是我强调过很多遍的上线纪律。夜间网络环境普遍比白天波动大夜间任务的等待超时和重试次数建议都设得比手动运行时宽松一档。进阶技能的补位HTTP采集与OCR验证网页采集之外两条进阶路线的网络兜底也要跟上。HTTP接口采集时请求失败重试、限流退避的骨架和网页一致接口的返回状态码要先判断再解析别拿一个报错页面的HTML去转JSON。HTTP下载类指令记得检查默认300秒的超时是否符合你的场景大文件下载要调大。有些站点网络恢复后会先弹验证码这是很多人忽略的坑网络兜底成功了流程却卡在验证页。简单的图形验证码可以接OCR识别影刀内置OCR或接第三方OCR都行识别失败同样要走重试和告警链路。验证页出现频繁的话说明请求频率太高了降速比识别更治本。手机端采集ADB方案在弱网下问题更多手机端有专门的等待元素、等待图像指令把网页端这套等待重试断点的思想平移过去指令名不同、骨架一样。工程化规范把兜底做成标准件兜底机制代码量大、逻辑琐碎最忌讳每个项目重写一遍。我的做法是沉淀四个标准子流程网络重试包裹、断点读写、错误记录日志截图失败标志三合一、告警推送。新项目像搭积木一样把它们插进主流程半小时就能给一个裸采集流程装上全套保险。命名沿用编号_功能的规范调试时单独跑网络重试包裹子流程手动断网模拟故障看着重试间隔和日志输出比等真实故障来验证快得多。每个兜底子流程的输入输出参数写清注释三个月后你自己会感谢现在写注释的自己。版本选择上顺带说一句无人值守挂机对运行时长有要求社区版每天30分钟的限制下定时挂机跑大任务不现实轻量日更任务够用任务重了再考虑升级先用好兜底框架流程稳了再谈规模。易错速查网络异常排查清单挂机出问题早上别慌先对表。现象原因解决等待页面加载超时网络慢或超时设太短放宽超时加重试骨架元素定位失败但元素在页面未渲染完加等待元素出现别用裸固定等待MySQL报2013连接丢失查询超时被断开read_timeout调大分批提交重试后越跑越乱上轮弹窗未清理Catch/Finally里关闭弹窗再重试断点没生效游标只存内存没落盘每批写入游标文件半夜任务压根没跑电脑睡眠或机器人离线关睡眠检查机器人在线状态日志里报错被截断打印日志长度限制完整内容写文本文件学习资源本文的重试骨架、断点读写、告警推送三件套完整流程源码我放在代码仓库 home.linyan.cloud可以直接参考改造断网模拟的测试方法也写在源码注释里。官方帮助中心建议精读等待页面加载超时和连接数据库2013报错两篇分别对应网页端和数据库端最容易踩的两个超时坑。#影刀RPA #RPA自动化 #异常处理 #定时任务 #数据采集作者林焱