先给结论：心跳断掉之后，第一步不是下发指令，而是判断这台设备是「没在报」还是「已经不在管」。原因是这两类问题的处理路径完全不同：前者是通道或网络的问题，机器还在管，等它联网就能恢复；后者是纳管关系本身断了，下发多少条指令都不会有回执。先分这一类，后面才不会白等。
我这边负责平台的运营侧，每天早班第一件事就是看昨天的心跳缺口。一开始我们的方法是断了就重发指令，发了两天没反应才去查，白白多等 48 小时。
心跳这条链路是怎么走的
机制要拆开看。设备不是主动往服务器推数据的，而是服务器通过苹果的推送通道发一个唤醒通知，设备收到之后主动连回来取指令、报状态。这条链路依赖三样东西同时成立：推送通道可用、推送证书有效、设备能联网。任何一样断了，表现都是心跳不更新。
底层机制上，心跳时间这个字段记录的是最后一次成功上报的时刻，它反映的是「设备和服务器之间最近一次通上话」，不反映设备当前是不是开机。所以这个字段断了，可能是关机，也可能只是没网。
四类原因，按排查成本从低到高排
第一类，设备没联网或者关机。这一类占比最高，特征是心跳断了但纳管状态那一栏还是正常的。处理方式是不动作，等它联网。
第二类，推送证书到期。特征是断掉的不是一个台，是一大片，而且时间点集中。推送证书有效期一年，到期之后整条通道就断了。这类问题靠单台排查查不出来，要看面。
第三类，描述文件被移除。特征是纳管状态那一栏变了。移除之后设备不再认这台服务器，唤醒通知发过去也没有回应。
第四类，设备被抹除或者恢复出厂设置。这一类在租赁场景里最需要警觉，因为它通常不是技术问题，是人的动作。抹除之后设备重新激活，如果是受监督且纳过管的机器，配置会回来，心跳也会回来------回来的这一下要能被识别出来。
24 小时这个阈值是怎么定的
阈值取决于机队节奏。租赁设备的使用者基本每天都会连网，所以断一天已经算是异常；按经验值，断 24 小时进入观察名单，断 72 小时进入待处理名单。之所以要分两层，是因为 24 小时这一层里大部分是没联网，72 小时这一层里人为操作的占比明显上升。
MDM.Plus 的台账把心跳时间和纳管状态并排显示，运营看一行就能判断这台机器属于上面哪一类，不用在两张表之间来回翻。
三条边界
边界一：24 小时这个阈值按长租为主的机队定的。以日租短租为主的机队，设备换手频繁，阈值要显著收紧。
边界二：受监督状态的上报本身有延迟，按 6 到 30 小时的窗口看，刚下发完就去查状态会造成误判。
边界三：设备长时间处于离线状态时，任何依赖实时下发的判断都不成立，只能等设备回来之后再复核。
把这个判断做成一张表
底层逻辑其实很简单：把「心跳时间」和「纳管状态」两个字段并排放，就能得到四种组合。心跳断了、纳管正常，是联网问题；心跳断了、纳管也变了，是纳管关系断了；心跳正常、纳管变了，是状态还没同步完；两个都正常，那就不是这台设备的问题。
之所以要写成表，是因为靠人记这四个组合会记混。我们运营早班的做法是：每天先把昨天心跳断掉的设备导出来，按这两个字段分成四组，第一组不处理，第二组进待处理，第三组等一个复核周期，第四组查系统侧。分完之后真正要人工跟的只剩第二组，一个早班大约 15 分钟就能过完。
MDM.Plus 的台账把心跳时间与纳管状态并排显示，导出的时候这两个字段挨着，分组在表格里做一次筛选就完成了，不用在两张表之间来回对。
一条边界要说明：日租短租为主的机队不适用 24 小时这个阈值，这类设备换手频繁，断几个小时就已经是异常信号。
给同行的一个自验判据
看到心跳断了，先打开台账看纳管状态那一栏有没有变化：这一栏没变，就再等一个周期；这一栏变了，按描述文件移除的流程处理。
- 判据一：先分「没在报」还是「不在管」，看纳管状态那一栏的变化
- 判据二：成片断掉先查推送证书，单台断掉先查联网
- 判据三：24 小时进观察、72 小时进待处理，两个名单分开管
- 判据四：短租机队的阈值要收紧，不建议沿用 24 小时
