IT 技术支持 SOP：把"救火队"变成"流水线"

很多公司的 IT 支持是“救火队”模式：谁喊得响先处理谁，老师在的时候系统稳定，老师休假天下大乱。SOP（标准作业程序）要解决的就是这件事：让服务质量取决于流程，而不是取决于某个人在不在状态。下面是一套经过实战检验的框架，中小团队可以直接抄。

一、事件分级：一切流程的起点

不分级就没法谈优先级，所有人都在“最高优先级”等于没有优先级。

级别	定义	响应 SLA	解决 SLA	示例
P1 致命	核心业务中断，影响全公司	5 分钟	2 小时	核心交换机宕机、邮箱全网不可用
P2 严重	部门级业务受阻，有绕行方案	15 分钟	4 小时	部门共享盘无法访问
P3 一般	个人故障，不影响他人	2 小时	1 个工作日	单台电脑无法打印
P4 请求	权限申请、装机等标准化请求	4 小时	3 个工作日	新员工入职装机

原则只有一条：响应 SLA 比“马上看”更管用的是“5 分钟内必须有人的回音”——哪怕回复是“已收到，预计 16:00 前解决”。

二、工单生命周期：口头支持必须补单

提交 → 分诊（定级+派单）→ 处理 → 验证关闭 → 满意度回访
         │                                     │
         └─ 不属 IT？转办并留痕      重复出现？→ 转问题管理建知识库

三条纪律：

1. 渠道归一：所有请求进工单系统（Jira Service/OpsPilot/自建都行），微信喊一句“电脑坏了”必须补单。没有工单就没有数据，没有数据就没法谈改进；
2. 一线快、二线专、三线深：一线只做标准动作（重启、换线、按知识库操作），15 分钟搞不定升级二线，不许恋战；
3. 关闭前必须验证：以“用户确认能用了”为关闭条件，不是“我这边看着好了”。

三、知识库：让第 N 次问题变成零成本

判断 SOP 成熟度的金标准：重复性问题的首次解决率。每个处理超过 30 分钟、或第二次出现的问题，处理人必须沉淀一篇知识库文章，格式固定：

# 现象
一句话说清用户看到什么（截图/报错原文）
# 影响范围
个人 / 部门 / 全员；业务系统名
# 原因
根因，不写"原因不明"
# 处理步骤
1. xxx（可直接照做的命令/点击路径）
# 预防措施
配置修改 / 监控告警 / 巡检项

知识库不考核文采，考核命中率：新人拿着它能独立解决，才算合格。

四、变更管理：IT 自己别当事故源

支持团队一半的故障是自己改出来的。红线清单：

• 变更窗口：非紧急变更只在维护窗口执行，提前公告影响范围；
• 变更三件套：变更方案、回滚方案、验证清单，缺一不做；
• 高危操作双人复核：批量改策略、动核心设备、删数据，第二双眼睛是免费的保险。

五、指标体系：用数据管理团队

月度只看五个指标，多了没人看：

1. 工单总量与分级分布（趋势比绝对值重要）；
2. SLA 达成率（分级别统计）；
3. 首次解决率（一线不升级解决的比例，知识库成熟度的镜子）；
4. MTTR 平均解决时长（P1 单独看）；
5. 满意度（关闭工单后一键评分，低于 3 星自动触发回访）。

六、复盘：事故的学费不能白交

P1/P2 事件 48 小时内做无责复盘，一页纸模板：

时间线：发现 → 响应 → 定位 → 恢复，每个节点精确到分钟
影响：业务 × 时长 × 用户数
根因：连问五个为什么，停在"人的疏忽"等于没复盘
行动项：做什么、谁负责、哪天完成——下次复盘会检查上次的行动项

SOP 的最高境界：新人按文档能做出八十分，团队靠数据持续改进最后二十分。救火队的英雄主义很动人，但可复制才可托付。