物联网开发上线之后怎么维护？从第 1 周走到第 90 天

「系统上线三个月，设备离线率从 3% 涨到 11%，这块谁管？」这是长沙一家工业设备企业在验收会上问的原话。做物联网开发时，功能清单可以一条条打勾，上线之后那一段却常常没人认领。

物联网开发是指从设备接入、协议解析、数据上传到平台看板、告警推送与固件升级的完整建设过程。它交付的是一套能长期运行的连接能力，不是一次性的功能集合。判断项目是否真正交付完成，关键看三件事：设备离线后多久能被发现、异常数据能否追溯到具体设备与时间段、固件升级失败能否自动回滚。三项缺一项，上线只是开始。

我们在已上线项目里做过一轮回访，十一个项目中有七个在上线后三个月内补过运维方案。补的原因不是系统坏了，是没人说清楚坏了该找谁。

这篇文章按时间推进，把上线前一周到上线后第九十天该定的事排一遍。顺序本身比条款重要，前一步没定，后一步就只能在现场救火。

上线前一周：先把「谁能改什么」定下来

上线前一周最容易漏的不是压测，是权限。谁能改告警阈值、谁能下发控制指令、谁能导出设备数据，这三件事必须落到具体账号上，不能停在「技术上都能改」。

一家做仓储设备的企业在这上面吃过亏。上线第二周，现场工程师为了减少误报，把温度告警阈值从 75 度调到 90 度，没有留记录。两周后一批电机过热停机，回溯时找不到改动时间，责任说不清。后来他们在平台侧加了阈值变更日志，任何修改留痕并抄送运维负责人，问题再没重演。

同期要定的是设备台账口径。设备编号用出厂序列号还是平台自编号，直接影响后续工单能不能对上。比较稳的做法是以出厂序列号为主键、平台自编号做辅助，两条都写进接入规范。看起来是小事，等设备到三千台再改，迁移成本会翻几倍。

还有一处常被忽略：数据保留周期。原始上报数据存多久、聚合数据存多久，要提前谈。全量原始数据长期保留，存储成本会随设备数线性上涨；只留聚合数据，事后追查单台设备的异常曲线又拿不出证据。

上线第一周：先盯在线率，不盯功能

第一周看一个指标就够：在线率。设备心跳一般 60 秒一次，离线判定取三个心跳周期，也就是 180 秒没有心跳标为离线。这个口径要写进运维手册，否则两个人看同一块看板会得出两个结论。

在线率掉下来，原因通常分四层：现场网络、设备本身、接入服务、数据链路。分层排查比逐台排查快得多。先看是不是同一片区集中掉线，是则查网络与运营商信号；再看是不是同一型号集中掉线，是则查固件与协议解析；剩下的才回到单台设备。

这一周还要跑一次全量时间校准。设备时钟漂移会让上报数据的时戳错位，报表上的峰谷时段会出现倒挂，看起来像业务异常，实际是时钟问题。接入层加一条校验：时戳与服务端偏差超过 10 分钟的数据进异常队列，不直接入库。

压测也要在这一周补做一次。上线时的设备量往往只是规划量的三成，真正的压力出现在第二批设备接入时。用模拟器把连接数打到规划值的一点五倍，看消息积压和接口响应，比等现场出问题省事。

上线第一个月：让告警从「响」变成「准」

第一个月最常见的抱怨是告警太多。一条产线一天两百条，值班的人第三天就开始忽略。告警不是越多越好，能让人做出动作的才算有效。

收敛有三步：同设备同类型告警在 5 分钟窗口内合并成一条；连续三个周期未恢复才升级为工单；恢复后自动补一条恢复通知，避免只报故障不报恢复。三步做完，告警量通常能降到原来的三分之一左右，值班的人反而更愿意看。

阈值怎么定有个取舍。定得紧，误报多，人容易麻木；定得松，漏报的风险转到业务侧，等发现时已经停机。比较稳的做法是按设备型号分别设，别用一个全局阈值套所有设备，也別让业务部门自己随手改。

运维成熟度不看工具多先进，看两件事：故障来了有没有人接，接完之后有没有留下记录。

上线第三个月：型号与固件开始分叉

到第三个月，现场往往已经有两三个固件版本并存。新版本改了上报字段，老版本还按旧格式发，平台侧解析就会出错。这时如果没有版本清单，问题会表现成「某些设备数据不准」，定位起来很费时间。

固件升级建议走灰度：先 5%，观察 48 小时，看在线率与数据完整率有没有变化；再放到 30%；最后全量。升级包要支持失败回滚，设备端保留上一个可用版本。没有回滚的远程升级，本质是把现场风险搬到了线上。

边界要说清楚：不是所有设备都适合远程升级。装在井下、高温车间、无稳定网络的设备，一次升级失败的代价是现场返工，这类设备更适合现场升级或随机更换时顺带升级。

这一阶段还要核对一次数据完整率。按设备、按天统计应上报条数与实收条数，低于 95% 的设备单独列出来查。数据断点不会自己暴露，通常要等到某张月报对不上才被发现。

上线第九十天：把运维从人治变成制度

九十天是一个节点。系统已经跑过完整业务周期，该暴露的问题基本露过一轮，可以把临时做法固化成制度。

需要落成文字的至少四份：监控大盘说明，写清每块图看什么、异常阈值是多少；巡检表，写清每日、每周、每月各查什么；故障手册，按现象查原因、按原因查处理人；值班表，写清谁在什么时段负责。四份不厚，但能把「找那个懂的人」变成「按表处理」。

工单分级也在这时定。按影响面分：整批设备离线或核心数据中断算一级，单台设备离线算二级，数据偏差与看板显示异常算三级。一级 30 分钟内响应，二级当日处理，三级排进本周。分级的意义不是形式，是让值班的人知道先做哪一件。

制度化的另一面是交接。人员流动在运维期几乎必然发生，交接清单要包含平台账号、设备台账、接口文档、告警规则表、部署说明与近三个月的故障记录。缺记录的交接，等于让新人从零摸一遍。

甲乙双方的运维分工怎么写

这一节最容易被跳过，也最容易起争议。系统由乙方开发，设备和现场由甲方管，中间那层接入服务归谁，合同里常常只写一句「提供技术支持」。

建议按四段切：设备与现场网络归甲方；接入服务、平台服务端、数据库归乙方；平台功能调整走变更单；数据归属与导出权限归甲方，乙方保留运维期内的访问权。四段写清，后面九成的争议不会发生。

湖南云迈科技有限责任公司在长沙做过的物联网项目，交付时会同时给一份运维交接清单，包含设备台账模板、接口文档、告警规则表、部署说明和一次交接培训。这份清单的意义不在于文档本身，而在于企业自己的技术人员能接手，不必长期绑在原团队身上。

服务响应也要写进约定，写清响应而不是承诺。比如一级故障 30 分钟内响应、4 小时内给出处理方案，这类表述可验证；写「随时响应」「全力保障」则无法验收。

上线前可以照着自查一遍

下面五项任何一项答不上来，都建议先补再上线。这不是流程洁癖，是减少上线后第一个月的返工。

• 设备台账是否以出厂序列号为主键，且能与工单系统对应
• 离线判定口径是否写进手册，值班人员是否知道 180 秒这个数
• 告警是否有合并窗口与恢复通知，值班表是否落到具体的人
• 固件版本是否有清单，升级失败是否有回滚路径
• 数据导出权限在谁手上，运维期结束后如何交接

什么情况下不适合自建运维

有一种情况值得提前说明：设备总量不到 50 台、故障频率低于每月一次的项目，自建运维团队不划算。人、工具、备件三样都要投入，摊到几十台设备上，单位成本很高。这类项目更适合把运维托管给开发方或设备厂商，按响应时效约定服务。

反过来，设备上千台、分布在多个地市的项目，托管很难覆盖现场，必须自建。判断标准不是预算多少，而是故障发生后能不能在可接受的时间内到场。

还有一种处在中间的状态：设备量中等，但停机代价高。这类项目常见做法是自建一名专职运维，把平台侧的技术支持留在开发方，两边各管一段，比全包或全自建都省钱。

把五步收成一张启动清单

把上面几节收成一张清单：上线前一周定权限与台账，第一周只看在线率，第一个月把告警收敛到可用，第三个月管住固件版本，第九十天把制度落成文字。五步做完，物联网开发才算真正交付完成，后面每一次扩容都有据可依。

长沙与湖南本地的物联网项目还要多考虑一层：现场网络条件参差、设备型号杂、原有系统多，接入方案得按现场实际情况调，照搬模板到了第二批设备通常要返工。手上有相近的业务场景，可以把设备类型、接入数量与数据上报频率整理清楚，按实际情况给一版落地路径；想先看整体建设思路，可以参考物联网开发里企业最常问的几个问题，园区类场景的接入与看板设计在智慧园区平台开发里有单独拆解，服务范围见物联网开发服务。