IT 升级矩阵模板：职能升级、层级升级、联系人和时限怎么写

先说结论： 升级矩阵是一份文件，写明什么时候事件必须升级，以及每一级由谁处理。它结合了两个概念：职能升级（把工单交给技能更强或专业不同的人）和层级升级（通知权限更高的人）。下面的模板给出需要填写的字段，全部用编号列表表示，所以可以放进任何文档或工单工具。

IT 事件拖下去的时候，最糟的问题就是“我该告诉谁？”升级矩阵提前回答了它：每个阶段由谁负责，工单在转走前有多少时间，哪些人必须被告知。没有矩阵，升级就要看当班的是谁，而且往往很晚才发生。

本文说明什么是升级矩阵，职能升级和层级升级的区别，以及文件里应写什么。随后给出一份可复制的编号列表模板，一个使用虚构人名的实例，和让矩阵保持有效的简短清单。我们还会讲，向管理型IT外包服务供应商了解他们的矩阵时该问什么。

什么是升级矩阵？

升级矩阵是一份文件或一套系统，规定什么时候应该升级，以及在每个升级层级由谁处理事件。这是 Atlassian 在事件管理指南“升级策略”一页的说法（我们在 2026 年 10 月 28 日读过）。同一页还指出，各组织的详细程度差别很大：有的用简单的层级图，每个人向技能更高的人升级；有的则维护针对具体情境的矩阵，说明不同类型事件或严重等级应联系哪个团队。它还说没有放之四海而皆准的做法，并建议把升级策略当作指导原则，而不是死板的规则。

在 IT 支持中，矩阵通常要为每个优先级回答五个问题：

1. 谁最先负责这张工单？
2. 他们有多长时间，工单必须转走？
3. 下一个接手的是谁？
4. 哪些人即使不参与处理，也必须被告知？
5. 怎样联系到每个人，包括下班时间？

它与支持分级模型不同。分级（L1、L2、L3）描述技能的层次；矩阵规定何时、如何在各级之间移动，以及谁位于它们之上。如果你想先看分级模型，请读我们的 L1、L2、L3 支持分级指南。

职能升级和层级升级有什么区别？

这两个词用于 ITIL 风格的服务管理。我们这次没有重新阅读 ITIL 的付费出版物，所以下面的解释是我们对通行做法的描述，不是原文引用。

职能升级

职能升级把工单转给有更专业知识或不同技能的人或团队。它在技能上是横向或向上，而不是职级上的向上。

1. 触发条件：当前层级解决不了，或者工单需要专家，例如网络、安全或某个应用团队。
2. 方向：从 L1 到 L2，从 L2 到 L3，从 L3 到厂商。
3. 告知对象：接手工单的专家；除非正式转移，工单责任人保持不变。
4. 例子：服务台人员把防火墙故障升级给网络工程师。

层级升级

层级升级把信息，有时还有决定权，交给权限更高的人。它是职级上的向上，而不是技能上的。

1. 触发条件：事件严重、耗时过长，或需要超出当前人员权限的决定，例如花钱、请外部方介入或通知客户。
2. 方向：从团队主管到服务经理，到 IT 负责人，到总监。
3. 告知对象：需要知情、可能需要决策的经理和业务负责人。
4. 例子：服务经理告诉 IT 负责人，某个 P1 在约定时间后还没修好，而且厂商上门会产生额外费用。

大多数真实的升级会两者同时使用。一个 P1 故障一边横向交给专业团队，一边向上让经理知情并帮忙清除障碍。好的矩阵在页面上把这两条路径分开，让人看得出自己走的是哪一条。

升级矩阵应包含哪些字段？

不管用什么格式，每份矩阵都应记录相同的基本字段。

1. 优先级或严重等级，按你的 SLA 定义。如需帮助，请看我们的严重程度和优先级的区别指南。
2. 服务或系统，因为合适的专业团队取决于什么出了问题。
3. 层级编号，从第一线到最终层级。
4. 角色和姓名，每个角色都有指定的代理人。
5. 联系方式，按应尝试的顺序排列：电话、即时通讯、邮件。
6. 可联系的时段，以及时段之外的值班安排。
7. 本层级的时限，超过后工单自动上移。
8. 通知名单，工单到达本层级时必须通知谁。
9. 决策权，本层级无需请示就能决定什么。
10. 最近一次复核日期，以及文件的负责人。

升级矩阵模板

这是可复制、可填写的模板。方括号里的内容由你自己选定。不要把示例时间当成标准，要根据你自己的 SLA、人手和业务风险来设定。

第 1 部分：文件控制

1. 矩阵名称：[公司或服务名称] IT 升级矩阵。
2. 负责人：[角色，例如 IT 负责人或服务交付经理]。
3. 版本和日期：[版本号和日期]。
4. 复核周期：[例如每季度一次，以及每次重大事件之后]。
5. 适用范围：[所涵盖的服务、办公点或客户清单]。

第 2 部分：按优先级设定的时间触发条件

为每个优先级记录首次响应目标、第一次升级前的时限，以及下一次升级前的时限。使用你 SLA 里的目标。

P1，危急

1. 在 [分钟数，取自你的 SLA] 内首次响应。
2. 如果 [分钟数] 内未解决，升级到下一层级，并通知服务经理。
3. 如果 [分钟数] 内仍未解决，通知 IT 负责人和业务负责人。
4. 每隔 [分钟数] 向受影响用户更新一次，直到解决。

P2，高

1. 在 [分钟数，取自你的 SLA] 内首次响应。
2. 如果 [小时数] 内未解决，升级到下一层级。
3. 如果 [小时数] 内仍未解决，通知服务经理。
4. 每隔 [小时数] 向受影响用户更新一次。

P3，中

1. 在 [分钟数，取自你的 SLA] 内首次响应。
2. 如果 [工作日数] 内未解决，升级到下一层级。
3. 至少每 [工作日数] 向用户更新一次。

P4，低

1. 在 [分钟数，取自你的 SLA] 内首次响应。
2. 如果 [工作日数] 内未解决，在每周服务例会上复核。

第 3 部分：职能升级路径

为每个服务领域，按介入顺序列出相关人员。每个领域重复一个区块。

服务领域：[例如终端设备]

1. 第 1 级：[角色和姓名]，[联系方式]，[时段]。
2. 第 2 级：[角色和姓名]，[联系方式]，[时段]。
3. 第 3 级：[角色和姓名]，[联系方式]，[时段]。
4. 厂商或外部方：[公司、合同或案例编号、支持热线、支持级别]。

服务领域：[例如网络与安全]

1. 第 1 级：[角色和姓名]。
2. 第 2 级：[角色和姓名]。
3. 第 3 级：[角色和姓名]。
4. 厂商或外部方：[详情]。

服务领域：[例如业务应用]

1. 应用负责人：[角色和姓名]。
2. 技术负责人：[角色和姓名]。
3. 厂商支持：[详情]。

第 4 部分：层级升级路径

按职级从低到高，列出随着事件扩大必须被告知的人。

1. 团队主管：[角色和姓名]，在 [条件，例如任何 P1，或超时的 P2] 时被告知。
2. 服务交付经理：[角色和姓名]，在 [条件] 时被告知。
3. IT 负责人或技术总监：[角色和姓名]，在 [条件，例如 P1 超过第二个时限] 时被告知。
4. 受影响服务的业务负责人：[角色和姓名]，在 [条件，例如服务对客户不可用] 时被告知。
5. 高层赞助人：[角色和姓名]，在 [条件，例如发生数据丢失或安全事件，或停机带来法律或合同风险] 时被告知。

第 5 部分：与时间无关的自动触发条件

1. 疑似安全事件：立即通知 [安全负责人]，并按安全事件流程处理。
2. 确认的数据丢失或数据泄露：立即通知 [高层赞助人和数据保护联系人]。
3. 同一故障被 [人数] 名或以上用户报告：按重大事件处理，并启用重大事件经理。
4. 人身安全或场地的实体风险：先联系 [设施或紧急联系人]。

第 6 部分：非工作时间的安排

1. 服务时段：[例如 8×5 或 24×7，取自你的合同]。
2. 值班表：[存放在哪里、由谁更新、怎样确认交接]。
3. 非工作时间联系方式：[电话号码或呼叫工具，不能只用邮件]。
4. 哪些情况可以在非工作时间呼叫：[例如仅 P1 和 P2]。
5. 值班人员在 [分钟数] 内没有回应时的后备：[代理人，然后是经理]。

第 7 部分：沟通规则

1. 谁负责与受影响用户沟通：[角色]。
2. 谁负责与高层管理者沟通：[角色]。
3. 谁负责与客户或第三方沟通：[角色，需经谁批准]。
4. 更新渠道：[例如状态页、聊天频道或邮件列表]。
5. 更新格式：我们已知什么，我们正在做什么，下一次更新在何时。
6. 结案通知：写明已知的原因、采取的修复措施和后续事项。

第 8 部分：事件之后

1. 在工单中记录所有升级，并写明时间。
2. 在下一次服务例会上复核所有到达 [层级] 的事件。
3. 如果原因不明或反复出现，创建问题记录。
4. 如果联系人有误、时限不现实或缺了某个步骤，更新本矩阵。

一个使用虚构人名的实例

这个例子纯属虚构，只用来说明各部分如何衔接。

1. 09:02：服务台的 Sam 登记了一张工单：总部没有人能打开财务应用。Sam 按矩阵把优先级设为 P1，并按第 4 部分的要求通知团队主管 Priya。
2. 09:15：Sam 检查了基本项，发现用户端没有问题。按第 3 部分，该应用属于业务应用领域，于是 Sam 做职能升级，交给技术负责人 Dev，并附上一份列明已尝试步骤的交接记录。
3. 09:40：Dev 发现该应用的数据库服务器没有响应，便拨打第 3 部分列出的厂商支持热线。
4. 09:45：P1 的第一个时限到了。按第 4 部分，服务交付经理 Maria 被通知，Priya 向用户发出第一次更新。
5. 10:30：第二个时限到了。Maria 通知 IT 负责人和该应用的负责人、财务总监。财务总监决定批准厂商的紧急服务费，这个决定超出了 Dev 的权限。
6. 11:20：厂商恢复了服务。工单关闭，备注里记录了每一次升级及其时间。同时创建问题记录，追查原因。

注意矩阵在每一步的作用：Sam 不用猜该打给谁，Dev 不必等批准就能联系厂商，财务总监也及时得知问题并作出了决定。

怎样让升级矩阵一直有用？

写好后就再没人碰的矩阵是有害的，因为人们相信它，它却把人指向一个已经离职的人。用一套简短的例行做法保持它的有效。

1. 每季度复核一次，每次重大事件之后也复核。
2. 核对每一位联系人，复核时给每个人打电话或发消息。
3. 测试非工作时间的路径，做一次包含值班电话的计划内演练。
4. 只发布一份最新副本，放在即使主系统宕机，所有人员也能访问的地方。
5. 记录没有按矩阵执行的情况，并问为什么。原因通常是矩阵里有缺口。
6. 与你的服务商共享，并请他们提供他们的矩阵。

常见的错误有哪些？

1. 写人名而不写角色。人会换岗。用角色加指定的担任者，并配一名代理人。
2. 只有一种联系方式。给一个正在飞机上的人发邮件，什么也升级不了。
3. 没人能达到的时限。一个总是被错过的时限，只会教大家无视它。
4. 没有层级升级路径。技术团队横向升级，经理却是从用户那里才得知事件。
5. 没有降级的办法。要写明服务恢复后，矩阵怎样解除。
6. 矩阵只放在服务台工具里。如果出问题的恰恰是这个工具，就没人能读到它。

向管理型IT外包服务供应商了解升级时该问什么？

如果由服务商负责你的一部分 IT 支持，他们的升级矩阵就成为你的矩阵的一部分。签约前值得问的问题：

1. 我们能看到矩阵以及每个优先级的时限吗？
2. 我们自己的哪些人在其中，被呼叫时要做什么？
3. 服务商团队里，每个层级升级对应的经理是谁？
4. 非工作时间怎样联系服务商，什么情况算非工作时间升级？
5. 服务商什么时候向厂商升级，额外费用由谁授权？
6. 我们怎样在月度报告里看到升级记录？

博迅（Brocent）在 SLA 页面上公布了响应目标（我们在 2026 年 10 月 28 日核对）：P1 和 P2 首次响应 15 分钟，P3 为 30 分钟，P4 和 P5 为 60 分钟，适用于标准 8×5 或高级 24×7 服务时段，并以合同条款为准。我们的 P1 响应时间是公开的，管理型IT外包服务方案与按人头定价上也能看到。想了解各个优先级的含义，请读 IT 支持 SLA 里的 P1 到 P4 优先级，或看 24×7 服务台 IT 支持概述。想聊聊升级机制怎样适合你自己的团队，欢迎联系我们。

常见问题

什么是升级矩阵？

它是一份文件，规定事件什么时候必须升级、每一级由谁处理、每一级有多少时间、谁必须被告知，以及怎样联系到他们。

职能升级和层级升级有什么区别？

职能升级把工单交给技能更专业的人；层级升级则通知权限更高的人，让他们决策或帮助清除障碍。严重事件通常需要两者同时进行。

升级矩阵应该有几层？

IT 里常见的是三到五层：第一线、第二线、第三线或厂商，再加上管理层。层级太多会拖慢决策，太少则可能在工程师和高层之间留下空档。

应该用什么时限？

根据你自己的 SLA 和能力来定。任何模板里的数字，包括本文的，都只是占位。从你公布的响应目标出发，为每次交接加一点余量。

谁应该负责升级矩阵？

一个明确的角色，通常是服务交付经理或 IT 负责人，负责复核矩阵，并确保每个联系人都是最新的。

升级矩阵和值班表有什么不同？

值班表说明某个时间谁可以联系到。矩阵说明按什么顺序、什么时候介入哪些人。两者应相互引用。

安全事件需要单独的矩阵吗？

通常需要，至少要有单独的一部分，因为安全事件涉及不同的人，比如安全负责人和数据保护联系人，通知义务也不同。

矩阵可以做成表格吗？

可以，在电子表格或文档里它常常显示为网格。两种做法结构相同；本文用编号列表，是为了方便复制到任何工具中。

接下来读什么

优先级怎么定，请读严重程度和优先级的区别。矩阵所连接的技能层级，请看 L1、L2、L3 支持分级。当 P1 演变成大范围故障时，下一步是重大事件管理流程。如果你在考虑怎样在自己的团队和服务商之间划分责任，请看 SLA 与 OLA 的区别。

*2026 年 10 月 28 日核对的来源：Atlassian 事件管理指南“升级策略”一页（atlassian.com/incident-management/on-call/escalation-policies）；博迅 SLA 页面（brocent.com/sla）。*

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