传递单基础：定义、类型与标准字段解析
传递单是 IT 运维中记录事件、请求或变更的标准化载体，也是故障排查流程中“审查意见闭环”的起点。每一张传递单都承载着从发现、处理到验证的完整轨迹。本节将系统梳理传递单的核心概念、三大类型及其标准字段结构。
1. 传递单的定义与核心价值
传递单（Ticket / Work Order）是在 IT 服务管理（ITSM）体系中，用于记录、跟踪和闭环某一项运维活动的结构化文档。它不仅是操作凭证，更是故障排查中追溯根因、对齐审查意见的关键证据链。
核心价值： 传递单将“发生了什么、谁处理的、怎么处理的、结果如何”固化为可审计、可复盘的记录，避免口头传递导致的信息丢失。
2. 传递单的三大类型
根据 ITIL 最佳实践，传递单主要分为以下三类，每类对应不同的运维场景和闭环要求。
| 类型 | 英文名称 | 触发场景 | 闭环目标 |
|---|---|---|---|
| 故障单 | Incident Ticket | 系统异常、服务中断、用户报障 | 恢复服务、消除影响 |
| 服务请求单 | Service Request Ticket | 权限申请、资源开通、信息查询 | 满足用户标准化需求 |
| 变更单 | Change Ticket | 配置修改、版本升级、架构调整 | 受控变更、降低风险 |
运维提示： 故障排查中，故障单和变更单的关联最为紧密。一次变更操作可能引发故障，而故障恢复后往往需要发起紧急变更单来修复根因。
3. 传递单的标准字段解析
无论哪种类型，传递单都包含一组核心字段。这些字段是审查意见闭环的基础，也是后续故障排查中“按图索骥”的关键索引。
- 单号（Ticket ID）： 全局唯一标识，用于快速检索和关联。
- 标题（Subject）： 简明扼要描述问题或请求，如“数据库连接池耗尽导致订单服务超时”。
- 优先级（Priority）： 通常分为 P1~P4，决定响应和处理顺序。
- 状态（Status）： 如新建、处理中、待审批、已关闭，反映当前生命周期阶段。
- 申报人（Reporter）： 发起传递单的人员或监控系统。
- 处理人（Assignee）： 负责处理该传递单的运维工程师或团队。
- 创建时间（Created Time）： 传递单生成的时间戳，用于计算响应时长。
- 解决时间（Resolved Time）： 实际完成处理的时间戳，用于计算解决时长。
- 描述（Description）： 详细记录现象、影响范围、初步诊断信息。
- 解决方案（Resolution）： 最终采取的处理步骤和结果，是审查闭环的核心输出。
- 关联单号（Related Ticket ID）： 链接相关的故障单、变更单或问题单，形成闭环链路。
4. 传递单类型与字段差异对比
虽然基础字段相似，但三类传递单在关键字段上存在显著差异，直接影响审查意见的闭环逻辑。
| 字段 | 故障单 | 服务请求单 | 变更单 |
|---|---|---|---|
| 影响度 | 高（影响用户数、业务中断时长） | 低（通常不影响核心业务） | 中（需评估变更失败风险） |
| 紧急度 | 高（需立即响应） | 低（可按 SLA 排期） | 中（紧急变更需加速审批） |
| 审批流程 | 可选（事后补审批） | 通常无需审批 | 必须（变更审批委员会） |
| 回滚计划 | 无（以恢复为主） | 无 | 必须（变更失败时的回退步骤） |
| 审查意见 | 根因分析 + 预防措施 | 合规性检查 | 变更结果验证 + 风险复盘 |
5. 传递单生命周期与闭环流程
下面这张 SVG 图展示了传递单从创建到关闭的完整生命周期，以及审查意见如何嵌入每个环节形成闭环。
6. 审查意见闭环的传递单实践要点
常见误区： 很多运维团队只关注“处理”环节，忽略了“审查意见”和“关联单号”的填写。这会导致故障排查时无法追溯变更历史，审查意见沦为形式。
- 故障单必须关联变更单： 如果故障是由变更引起的，故障单的“关联单号”字段必须填写对应的变更单号，形成闭环。
- 变更单必须包含回滚计划： 审查意见会重点检查回滚步骤是否完整，这是降低变更风险的核心。
- 服务请求单需记录审批记录： 即使是标准化请求，也需要在审查意见中记录审批人、审批时间，确保合规。
- 状态流转不可逆但可追溯： 传递单一旦关闭，不应再修改；如需补充信息，应通过“关联单号”发起新的传递单。
7. 传递单标准字段模板示例
以下是一个通用的传递单字段模板，适用于大多数 ITSM 工具（如 ServiceNow、Jira、Zabbix 等）。
{
"ticket_id": "INC-20250321-001",
"title": "生产环境数据库连接超时",
"type": "故障单",
"priority": "P1",
"status": "处理中",
"reporter": "监控系统 Zabbix",
"assignee": "张工（DBA 组）",
"created_time": "2025-03-21 14:30:00",
"resolved_time": null,
"description": "14:28 告警：数据库连接池使用率 98%，应用层出现大量超时错误，影响订单创建接口。",
"resolution": "",
"related_ticket_ids": ["CHG-20250320-045"],
"review_comment": ""
}
最佳实践： 在故障排查中，优先查看“关联单号”字段。如果故障单关联了变更单，先审查变更单的内容，往往能快速定位根因。