严重程度和优先级有什么区别？IT 事件的影响度×紧急度矩阵怎么用

先说结论： 严重程度（severity）描述一个事件有多严重；优先级（priority）决定事件处理的先后顺序和响应速度。严重程度基本是对损害的事实判断，优先级则是综合影响度、紧急度和业务背景后的一个决定。大多数服务台用“影响度×紧急度矩阵”算出优先级，再允许指定的人在特殊情况下人工调整。

IT 服务台上有两个词，常常引起不必要的摩擦。客户说问题“很严重”，工程师说“严重程度不高”，工单就在队列里躺着，而两边按各自的标准都没说错。原因是把严重程度和优先级当成了同一个旋钮。它们回答的是两个不同的问题，一套好的支持流程会把两个问题都问一遍，并且都记录下来。

本文用平实的话讲清两者的区别，说明影响度和紧急度矩阵怎样把两个简单判断变成优先级，并用一个公开的矩阵做示范。这个矩阵来自 博迅（Brocent）自己的 SLA 页面，我们在 2026 年 10 月 28 日核对过。文中还有几个情景实例、矩阵容易出错的地方，以及一份可以直接改用的落地步骤，无论你是自建 IT 团队，还是在评估管理型IT外包服务供应商，都用得上。

严重程度和优先级到底有什么区别？

严重程度回答“有多严重”，优先级回答“先做什么、多快做”。

严重程度描述问题本身的大小：什么坏了，影响多少人或多少系统，数据、安全或收入有没有风险。它通常在事件刚被弄清楚时确定，只有事实变了才会改，比如工程师发现故障范围比最初看到的更大。

优先级描述处理的顺序。它从同样的事实出发，再加上时间和背景：有没有截止时间，临时办法能不能接受，是不是月末，受影响的是一个人还是整个财务部。优先级在事件过程中可以升高或降低，而严重程度完全没变。

可以这样区分：

• 严重程度是诊断。 医生可以说一处伤很重，却还不知道候诊室排了多少人。
• 优先级是分诊顺序。 顺序取决于诊断，也取决于谁在等、有多少人手、每个病例有多急。

这两个词行业里都在用，但用法并不完全一致。Atlassian 的事件管理指南（严重等级一页，我们在 2026 年 10 月 28 日读过）用 SEV 等级表示事件的严重程度：SEV 1 是影响非常大的严重事件，SEV 3 是影响较小的轻微事件；它同时强调，关键是理解自己的业务，选择适合自己的严重等级和优先级定义。采用 ITIL 做法的服务台，则通常把“优先级”作为主字段，由影响度和紧急度推算出来。两种用法都不算错，要紧的是团队把每个词的含义写下来，并且每次都用同一种方式。

为什么要把严重程度和优先级分开？

如果两者永远一样，就没必要留两个字段。但实际中它们经常不一致，合并后会出现真实的错误。

1. 严重的问题可以是低优先级。 一个可能扩散、但目前已被控制、有可用的临时办法、且要下周才会用到的系统故障，可以排进计划变更窗口。
2. 轻微的问题可以是高优先级。 一个人登录不了只是小故障，但如果他一小时后要向客户做演示，截止时间会改变处理顺序，尽管故障本身没有变严重。
3. 两个字段的负责人不同。 懂故障的工程师通常判断严重程度；懂业务期限的服务负责人或业务方判断紧急度。只有一个字段，就等于让一个人去猜另一半。
4. 报表需要两者。 只记优先级，你分不清 P1 工单增多是基础设施真的在出问题，还是大家学会了“喊急”。同时记录严重程度，就能把这两种情况分开。

什么是影响度和紧急度？

影响度×紧急度矩阵由两个输入组成，它们都是对业务的判断，而不是对技术的判断。

影响度是影响的范围：多少人、系统、办公点或业务流程受到影响，受影响的程度如何。常见的写法从“全公司”一直到“单个用户，有临时办法”。

紧急度是时间压力：影响会多快恶化，或业务多快需要服务恢复。同一个坏掉的系统，有明显的临时办法时紧急度较低，在发薪日当天则很高。

ITIL 是最知名的一套 IT 服务管理实践，业内普遍把优先级理解为这两项的组合。我们这次没有重新阅读 ITIL 的付费出版物，所以这里只当作通行做法来介绍，不作为原文引用。如果你的组织要围绕 ITIL 建立正式流程，请以官方 ITIL 指南的措辞为准。

影响度分几级、怎么写？

对大多数中小型组织，四级就够了。措辞要让服务台一分钟内能判断。

1. 关键影响： 全公司范围或面向客户的服务中断，或者正在发生安全事件、数据丢失事件。
2. 严重影响： 一个部门、一个办公点或一个重要系统不可用或严重降级。
3. 中等影响： 一组用户或一个非关键系统受影响，工作可以降级继续。
4. 轻微影响： 单个用户，或只是外观、低价值功能受影响。

紧急度分几级、怎么写？

紧急度更难写，因为它取决于时间。同样用四级。

1. 关键： 工作现在已经停了，或一小时内会停，且没有临时办法。
2. 高： 影响会在当天工作时间内恶化，或今天就有截止时间。
3. 中： 影响可以等几天，或者有可用的临时办法。
4. 低： 没有截止时间，影响也不会恶化。

影响度紧急度矩阵怎样得出优先级？

矩阵就是一次查表：选定影响度，选定紧急度，读出优先级。培训教材通常把它画成网格，所以很多人以为矩阵必须用表格。其实不必。它就是一组简单规则，完全可以用标题和编号列表写出来，本文就是这样做的。

方法分三步：

1. 按上面的定义确定影响度。
2. 按上面的定义确定紧急度。
3. 查出交叉点，填入优先级字段。如果指定的人认为结果不对，可以人工调整，但必须记录理由。

不少团队还会加一条规则：提交工单的人不直接设置优先级，只描述影响和截止时间，由服务台套用矩阵。这样就不会出现每张工单都标成“紧急”的情况。

公开的事件优先级矩阵长什么样？

博迅 把矩阵公布在 SLA 页面上，所以你能看到真实的矩阵，而不是编出来的例子。该页面（我们在 2026 年 10 月 28 日核对）说明，优先级由业务影响度和紧急度组合决定，服务台在受理每张工单时套用这个矩阵。业务影响度分为关键（Critical）、严重（Serious）、中等（Medium）和轻微（Minor），紧急度分为关键（Critical）、高（High）、中（Medium）和低（Low）。

下面按影响度逐级写出这份公开矩阵。

业务影响度为“关键”时

1. 紧急度关键，优先级 P1。
2. 紧急度高，优先级 P1。
3. 紧急度中，优先级 P2。
4. 紧急度低，优先级 P4。

业务影响度为“严重”时

1. 紧急度关键，优先级 P1。
2. 紧急度高，优先级 P2。
3. 紧急度中，优先级 P3。
4. 紧急度低，优先级 P4。

业务影响度为“中等”时

1. 紧急度关键，优先级 P2。
2. 紧急度高，优先级 P2。
3. 紧急度中，优先级 P3。
4. 紧急度低，优先级 P4。

业务影响度为“轻微”时

1. 紧急度关键，优先级 P2。
2. 紧急度高，优先级 P3。
3. 紧急度中，优先级 P3。
4. 紧急度低，优先级 P4。

有两点值得注意。第一，紧急度可以在影响很小时把优先级拉上去：影响轻微但紧急度关键的事件是 P2，而不是 P4。第二，在这份矩阵里，紧急度低就把一切封顶在 P4，因为没有时间压力，工作就可以排期。

同一个 SLA 页面还列出了第五级 P5，用于根本不是故障的例行请求，比如新装设备、离职处理或重置密码。这些是服务请求而不是故障，所以不在影响度紧急度矩阵之内。

每个优先级对应什么响应时间？

优先级只有带着承诺才有用。同一个 SLA 页面公布了每一级的首次响应、远程支持和上门或解决目标：P1 和 P2 的首次响应是 15 分钟，P3 是 30 分钟，P4 和 P5 是 60 分钟。这些是首次响应时间，不是修复时间，而且取决于服务时段：标准的 8×5 时段是周一至周五、每天九个工作小时，高级的 24×7 时段则全天候。页面也注明，响应时间以合同条款为准。

我们的 P1 响应时间是公开的，你在和任何人沟通之前，就可以在 SLA 页面和管理型IT外包服务方案与按人头定价上核对。想用大白话了解四个级别各自承诺什么，可以读我们的配套文章：IT 支持 SLA 里的 P1 到 P4 优先级。

实例：严重程度和优先级并排看

下面的场景是示意，不是真实客户案例。它们展示同一个矩阵怎样处理不同情况，以及每种情况下严重程度和优先级怎样不同。

1. 周一早上全公司邮件不可用。 影响度关键，紧急度关键，矩阵给出 P1。严重程度也在你所用等级的最高档。所有人先处理它。
2. 月末前两天，财务系统对财务部非常慢。 影响度严重，紧急度高，矩阵给出 P2。工程师可能把严重程度评为中等，因为系统还能用，但月末的截止时间把优先级抬高了。
3. 一位用户在明天开会前打印不了。 影响度轻微，紧急度高，矩阵给出 P3。严重程度低，优先级处于中间位置。
4. 一个软件许可下个季度要续期。 影响度轻微，紧急度低，矩阵给出 P4，工单排期处理。
5. 一台备用服务器出了故障，但故障转移正常。 工程师的记录里可能把严重程度评为严重，因为如果故障转移也失效，问题会扩大。但今天的影响度是轻微、紧急度是低，矩阵给出 P4。于是预约一个变更窗口，严重程度仍然留在记录里。

第 5 个场景最能说明为什么两个字段都有价值。如果团队只有优先级字段，记录上只会写“低”，风险就被忘掉了。

什么时候应该人工调整矩阵的结果？

没有矩阵能覆盖所有情况。好的流程允许指定角色调整计算出的优先级，并要求写明原因。合理的调整理由包括：

1. 安全信号。 一个行为像被入侵的账号，可能值得比表面影响更高的优先级。
2. 固定的外部期限。 业务必须在某个时间前申报或交付时，要提高紧急度。
3. 重复出现的故障。 同一原因导致的五张 P4 工单，其实是一个更大的问题，应按问题记录处理，而不是当作五个小事。
4. 临时办法失效。 临时办法不再管用，紧急度就变了，即使其他方面没变。
5. 敏感岗位。 有些岗位，比如按固定时间处理付款的人，能容忍的中断比单看人数要少。

人工调整要保持少见。如果有相当比例的工单被调整，说明定义本身有问题，应该重写定义，而不是逐个修补。

怎样落地一套优先级矩阵？

一个下午可以搭好，第一个月里再慢慢改进。这套步骤适合任何规模的内部 IT 团队，也是你应该要求管理型IT外包服务供应商展示的内容。

1. 用自己的话写出四级影响度和四级紧急度的定义，每级配一个例子。
2. 把矩阵写成列表，每个影响度一个标题，放在所有服务台人员都看得到的一页上。
3. 给每个优先级配上响应目标，并写明按工作小时还是按自然小时计算。
4. 确定谁可以人工调整，并要求在工单中写明理由。
5. 如果想统计事件的严重程度，另设一个严重程度字段，并定义它的等级（例如三级或四级）。
6. 一个月后复盘。查看被调整过或被重新打开的工单，修正定义。
7. 教提交人描述，而不是打分。给他们一份简短的表单，问清楚什么受到了影响、有什么截止时间。

向 IT 服务商了解严重程度和优先级时该问什么？

如果你采购管理型IT外包服务，合同里会有优先级定义，而这些定义写得好不好，能说明服务运作得怎么样。可以问：

1. 合同用的是哪些词，严重程度和优先级是否分开？
2. 优先级由谁来设置，是提交人还是服务台？
3. 矩阵是否公开，签约之前能不能看到？
4. 每一级的首次响应和解决目标是多少，适用哪些时段？
5. 谁可以调整优先级，理由是否记录？
6. 每月怎样把各优先级的情况汇报给你？

想了解怎样把这些写进合同，可以看我们的 24×7 服务台 IT 支持概述，或者联系我们聊聊你自己的服务级别。

常见问题

一句话说，严重程度和优先级有什么区别？

严重程度衡量事件有多严重；优先级根据影响度、紧急度和背景，决定响应的顺序和速度。

P1 就是 SEV 1 吗？

不一定。两者通常都代表各自等级的最高档，但 SEV 等级一般描述严重程度，P 等级一般描述处理顺序。有些团队两者共用一套等级。如果这样做，要定义清楚并始终一致地使用。

什么是影响度紧急度矩阵？

它是一条查表规则，把两个判断，即业务影响的范围和时间压力，合成一个优先级。可以画成表格，也可以像本文这样，用标题和编号列表写出来。

工单的优先级应该由谁来定？

由服务台按约定的矩阵来定。提交人描述影响和截止时间。指定角色可以调整结果，理由要写进工单。

需要几个优先级？

四个事件级别，加上一个单独的例行请求级别，对大多数组织已经够用。级别太多会让人犹豫，选择也会不一致。

事件处理过程中优先级会变吗？

会。影响扩大、临时办法失效或出现截止时间时，应当提高优先级并记录变更。找到了临时办法，则可以降低。

ITIL 要求必须用影响度紧急度矩阵吗？

ITIL 的指导通常把优先级描述为影响度和紧急度的函数，但它是一套实践框架，不是必须原样照抄的规则。请按自己的业务调整等级。

接下来读什么

想了解严重程度和优先级怎样融入整个支持流程，可以读我们关于 L1、L2、L3 支持分级和 IT 升级矩阵模板的文章。合同方面，请看 IT 支持里的 SLA 是什么意思。

*2026 年 10 月 28 日核对的来源：博迅 SLA 页面（brocent.com/sla）；Atlassian 事件管理指南严重等级一页（atlassian.com/incident-management/kpis/severity-levels）。*

想把这些指标写进合同，而不是停留在 PPT 上？ 博迅的管理型IT外包服务方案把 SLA 和按人头的月费并排公开，覆盖香港、新加坡、中国大陆和美国。查看方案与定价，或联系顾问。