ITIL运维流程配置：从工单到闭环的实操指南
ITIL运维流程配置不是把书上的流程图搬进系统，而是先把团队实际处理故障、变更和请求的方式梳理清楚，再在工单工具里定义状态、优先级、审批和时限。
零基础落地时，建议先从事件管理和服务请求两条最常用的流程开始，跑顺后再补问题管理和变更管理。
先明确要配哪几类流程
ITIL v4 里流程很多，但日常运维真正高频的是这四类：
- 事件管理：服务器宕机、服务不可用、用户报障等，目标是尽快恢复。
- 服务请求：开通账号、申请权限、重置密码等计划内需求。
- 问题管理：多个事件反复出现，需要找根因。
- 变更管理：上线、改配置、换硬件等有风险的操作。
如果团队刚开始，先配事件和服务请求，把工单能创建、能流转、能关闭跑通，再考虑问题与变更的关联。
配置前的准备清单
动手之前，把这些信息整理成表格，后面填进工具会快很多：
- 流程责任人：每条流程谁负责分派、谁负责审批、谁负责关闭。
- 状态节点：常见的是新建、处理中、待用户确认、已解决、已关闭。
- 优先级规则：一般按影响范围加紧急程度组合，例如影响全公司且业务中断为最高级。
- SLA时限：响应时间和解决时间，按优先级分别设定。
- 通知方式：邮件、企业微信、钉钉或短信，明确触发时机。
准备阶段最容易被忽略的是关闭权限：谁有权把工单标记为已关闭，必须在配置前定好，否则后期会出现工单被随意关闭、统计失真的问题。
在工单系统中配置流程
不同工具界面不同，但配置逻辑基本一致。
下面以常见的自建或开源工单系统为例说明通用步骤。
创建流程与状态
进入后台的流程管理或工单类型设置，新建工单类型，例如“事件工单”。
然后定义状态字段：
新建 -> 处理中 -> 待确认 -> 已解决 -> 已关闭每个状态要设置允许的下一步，避免出现“新建”直接跳到“已关闭”这种绕过处理的路径。
设置优先级与SLA
在优先级配置中建立映射关系，例如：
P1 紧急：影响核心业务，响应 15 分钟，解决 2 小时
P2 高：影响部分用户，响应 30 分钟，解决 4 小时
P3 中：单个用户受影响，响应 2 小时，解决 1 个工作日
P4 低：咨询类，响应 1 个工作日，解决 3 个工作日上面的时间是示例，请按自己团队的实际能力填写，不要照抄。
设定后要在工具里开启超时提醒，否则SLA只是纸面数字。
配置审批与通知
变更类流程需要加审批节点。
在流程设计里插入审批环节，指定审批人角色而不是具体某个人，这样人员变动时不用改流程。
通知规则建议按事件触发：
- 工单创建时通知处理组；
- 状态变更时通知提交人；
- 临近SLA超时时通知负责人。
关联知识库
在关闭工单前，可设置必填“解决方案”字段，并允许一键沉淀到知识库。
这样同类问题再次出现时，处理人可以先查知识库，减少重复排查。
避坑与验证
配置完成后不要直接全量上线，先做小范围验证：
- 用测试账号提交一张工单，走完新建到关闭全流程，确认每一步通知都正常收到。
- 故意让一张工单超过SLA时限，检查超时提醒是否触发。
- 尝试用非授权账号关闭工单，确认权限控制生效。
常见坑点有三个：一是状态太多，处理人不知道选哪个，建议初期控制在五个以内；
二是SLA定得太紧，团队长期超时反而失去约束力；
三是审批人设成个人，一旦该同事请假流程就卡住，应改为角色或组。
如果工单量统计和实际不符，先检查是否有工单被直接关闭而没有经过处理状态，这是最常见的数据失真原因。
常见疑问
ITIL流程配置必须一次全上吗？ 不需要。
先跑事件和服务请求，稳定后再补问题和变更，逐步推进更容易被团队接受。
小团队也需要SLA吗？ 可以简化，但建议至少设定响应时间，让提交人知道多久会有反馈，避免反复催问。
流程和工具哪个先定？ 先梳理流程，再选工具。
反过来容易被工具自带模板牵着走，配出一套和实际工作不符的流程。
ITIL运维流程配置的核心是让每个工单都有明确的状态、责任人和时限，并且能闭环。
按本文顺序先把准备清单整理好，再在系统里配置状态、优先级和通知，最后用小范围工单验证，确认无误后再推广到全团队。
