4. 工单创建规范：标题、描述、附件、关联配置项（CI）的填写标准
工单创建，是整个闭环管理的第一道关口。我见过太多团队，工单标题写「服务器挂了」，描述就两个字「快修」。结果呢？处理人得花半小时追问细节，排障效率极低。
说白了，工单创建规范不是为了折腾人。它是为了让信息一次到位，减少来回沟通。今天我就把标题、描述、附件、CI 这四个维度的填写标准，掰开了讲清楚。
核心原则：工单创建时多花 3 分钟，处理环节就能省下 30 分钟。信息完整度直接决定工单的流转效率。
4.1 标题怎么写？—— 一眼看懂问题
标题是工单的「脸面」。处理人扫一眼标题，就得知道：什么系统、出了什么事、影响多大。
我建议采用三段式结构：
【系统/模块】故障现象简述 - 影响范围/紧急程度举个例子：
- ❌ 错误写法：「网络不通」、「数据库报错」、「系统卡顿」
- ✅ 正确写法：「【CRM 生产库】主库连接超时 - 影响全部销售下单，P1 紧急」
- ✅ 正确写法：「【OA 审批流】附件上传失败 - 仅影响 IE 浏览器用户」
这里有几个硬性要求：
- 必须包含系统名称：用方括号括起来，比如【ERP】、【监控平台】
- 现象要具体：别写「异常」，写「502 报错」或「磁盘写满」
- 标注优先级：P1（紧急）、P2（高）、P3（中）、P4（低）
- 控制在 30 字以内：太长了在列表里会被截断
我的习惯：标题写完后，自己读一遍。如果 5 秒内说不清问题是什么，就重写。我曾经带过一个团队，强制要求标题里不能出现「问题」、「故障」这种泛词，必须写具体现象。效果立竿见影，工单分派准确率提升了 40%。
4.2 描述怎么写？—— 让接手的人能直接干活
描述是工单的「灵魂」。我见过最差的描述就一句话：「帮我看看怎么回事」。这等于把排查工作全甩给了处理人。
好的描述，应该让接手的人看完就能开始操作，不需要再问任何问题。我推荐用 5W1H 模板：
| 要素 | 说明 | 示例 |
|---|---|---|
| What | 发生了什么现象 | 页面返回 502，持续 5 分钟未恢复 |
| When | 什么时间开始、持续多久 | 2024-03-15 14:22 首次出现，至今未恢复 |
| Where | 哪个环境、哪个模块 | 生产环境，订单服务集群 node-3 |
| Who | 谁发现的、影响了谁 | 客服部反馈，影响线上用户下单 |
| Why | 初步判断的原因 | 查看日志发现 OOM 错误，疑似内存泄漏 |
| How | 已尝试的操作 | 已重启一次，5 分钟后再次 502 |
你想想看，如果描述里把这六项都填全了，处理人是不是直接就能上手？
另外，我强烈建议在描述里加上 时间线：
14:22 - 监控告警触发，502 错误率飙升
14:25 - 客服确认用户无法下单
14:30 - 尝试重启 node-3，短暂恢复
14:35 - 再次 502，确认非偶发
14:40 - 提单转二线处理注意：不要写主观判断。比如「肯定是网络问题」、「开发又改坏了吧」。这些情绪化表达只会激化矛盾。写事实，写数据，写日志。
4.3 附件怎么传？—— 证据链要完整
附件是工单的「证据」。光靠文字描述，有时候说不清楚。截图、日志、抓包文件，这些才是硬通货。
我总结了几类必须附件的场景：
- 报错截图：必须包含报错时间、错误码、完整页面（别只截一小块）
- 日志片段：提供关键时间点前后 5 分钟的日志，标注出异常行
- 监控截图：CPU、内存、磁盘、网络，至少提供异常时间段的趋势图
- 配置文件：如果怀疑配置问题，附上相关配置段
关于附件命名，我有个血的教训。以前团队里有人传附件叫「截图1.png」、「日志.txt」，结果工单一多根本分不清。后来我们强制要求：
【工单号】_【内容描述】_【时间】.扩展名
示例：INC20240315001_订单服务502日志_20240315_1422.log还有一点：不要传压缩包。处理人没时间解压。单个文件控制在 10MB 以内，超过的用内部网盘链接。
我曾经遇到一个案例：用户传了一张截图，但截图里只显示了错误弹窗，没有显示浏览器地址栏和系统时间。结果排查了半天才发现是测试环境的问题，不是生产环境。从那以后，我要求所有截图必须包含：地址栏（或系统标识）、时间、完整的错误信息。
4.4 关联配置项（CI）怎么填？—— 给问题打上坐标
CI 是工单的「坐标」。没有 CI 的工单，就像快递没有地址——知道有问题，但不知道问题出在哪儿。
配置项包括但不限于：
- 服务器：主机名、IP、所属集群
- 应用服务：服务名称、版本号、部署环境
- 数据库：实例名、库名、连接串
- 网络设备：交换机、防火墙、负载均衡器
- 中间件：Nginx、Redis、Kafka 等
填写 CI 时，我建议遵循 三级关联法：
- 直接关联：出问题的那个具体资源（比如 node-3 服务器）
- 间接关联：依赖的上游或下游资源（比如 node-3 调用的数据库实例）
- 影响范围：受影响的业务系统或用户群体
举个例子：
直接关联：prod-app-node-3（服务器）
间接关联：prod-db-master（数据库）、prod-redis-cluster（缓存）
影响范围：订单服务、支付服务为什么要填三级？因为很多时候，根因不在直接关联的资源上。比如服务器 CPU 飙高，可能是上游调用量突增，也可能是数据库慢查询拖死了连接池。有了间接关联，处理人就能快速扩大排查范围。
关键点：CI 信息必须从 CMDB（配置管理数据库）中选取，不要手动输入。手动输入容易写错主机名或 IP，导致工单关联到错误的资源上。我们系统里做了下拉选择，从 CMDB 同步数据，就是为了避免这个问题。
4.5 一张图看懂工单创建规范
下面这张图，把标题、描述、附件、CI 的关系和填写流程串起来了。我建议你保存下来，每次创建工单前对照着看一遍。
4.6 常见避坑指南
最后，我把自己踩过的坑和见过的坑，列成了一张表。你对照着看看，自己有没有中招。
| 常见错误 | 后果 | 正确做法 |
|---|---|---|
| 标题写「系统故障」 | 处理人不知道哪个系统，无法分派 | 写【ERP】库存模块查询超时 |
| 描述只写「帮忙看看」 | 处理人需要反复追问细节 | 按 5W1H 模板填写完整 |
| 截图不包含时间 | 无法判断是历史问题还是当前问题 | 截图必须包含系统时间和地址栏 |
| CI 手动输入主机名 | 写错名字，工单关联到错误资源 | 从 CMDB 下拉选择 |
| 附件传压缩包 | 处理人没时间解压，直接跳过 | 单文件上传，超 10MB 用网盘链接 |
嗯，工单创建规范就讲到这里。说白了，这些规范不是为了增加你的工作量，而是为了让问题更快被解决。你想想看，如果每个工单都按这个标准来，处理人拿到手就能直接干活，那整个团队的效率能提升多少？