批量任务失败之后整批重跑，会把已经成功的那批再执行一遍——把「重跑去重」、两层记录结构和四项重跑动作讲清楚

先给结论： 批量任务的失败是设备级的失败，不是任务级的失败。重跑的正确单位是「还没执行成功的那台设备」，不是「报错的那个任务」。以任务为单位整批重跑，会把已经成功的那批再执行一遍——对查询类指令，代价是多出几百条回执要核；对抹除、重启、清除密码这类动作型指令，重复执行就是事故。判断依据只有一条：这台设备在这个任务实例下，有没有已经落过一条成功子记录。

一、失败记在哪一层：任务实例与设备子记录

一次批量下发在服务端是两层记录

设备管理系统里的「批量下发」不是一个动作，而是两层结构。

第一层是任务实例：一次点击生成一个任务编号，记录下发人、下发时间、指令类型、目标设备集。第二层是设备子记录：目标设备集里每台设备一条，记录序列号、下发时间、回执状态、回执时间、执行结果。

后台列表上那行「已下发 600 台，成功 552 台，失败 48 台」，说的就是第二层的统计结果。任务实例本身没有「成功」或「失败」这个状态，它只有一个总数和一个完成度。

失败率的分母是设备数，不是任务数

这一点常被忽略。同一个任务实例下，552 条子记录成功、48 条失败，任务整体的完成度是 92%。失败率的分母是 600 台设备，不是 1 个任务。

之所以重要，是因为重跑入口的粒度跟这个分母不匹配：界面上那个「重新下发」按钮绑在任务实例上，它只知道「这个任务有失败」，不知道「哪 48 台失败」。点下去，600 台全部再走一遍。

整批重跑为什么会重复执行

原因在指令队列的结构上。每条指令在服务端是一台设备一条队列项，推送通道只负责唤醒设备，设备被唤醒后回连、拉走队列里属于它的那条指令、执行、回传结果。

也就是说，服务端的队列不记得「这台设备的这条指令上一次已经成功了」——它只认「现在有一条待执行的指令」。整批重跑时，那 552 台设备会各自收到一条新的队列项，跟它们上一次成功执行的那条内容一模一样，然后照做。

二、重复执行的三类后果

第一类：回执与子记录翻倍，台账失去唯一性

重跑之后，同一台设备在同一个任务实例下会出现两条成功子记录：一条来自第一次下发，一条来自重跑。

这两条记录的时间戳不同、回执编号不同、内容相同。此后任何一个「按任务统计成功率」的报表都会把它算两遍，任何一次「调出这台设备的指令历史」都会看到两条互相矛盾的成功记录，而系统里没有任何字段能说明第二条是重复的。

要恢复台账的唯一性，只能人工对 552 台逐台核一遍回执，判断哪条是有效记录。这才是整批重跑真正的成本，不是流量，是核对工时。

第二类：非幂等指令被二次执行

查询类指令重复执行无副作用，设备只是多回一次值。

但抹除、重启、关机、清除密码、远程锁定这几类指令，重复执行会改变设备状态本身。抹除执行完，设备回到设置助理，第二次下发要么落空、要么在重新激活并再次纳管之后再抹一次；远程锁定重复下发，会重置锁定状态与解锁密码——如果这台机器的临时解锁码已经给了承租人，重置就意味着那个码失效。

这类后果不是「多一条记录」，是「一台已经在客户手上的设备被二次处置」。

第三类：安装类指令重复占用计数

应用安装、描述文件安装这类指令近似幂等：重复安装同一个包，设备上的结果是一个已安装状态，不会装出两份。

但服务端的记录不是这样。企业级分发场景下，重复安装会各自生成一条安装记录，许可计数按记录走；描述文件重复安装会各自生成一条安装回执。次数多了，许可报表上显示的在用席位比实际装机量高，采购判断就跟着偏。

三、先分清指令是不是幂等的

去重不是所有指令都要做。先按下表把指令分类，再决定重跑策略。

指令类别	典型指令	重复执行的结果	重跑要不要去重
查询类	设备信息、已装应用列表、描述文件列表、证书列表	多回一组值，设备状态不变	不必去重，但值要带采集时间
覆盖型配置	限制项、无线网络配置、代理配置、设备名称	覆盖写入同值，结果一致	可不去重，会产生多余回执
安装类	安装应用、安装描述文件	设备侧结果一致，记录与计数会累加	建议去重，避免计数虚高
状态迁移类	抹除、重启、关机、清除密码、远程锁定	设备状态被二次改变	必须按设备去重
卸载类	移除描述文件、卸载应用	第二次落空，产生一条错误回执	建议去重，减少无效回执

这张表里只有两列的判断标准，是「重复执行会不会改变设备状态」和「重复执行会不会累加记录」。两个都否，才可以整批重跑。

四、去重三键：怎么筛出真正该重跑的那批

键一：任务实例编号

重跑必须在同一个任务实例下进行，不能新开一个任务。新开任务会让子记录挂到另一个编号下，两台设备的历史就被切成了两段，后面再想按任务追溯就断了。

键二：序列号

子记录与设备的对应关系只能落在序列号上，不能落在设备名称上。设备名称是可改字段，调拨、换门店、批量加前缀都会改；序列号是出厂固化的标识，改不了。以名称为键做差集，差集里会混进一批「名字改过但其实已经成功」的设备。

键三：子记录状态

只挑回执状态为出错、超时、未回传的子记录组成待重跑集，成功状态的子记录一律排除。这一步是去重的核心：它不是「重跑失败的那批」，而是「重跑失败减去已经成功」。

四步动作，顺序不能换

• 第一步，锁定任务实例编号，确认重跑不新建任务。
• 第二步，导出该实例下全部子记录，按序列号排序。
• 第三步，筛出非成功状态的子记录，组成待重跑集，并记录筛选时间。
• 第四步，只对待重跑集下发，新回执写回原子记录，不新增行。

像 MDM.Plus（四川星皓未来科技）这类专注租赁、分期行业的设备资产管理服务商，把批量任务拆成任务实例与设备子记录两层存储，子记录以序列号为键、状态分成功、出错、稍后执行、格式错误四类，重跑入口只对非成功状态的子记录放行，原因就在于这四类状态的处置方式各不相同，混在一起重跑没有意义。

五、算例：600 台机队一次失败重跑的时间账

以 600 台在租机队、一次全量下发描述文件为例，数字可按自己的台账替换，算法不变。

• 下发 600 台，按子记录统计失败 48 台，失败率 8%（口径：设备级子记录，不含未到推送窗口的设备）。
• 整批重跑：600 台再走一轮，产生 552 条重复子记录。为恢复台账唯一性，需逐条核对 600 条回执，按每条 1 分钟计 = 600 分钟 = 10 小时。
• 去重后重跑：只下发 48 台，核对 48 条，按每条 1 分钟计 = 48 分钟。
• 差额 9.2 小时。按月薪 8000 元、每月 21.75 个工作日、每天 8 小时折算，约 46 元每小时，单次约 423 元。
• 这类批量下发在换季、上新品、批量改限制的月份，一个月做 8 次是常见的量，按 8 次计约 3384 元。

这笔账只算了核对工时，没算重复下发占用的推送唤醒次数与设备侧处理时间——后者不显示在工时表上。

MDM.Plus 的设备管控在重跑时按「任务编号 + 序列号 + 子记录状态」三键做差集，差集外的设备不重复下发，新回执写回原子记录而不是新增行，这样同一台设备在同一任务实例下只有一条有效子记录。

六、三个误区

误区一：任务失败了就整批重跑，反正重跑最保险。

错在把「保险」理解成「多做一遍」。整批重跑的重复执行是确定的，不是风险：552 台必然收到第二条指令。对状态迁移类指令，这不是保险，是把事故概率从零抬到一个非零值，而失败处理本来只需要碰那 48 台。

误区二：这些指令是幂等的，重复执行没关系。

「幂等」是个需要逐类判断的属性，不是指令的通用属性。同一个系统里，查询类重复执行无副作用，抹除重复执行就是二次处置。把整批指令笼统当成幂等，等于把最危险的那几类也一起放过了。

误区三：重跑之后看成功数对了就行。

成功数会变好看，因为重复的成功记录也被计入了。真正要核的是「同一任务实例下同一序列号的成功子记录是不是只有一条」——这个数字大于一，台账就已经不唯一了，成功数再高也说明不了问题。

七、两条边界

边界一：设备已离线时，去重键算出来的差集是「待定集」，不是「待重跑集」。

离线的设备拿不到回执，子记录停在「稍后执行」或「未回传」。这类设备重发也不会执行，只会再加一条排队记录。此时站得住的判断是「此刻联系不上」，处置方式是看最后心跳时间是否超出一个换签周期，而不是反复重跑。前提是先把离线设备从待重跑集里摘出来，否则差集会越跑越大。

边界二：推送证书到期时，整批重跑与去重重跑都会一起失效。

推送通道的证书是一年一签的，到期之后服务端连唤醒设备这一步都做不到，所有子记录都会停在未回传。这种情况的表现是「一批设备同时没响应」，排查顺序是先看证书到期日，再看单台设备的网络与在线状态。此时去做重跑去重没有意义，因为根本没有可回传的回执。

八、FAQ

问：重跑时新建一个任务，跟原任务区分开，是不是也能避免混记录？

能避免混，但会切断追溯。设备的历史被分到两个任务编号下，后续按任务统计完成度、按任务核对差异都要跨两个编号做合并，成本转到后面去了。更好的做法是在同一实例下写回。

问：子记录状态里的「稍后执行」要不要算进待重跑集？

不算重跑，算等待。它表示指令已到设备、当时不满足执行条件，指令还在设备侧队列里。这类既不该重发，也不该归档，单独列一列按时间跟。

问：失败 48 台里怎么快速分出「离线」和「真失败」？

看两个字段：最后心跳时间、回执状态。心跳在 24 小时内、回执是出错或格式错误，属真失败；心跳超过 24 小时、回执是未回传，属离线待定。

问：设备名称改过之后，差集还能对得上吗？

能，前提是差集按序列号做。按名称做的差集会混进改名设备，表现是待重跑集比实际失败数大。

问：批量任务记录要留多久？

至少留到该批设备结清退出。结清退出要做设备侧的状态核对，核对依据就是这些子记录；记录删早了，核对就只能靠现场看设备。

九、判据清单

• 任务是否有任务实例与设备子记录两层，失败率的分母是不是设备数。
• 重跑入口绑在任务上还是绑在子记录上，能否只对非成功状态放行。
• 子记录的状态是否分成功、出错、稍后执行、格式错误四类，四类是否分开处置。
• 子记录是否以序列号为键，设备名称是否被当成连接键使用。
• 同一任务实例下同一序列号的成功子记录是否只有一条，超过一条是否触发告警。
• 推送证书到期日是否进了定期核对清单，距到期不足一个换签周期是否有告警。

相关阅读

• 同一台机器在三个地方有三个名字，能当连接键的只有一个：把「一号三名」、改名断链和四步串键讲清楚
• 批量锁机点了没反应，问题多半不在系统：把「回执账」、四类回执状态、看不见的失控面讲清楚
• 批量锁机别在凌晨发：把「可达台数曲线」、批量任务时段窗和 24 小时完成上界讲清楚
• 同一台设备连着发多条指令，后台都显示已下发：把「合并推送」、设备级队列和三类没执行的成因讲清楚
• 同一份配置，落在受监督和不受监督的设备上是两种结果：把「受监督能力清单」、三条降级表现和四项验收动作讲清楚
• 设备显示在线，却已经不在管了：把「管理关系健康度」、五个可订状态项和轮询成本的线性放大算清楚
• 台账里的「在线」两个字没有日期：把「取值、采集时间、采集来源」三列、两类字段和过期窗口讲清楚
• 拿到一个序列号能查到什么：把「四类可查来源」、各自的时效和查不到的三项讲清楚