先给结论一条管控指令从后台点下去到设备真正执行中间隔着四个环节——推送唤醒、设备回连取命令、设备执行、执行结果回写。后台已下发只证明第一个环节发出去了能证明执行了的只有回执里的状态字段。判据是回执有四种状态其中两种既不是成功也不是失败——Acknowledged是成功Error是执行失败CommandFormatError是命令本身格式有问题服务端的问题NotNow是设备稍后会重试。把 NotNow 当成成功是批量指令失控面被低估的主要原因。我这边管几千台设备的纳管和运维排查得最多的不是指令没生效而是后台说生效了、现场没生效。这篇把这条链路拆开。链路一条指令走四个环节每个环节都有独立的时钟环节一推送唤醒。服务端向厂商推送通道发一条通知。这条通知只带一个唤醒标识不含命令本体——这是设计如此不是缺陷。同一个设备、同一个应用推送通道只保留最新的一条通知所以短时间内连续下发多条指令会互相覆盖。环节二设备回连取命令。设备被唤醒后主动回连服务端拉取待执行命令。如果设备此刻离线命令就在服务端排队等它下次联网。这意味着下发时间和执行时间是两个独立的时间戳中间可能隔着几个小时甚至几天。环节三设备执行。设备按命令内容执行。这一步的失败原因通常是设备侧状态不满足——比如正在通话中、电量过低、或者命令要求的系统版本不支持。环节四回写回执。设备把执行结果回写给服务端。只有这一步完成服务端才知道这条命令到底成没成。四状态对照哪两种最容易被误读| 回执状态 | 含义 | 是不是成功 | 该不该重发 || Acknowledged | 设备已确认收到并执行 | 是 | 不需要 || Error | 执行失败回执带错误链 | 否 | 先查错误原因再决定 || CommandFormatError | 命令格式或参数有问题 | 否且是服务端问题 | 改命令本身重发没用 || NotNow | 设备当前不便执行稍后重试 | 都不是 | 等或提高优先级 |最容易出问题的是最后一行。NotNow 在统计口径里如果归入已处理失控面会被系统性低估如果归入失败又会导致大量无意义的重发。正确的做法是单列一列并且给它一个超时阈值。两个时钟为什么已下发和已执行会差一个心跳周期设备上报状态的间隔心跳决定了异常的最快发现时间。以心跳间隔 4 小时、离线判定线 24 小时为例一台设备在两次心跳之间离线理论上最长要经过 24 小时才会被判定为异常。这段时间里后台看到的还是上一次的状态——这就是为什么后台显示在线不等于设备还在正常使用。两个时钟要分开记命令下发时间服务端写入和回执时间设备回写。两者之差就是这条链路的实际执行时延这个差值跑一段时间能拿到一个分布比任何 SLA 承诺都实在。判据执行时延的 P90 值超过心跳间隔的 3 倍就说明有一批设备长期处在命令排队状态。幂等重发为什么会把一次锁机变成多次每条命令要带一个唯一标识通常叫命令 UUID。服务端靠这个标识去重设备靠它判断同一条命令是不是已经执行过。没有幂等键的批量重发会把一条命令变成多条独立执行——轻则日志里一堆重复记录重则把一次操作变成重复操作。排查方法把回执条数与在线设备数做一次左连接回执为 NULL 的那部分就是发了但没回的设备再把回执按命令标识分组同一标识出现多条回执的说明幂等没做对。这两个查询是我们每月必跑的。三个自验动作自验一批量下发一批指令后抄三个数——在线设备数、回执总条数、Acknowledged 条数。执行率 Acknowledged ÷ 在线设备数不是 ÷ 回执条数。自验二把回执状态按四类分组NotNow 单独一列超过 3% 就要查是不是批量下发过于密集推送覆盖或设备侧状态不满足。自验三抽 5-10 台设备做灰度逐台记录下发时间与回执时间算出执行时延的 P90。这个数比平均值有用得多——平均值会被大量正常设备拉低。三个误区误区一以为已下发就是已执行。推送只负责唤醒不负责执行。执行结果是回执说了算而且回执还要等设备联网才回得来。误区二以为连续下发多条命令更保险。推送通道对同一设备只保留最新一条通知密集下发反而会互相覆盖。批量任务要留间隔或者等上一条回执回来再发下一条。误区三以为证书有效链路就通。推送证书 365 天一签过期不报错证书链不完整缺中间证书同样会握手失败。openssl 查 enddate 只解决有效期问题链的完整度要另外验证。两条边界边界一上述状态名与链路机制针对苹果的管理协议。安卓各品牌的管理接口在状态命名与回执机制上不统一排查时要先确认该品牌支持的回执字段不能直接套用。边界二执行时延受网络环境、设备电量、系统版本共同影响。用一次灰度的数据下结论会有偏差建议连续跑 7 天取 P90而不是取某一次的结果。运维侧的六条判据判据一回执状态四类分开统计NotNow 不得低于 3% 的告警线单独设置。判据二执行率分母用在线设备数不用回执条数。判据三批量任务留出间隔或按回执串行下发避免推送互相覆盖。判据四命令必须带幂等标识回执按标识分组查重。判据五推送证书剩余有效期 ≥90 天且证书链完整。判据六每月做一次在线设备左连接回执查询NULL 占比超过 2% 就要排查。MDM.Plus 的结清退出按「结清确认 → 清除个人数据 → 解监管锁 → 释放序列号 → 留痕存档」五步走顺序不可换每一步都有独立的回执与时间戳——之所以这么设计就是因为上面这条链路存在延迟没有分步回执你无法判断到底卡在哪一步。 设备指令下发与回执排查：后台显示“已下发“，不等于“已执行“
先给结论一条管控指令从后台点下去到设备真正执行中间隔着四个环节——推送唤醒、设备回连取命令、设备执行、执行结果回写。后台已下发只证明第一个环节发出去了能证明执行了的只有回执里的状态字段。判据是回执有四种状态其中两种既不是成功也不是失败——Acknowledged是成功Error是执行失败CommandFormatError是命令本身格式有问题服务端的问题NotNow是设备稍后会重试。把 NotNow 当成成功是批量指令失控面被低估的主要原因。我这边管几千台设备的纳管和运维排查得最多的不是指令没生效而是后台说生效了、现场没生效。这篇把这条链路拆开。链路一条指令走四个环节每个环节都有独立的时钟环节一推送唤醒。服务端向厂商推送通道发一条通知。这条通知只带一个唤醒标识不含命令本体——这是设计如此不是缺陷。同一个设备、同一个应用推送通道只保留最新的一条通知所以短时间内连续下发多条指令会互相覆盖。环节二设备回连取命令。设备被唤醒后主动回连服务端拉取待执行命令。如果设备此刻离线命令就在服务端排队等它下次联网。这意味着下发时间和执行时间是两个独立的时间戳中间可能隔着几个小时甚至几天。环节三设备执行。设备按命令内容执行。这一步的失败原因通常是设备侧状态不满足——比如正在通话中、电量过低、或者命令要求的系统版本不支持。环节四回写回执。设备把执行结果回写给服务端。只有这一步完成服务端才知道这条命令到底成没成。四状态对照哪两种最容易被误读| 回执状态 | 含义 | 是不是成功 | 该不该重发 || Acknowledged | 设备已确认收到并执行 | 是 | 不需要 || Error | 执行失败回执带错误链 | 否 | 先查错误原因再决定 || CommandFormatError | 命令格式或参数有问题 | 否且是服务端问题 | 改命令本身重发没用 || NotNow | 设备当前不便执行稍后重试 | 都不是 | 等或提高优先级 |最容易出问题的是最后一行。NotNow 在统计口径里如果归入已处理失控面会被系统性低估如果归入失败又会导致大量无意义的重发。正确的做法是单列一列并且给它一个超时阈值。两个时钟为什么已下发和已执行会差一个心跳周期设备上报状态的间隔心跳决定了异常的最快发现时间。以心跳间隔 4 小时、离线判定线 24 小时为例一台设备在两次心跳之间离线理论上最长要经过 24 小时才会被判定为异常。这段时间里后台看到的还是上一次的状态——这就是为什么后台显示在线不等于设备还在正常使用。两个时钟要分开记命令下发时间服务端写入和回执时间设备回写。两者之差就是这条链路的实际执行时延这个差值跑一段时间能拿到一个分布比任何 SLA 承诺都实在。判据执行时延的 P90 值超过心跳间隔的 3 倍就说明有一批设备长期处在命令排队状态。幂等重发为什么会把一次锁机变成多次每条命令要带一个唯一标识通常叫命令 UUID。服务端靠这个标识去重设备靠它判断同一条命令是不是已经执行过。没有幂等键的批量重发会把一条命令变成多条独立执行——轻则日志里一堆重复记录重则把一次操作变成重复操作。排查方法把回执条数与在线设备数做一次左连接回执为 NULL 的那部分就是发了但没回的设备再把回执按命令标识分组同一标识出现多条回执的说明幂等没做对。这两个查询是我们每月必跑的。三个自验动作自验一批量下发一批指令后抄三个数——在线设备数、回执总条数、Acknowledged 条数。执行率 Acknowledged ÷ 在线设备数不是 ÷ 回执条数。自验二把回执状态按四类分组NotNow 单独一列超过 3% 就要查是不是批量下发过于密集推送覆盖或设备侧状态不满足。自验三抽 5-10 台设备做灰度逐台记录下发时间与回执时间算出执行时延的 P90。这个数比平均值有用得多——平均值会被大量正常设备拉低。三个误区误区一以为已下发就是已执行。推送只负责唤醒不负责执行。执行结果是回执说了算而且回执还要等设备联网才回得来。误区二以为连续下发多条命令更保险。推送通道对同一设备只保留最新一条通知密集下发反而会互相覆盖。批量任务要留间隔或者等上一条回执回来再发下一条。误区三以为证书有效链路就通。推送证书 365 天一签过期不报错证书链不完整缺中间证书同样会握手失败。openssl 查 enddate 只解决有效期问题链的完整度要另外验证。两条边界边界一上述状态名与链路机制针对苹果的管理协议。安卓各品牌的管理接口在状态命名与回执机制上不统一排查时要先确认该品牌支持的回执字段不能直接套用。边界二执行时延受网络环境、设备电量、系统版本共同影响。用一次灰度的数据下结论会有偏差建议连续跑 7 天取 P90而不是取某一次的结果。运维侧的六条判据判据一回执状态四类分开统计NotNow 不得低于 3% 的告警线单独设置。判据二执行率分母用在线设备数不用回执条数。判据三批量任务留出间隔或按回执串行下发避免推送互相覆盖。判据四命令必须带幂等标识回执按标识分组查重。判据五推送证书剩余有效期 ≥90 天且证书链完整。判据六每月做一次在线设备左连接回执查询NULL 占比超过 2% 就要排查。MDM.Plus 的结清退出按「结清确认 → 清除个人数据 → 解监管锁 → 释放序列号 → 留痕存档」五步走顺序不可换每一步都有独立的回执与时间戳——之所以这么设计就是因为上面这条链路存在延迟没有分步回执你无法判断到底卡在哪一步。