结论先行：端点失联的危险在于"看起来正常"——管理端还保留着最后一次上报的状态，策略条目也还在，但实际上这台主机已经不再执行任何访问控制。可行的检测方式是同时看三类信号：心跳超时、策略下发回执缺失、访问日志断流；任一类异常先告警，两类同时异常判定为失联。阈值按资产重要程度分档，核心业务域的心跳超时窗口设得比普通域更短，并配套失联期间的临时处置动作。
失联为什么比"采集缺失"更危险
网络设备的采集失败，影响的是分析结论不准确；微隔离的执行端点失联，影响的是防护本身失效。差别在于：采集类平台的输出错了，人还能靠经验兜底；执行端点的策略不再运行，管理端的策略列表、拓扑图、合规报告依旧显示原状，没有任何一处会主动提示"这段防护现在是空的"。
更麻烦的是失联往往不是孤立的。一次批量升级、一次网络割接、一次主机镜像重建，都可能让一批端点同时掉线。如果只看总数变化，很容易被"今天纳管数还涨了几十台"这样的表面数据掩盖。
三类离线信号
| 信号 | 来源 | 能发现什么 | 盲区 |
|---|---|---|---|
| 心跳超时 | 端点向管理中心的周期性上报 | 主机宕机、进程被停、网络中断 | 进程在但策略未生效时不会触发 |
| 策略下发回执缺失 | 管理中心下发策略后的确认 | 端点无法接收新策略 | 不下发策略的时段收不到信号 |
| 访问日志断流 | 端点上报的连接与阻断日志 | 进程假死、日志通道异常 | 本就无业务的静默主机不适用 |
单一信号都有盲区，三类一起看才能覆盖"主机没了""进程停了""进程在但不干活"三种状态。
阈值怎么定
| 资产分档 | 心跳超时窗口 | 告警级别 | 响应要求 |
|---|---|---|---|
| 核心交易域 | 连续 3 个周期无上报 | 高 | 立即核对，必要时临时收紧上游访问 |
| 一般业务域 | 连续 5 个周期无上报 | 中 | 当班内处理并记录原因 |
| 测试与预发环境 | 连续 10 个周期无上报 | 低 | 纳入周度清单统一处理 |
窗口设得太短会被正常重启、补丁安装的短暂中断淹没，告警一旦失去可信度，后面再响就没人看了。设得太长又失去意义。比较稳妥的做法是先按上表起一个初值，跑两周统计误报量，再逐档微调。
对于长期静默的主机（如冷备、归档库），建议单独标记，走"预期离线"清单管理，并定期复核清单本身是否还成立。
失联期间怎么办
- 先确认范围。是单台还是一批，同机房、同业务域还是随机分布。成批失联优先怀疑升级、割接、网络变更。
- 评估暴露面。失联主机当前对外开放的端口、它所在的业务域、以及从低信任域到它的可达路径，这三项决定处置优先级。
- 临时补偿。在补偿措施可用时，用边界侧的访问控制临时兜住失联主机的高风险端口，避免防护出现真空。
- 同步业务方。失联期间该主机的访问不受控，涉及敏感数据的要告知业务负责人，不要等恢复后再说。
- 记录时间线。失联起止时间、影响主机清单、补偿动作、恢复验证结果，一并留档，审计时会用到。
恢复后要核对的四件事
- 策略是否真正重新生效，而不是只恢复了心跳上报——用一条已知访问做一次阻断验证。
- 失联期间是否有策略变更下发过，这批变更需要补发。
- 业务标签与工作组归属是否仍然正确，重建镜像常常丢标签。
- 该主机在失联窗口内的访问日志缺口，是否需要在合规报告里说明。
落地清单
- 把三类信号都接进告警规则，不要只依赖心跳。
- 按资产分档设阈值，并对误报量做两周观察后再固化。
- 建立"预期离线"清单并定期复核，避免长期静默主机稀释告警可信度。
- 失联处置写成操作卡片，明确谁在多久内做什么。
- 恢复验证纳入变更留痕，作为合规审计材料。
奇摩在为金融与能源客户做微隔离运营时，通常把端点在线率作为一级运营指标，与暴露面治理并列查看。若您希望梳理现网的端点健康度检测机制，欢迎了解自适应微隔离方案或预约咨询。