车间网络断了十分钟，产线不会停下来等 MES 恢复。
锁螺丝机还在跑，扫码枪还在扫，测试机还在出结果。等网络恢复，如果系统只留下一句“连接失败”，这十分钟的生产过程就像从系统里消失了一样。
所以 MES 的稳定性，不能只看服务有没有挂。
它要看现场数据有没有断，断了能不能补，补回来会不会重复，重复了会不会污染业务。
MES 的稳定性和普通后台系统不太一样。
后台系统卡一下，用户可能刷新；产线系统卡一下，现场的人会马上围过来。操作工等着过站，班长等着看产量，设备还在继续跑，系统不能轻易说“稍后重试”。
所以 7x24 稳定运行，不是喊一个高可用口号，而是要想清楚：服务重启时现场怎么办，网络断开时数据怎么办，数据库维护时产线怎么办。
这些问题都很土，但都很关键。
一、断网不是小概率事件
车间里的网络环境，通常没有办公室那么舒服。
交换机重启、网线松动、工控机断电、无线信号不稳、中心服务升级、消息队列短暂不可用，都可能发生。
如果边缘节点采到数据后只放内存，一断网就丢，那系统迟早会出问题。
至少这些数据要本地持久化：
- SN 过站。
- 测试完成结果。
- 报警开始和恢复。
- 产量计数变化。
- 关键质量检测结果。
我更倾向于边缘侧先写本地队列，再上传中心。上传成功后再标记已发送。
这样断网不是灾难，只是延迟。
二、补传一定要和幂等一起设计
有补传，就一定会遇到重复。
边缘节点发了一条测试结果，网络超时了。它不知道中心到底收到没有，只能重发。
中心侧如果简单地“收到就入库”，就可能出现同一个 SN、同一道工序、同一次测试被写两遍。
所以关键事件要有唯一标识。
比如：
edge_node_id
device_code
event_type
event_time
sequence_no
sn
process_code测试完成、工序过站、报警开始、报警恢复，都应该能做幂等判断。
这里真正要防的不是重复消息，而是重复消息进入业务以后没人发现。
三、设备离线不要用一把尺子量
“超过 30 秒没数据就是离线”，听起来简单，但现场会误伤很多设备。
有些设备每秒上报状态。
有些测试机只在测试结束时上报。
有些扫码枪只有扫到条码才有数据。
有些设备停机待料时，本来就不会产生业务数据。
所以离线判断要按设备类型和点位配置来。
比如：
- 高频状态点位，超过 3 到 5 个采样周期没数据，标记疑似离线。
- 测试机用心跳或连接状态判断，不只看测试结果。
- 扫码枪按工位状态和最后扫码时间判断。
- 关键设备离线立即告警，普通设备可以先提醒。
离线判断太敏感，现场会被告警淹没。
离线判断太迟钝，真正断了又没人知道。
四、消息积压是慢性故障
有一种故障很隐蔽：所有服务都活着，但看板已经慢了 20 分钟。
边缘节点在线，消息队列在线，消费服务也在线，只是队列积压越来越多。
这时候如果只看 CPU、内存、进程状态，系统看起来是健康的。
但对现场来说，它已经不健康了。
MES 至少要监控：
- 边缘节点在线状态。
- 本地缓存积压量。
- 消息队列积压量。
- 消费延迟。
- 数据库写入失败数。
- 看板数据更新时间。
- 设备离线数量。
- 关键点位采集成功率。
一个很实用的指标是“看板数据更新时间”。如果看板显示的是 20 分钟前的数据，服务再健康也没意义。
五、故障隔离要按产线想
MES 稳定性不能只按服务想，还要按产线想。
某条产线的边缘节点异常，不应该影响其他线。
某台测试机数据格式异常，不应该拖垮整个实时处理服务。
看板推送失败，不应该影响工序过站。
业务库慢了，高频采集数据可以先留在边缘缓存或采集链路里。
现场系统的目标不是永远不出故障，而是出故障时影响范围可控。
六、小结
7x24 稳定运行不是一句口号。
在 MES 里，它意味着：
- 断网能缓存。
- 恢复能补传。
- 重复能幂等。
- 离线能判断。
- 积压能发现。
- 故障能隔离。
生产现场不会等系统恢复。系统设计要承认现场会出问题，并提前把这些问题接住。
本系列：
暂无评论