L1、L2、L3 支持分级详解：各级做什么，工单怎么交接

先说结论： L1（一级、tier 1）支持是第一线：登记工单、判断问题，并解决常规问题。L2 处理需要更深技术工作或更大权限的问题。L3 是专家层，处理最难的故障，常常要和厂商或研发工程师一起工作。好的分级模型有明确的转入规则、书面的交接记录和规定的时限，所以工单能很快往上走，而不是在各级之间踢来踢去。

如果你提过 IT 工单，又看着它在几个人之间流转，每个人对同一份工作有不同叫法，那你就接触过分级支持。L1、L2、L3（或 tier 1、tier 2、tier 3）这些标签，是 IT 服务管理里最古老的概念之一，现在大多数服务台依然用它们来说明“谁做什么”。标签很简单，做法却不简单，因为真正的工作在交接上：每一级在升级之前承诺做什么，又把什么交给下一级？

本文说明每一级做什么，工单怎样从一级转到下一级，以及把部分 IT 支持外包的企业，通常怎样在自己与服务商之间划分各级。凡是讲通行模型的地方，我们都引用公开来源并注明阅读日期。凡是讲“应该向服务商问什么”的地方，我们也会说明，因为各家服务商的人员分级方式不同，我们不能替别人下断言。

L1、L2、L3 在 IT 支持里是什么意思？

它们是三个技术深度的层级。用户的问题从能合理解决它的最低一级进入，只有当这一级解决不了时才往上转。

维基百科的“Technical support”条目（我们在 2026 年 10 月 28 日读过）这样描述三级模型：Tier I（一级，简称 T1 或 L1）是第一技术支持层，首要工作是收集客户信息并找出根本问题。Tier II（二级）比一级更深入，成本也更高，因为技术人员经验更丰富。Tier III（三级）是三级模型里最高的一层，负责最困难或最高阶的问题，由领域专家组成，支持低层级，并为新问题或未解决的问题开发解决办法。

不同组织对同样的层级用不同的名字。你还会看到“第一线、第二线、第三线”，“前线、后端、专家”，或者“服务台、桌面支持、工程”。名字不重要，重要的是层级之间如何转移的规则。

有些组织会在两端再加层：

1. 0 级（自助服务）：知识库、密码重置门户、自动助手。用户不用人工就能解决常规问题。
2. 4 级（厂商或产品研发）：软硬件厂商，或内部开发团队，他们能修改产品本身。

L1 支持做什么？

L1 是前门。它是用户接触到的第一个人或第一个系统，工作重在广度，而不是深度。

L1 的典型职责：

1. 接收并登记每一次联系，无论电话、邮件、聊天还是门户，使每一次联系都变成一张有编号的工单。
2. 识别用户和受影响的服务，并用用户自己的话记录现象，附上报错信息或截图。
3. 设置优先级，按约定的影响度和紧急度规则来做。想了解具体做法，可以读我们的文章：严重程度和优先级的区别。
4. 按脚本或知识库文章解决已知的常规问题：密码重置和账号解锁、邮箱和打印机问题、基本的连通性检查、标准软件安装，以及操作咨询。
5. 查看问题是否已知，比如一个正在进行的故障，这样重复工单就能关联起来，而不是各自处理。
6. 按约定的间隔向用户通报进展。
7. 在问题超出 L1 范围或时限时，带着一份好的交接记录升级。

L1 最重要的能力不是很深的技术知识，而是诊断和沟通：问对问题，识别模式，写出下一个人不必再回访用户就能接手的工单。

L2 支持做什么？

L2 接手 L1 关不掉的工单。它有更深的技术知识、更大的权限，每张工单也有更多时间。

L2 的典型职责：

1. 先看 L1 的记录，这样就不会让用户回答两遍同样的问题。
2. 排查超出脚本的问题：服务器和网络问题、应用故障、组策略和设备管理问题、权限问题，以及需要远程访问用户设备或后端系统的问题。
3. 在批准的范围内做变更，例如已有标准变更涵盖的配置修改。
4. 处理上门或需要动手的工作，远程办法不够时调派现场工程师。
5. 跨工单识别模式，当多起事件有共同原因时，创建问题记录。
6. 更新知识库，让 L2 今天学到的东西，明天变成 L1 的解决办法。
7. 当故障需要深入的产品、架构或代码知识时，升级到 L3。

维基百科的描述还提到，L2 同时负责协助 L1 人员处理基本技术问题，所以很多团队会在两级之间开一个简短的“求助”渠道。

L3 支持做什么？

L3 是专家层。这些工程师、架构师或专家深入了解某个平台，被期望去解决在该环境中还没人解决过的问题。

L3 的典型职责：

1. 分析复杂、反复发生或高影响事件的根本原因。
2. 设计并实施修复，这类修复需要改动架构、代码、集成或安全控制。
3. 与厂商和制造商合作，包括在厂商提供的最高支持层级开立并跟进案例。
4. 为 L1 和 L2 提供建议，并为没有已知解决办法的问题制定新的操作流程。
5. 作为技术负责人参与重大事件。这一流程的做法，请看我们的重大事件管理指南。
6. 把经验反馈到知识库和变更计划中，避免明年又重新发现同一个故障。

L3 的时间是模型里最贵的时间。所以健康的分级体系要保证 L3 腾得出手，去做只有 L3 才能做的事。

工单怎样从一级交接到下一级？

分级支持的大多数失败，都是交接的失败。一张带着“用户登录不了，请查看”这一句备注到达 L2 的工单，已经丢掉了 L1 做过的工作。好的交接遵循固定的格式。

每一份升级记录都应包含：

1. 谁受影响：用户、所在地点和设备，以及还有多少人受影响。
2. 现象是什么：用户的原话、准确的报错文字和开始时间。
3. 已经试过什么：每一步及其结果，避免有人重复。
4. 优先级是多少、为什么：所选的影响度和紧急度。
5. 需要下一级做什么：一个具体的问题或动作，而不是笼统的“请看看”。
6. 用户那边进展到哪里：已经告诉用户什么，下一次更新应在何时。

让工单保持流动的交接规则：

1. 按能力升级：问题不在 L1 脚本或知识库里，就升级，不要猜。
2. 按时间升级：为每个优先级设定时限，超时未解决的工单自动上移。P1 可能只有几分钟，P4 可能有几天。
3. 按风险升级：一旦出现安全事件、数据丢失或更大范围故障的迹象，不管时限，立即上报。
4. 工单责任人始终可见：工单任何时候都在某个明确的人或团队名下，用户始终有一个联系人。
5. 允许退回：如果 L2 发现这是用户权限或流程问题，可以带着备注退回 L1，知识库就是这样长大的。

时限来自 SLA。博迅（Brocent）在 SLA 页面上按优先级公布响应目标（我们在 2026 年 10 月 28 日核对）：P1 和 P2 首次响应为 15 分钟，P3 为 30 分钟，P4 和 P5 为 60 分钟。这是在标准 8×5 或高级 24×7 服务时段下的首次响应目标，页面也注明以合同条款为准。想用大白话了解各个级别，请读 IT 支持 SLA 里的 P1 到 P4 优先级。我们的 P1 响应时间是公开的，在管理型IT外包服务方案与按人头定价上也能看到。

以上规则讲的是在各级之间向上转。至于 L3 之后的联系人、时限和通知步骤，比如 P1 超过一定时间未解决时通知谁，请读配套的 IT 升级矩阵模板。

外包时怎样划分 L1、L2、L3？

外包不必是“全有或全无”。企业通常在几种常见的划分里选一种，哪种合适，取决于你自己保留多少 IT 知识。

方案一：只外包 L1

1. 服务商负责：登记、分流、常规修复，以及向你的内部团队升级。
2. 你的团队负责：L2 和 L3，也就是它最熟悉的系统。
3. 适合：有能干的内部 IT 团队、但花了太多时间在重置密码和操作咨询上的公司。
4. 留意：交接记录写得差，以及内部团队被本该由 L1 解决的升级打断。

方案二：外包 L1 和 L2，L3 留在内部或交给厂商

1. 服务商负责：整个服务台，以及它背后的桌面、网络和服务器工作。
2. 你的团队负责：架构决策、业务应用和厂商关系。
3. 适合：希望把日常 IT 交出去，但保留一个小团队或一位技术负责人的公司。
4. 留意：谁可以改什么的边界不清，以及服务商不熟悉的应用交接缓慢。

方案三：标准环境的 L1 到 L3 全部外包

1. 服务商负责：它所管理的基础设施和工具的全部三级，包括向厂商升级。
2. 你的团队负责：业务专用的应用，以及与服务商的关系。
3. 适合：没有内部 IT 人员的组织。
4. 留意：约定范围之外的应用，应在合同里点名，免得掉在双方之间。

无论选哪种，都要写下这些

1. 一页范围清单，列出系统和服务，以及每一项在哪一级由哪一方负责。
2. 各级可用的时段，因为 24×7 的服务台，其 L2 和 L3 可能只是随叫随到。
3. 双向的升级路径，包括你方对接服务商 L3 的联系人。
4. 谁可以做变更，谁必须批准。
5. 你将收到的报告：各级的工单数、解决时间、L1 解决的数量，以及在各级之间来回的数量。

想了解服务商的服务台如何全天候运作，可以看我们的 24×7 服务台 IT 支持概述。如果想一起讨论哪种划分适合你，欢迎联系我们。

哪一级处理哪一类工单？

下面的例子仅为示意，真正的边界由你自己的范围清单决定，但它们能说明各级在实际中的差别。

1. 用户忘了密码：L1，按重置流程，一次联系解决。
2. 某个办公点的一台笔记本连不上 Wi-Fi：L1 检查基本项和用户设置；如果问题出在接入点、网络策略或设备配置上，则由 L2 接手。
3. 整个团队的共享邮箱权限不对：L2，因为需要管理员权限，并理解组是怎样设置的。
4. 厂商更新后业务应用出错：L2 收集日志并测试，如果原因在产品里，L3 与厂商一起处理。
5. 几个办公点的云服务中断一小时：L1 把工单关联起来并通知用户；L2 和 L3 作为技术负责人加入，由重大事件流程接管。
6. 为新员工申请笔记本和账号：这是服务请求，不是故障，由 L1 或 L2 按入职流程处理。

如果大多数被升级的工单都落到同一两个人手里，应当把它看作 L2 人手不足的信号，而不是这几个人表现好的证明。

怎么衡量分级是否有效？

四个指标就能说明大部分情况，都不需要特殊工具。

1. 首次联系解决率：在首次联系中就得到解决的工单比例，无论由哪一级解决。数值低，说明 L1 缺脚本、缺权限或缺培训。计算方法见我们的首次呼叫解决率指南。
2. 各级升级率：往上转的工单比例。L1 到 L2 的比例很高，说明 L1 把本该自己做的活传了出去；比例很低，则可能是 L1 把工单扣得太久。
3. 各级解决时间：工单在每一级停留的时间。延误常常藏在交接点上，而不是某一级内部。
4. 重开和回弹率：退回前一级或关闭后又被重开的工单。它们反映交接记录薄弱，或修复没有真正生效。相关指标请看 MTTR、MTBF 和 MTTA。

每月复盘一次，每次问同一个问题：如果 L1 有更好的文章、更多的权限或更清楚的规则，哪些工单本来可以由它解决？

分级支持常见的错误有哪些？

1. 升级太晚，因为 L1 怕“失败”。时限和风险触发条件可以让这个判断不再靠个人。
2. 升级太早，因为 L1 没有权限或脚本。表现为简单故障的升级率偏高。
3. 只把 L1 当作呼叫中心。L1 还应负责知识库文章，并发现规律。
4. 让 L3 拿不到背景。L3 应当了解规律和计划，而不是只在出紧急情况时才被叫到。
5. 让用户重复描述。每一个重复的问题，都说明交接上有缺口。
6. 让一个“英雄”扛下一切。如果有一个人是非正式的 L2 和 L3，这套模型就存在单点故障。

常见问题

什么是 L1 支持？

L1，即一级或 tier 1 支持，是 IT 支持的第一线。它登记工单、判断问题、按脚本和知识库文章解决常规问题，并把解决不了的问题升级。

L1、L2、L3 有什么区别？

区别在于深度。L1 处理常规问题和分流，L2 处理需要更深技术工作或更大权限的问题，L3 则与专家和厂商一起处理最复杂的故障。

tier 1 和 level 1 是一回事吗？

是。tier 1、level 1、T1、L1 和“第一线”说的都是同一个第一层。各组织用词不同，请以你自己文件里的定义为准。

小公司需要三级都有吗？

不一定要作为三个独立的团队。小型 IT 团队可以身兼数级。重要的是任务、交接和时限有定义，即使同一个人做不止一级。

哪些可以外包？

任何一级都可以。很多公司先外包 L1，等交接顺畅后再加上 L2。合同里应写明哪一级的哪些系统由谁负责。

升级和 SLA 有什么关系？

SLA 为每个优先级设定响应和解决目标，升级规则把这些目标当作触发条件。如果一张工单快要违反目标，就往上转。

升级工单和转派工单有什么区别？

升级是因为当前层级解决不了，把工单转给能力更强或级别更高的一级；转派是平级地转给负责该系统的团队。好的记录会把两者分开。

接下来读什么

先看优先级是怎么设定的：严重程度和优先级的区别，再看 IT 升级矩阵模板了解联系人和时限。合同措辞方面，请看 IT 支持里的 SLA 是什么意思。

*2026 年 10 月 28 日核对的来源：维基百科“Technical support”条目（en.wikipedia.org/wiki/Technical_support）；博迅 SLA 页面（brocent.com/sla）。*

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