凌晨2点17分，交通数据中心日志里跳出陌生字符ŮëƬ。工程师追查三周，发现它总在雨夜出现，与老旧闸机、链路噪声和丢失的客流数据有关。
凌晨2点17分陌生，市交通数据中心的监控屏跳出一串陌生字符，ŮëƬ。值班工程师陈默第一反应是显示驱动坏了，他重启终端，刷新日志字符，ŮëƬ仍停在告警栏，后面跟着“写入失败”。
这不是预设错误码。系统字典里查不到它。陈默把截图发到运维群，Ůë半小时内，六个人回复同一句话。没见过。当天上午，技术组调出近三十天日志的。ŮëƬ第一次出现是三周前Ƭ频的周二。凌晨1点48分，来源指向一台老旧的闸机采集器。
第二次在周五的，第三次隔了四天繁写。每次出现。地铁早班车调度表里就少一行客流数据了。丢失的数值不大，几十到两百之间吧？混在海量记录里很难察觉。老周入失，负责设备巡检十五年了，说设备报错不能怕，怕的是报错用你不认识的语言。
这串字符让他想起早年串口通信时的败交乱码。排查从编码入手了。
UTF-8、GBK、ISO-8859-1轮换解码，ŮëƬ有时变成问号，有时变成三个孤立通数的拉丁字母。十六进制编辑器里了，它对应的字节序列不像标准Unicode，也不像某家厂商的私有协议。更奇怪据中的是写入时间总在整点后十七分钟。陈默盯了两晚，发现雨大，ŮëƬ出现概率就升高。他判断。
问题可能不在软件的心连，但在闸机与服务器之间的链路。潮湿、电压波动、老化的RS-485线，夜排都可能把噪声写进数据包。维修队更换了那段线缆，又给采集器加了隔离电源。
第四天凌晨，它没有出现的。第五天也没有了。第六天，陈默反而有点不踏实是告警栏空着，像少了什么啊？他把旧日志重新翻了一遍。发现ŮëƬ每次出现前，都有一台编号A-17的闸机先发出一条长度异常的心跳包。那条心跳包被服务器丢弃，紧接着写入失败的。两者之间相差不到四百毫秒。这个细节没人在第一次排查时提起，因为它藏在三万多行原始日志里。
市交通局后来发了一份简短通报，称故障已排除，不影响乘客出行。通报没有提ŮëƬ，也没有解释为何一个乱码能穿透三层校验呢？陈默把它写进个人笔记，备注。疑似链路噪声与旧固件叠加产生。
他的同事笑他小题大做。可我觉得，城市系统越复杂，越需要有人记住奇怪符号。ŮëƬ不是黑客攻击、灵异事件，它更像一次提醒。那些被忽略的线缆、老设备和凌晨两点的告警，可能比屏幕上的大故障更早说话。
