工单系统先解决“事情有没有被接住”
用户报障、权限申请、设备故障、账号异常,如果只靠微信群或口头沟通,很容易出现没人负责、过程丢失、重复排查、结果说不清。ticket 记录系统的第一层价值,就是把每个请求变成可追踪的记录。
一条比较完整的 IT ticket,通常至少包括:请求人、影响范围、优先级、现象描述、处理人、处理过程、升级记录、解决方案和关闭确认。考试不一定直接考英文 ticket,但会考服务台、事件管理、问题升级和服务质量。
| 记录项 | 为什么重要 | 常见问题 |
|---|---|---|
| 现象描述 | 方便一线快速判断问题 | 只写“系统坏了” |
| 影响范围 | 用于判断优先级和升级路径 | 不知道影响几个人或哪些业务 |
| 处理过程 | 避免重复排查,便于交接 | 只在聊天里说,工单里没记录 |
| 升级记录 | 说明为什么转二线或三线 | 没有留下已尝试动作 |
| 关闭确认 | 确认用户问题已解决 | 技术人员自己关单,用户未确认 |
事件、问题、请求不要混在一起
IT 服务管理里,事件通常是已经影响服务的异常,比如系统登录失败、打印机无法使用;服务请求可能是申请账号、开通权限、安装软件;问题管理更关注根本原因,比如同类故障反复发生,需要分析根因并制定长期措施。
ticket 系统不是只用来记录故障。它也可以记录请求、变更、问题和知识库沉淀。区别在于每类记录的处理流程和考核指标不一样。
| 类型 | 典型场景 | 处理重点 |
|---|---|---|
| 事件 | 系统不可用、网络中断、设备故障 | 尽快恢复服务 |
| 服务请求 | 开账号、装软件、申请权限 | 按流程交付请求 |
| 问题 | 同类事件反复出现 | 找根因,减少再次发生 |
| 变更 | 调整配置、升级系统 | 评估影响和风险 |
考试喜欢考“升级前为什么要记录”
一线支持把工单升级给二线或三线之前,必须记录已经做过什么。否则接手的人不知道现象、环境、尝试步骤和结果,只能从头问一遍,既浪费时间,也影响用户体验。
老师讲这类题会强调一句:升级不是甩锅,是带着上下文交接。工单记录越完整,升级越有效;记录越含糊,后续越容易重复劳动。
相关题目解析
下面这些题目和本专题的判断方法关联较强,适合读完概念后回到具体题干里校验理解。
- SLA、OLA 和 UC 有什么区别?SLA / OLA
- CMDB 和资产台账有什么区别?CMDB / 资产台账