3. 工单数据模型设计
跨系统异常工单自动流转的核心难点，不在于“能不能把消息发出去”，而在于不同系统对同一张工单的理解是否一致。监控系统关心告警指纹，ITSM 关心工单号与 SLA，发布系统关心变更单与批次，通知渠道只关心接收人和内容。如果每个系统各自维护一套字段，流转过程中就会出现“工单到了但字段对不上”“状态回写覆盖了人工处理结果”“同一异常重复建单”等问题。因此，本节要解决的是：设计一份可被多系统共同引用的统一工单数据模型，并明确字段映射、优先级、状态机与跨系统标识的落地方式。
一、统一工单结构：以“工单主对象 + 扩展段”组织
统一工单结构建议采用“主对象 + 扩展段”的方式。主对象只保留跨系统流转必须共享的字段，扩展段承载各系统私有信息，避免主结构被单一系统的字段污染。一个可落地的统一工单结构如下：
{
"ticket_id": "INC-20250612-000871", // 平台统一工单号
"biz_key": "order-service:prod:cn-east:CPUHigh", // 跨系统业务标识
"source_system": "prometheus",
"source_ref": "alert-9f3c2a71", // 源系统内唯一引用
"title": "订单服务生产集群 CPU 持续高于 90%",
"severity": "P2",
"priority": "P2",
"status": "PROCESSING",
"assignee": "zhangsan",
"created_at": "2025-06-12T10:21:03+08:00",
"updated_at": "2025-06-12T10:36:41+08:00",
"sla_deadline": "2025-06-12T12:21:03+08:00",
"ext": {
"cmdb_ci": "order-service-prod",
"change_id": "CHG-20250612-0042",
"notify_channel": "oncall-order"
}
}其中 ticket_id 是平台内部主键，biz_key 是跨系统识别同一业务异常的稳定键，source_ref 用于回溯源系统原始记录，ext 为扩展段。主对象字段一旦确定，各系统只能读取或按规则写入，不能随意新增同义字段。
二、字段映射：建立“源字段 → 统一字段”的映射表
字段映射不是简单改名，而是语义对齐。以 Prometheus 告警、Zabbix 告警、Jira 工单三类源为例，映射关系可设计为：
| 统一字段 | Prometheus | Zabbix | Jira |
|---|---|---|---|
| title | annotations.summary | trigger.name | fields.summary |
| severity | labels.severity | trigger.severity | priority.name |
| source_ref | fingerprint | eventid | issue.key |
| biz_key | labels.service + labels.env + labels.region + labels.alertname | host + trigger.expression | project + components + labels |
| assignee | labels.owner | host.groups.owner | assignee.name |
映射实现上，建议在接入层维护一份 YAML 映射配置，由适配器在工单创建时执行转换。映射失败时不能静默丢弃，应写入 ext.mapping_error 并触发人工确认，否则后续状态机无法正确推进。
三、优先级：从“严重度”到“处理优先级”的二维计算
很多团队把 severity 直接当 priority 用，这是跨系统流转中最常见的隐患。严重度描述异常本身的影响，优先级描述处理顺序，二者应分开。建议采用“影响范围 × 紧急程度”的二维矩阵：
priority_score = impact_weight × urgency_weight
impact: 单实例=1, 单服务=2, 多服务=3, 核心链路=4
urgency: 可延迟=1, 工作时间=2, 立即=3
P1: score >= 10
P2: 6 <= score < 10
P3: 3 <= score < 6
P4: score < 3例如“核心链路 + 立即”得分为 12，判为 P1；“单服务 + 工作时间”得分为 4，判为 P3。优先级一旦确定，应写入 priority 字段并同步到 ITSM 的 SLA 计算，避免各系统各自解释。
四、状态机：跨系统状态必须可收敛
状态机是自动流转的“轨道”。统一状态建议收敛为：NEW → ACK → PROCESSING → RESOLVED → CLOSED，并允许 PROCESSING → PENDING 表示等待外部依赖，RESOLVED → REOPENED 表示验证不通过。关键约束有三条：第一，状态只能由当前持有方推进，避免多系统并发写；第二，每次状态变更必须携带 operator、timestamp、reason；第三，源系统告警恢复只能触发 RESOLVED 候选，不能直接 CLOSED，关闭必须由人工或验证任务确认。
五、跨系统标识：biz_key 与 ticket_id 的分工
跨系统标识要解决两个问题：一是同一异常在多个系统中被识别为同一件事，二是工单在系统间跳转时能被准确回写。ticket_id 是平台生成的全局唯一号，用于对外展示和审计；biz_key 是业务稳定键，用于去重和关联。建议 biz_key 由“服务名 + 环境 + 区域 + 告警类型”拼接，例如 order-service:prod:cn-east:CPUHigh。当同一 biz_key 在 30 分钟窗口内再次触发时，不新建工单，而是将新告警追加到已有工单的 ext.related_alerts 中，并提升 priority。这样既避免重复建单，又保留完整证据链。