脚本半夜挂了第二天才发现？苹果群控的异常告警怎么配

苹果群控，是通过一台电脑对多台 iPhone 做集中管理与批量操作的技术方案，不越狱、不装插件，靠外部输入注入驱动设备。这篇聊的是脚本半夜挂了第二天才发现，苹果群控的异常告警怎么配。

先看得见：把任务面板读熟

有个做机房的朋友，某天上午九点半到公司，发现昨晚定时跑的发布任务一台都没执行。先怀疑设备掉了，查了半小时设备全在线；又怀疑脚本坏了，回滚一个版本还是没跑。最后在任务面板看到状态写着「已暂停」——流程里有个步骤在等人点一下。任务凌晨两点挂的，他九点半才知道，中间七个多小时什么都没发生。他说的一句话是：我不怕它挂，我怕的是挂了没人告诉我。

巡检和告警能发现的问题不一样。巡检擅长慢性的：某几台设备最近老掉线、某个账号表现一直下滑、线材开始接触不良——不紧急但拖着会出事。告警擅长突发的：半夜两点定时任务整体失败、某台设备从昨天下午就掉线、脚本卡在某一步不动。

告警的前提是监控，第一件事不是配通知，是把任务面板读熟。每条任务上显示四个字段：状态、来源、跑了多少台设备、成功和失败数量，以及执行时间；来源会标出这条任务是 AI 会话触发的、工作流编辑器试跑的、还是定时任务自动触发的。四个状态里两个最需要认识。部分成功：流程本身跑通了但有设备掉队，最容易被当成「成功」忽略，而它恰恰是问题最早的信号——一批 30 台里固定有 4 台失败，通常是那 4 台线材或系统版本有问题。已暂停：通常是流程里有「等人操作」的步骤，系统停在那里等你；无人值守的流程一暂停就没人推进，会一直挂在后台。点开一条任务能看到每台设备单独的状态，失败的给出错误说明——这一步是判断影响面的关键：是整批的问题，还是集中在某几台。

至于「半夜跑」靠的是定时任务：按设定的时间规则自动运行已保存的工作流，每次触发都会生成一条普通任务落到同一个任务面板里，所以只要规则没错，夜里跑的东西白天是能查到的。还有个坑：触发时如果所有目标设备都被跳过（设备正忙），这次触发算作失败，失败原因记在定时任务列表的「最近错误」列里——这时候任务面板看不到任何记录，它根本没生成任务。排查「任务没跑」时两个地方都要看。

再让它主动找你：钉钉告警怎么接

光能查到还不够，你要的是「它出事了会来敲你」。脚本里可以直接往钉钉机器人发消息，EC USB 6.16.0 以上提供了这个函数，传入 Webhook 地址、密钥和消息内容，还能指定 @ 谁或 @ 所有人：

function main() {
  let url = "https://oapi.dingtalk.com/robot/send?access_token=你的 token";
  let secret = "你的密钥";   // 也可以不写，改用关键字过滤方式
  var res = sendDingDingMsg(url, secret, "夜间发布任务失败，请查看任务面板", "", true);
  logd("告警返回：" + res);
}

main();

返回值是 JSON 字符串，errcode 等于 0 代表成功、其他值都是错误——一定要打日志，不然告警通道自己坏了你都不知道。最小可用做法是把调用放进脚本的异常分支：任务出错就推送；更进一步是在关键节点主动上报进度，比如「30 台全部完成」「有 4 台失败」，这样不只能知道出事了，还能知道结束时的状态。

和告警配套的是运行日志。任务失败后到日志里能看到停在哪一步：没找到元素、加载超时、还是权限弹窗挡住；日志在任务面板里能直接打开，编辑器里回放失败步骤时也会标出原因。

告警覆盖哪些事件，怎么分级

只接一个「任务失败就通知」不够，实践中至少覆盖四类，前两类是业务层、后两类是基础设施层。任务整体失败：整批没跑成，影响当天交付。单台设备连续多次失败：一台不算事，同一台连着好几次多半是那台机器的问题，不是脚本的问题。设备掉线超过设定时长：比如离线超过两小时就通知，能抓住「设备自己在夜里掉了」而任务面板不一定反映得出来。授权或环境异常：授权到期最坑，脚本根本没跑起来、也就不会触发告警，需要独立的定时检查。

告警要分级，不然一周内你就会免疫——半夜被叫起来三次、其中两次是单台设备的小问题，第三天你就把通知静音了，第四天事故来的时候没看见。建议分两级：

级别	什么情况	怎么处理
立即通知	整批任务失败、关键时段的关键任务没跑、大面积掉线	推送到手机并 @ 人
攒着看	单台设备失败、非关键时段的小范围异常、部分成功	攒成一条早报，早上一起看

关键是「@ 人」留给真正需要起床的那一类——所有告警都 @ 所有人，等于都没有 @。还有一条边界：告警是给你争取时间的，不是替你解决问题的；半夜收到告警后如果处置流程没想好（是先重跑还是先停），爬起来也只是盯着屏幕，这个判断最好白天定好、写进流程。

别让告警自己失效，收到后按顺序处理

告警通道坏掉很隐蔽：消息发不出去但脚本不报错，你以为一切正常。三种常见失效：机器人配置失效（密钥或地址过期、群机器人被移出、关键字规则对不上）；授权到期（脚本压根没启动）；中控所在电脑的问题（关机、断网、系统更新重启，最容易被忽略，因为整套链路都跑在这台机器上）。应对是加一条反向自检：每天固定时间主动发一条测试消息确认通道通。另外把授权有效期纳入检查——返回授权信息的函数可以查到期时间，做成一条定时任务，快到期时提前通知你。

收到告警后的处置顺序四步。先看影响面：全部失败还是部分成功，范围决定后面怎么动。点开任务看明细：哪几台设备、错误说明是什么、有没有集中在某个特征上（同一批线材、同一个系统版本）。到运行日志里定位：失败停在哪一步、有没有截图留证、前面几步是否正常。最后才决定动作：重跑、跳过问题设备、还是改脚本。顺序颠倒最常见的结果是一看失败就急着重跑，把同一个问题重复一遍，还把现场毁了——先判断，再动手。

回到那位朋友，他后来把告警接上了，最大的变化不是少出事故，是睡觉踏实了。苹果群控要做到无人值守，前提不是脚本永远不挂，而是它挂了你知道、而且知道该做什么。先做最小可用版本：定时任务建起来、任务面板四个字段看熟、异常分支里加一次钉钉告警调用，通常一个下午就够；剩下的时间花在分级和通道自检上，比追求告警项越全越好更有价值。设备侧如果已经在做人工巡检，可以配合着看苹果群控设备巡检怎么做；定时任务本身怎么建，参考AI 智能体定时任务怎么配。

---

iEasyClick：手机自动化脚本与群控方案站，覆盖安卓免 root、iOS 免越狱、鸿蒙 Next，提供脚本开发教程、中控投屏与批量运维方案。官网 ieasyclick.net