定义
Work Order（工单）将告警、故障转化为可跟踪的运维任务，支持派单、处理、闭环。可与 ITSM、Event Stream 集成，记录 MTTR 等运维指标。
工单生命周期
工单通常经历创建、派单、处理、验证、关闭等阶段。设备管理平台可从 Event Stream 告警事件自动创建工单，或由运维人员手动创建；派单支持按区域、技能、负载等策略分配；处理过程中可关联设备信息、遥测历史、Remote Diagnosis 远程诊断结果；验证通过后关闭，并记录实际处理时长用于 MTTR 统计。与 ITSM 集成时，工单可同步至服务台，实现统一运维流程。
与 DMP 的集成
设备管理平台作为工单的数据源与执行上下文，提供设备在线状态、健康评分、历史告警、OTA 记录等上下文信息。工单可关联具体设备或设备组，支持从设备详情页一键创建工单；处理人可在工单内直接发起远程控制、日志采集、固件升级等操作。平台通过 OpenAPI 与 ITSM、EAM、CMMS 等系统对接，实现告警到工单的自动流转及运维数据的双向同步。
应用场景
工单适用于能源、制造、交通、市政等拥有大量物联网设备的行业。故障告警自动转工单可缩短响应时间；预防性维护、巡检任务可通过计划工单管理；批量设备升级、迁移等操作也可通过工单跟踪执行进度。工单数据支撑运维 KPI 分析、人员绩效评估及持续改进，是设备运维闭环管理的关键环节。
工单是可派发的处置记录
工单把一次需要人负责的处置从告警流里拆出来。它有创建来源、责任人、涉及的设备、处理步骤和关闭结果。告警可以自动消失，工单不会因为告警恢复就失去过程记录。修复时长只在关闭时计算，并且要写明从哪个时刻算到哪个时刻：从开单到关闭，还是从接单到关闭。不写明的话，两个团队的时长不能比较。未关闭的单只有已等待时长，不能提前写成修复完成。
派发应基于当时的责任范围和人员是否在班，而不是把所有单都丢进一个公共队列让人自取。自取会造成同一张单被两人同时处理，或没人处理。每一步状态变化都留下操作者。和外部服务台同步时，以约定的一侧为主状态，另一侧保存对方单号，避免两边都能关闭、后又互相打开。需要规则自动开单时，由规则引擎提交“请求开单”事件，工单模块再决定是新建还是并入，规则本身不直接改关闭状态。
自动开单要有抑制和合并条件
自动开单可用的条件是：同一设备、同一故障类别在已有未关闭工单时不再新建，而是在原单上追加次数和最后发生时间。没有合并键，抖动告警会在几分钟内打开几十张单，责任人只能批量关闭，真正的新问题混在里面。抑制还应识别计划内维护：维护窗口内的预期离线不产生故障单，或产生的单标记为已知影响，不进入响应计时。
合并不能跨设备无限制地进行。一个站点大面积断连，可能需要一张站点级的单来协调，同时保留每台设备的附件，而不是生成一万张完全相同的单，也不是只留一张却丢失设备清单。开单时复制的上下文应是标识、位置、最近相关状态和告警编号，而不是把全部历史曲线贴进描述字段。权限上，处理人必须本来就能访问这些设备，不能借工单看到范围外的数据。派单规则引用角色与范围的判定，而不是在工单模块里另写一套互相矛盾的名单。
告警恢复却不关闭对应工单
告警恢复只说明监测值回到了阈值以内，不说明原因已经处理。自动把工单关掉，会让重启后暂时正常的设备被记成已修复，间歇故障永远没有责任人。恢复事件应写进工单时间线，由人确认后关闭，或由明确的规则在恢复持续满一个观察期且没有其他动作时关闭。观察期未满就关闭，时长会被算短。
相反的错误是恢复之后单仍留在待处理，且没有人区分“仍需处置”和“只是忘了关”。队列因此越来越长，新的紧急单被挤到后面。列表应能按是否已经恢复、是否已有责任人筛选。重复打开同一问题时应重开原单或建立关联，而不是再开一张没有历史的新单，否则同一故障的时长被切成几段，每段都看起来很短。关闭原因要区分已修复、重复、误报和不处理。把所有关闭都算成已修复，会让误报也进入质量统计。没有填写原因的关闭应被拒绝，至少保留一个必选的结果类别。
关闭单之前核对时间线里是否还有未完成的远程动作。有未确认的升级或控制时，不允许把结果选成已修复。等待配件和等待窗口应使用单独的挂起状态，挂起期间是否计入响应时限要按协议事先约定，不能由关闭人在备注里自行决定。重开必须回到明确的处理状态并通知当前责任人，避免单在系统里被打开却没有人收到。