多数 RFID 项目在立项时被当成「安装工程」，交付后却被当成「运维系统」来评判。验收报告只能证明集成商离开那天硬件是好的；而十八个月后还有没有人相信这套系统，取决于另一件事：一根退化的月台天线、一段开始积压的中间件队列、一个慢慢漂移的账实差，能否在几分钟内被发现，而不是等到季度审计。
监控不是最后加装的一块看板，而是把一次性部署变成有可测服务水平的资产的机制；它决定了系统是悄悄衰减，还是在用户察觉之前就被修好。
监控从上线第二天开始
项目计划通常止于验收，而运营计划应当从验收那天开始：有明确的负责人，有写清楚的服务水平。
- 每一台读写器、每一支天线、每一个交换机端口和每一个中间件节点都要有人负责，哪怕是「角色」而不是具体的人。
- 在第一次故障之前，而不是故障当中，用数字定义什么叫「健康」。
- 对外公布业务能拿来考核你的服务水平：读取率、时延、账实差异率。
- 资本预算和运营预算同时做，并把备件算进去。备件是把两天停机变成两小时停机的东西。
- 把验收时测得的基线存档。没有基线，之后任何衰减都无法被证明。
三层监控，对应三类故障
只盯硬件的 RFID 监控注定失败。真正伤人的故障分布在三层，每层都需要自己的探针。
- 设备层：读写器连通性、天线状态、发射功率与反射功率、温度，以及设备上运行的那些读取规格的执行成功率。
- 中间件层：原始事件吞吐、去重后吞吐、派发时延与队列深度。
- 业务层：关键流程的读取率、与 ERP 的账实差异、以及从标签到记录的全链路时延。
- 设备故障看得见、叫得响；中间件故障很安静；业务故障则一直沉默，直到有人信了一个错数字。
- 一台在线且正在发射、但读取率已跌到 70% 的读写器，属于业务层故障，设备监控永远抓不到。
值得设告警的八个指标
一张真的会被人执行的短清单，胜过一面墙的图表。下面八个覆盖了生产环境里的大多数问题。
- 读取率：低于 99% 预警，低于 95% 值班呼叫。按通道、按流程分别测，绝不要用全站平均。
- 读写器重连次数：每天超过 2 次预警，超过 5 次呼叫。频繁重连通常指向线缆、PoE 供电余量或固件。
- 原始事件吞吐：低于七日平均 30% 预警，50% 呼叫。这是天线坏掉最早出现的信号。
- 队列积压：超过 1,000 条预警，超过 10,000 条呼叫。积压是数据丢失的先行指标。
- 全链路时延：超过 2 秒预警，超过 5 秒呼叫。时延在月台最要命，因为操作员正在那儿等。
- 账实差异率：超过 0.1% 预警，超过 0.5% 呼叫。这是财务一定会问的那个数。
- 读写器温度：超过 60°C 预警，超过 70°C 呼叫。在不通风的后仓里，高温是固定式读写器的慢性杀手。
- 循环盘点时的标签盘点准确率：低于 99.5% 预警，低于 99% 呼叫。低于这个线，盘点结果只能当传闻。
阈值要分级，并且绑定响应时间：预警四小时内处理，呼叫三十分钟内响应，并自动升级到值班工程师。没人响应的阈值比没有阈值更糟，因为它训练团队忽略看板。
设备层：读写器、天线与 LLRP
设备层最容易上监控，也最容易被过度监控。把注意力放在「故障之前」的那些信号上。
- 跟踪每台读写器的 LLRP 连接状态，而不只是 IP 能不能 ping 通。
- 分别监控每支天线的发射功率与反射功率。反射系数上升，通常意味着进水或线缆受损。
- 记录每一条读取规格的执行结果。一条不再被重新装载的规格，就是一次无声的停机。
- 盯住读写器时钟。时钟漂移会产生时间戳错误的事件，而这些事件会在下游被直接拒绝。
- 把固件版本纳入资产台账。同一站点内固件混杂，是间歇性、无法解释行为最常见的成因。
中间件层：事件管道
好读数变成坏记录，就发生在中间件，所以它值得有自己的指标。
- 同时统计去重前每秒事件数与去重后每秒事件数。两者的比值能告诉你过滤器还在工作，还是标签数量已经爆炸。
- 跟踪向 ERP 的派发时延，并把重试算进去。重试风暴看起来像吞吐，直到队列被填满。
- 给死信队列上监控。每一条被拒绝的事件都应能连同载荷与原因被检视。
- 连接器的健康状态要单独监控。读写器可以完美无缺，而连接器已经被限流。
- 对配置漂移告警。在事故处理中被手工改过的中间件节点，就是下一次停机。
业务层：读取率与账实差异
这是业务真正在意的一层，也是最常缺席的一层。
- 按流程定义读取率：收货、上架、拣选、发货、循环盘点。一个全站数字会掩盖掉坏掉的那条流程。
- 从 ERP 侧计算，而不是用读写器自己的计数。读写器只数它听到的，ERP 知道本应有多少。
- 每天测账实差异，每周看趋势。缓慢变大的差异是设计问题；突然跳起来的差异是事故。
- 跟踪从物理读取到操作员看到记录的全链路时延。
- 每月用业务语言出一份简报：漏了什么、代价多少、因此改了什么。
日志、trace ID 与三十分钟定位
日志是最后一道防线，而它的价值几乎完全取决于能不能把不同系统的日志拼在一起。
- 统一一种结构化格式、统一 UTC 时间戳、统一一个贯穿所有系统的 trace 标识。
- 采集四类日志：读写器、中间件、ERP 集成、业务结果。
- 热存至少九十天，冷存一年。很多事故的解释，藏在三周前的一条事件里。
- 让 trace 标识显示在操作员界面上，用户报故障时可以直接把这个编号交出来。
- 演练定位。一个从没做过故障演练的团队，会花几个小时去找本来几分钟就能找到的东西。
运维节奏与「无人值守」之路
运维是一个闭环，不是一张工单台。节奏才是把事故变成改进的东西。
- 每周：复盘上周的告警与事故，把根因归到硬件、软件、环境、人四类，并确定改进项。
- 每月：对最高频的三类故障做深度分析，在设计层面关闭它们，而不是在工单层面关闭。
- 每季：评估硬件健康状况、平均无故障时间与更换预算，并评估中间件版本升级。
- 把两个结果指标作为出口：平均无故障时间与平均修复时间。成熟站点分别达到三十天与三十分钟。
- 经过六到十二个月有纪律的运维，所需人力通常能降到不足一个全职岗位的一小部分，系统接近无人值守——前提是这个闭环真的在转。
被监控的 RFID 系统，不是从不故障的系统，而是故障得看得见、故障得短暂、且不会让业务措手不及的系统。
