目录
一句话理解
在 osTicket 中：
工单（Ticket）是面向用户的服务请求主记录；任务（Task）是面向内部工作人员的具体执行事项。
可以理解成：
工单 = 这件事情为什么要做、谁提出、处理到哪一步、最终如何回复 任务 = 为了完成这张工单，内部具体要做哪些工作、由谁执行
osTicket 官方将任务描述为一种“内部待办事项”。任务既可以关联到某张工单，也可以脱离工单独立创建。(osTicket 文档)
一、工单是什么
工单是 osTicket 的核心业务对象，主要用来记录：
- 谁提出了请求；
- 请求解决什么问题；
- 用户和运维人员之间的沟通记录；
- 当前由哪个部门、人员或团队处理；
- 优先级、SLA、截止时间；
- 处理结果；
- 用户是否已经得到回复。
工单通常有一个明确的工单所有者，也就是提交请求的用户。用户可以通过客户门户、邮件等方式创建工单，运维人员也可以代用户创建工单。用户和协作者可以查看工单、回复工单、接收处理进展通知。(osTicket 文档)
例如：
工单编号：#IT20260802001 帮助主题：账号与权限 工单标题：为新员工张三开通系统账号 申请人：人事部李经理 协作者：张三直属主管 负责部门：IT 运维部 优先级：普通 期望完成时间：2026-08-05 申请内容： 请为新员工张三开通企业邮箱、VPN、Pstar 系统和文件服务器权限。
这张工单代表的是一个完整的服务请求。
二、任务是什么
任务是工作人员在 osTicket 内部使用的执行事项。
任务可以有两种存在方式：
1. 关联工单的任务 2. 独立任务
任务一般需要填写：
- 任务摘要；
- 任务详情；
- 负责部门；
- 负责人；
- 截止时间；
- 优先级。
其中，任务摘要、任务详情、负责部门是创建任务的基本字段，负责人和截止时间等可以根据实际需要填写。管理员还可以通过“Task Details”内置表单扩展任务字段。(osTicket 文档)
例如：
任务编号：#TASK000128 任务摘要：创建企业邮箱 关联工单：#IT20260802001 负责部门：IT 基础设施部 负责人：王工 截止时间：2026-08-03 18:00 任务详情： 1. 创建 zhangsan@company.com； 2. 加入员工通讯录； 3. 开启 IMAP/SMTP； 4. 将初始密码发送给直属主管。
这个任务只是完成工单的一部分，不代表整个申请已经处理完成。
三、工单与任务的主要区别
| 对比项目 | 工单 Ticket | 任务 Task |
|---|---|---|
| 核心定位 | 服务请求、问题、申请的主记录 | 内部具体执行事项 |
| 主要使用者 | 用户、协作者、运维人员 | 主要是运维人员、内部工作人员 |
| 是否有申请人 | 通常有明确的工单所有者 | 通常没有“申请人”概念，重点是负责人 |
| 用户能否在门户查看 | 可以 | 通常不可以 |
| 是否可以邮件回复 | 用户和协作者可以回复工单 | 第三方协作者可接收任务活动通知并通过邮件回复，但不能登录客户门户查看任务 |
| 是否能独立存在 | 可以 | 可以 |
| 是否能关联其他对象 | 可以关联任务、其他工单 | 可以关联工单，也可以独立存在 |
| 主要关注内容 | 请求、沟通、状态、SLA、用户反馈 | 执行步骤、负责人、截止时间、完成情况 |
| 分配方式 | 部门、人员、团队 | 部门、人员 |
| 关闭条件 | 请求处理完成后关闭 | 执行事项完成后标记完成 |
| 编号 | 有独立工单编号 | 有独立任务编号 |
| 适用对象 | “一件需要被服务和跟踪的事情” | “为了完成事情要采取的一个动作” |
任务只对拥有对应部门访问权限的工作人员可见。任务即使添加了外部协作者，协作者也只能接收任务活动通知，不能登录客户门户查看任务页面。(osTicket 文档)
四、工单与任务的关联关系
一个工单下面可以创建多个任务：
工单 ├── 任务1 ├── 任务2 ├── 任务3 └── 任务4
关联工单的任务有一个非常重要的规则：
只要工单下面还有未完成的关联任务，这张工单就不能关闭。
这可以防止运维人员只完成了部分工作，就错误地关闭整个服务请求。(osTicket 文档)
在较新的任务功能中，关联任务完成后，系统还可以在工单中自动增加内部备注；关联任务的截止时间也应早于工单截止时间。(osTicket 文档)
五、详细场景举例
场景一：新员工账号开通
工单
标题：为新员工张三开通入职账号 申请人：人事部 帮助主题：账号与权限 / 新建账号
工单表单记录：
- 员工姓名；
- 所属公司；
- 所属部门；
- 岗位；
- 入职日期；
- 直属主管；
- 需要开通的系统；
- 需要分配的角色；
- 期望完成时间。
工单下面创建任务
任务1：创建企业邮箱 负责人：邮箱管理员 任务2：创建域账号 负责人：桌面运维人员 任务3：开通 Pstar 系统账号 负责人：应用运维人员 任务4：开通 VPN 权限 负责人：网络管理员 任务5：配置文件服务器目录权限 负责人：服务器管理员
处理关系：
人事部提交工单
↓
IT 服务台审核信息
↓
分别创建5个内部任务
↓
各负责人完成自己的任务
↓
所有任务完成
↓
运维人员在工单中回复申请人
↓
关闭工单
这里：
- 工单代表“张三入职账号开通申请”；
- 任务代表“创建邮箱、创建域账号、开通 VPN”等具体工作。
场景二：系统发布与更新
工单
标题：Pstar 订单系统 V3.2.0 生产环境发布 帮助主题：系统发布与更新 / 功能迭代 申请人：研发负责人 协作者：产品经理、测试负责人、业务负责人 发布时间：2026-08-03 22:00
工单中记录：
- 发布版本；
- 发布内容；
- Git 仓库地址；
- 发布分支；
- 数据库变更；
- 测试结果；
- 发布窗口；
- 回滚方案；
- 业务确认情况。
关联任务
任务1：发布前数据库备份 负责人：数据库管理员 任务2：执行数据库变更脚本 负责人：数据库管理员 任务3：发布后端程序 负责人：应用运维 任务4：发布前端程序 负责人：应用运维 任务5：执行冒烟测试 负责人：测试人员 任务6：观察生产日志及监控 负责人：应用运维
这时，工单负责记录完整发布过程及各方沟通；任务负责分配和跟踪每一个执行动作。
需要注意：osTicket 可以记录审批意见、测试结论和内部备注，但它本身不是完整的 BPM 审批引擎。实际使用中，可以通过自定义字段、内部备注和状态约定记录“已审批、已测试、同意发布”等结果。
场景三：服务器重启申请
简单情况：只需要一个人操作
工单标题：重启测试环境应用服务器 申请人：研发人员 服务器：10.10.1.20 重启时间：今天18:00 原因：应用服务内存异常
这种情况处理步骤非常简单：
确认时间 → 登录服务器 → 重启 → 验证 → 回复用户
可以只使用工单，不必另外创建任务。
复杂情况：涉及多个部门
工单标题：生产环境服务器重启申请
下面创建任务：
任务1：业务部门确认停机窗口 任务2：检查当前用户连接 任务3：创建云服务器快照 任务4：停止应用服务 任务5：重启服务器 任务6：启动应用并进行业务验证 任务7：观察监控30分钟
这种情况下，使用任务拆解更合适。
场景四：故障处理
工单
标题：Pstar 系统无法登录 申请人：业务操作部 优先级：紧急 现象：所有用户登录后提示数据库连接失败
内部任务
任务1：检查应用服务状态 任务2：检查数据库连接状态 任务3：检查服务器磁盘空间 任务4：恢复数据库连接 任务5：验证业务功能 任务6：编写故障复盘记录
用户只需要关注：
故障是否受理 当前处理进展 什么时候恢复 故障原因是什么 是否已经解决
运维团队内部则需要关注：
谁检查数据库 谁处理服务器 谁负责恢复验证 谁编写复盘
所以外部沟通放在工单，内部执行放在任务。
场景五：独立任务
任务不一定必须关联工单。
例如，运维主管安排工作人员：
任务标题：验证测试服务器备份可恢复性 负责人：李工 截止时间：2026-08-10
这项工作没有用户提交申请，也不需要与用户沟通，因此可以直接创建独立任务。
其他适合独立任务的场景：
- 整理服务器资产资料；
- 检查过期账号；
- 更新系统架构图；
- 验证备份文件；
- 整理机房设备标签；
- 调查某项技术方案；
- 补充运维文档；
- 处理主管安排的内部工作。
六、什么时候只使用工单
出现以下情况时，通常只需要工单：
- 一个申请只需要一个人简单处理；
- 不需要跨部门协作；
- 执行步骤很少；
- 不需要分别设置负责人和截止时间；
- 处理过程可以直接通过工单内部备注记录。
例如：
重置一个用户的密码 修改一个邮箱显示名称 将一个账号解锁 重启一个测试环境服务 查询服务器日志 增加一个普通系统权限
不要为了使用任务功能，而强制给每张工单创建任务。
例如：
工单：重置张三的邮箱密码 任务：重置张三的邮箱密码
这种工单与任务内容完全重复，没有实际价值。
七、什么时候应该创建任务
符合下面任意情况时，可以考虑创建任务：
- 一张工单涉及多个处理步骤；
- 涉及不同部门或不同负责人；
- 每个执行事项有独立截止时间；
- 必须确保所有步骤完成后才能关闭工单；
- 某些操作不适合直接展示给用户；
- 需要明确记录每个工作人员完成了什么。
判断公式可以简化为：
一个用户请求 + 一个处理动作 → 只建工单 一个用户请求 + 多个内部处理动作 → 工单 + 多个任务 没有用户请求 + 纯内部工作 → 独立任务
八、任务不是“子工单”
虽然任务看起来像工单下面的子项，但它不完全等于子工单。
任务更强调：
执行、负责人、部门、截止时间、完成
子工单更强调：
独立请求、独立沟通、独立状态、独立SLA、独立用户
例如一张工单中，用户说：
1. 给张三开通 Pstar 账号； 2. 给李四修改订单系统权限； 3. 给王五回收离职账号。
虽然可以拆成三个任务，但更建议拆成三张工单，因为：
- 涉及三个不同用户；
- 三件事情可以独立完成；
- 可能有不同审批人；
- 可能有不同完成时间；
- 其中一件失败，不应该影响其他工单关闭；
- 后续审计时更容易查询每个人的账号记录。
osTicket 也支持关联或链接多张相关工单，而不必把所有事项都塞进一张工单。(osTicket 文档)
九、结合你们 IT 运维团队的推荐用法
你们目前主要有：
1. 系统发布与更新 2. 账号与权限 3. 业务系统重启 4. 服务器重启
建议这样设计。
工单负责记录申请
系统发布与更新
工单：Pstar V3.2.0 生产发布申请 任务： - 数据库备份 - 执行SQL - 发布后端 - 发布前端 - 冒烟测试 - 监控观察
账号与权限
工单：新员工张三账号开通申请 任务： - 创建邮箱 - 创建Pstar账号 - 开通VPN - 配置文件权限
业务系统重启
工单：订单系统应用服务重启申请 任务： - 确认业务停止 - 检查当前任务 - 重启应用 - 验证业务
服务器重启
工单：生产服务器重启申请 任务： - 创建快照 - 停止应用 - 重启服务器 - 启动服务 - 验证监控
十、推荐的内部定义
可以在你们的 osTicket 使用规范中这样定义：
工单：由用户、业务部门或运维人员发起，用于记录服务申请、故障、变更、发布及相关沟通过程的主业务单据。
任务：为完成某张工单而拆分的内部执行事项，也可以用于记录不需要用户参与的内部工作安排。任务必须明确负责部门、负责人、工作内容和完成标准。
最容易让员工理解的叫法是：
工单 = 服务申请单 任务 = 内部执行项
最终关系可以概括为：
用户提出一件事情
↓
创建工单
↓
运维人员判断是否需要拆分
↓
创建一个或多个任务
↓
各任务负责人完成执行
↓
工单负责人汇总结果并回复用户
↓
关闭工单