3. 工单分类与优先级：紧急程度、影响范围、服务级别协议（SLA）的设定方法

工单一进来，第一件事是什么？不是马上动手修，而是先搞清楚——这活儿有多急？影响多大？我见过太多团队，一上来就埋头处理，结果修了个边缘问题，核心业务却崩了一下午。说白了，分类和优先级搞不清楚，运维就是无头苍蝇。

这一章，我就把工单分类的底层逻辑、优先级矩阵怎么搭、SLA怎么定，掰开揉碎讲清楚。你想想看，没有标准，你怎么跟业务方对齐？怎么跟研发扯皮？怎么跟老板汇报？

3.1 工单分类的底层逻辑：先分对，再排优

我个人习惯，工单分类必须从两个维度入手：紧急程度和影响范围。这两个维度一交叉，优先级就出来了。

3.1.1 紧急程度：时间敏感度

紧急程度看的是时间窗口。问题发生后，你能容忍多久？

• 紧急（Critical）：必须在 30 分钟内响应，否则业务受损。比如支付链路断了、核心数据库挂了。
• 高（High）：1 小时内响应。比如某个 API 响应超时，影响部分用户。
• 中（Medium）：4 小时内响应。比如后台报表生成慢，不影响前端。
• 低（Low）：24 小时内响应。比如某个非核心页面样式错乱。

3.1.2 影响范围：波及面

影响范围看的是用户量和业务链路。我把它分成四档：

3.2 优先级矩阵：把分类变成可执行的规则

有了紧急程度和影响范围，下一步就是搭优先级矩阵。说白了，就是一张 4x4 的表格，告诉你每个组合该排多高。

我常用的矩阵是这样的：

你看，全局 + 紧急 = P0，这是最高优先级，必须立即响应。边缘 + 低 = P5，这种工单可以排到下周处理。

3.3 SLA 的设定方法：把承诺变成可量化的指标

SLA 是什么？说白了，就是你对业务方的承诺。承诺多久响应、多久解决。但很多团队把 SLA 定得太死，结果天天被打脸。

我建议你按优先级来设定 SLA，分三个维度：

• 响应时间（Response Time）：从工单创建到运维确认接手的时间。
• 处理时间（Resolution Time）：从接手到给出解决方案或恢复服务的时间。
• 升级时间（Escalation Time）：超过处理时间后，自动升级到更高级别处理。

举个例子，我常用的 SLA 标准：

3.4 核心流程：从分类到闭环

嗯，到这里，我把分类、优先级、SLA 都讲清楚了。但光有规则不行，你得把它串成一个可执行的流程。下面这张图，就是我常用的工单分类与优先级处理流程：

3.5 避坑指南：我踩过的三个坑

做工单分类这么多年，我踩过不少坑。挑三个最典型的，你注意避开：

1. 坑一：SLA 定得太死

   我曾经给 P0 工单定了「15 分钟响应，1 小时解决」。结果呢？运维团队天天被追着打，因为很多问题根本 1 小时搞不定。后来我改成「15 分钟响应，2 小时给出解决方案或临时恢复」，压力一下子就下来了。

2. 坑二：忽略业务方的主观感受

   有一次，一个 P3 工单被业务方投诉到 VP 那里。为什么？因为那个 bug 虽然影响范围小，但正好卡住了业务方的关键汇报。从那以后，我加了一条规则：业务方可以申请优先级重评，但必须提供理由。

3. 坑三：没有自动升级机制

   我记得有一次，一个 P1 工单卡在某个工程师手里 6 个小时没人管。为什么？因为没人知道这个工单超时了。后来我加了自动升级规则：超过 SLA 处理时间，自动通知主管；再超时，自动通知总监。嗯，从那以后，超时工单基本绝迹了。