📚 课程目录第2章异常工单来源系统梳理

2. 异常工单来源系统梳理

异常工单自动流转的第一步，不是写流转规则，而是把“工单从哪里来”这件事彻底梳理清楚。来源系统决定了工单的字段结构、严重程度语义、触发时机和后续可追溯性。如果来源没有分类清楚，后面的自动分派、去重、升级和闭环校验都会失去稳定的输入基础。本节把常见来源划分为四类：业务系统、监控系统、日志平台、客服系统，并说明它们各自的触发方式与典型字段。

一、四类来源系统的定位差异

业务系统是“业务逻辑自己发现异常”的地方。例如订单系统在支付回调超时后主动抛出异常，库存系统在扣减失败时记录一条待处理事件。它的特点是：异常与业务语义强绑定，往往带有订单号、用户ID、商户号等业务主键，但缺少基础设施层面的上下文。

监控系统是“指标和阈值发现异常”的地方。Prometheus、Zabbix、云监控等平台基于采集到的时序数据，在规则命中时产生告警。它的特点是：触发及时、可量化，但告警内容偏技术指标，缺少业务影响面描述。

日志平台是“从文本中挖掘异常”的地方。ELK、Loki、SLS 等平台通过关键字匹配、正则抽取或日志聚类发现错误模式。它的特点是：信息量大、上下文丰富，但噪声也大，需要收敛和去重。

客服系统是“人发现异常”的地方。客服在接到用户投诉或咨询后创建工单，带有用户描述、会话记录和情绪标签。它的特点是：业务影响明确、优先级高，但技术定位信息往往不足，需要反向关联监控和日志。

二、触发方式的工程差异

四类来源的触发方式不同，直接决定了接入层需要做哪些适配。业务系统通常通过异常捕获或事件发布触发，例如在支付回调代码中捕获超时异常后，向消息队列发送一条事件；监控系统通过规则命中后回调 Webhook 触发；日志平台通过关键字匹配或日志聚类命中后输出告警事件；客服系统则由人工在界面创建工单，或由会话升级规则自动建单。

这四种触发方式在时效性、可靠性和字段完整度上差异明显。监控和日志触发是自动的、秒级到分钟级；业务系统触发依赖代码埋点质量；客服触发是人工的、分钟级到小时级。接入层必须为每种来源定义独立的适配器，而不是用一套解析逻辑硬套。

三、统一字段映射与来源标记

无论来源如何，进入流转引擎前都要映射为统一工单模型。建议至少包含以下字段：source_system（来源系统标识）、source_type（业务/监控/日志/客服）、biz_key（业务主键，如订单号）、severity（归一化严重度）、trigger_time（触发时间）、raw_payload（原始报文）、dedup_hash（去重指纹）、trace_id（链路追踪ID）。

其中 severity 的归一化最容易出问题。监控系统的 P0/P1/P2 与客服系统的“紧急/一般/低”语义并不等价，需要建立映射表。例如监控 P0 映射为 critical，客服“紧急”也映射为 critical，但客服“一般”可能对应监控 P2。映射表应由运维、客服和业务方共同确认，不能由单方拍板。

实践建议：接入层先做“来源标记”，再做“字段映射”。来源标记保留原始系统名和原始严重度，便于回溯；字段映射只负责生成流转引擎可消费的标准化字段。两者分离后，后续新增来源只需增加适配器，不必改动流转规则。

四、去重指纹的设计

同一异常可能同时被监控和日志捕获，也可能被多个业务节点重复上报。去重指纹 dedup_hash 通常由 source_type + biz_key + 异常类型 + 时间窗口 拼接后哈希生成。例如订单支付超时，监控告警和业务异常都带同一个订单号，若时间窗口设为 5 分钟，则两条记录会生成相同指纹，接入层只保留最早一条并合并上下文。

dedup_hash = sha1(
  source_type + "|" +
  biz_key     + "|" +
  error_code  + "|" +
  floor(trigger_time / 300)   # 5分钟窗口
)

时间窗口不宜过短，否则同一故障的多次告警会重复建单；也不宜过长，否则不同批次的同类异常会被误合并。建议按异常类型分别设置窗口：基础设施类 5 分钟，业务类 15 分钟，客服类 30 分钟。窗口值应作为配置项，而不是硬编码。

五、来源梳理的交付物

完成本节梳理后，应形成一份“来源系统接入清单”，至少包含：来源系统名称、来源类型、触发方式、关键字段、严重度映射、去重窗口、责任人和接入状态。这份清单是后续编写适配器和流转规则的基础输入。下面给出一个可直接填写的示例结构。

来源系统	来源类型	触发方式	关键字段	严重度映射	去重窗口	责任人	接入状态
订单中心	业务系统	异常捕获后发 MQ	order_id, error_code	error_code→P1/P2	15 min	订单组-张工	已接入
Prometheus	监控系统	规则命中回调 Webhook	alertname, instance, severity	P0→critical, P1→high	5 min	运维组-李工	已接入
ELK	日志平台	关键字匹配输出告警	service, trace_id, message	按关键字分级	5 min	平台组-王工	调试中
客服工单台	客服系统	人工建单 / 会话升级	ticket_id, user_id, 描述	紧急→critical, 一般→medium	30 min	客服组-赵工	待接入

常见误区：把客服工单直接当作技术工单流转。客服工单缺少 trace_id 和实例信息，若不做反向关联（用 user_id 或订单号去查监控和日志），流转到技术团队后仍需人工补查，自动流转的价值会大打折扣。正确做法是在接入层为客服工单补充关联查询，把监控和日志上下文一并带入。

来源系统梳理不是一次性工作。新增业务系统、更换监控平台、调整日志采集规则，都会改变工单来源结构。建议把“来源接入清单”纳入版本管理，每次变更同步更新适配器和映射表，并在接入层保留来源健康度指标（如各来源近 24 小时建单量、去重率、字段缺失率），以便及时发现某类来源的接入异常。