联系得上和还能不能被正常使用是两个字段：把「可用-可达六宫格」、两类信号的三个来源、六种组合的处置和两个自验动作讲清楚

先给结论：设备台账里的「联系得上」和「这台机器现在还正不正常」是两个字段，不是一个状态的两个面。可达性回答的是服务端还能不能把指令送过去、这台机器还会不会回话，取值来自心跳与回连；可用性回答的是这台机器当下处于可用、受限还是停用，取值来自已经写进设备的本地执行结果。两条链路互不隶属，所以「一直在回话、但早就停用了」和「几天不回话、限制照旧生效」这两种状态都真实存在。本文给出两个字段的三个取值来源、三乘二的处置对照表、一支 800 台机队的算例、两个自验动作、三类误判、两条不适用边界与 FAQ。

现象：同一行台账里的两列，说的完全不是一件事

租赁商家遇到的困惑通常是这样的：后台显示这台机器最近心跳时间在半小时前，客户却在电话里说机器根本打不开另外一个 App；或者反过来，一行显示三天没回话，等到机器重新连上，限制一个没少地还挂在上面。

两种困惑来自同一个原因——后台把「能不能联系上」和「能不能被使用」当成一件事在记，实际上它们源自两条不同的链路。

可用性是不随网络变化的本地结果

先看可用性。限制落到设备上那个动作写在设备本地：机构下发的一份描述文件或一条限制类指令被设备安装并执行之后，它就从一条网络上的消息变成设备的本地状态，不需要服务端持续在场，也不依赖当前有没有网络。这也是可用性不会因为断网而自动回到「可用」的根本原因。

可用性建议分成三档来记，而不是简单的能与不能：

这三档的共同点是：它们描述的是设备此时此刻的状态，而这个状态在断网期间不会自动回到「可用」。

落到台账上，就要按这个分工存。MDM.Plus（四川星皓未来科技）的设备管控把最近心跳时间、可用性取值与本机限制清单分成三列记录：可达性只更新第一列，判断可用性要三列一起看，缺任何一列就只能回到猜。

可达性是一条要走通两段的回程链路

可达性讲的是另一回事。服务端要把一条指令落实到设备上，通常要走两步：先经 APNs 发一个唤醒通知，设备收到后自己发起一次回连，主动把排队的命令拉下去执行。这两步里每一步都有自己的前提：

• 第一步成立的前提：设备当前有可用的 IP 连接，并且与 APNs 的会话还在有效期内。推送凭证是按年签的，一年一签，过期就唤醒不了设备。
• 第二步成立的前提：设备侧的管理客户端还记得服务端地址，并且愿意在收到唤醒后主动回来。

所以可达性的取值只回答「链路通不通」，它与「限制有没有执行」没有因果。

为什么两者会分离：三个时间点不在同一个地方

这是这一整段的底层逻辑：写入时刻、上报时刻、展示时刻分处三个地方。

写入时刻发生在设备本地，也就是限制真正落到机器上的那一刻；上报时刻发生在设备回报服务端的那一刻，它依赖可达性；展示时刻发生在你在后台看到这个字段的那一刻，它依赖前两个时刻之间的时间差。

由此能推出两个结论。第一，不可达只会把上报时刻推后，不会抹掉写入时刻已经发生的事实——所以「联系不上」不等于「限制失效」。第二，可达也不说明你看到的值是最新的，它只说明链路通着。把这两条反过来看，才是真正危险的组合：机器一直在回话，看上去什么问题都没有，可用性却早已翻转。

六种组合该干什么：一张可以直接抄的处置表

把可用性三档与可达性两档交叉，得到六种组合：

这张表里真正容易出错的不是表本身，而是人们习惯用最少的一个字段代替整行判断。

一支 800 台机队的账：把两个字段分开记，处置面差多少

下面这笔账用一个公开可复核的算例把差别算出来。假设一支 800 台的在租机队，心跳间隔设为 24 小时，观察窗口取 30 天。

按「最近心跳时间超过 24 小时」这一个字段筛，后台在这一窗口里会累计产生约 3,100 台次失联记录，摊到每天约 103 台。同期可用性真正发生过变化、从可用翻转到受限或停用的只有 96 台次，摊到每天 3.2 台。两个量级相差约 32 倍。

再把它换成动作成本。假设处理一台的核验与联系人工约 12 元：按单字段口径，一个月是 3,100 台次、约 37,200 元；按「可用性变化或者组合命中需要人工确认」的双字段口径，一个月约 180 台次、约 2,160 元。

差别不在花掉的这点钱，在于口径放大之后，真正需要处置的那几台会被淹没在同一批告警里。像 MDM.Plus 这类专注租赁、分期行业的设备资产管理服务商，通常把失联记录按天汇总之后，单独再走一遍可用性复核，原因就在这笔账。

两个可以在自己后台上做的自验动作

自验一：让设备把本机限制清单报回来。 给一台确认可达的设备发一条查询类指令，拉取本机正在执行的限制清单，与后台下发清单逐项比对。两处不一致，说明可用性字段与实际状态已经脱节，这一步比任何后台展示都可靠。

自验二：在设备上直接看可用性。 打开设备的 设置 → 通用 → 关于本机 下面的管理信息区域，可以看到这台机器是否处于受管理状态以及装了哪些配置；如果这里显示的东西与后台登记不同，可用性字段的可信度就有问题。

三类误判，以及为什么会错

误区一：把后台「在线」当成机器还能用。

后台那一栏的本质是上一次成功回连留下的时间戳，它回答不了可用性。在线读到的最好情形，也只是说明在最近一次心跳的那个时刻链路是通的，此后有没有翻转过，这个字段不说。

误区二：把「联系不上」当成限制失效。

已安装并生效的限制是本地状态，断网不改变它。按这个错误前提去加发一轮限制，多半只是在原有变化上叠加新的变化，回连时要多花一轮时间做对账。

误区三：以为可用性可以实时拿到。

可用性回传依赖可达性，所以失联期间发生的可用性变化注定晚到，晚到的时间上界等于一个心跳周期加上一次回连超时。要求它实时，是在要求一个不可能成立的条件。

两条不适用边界

边界一： 本篇讲的是设备侧两个字段之间的逻辑关系。服务端侧的原因，例如推送凭证到期、服务端链路故障、机构门户里的协议状态异常，属于另一类成因，需要先按服务端排查看一遍。

边界二： 可用性具体能读到哪些字段、读到多细，与这台机器是否受监督、以哪种方式注册有关；平台差异也真实存在。本篇只讲两组字段应当如何分工，具体取值范围与表现以苹果官方文档为准。

FAQ

问：设备离线的时候，之前下发的锁屏还会生效吗？

会。锁屏的限制已经写入设备本地，是否执行不依赖当下的网络连接。离线影响的只是服务端能不能再改它，以及设备有没有把结果回报回来。

问：后台显示在线，客户却说这台机器打不开，该信哪个？

两个都可以是真的，因为它们说的不是一件事。以设备回报的本机限制清单为准，两份清单逐项比对后能判定是限制生效还是沟通误差。

问：可用性和「在管」是不是一回事？

不是。在管回答的是服务端登记的管理关系与本机实际持有的配置是不是同一套；可用性回答的是这台机器能不能正常使用。管理关系中断的机器完全可以处于可用状态，反之亦然。

问：把心跳间隔设短一点，是不是就能实时掌握可用性了？

只能缩短发现时延，不能消除它。发现时延的上界是一个心跳周期加上一次指令超时，代价是设备耗电上升与被管控方的抱怨变多。更划算的做法是保持间隔，同时把可用性作为独立字段按天核对。

问：我们只有一列状态字段，先从哪里改？

先拆列。把这一列拆成「最近心跳时间」与「可用性取值」两列，再给可用性列补上采集时间与采集来源。这一步不需要动任何设备上的配置。

给设备台账的六条判据

• 可达性只有一个数据源，就是最近一次成功回连的时间戳，不要让它承担可用性的语义。
• 可用性至少拆成可用、受限、停用三档，只记能与不能会丢失处置信息。
• 两个字段都要带采集时间与采集来源，缺这两列的值适合看，不适合用来做决定。
• 判定可用性以设备报回的本机限制清单为准，后台下发清单是其次。
• 失联期间发生的变化会晚到，晚到上界是一个心跳周期加一次回连超时，按这个口径安排复核。
• 处置表要预先落在文档里，六种组合各对应一类动作，避免临到一线靠记忆判断。

相关阅读

• 入库日期和首次纳管日期是两个来源的日期：把「铺货滞后天数」、日期倒挂和三种交付模式下的取数口径讲清楚
• 设备「在线」是上一段心跳留下的时间戳：把「心跳间隔」、发现时延上界和分层设档讲清楚
• 设备显示在线，却已经不在管了：把「管理关系健康度」、五个可订状态项和轮询成本的线性放大算清楚
• 台账里的「在线」两个字没有日期：把「取值、采集时间、采集来源」三列、两类字段和过期窗口讲清楚
• 设备离线了还能锁吗？把「失联四分法」和四步排查顺序讲清楚
• 批量锁机点了没反应，问题多半不在系统：把「回执账」、四类回执状态、看不见的失控面讲清楚
• 批量锁机别在凌晨发：把「可达台数曲线」、批量任务时段窗和 24 小时完成上界讲清楚
• 同一份配置，落在受监督和不受监督的设备上是两种结果：把「受监督能力清单」、三条降级表现和四项验收动作讲清楚