定义
ITSM（IT Service Management，IT 服务管理）是企业 IT 运维管理体系。设备管理平台的告警可对接 ITSM 系统，告警自动创建 Work Order（工单），实现告警→工单→处置→审计的运维闭环。
核心流程
ITSM 基于 ITIL 等最佳实践，涵盖事件管理、问题管理、变更管理、发布管理等流程。设备管理平台通过 Webhook 或 API 将告警推送至 ITSM，自动创建事件单或工单，关联设备信息、告警内容、严重等级；运维人员处置后更新工单状态，实现可追溯的运维闭环。
与 DMP 的集成
集成方式包括：告警触发工单创建、工单与设备/告警关联、工单状态回写、SLA 服务等级协议监控。平台可配置告警级别与工单类型的映射规则，支持与 ServiceNow、Zendesk、Jira Service Management 等主流 ITSM 工具对接。
价值与场景
实现设备告警与运维流程的统一管理，避免告警遗漏、处置无记录；支持 MTTR 平均修复时间、工单响应率等 KPI 统计；满足合规审计对运维流程可追溯的要求。适用于运营商、能源、制造等拥有大规模设备与成熟运维体系的企业。
告警事实和服务单如何衔接
IT 服务管理关心的是服务是否按约定被响应和恢复，设备平台关心的是哪台设备发生了什么。两者衔接时，告警或事件是输入，服务单是处置载体，不能把每一条报文都直接叫成一张新单。事件管理处理的是“现在要有人看”的中断，问题管理处理的是反复出现、需要找出原因的缺陷，变更管理处理的是有计划的升级和配置修改。一张单应能回到触发它的设备、时间和告警标识，关闭时要写明是恢复、误报还是被并入其他单。平台上的告警状态和服务单状态是两套生命周期：告警可以先复归，单仍在等待复盘；单也可以在告警尚未复归时被升级转派。自动开单只是创建动作，优先级、处理组和时限要来自事先写好的映射，而不是临时从告警标题里猜。事件流保留发生事实，服务单保留人如何处理，两边都要留。
自动开单之前要具备的映射
适合自动开单的告警，应当已经过去重、有稳定的告警标识，并且能对应到服务目录里的某一类事项。设备主数据要能翻译成服务系统认识的配置项或资产，组织、场地和处理组不能靠名称模糊匹配。同一告警在抖动期间应并入已有单或更新次数，而不是每抖动一次新建一张。低级别、预期内的状态切换，例如维护窗口内的离线，应被排除在自动开单之外。回写同样是条件的一部分：单被接单、挂起、解决时，平台上要能看到，否则值班人员会在两个界面里各处理一遍。需要变更审批的升级，不应伪装成普通事件单自动执行。故障诊断给出的可能原因可以写进单的描述，但不能在开单的同时自动执行有风险的维修动作。
级别映射和状态各写各的
告警级别和服务优先级若没有对照表，全部被开成同一优先级，时限就失去作用；对照表过粗，又会把提示性信息开成紧急单，处理队列被淹没。去重键只用了设备编号、没用告警码，不同故障被并进一张单，关闭时无法说明到底恢复了哪一件。只用告警码、不用设备，一批设备的同一故障合成一张无法派工的单。服务单解决了但告警仍在触发，回写被当成“已恢复”，平台停止提醒，现场并未恢复。告警已复归、单却因为缺少回写一直开着，统计出来的处置时长被无限拉长。测试组织的告警写进生产服务系统，打乱值班队列。变更单和事件单共用一个自动规则，计划内升级也被当成故障开出紧急单。服务单上的设备标识应使用对照后的主键，不能只把告警原文贴进描述，否则状态回写时找不到平台上的那一条。