客户把机器恢复出厂设置，运营端多久能发现：三个信号的上报时点

先给结论：客户在机器上执行一次抹除，运营端不是立刻知道的，能多快发现取决于你盯的是哪一个信号——心跳中断最快，纳管状态变化次之，激活锁状态最慢。原因是这三个信号的产生机制不同：心跳是设备按间隔主动上报的，纳管状态要等设备重新报到才会更新，激活锁状态则是一次查询才返回一次结果，不会自己推。MDM.Plus 的设备状态里，最后心跳时间、纳管状态、激活锁状态三项各自独立更新：心跳按间隔走、纳管在设备重新报到时刷新、激活锁在查询时返回，三个时点不同，所以不能用任何一个去替代另外两个。底层机制是：抹除这个动作发生在设备本地，它不会向服务器发一条"我被抹了"的通知，运营端看到的永远是"副作用"，不是"事件本身"。

信号一：心跳中断，最快也最容易误报

已纳管的设备会按心跳间隔与服务器保持联系。设备被抹除之后，在重新走完设置助理之前，这条心跳会中断。

所以心跳中断是三个信号里最早出现的。它的时点取决于心跳间隔本身，后台一般会把"最后心跳时间距现在超过 24 小时"作为离线判据，也有把阈值设到 4 小时的。阈值定得越短，发现越快，误报也越多，这两个数是绑在一起的。

但它的误报率也是三个里最高的。关机、没电、进电梯、开了飞行模式、在没有信号的地下室，都会让心跳断掉。之所以不能单看这个信号就下结论，原因就在这里：它只能证明"设备现在联系不上"，不能证明"设备被抹了"。

信号二：纳管状态变化，看的是设备重新报到

第二个信号是纳管状态。设备抹除后重新开机，如果它是通过自动设备注册进来的、序列号还在企业的苹果商务管理门户里，它会重新走一遍设置助理并再次纳管。

这种情况下后台看到的是一条很特别的曲线：纳管状态短暂变成未完成，过一阵又自己回到正常。如果只看当前状态、不看变化过程，这一整件事会被完全漏掉——因为最终状态是正常的。

如果设备不是自动设备注册进来的，或者序列号已经被释放掉了，抹除之后它就不会自己回来，纳管状态会一直停在未完成。这时候这个信号是可靠的，但它出现得比心跳中断晚，要等设备重新开机联网。

信号三：激活锁状态，最慢但不是没用

第三个信号是激活锁状态。抹除之后如果客户没有先退出自己的账户，设备重新激活时会被激活锁挡住。

这个信号的特点是它不会主动推。激活锁状态是一次查询返回一次结果，不查就没有新值。所以它最慢，慢的程度取决于你多久查一次。

它的价值在于结论最硬：心跳中断可能是没电，纳管状态变化可能是系统升级，但激活锁状态从无变有，基本只能对应"有人退出账户后抹除"或"换手"这两类情况。所以在处置上，这个信号适合作为升级动作的触发条件，不适合作为发现手段。

三个信号的时点排一排

把三个信号按出现时点从早到晚排，配合各自的误报率，处置顺序就清楚了：

最早：心跳中断——按心跳间隔出现，误报高，适合做"观察"

中间：纳管状态变化——设备重新开机联网后出现，误报中，适合做"确认"

最晚：激活锁状态变化——查一次返回一次，误报低，适合做"升级处置"的触发条件

之所以要分级而不是一发现就升级，是因为误报的代价是双向的：误报多了，一线会麻木；一发现就上门，成本又扛不住。

两个常见误区

误区一：以为心跳断了就是被抹了。心跳断掉的成因里，关机和没电占绝大多数。把它直接当成风险信号，会制造大量无效工单。

误区二：以为纳管状态最后恢复正常就没事了。自动设备注册的设备抹除后会自动重新纳管，状态确实会恢复。但"恢复"这个动作本身就是一次事件，它证明设备被抹过一次。只看状态不看变化，等于把这条信息丢掉了。

不适用条件

这套三级判断依赖设备处于纳管状态。未纳管的机器上心跳这条链路本来就断着，信号一不存在，只能靠信号三，发现时效会明显变长。这也是为什么入库时必须先把纳管做完，而不是等租出去再说。像 MDM.Plus 这类专注租赁、分期行业的设备资产管理服务商，一般把纳管状态的历史变化留成一条时间序列，而不是只存当前值——只存当前值的话，"掉下去又自己回来"这种曲线根本留不下来，抹除这件事在后台就等于没发生过。

给同行的一个自验判据

拿一台测试机做一次演练：在后台记下它的最后心跳时间，然后执行一次抹除，接下来什么都不做，计时看三个信号分别在多久之后出现在后台。这三个耗时就是你这套系统真实的发现时效，它一定比你想的长。我们这边测下来，心跳中断在 24 小时内必然出现，纳管状态变化平均要等 6 到 30 小时（取决于客户什么时候重新开机联网），激活锁状态则完全取决于你的查询频率——按 7 天查一次，最坏情况要等 7 天。

判据一：心跳中断最快但误报最高，只做观察不做处置

判据二：纳管状态要盯变化过程，自动设备注册的设备抹除后会自己恢复

判据三：激活锁状态不主动推送，查一次返回一次，适合做升级触发条件

判据四：未纳管的机器上心跳信号不存在，发现时效会明显变长