服务级别协议（SLA）是服务提供方与服务使用方就服务范围、可用性、响应与解决时限、统计口径及未达标处理作出的书面约定，核心是可测量的承诺指标。本文依次说明它的定义、范围边界、计时与达标率统计方法，并区分它与工单优先级、缺陷严重程度等相邻概念。
要点总览（TL;DR）
- 服务级别协议（SLA）是服务提供方与服务使用方就服务范围、可用性、响应与解决时限、统计口径及未达标处理作出的书面约定，核心是可测量的承诺指标。
- SLA 约定服务范围、指标与时限、统计口径和未达标处理；缺陷严重程度分级与人员派单路由属于相邻管理动作，不写进协议条款。
- 时限要写清起算点、暂停条件和统计周期，达标率按周期用达标工单数除以纳入统计的工单总数计算，单张工单按时完成不代表整类服务达标。
- 工单优先级回答先处理哪一张，缺陷严重程度回答质量影响有多大，派单路由回答由谁处理，SLA 为它们提供可考核的目标值。
- 承诺时限要依据服务重要程度、历史数据和支撑能力设定档位，过短的承诺会拉低达标率，削弱协议可信度。
服务级别协议的直接定义
服务级别协议，英文全称 Service Level Agreement，缩写为 SLA。它是服务提供方与服务使用方之间签署的一份书面约定，用来明确前者向后者提供什么服务、服务需要达到什么水平，以及水平未达到时如何处理。协议双方可以是两家企业，也可以是同一组织内的业务部门与 IT 服务部门。
这份约定通常覆盖四类对象：服务范围，即哪些系统、哪些类型的请求纳入协议；可用性指标，即服务在约定周期内可正常使用的时间比例；响应与解决时限，即从请求进入到给出回应、再到问题关闭分别允许用多长时间；衡量口径，即上述指标按什么数据、什么周期、什么公式计算。四类对象共同构成“可测量、可追溯”的承诺基础。
把它写成书面形式并配套统计口径，是 SLA 区别于口头服务态度的关键。一份可用的 SLA 应当让双方在事后能够拿出同一组数据，对“是否达标”得出相同结论。缺少统计口径的时限描述，只是愿望，无法作为履约依据。
SLA 包括什么、不包括什么
SLA 管的是“服务承诺的水平与核算方式”，它不负责回答某张工单该由谁处理、先处理哪一张。把这两类内容分开，可以避免把流程规则塞进协议，也避免协议条款被日常操作细节稀释。
| 范围 | 内容 | 说明 |
|---|---|---|
| 属于 SLA | 服务范围与服务对象 | 明确哪些服务、哪些用户群体纳入协议 |
| 属于 SLA | 指标与时限 | 可用性、响应时间、解决时间的具体数值 |
| 属于 SLA | 统计口径 | 计时起点、暂停条件、统计周期、达标率公式 |
| 属于 SLA | 未达标处理 | 服务 credits、整改要求、复盘机制等约定 |
| 不属于 SLA | 缺陷严重程度分级 | 属于缺陷分类与分级，回答质量问题的影响程度 |
| 不属于 SLA | 人员派单与路由规则 | 属于工单分派与路由，回答由谁接手、如何流转 |
还需要区分两个层次。单张工单上的处理承诺，例如“本工单将在 4 小时内首次回复”，是操作层的时限标记；SLA 是协议层的整体承诺，通常按周期统计一类工单的达标情况。二者可以衔接，但不能互相替代：一张工单按时回复，不代表整类服务的达标率合格。
在组织内部，还常见运营级别协议（OLA，Operational Level Agreement）的概念。OLA 是内部团队之间为支撑对外 SLA 而设定的内部目标，例如二线团队承诺在 2 小时内接手一线升级的问题。层次关系是：对外 SLA 决定承诺水平，内部 OLA 把承诺拆解到各支撑团队，二者口径需要对齐，否则对外承诺缺少内部支撑。
SLA 的组成与计时机制
理解 SLA 的关键在于计时。同样的“4 小时解决”，起算点不同、暂停规则不同，实际考核结果会相差很大。下表列出常见要素及其需要写清的口径。
| 要素 | 需要约定的内容 | 常见口径差异 |
|---|---|---|
| 服务范围 | 纳入协议的服务、系统与用户群体 | 按服务目录划分，或按请求类型划分 |
| 可用性 | 统计周期内可正常使用的时间占比 | 按月或按季度统计，计划维护是否计入 |
| 响应时间 | 从请求进入到首次有效回应的时间 | 自动回复是否算有效回应 |
| 解决时间 | 从请求进入到问题关闭的时间 | 关闭以用户确认为准还是以处理方标记为准 |
| 计时起点 | 时限从哪一刻开始计算 | 提交时刻、受理时刻、双方确认时刻 |
| 暂停条件 | 哪些等待期间不计入时限 | 等待客户补充信息、等待第三方厂商 |
| 统计周期 | 达标率按多长时间汇总 | 按月、按季度，或按滚动窗口 |
| 未达标处理 | 未达标时的补救与复盘约定 | 服务抵扣、整改计划、联合复盘 |
一条时限从起算到统计，通常经过以下环节：请求提交后，系统记录提交时间；服务台受理并确认请求有效，此时按约定口径决定是否从受理时刻重新起算；处理过程中若进入等待客户回复或等待第三方的状态，按暂停规则挂起计时；问题解决并关闭后，记录结束时间；统计周期结束时，用达标工单数除以纳入统计的工单总数，得到该类服务的达标率。每个环节都需要在工单上留下可核对的时间字段，否则统计无法复现。
这套机制落到工具上，依赖工单状态流转与时间字段的规范配置。在 ONES Desk 中，团队可以自定义工单属性与工作流，把受理、等待、解决等状态和对应时间记录下来，并通过工单分析报表汇总处理情况、把控进度；当工单涉及研发侧问题时，还可一键关联到 ONES Project 的需求或缺陷工作项持续跟踪。需要说明的是，具体时限字段如何命名、暂停如何触发、达标率报表按什么口径输出，属于实施时需要结合自身协议逐项确认的配置项，应以实际产品能力核验为准。
SLA 与优先级、缺陷严重程度的区别
这几个概念经常被混用，原因是它们都会影响“多快处理”。但它们回答的是不同问题，归属不同的管理动作，配合使用才能形成完整规则。
| 概念 | 回答的问题 | 归属主题 | 与 SLA 的衔接点 |
|---|---|---|---|
| 工单优先级 | 先处理哪一张 | 工单优先级管理 | 高优先级工单通常对应更短的响应与解决时限 |
| 缺陷严重程度 | 质量问题的影响有多大 | 缺陷分类与分级 | 严重程度可作为设定时限档位的输入之一 |
| 派单与路由 | 由谁处理、流向哪个团队 | 工单分派与路由 | 路由决定责任团队，SLA 考核该团队的服务水平 |
| SLA | 承诺在多长时间内达到什么水平 | 服务级别管理 | 为上述规则提供可考核的目标值 |
三者的常见组合方式是：缺陷严重程度描述影响，优先级据此和业务影响确定处理顺序，路由把工单送到具备处理能力的团队，SLA 则为不同优先级设定对应的时限档位并统计达标情况。冲突也常出现，例如一张低优先级工单因等待客户回复而临近超时，此时应按暂停规则处理，而不是临时抬高优先级来“救火”；反过来，若高优先级工单频繁超出时限，应回看时限档位设定是否合理、路由是否顺畅，而不是简单取消优先级区分。
一个具体例子与常见误解
以下为演示性示例，用于说明计时过程，不代表任何真实客户案例。某企业的 IT 服务台与业务部门约定：办公软件类服务请求，响应时限 2 工作小时，解决时限 1 个工作日，计时从服务台受理时刻起算，等待用户补充信息期间暂停计时，按月统计达标率，未达标时由服务台提交整改说明。
周一上午 9:30，员工提交一条“邮件客户端无法登录”的请求。9:45 服务台受理并确认属于协议范围，计时开始。10:20 处理人员回复排查步骤，响应完成，用时 35 分钟，在 2 小时时限内。随后处理人员请员工提供报错截图，工单进入等待状态，计时暂停。员工在下午 14:00 回复，计时恢复。15:10 问题解决并关闭，解决环节累计用时约 1 小时 25 分钟，在 1 个工作日时限内。月末统计时，该类请求共 120 张，其中 114 张在时限内完成，达标率为 95%。这个例子说明：响应与解决分别计时，暂停期间不计入，达标率按周期汇总而非看单张工单。
围绕 SLA 有四条常见误解需要纠正。
误解一：SLA 等于工单优先级。优先级决定处理顺序，SLA 决定承诺时限与考核口径。一张工单可以优先级不高但仍在 SLA 时限内，也可以优先级很高却因路由不畅而超时，两者不能互相替代。
误解二：SLA 承诺越短越好。时限越短，对人员和流程的要求越高，未达标风险也越大。合理的做法是依据服务的重要程度、历史处理数据和支撑能力设定档位，并保留调整机制。承诺短于实际能力，会让达标率长期偏低，反而削弱协议的可信度。
误解三：SLA 只用于对外客户。内部 IT 服务台、共享服务中心同样需要与业务部门约定服务水平，内部协议与 OLA 配合，可以把对外承诺拆解到各支撑团队。对外和对内只是协议双方不同，方法一致。
误解四：达成率按平均值统计即可。平均值会掩盖分布，少量严重超时的工单可能被大量快速完成的工单稀释。更稳妥的口径是按周期统计达标工单占比，并单独列出超时工单及其原因，让统计结果既能反映整体水平，也能定位需要改进的环节。
常见问题
SLA 的时限从提交时刻起算还是从受理时刻起算，两种口径有什么实际差别？
两种口径都常见，差别在于由谁承担等待确认的时间。从提交时刻起算，用户提交后到服务台受理之间的排队时间计入时限，对服务方的响应速度要求更高；从受理时刻起算，服务台确认请求有效后才开始计时，排队时间不计入。选择哪种口径取决于服务台的人力安排和请求量的波动情况，关键是写进协议并在工单上留下对应的时间字段，让统计可以复现。同一份协议内不同服务类型可以采用不同起算点，但需要逐类写明。
等待客户回复期间暂停计时，会不会被用来人为压低超时数量？
暂停规则本身是合理的，因为等待客户补充信息的时间不受服务方控制。风险在于暂停的触发和恢复缺少记录。可执行的做法是：工单进入等待状态时记录暂停时间与原因，客户回复后记录恢复时间，暂停时长单独统计并纳入月度复盘。若某类工单的暂停时长占比明显偏高，应检查是否在请求提交环节缺少必要信息，从源头减少往返，而不是收紧暂停规则。
内部服务台与业务部门之间的约定，算不算 SLA？
算。SLA 的双方可以是两家企业，也可以是同一组织内的业务部门与 IT 服务部门，方法一致，只是协议双方不同。内部场景中常配合运营级别协议（OLA）使用：对外 SLA 决定承诺水平，OLA 把承诺拆解到各支撑团队，例如二线团队承诺在约定时间内接手一线升级的问题。两层口径需要对齐，否则对外承诺缺少内部支撑。
SLA 达标率长期偏低时，应该先调整时限还是先改流程？
先定位超时集中在哪个环节。若超时主要发生在路由之后、处理之前，说明分派规则或团队负载有问题，调整时限只会掩盖瓶颈；若超时分散在各环节且处理时长普遍接近上限，说明时限档位设定偏紧，可依据历史处理数据适度放宽并保留调整机制。无论哪种情况，都应把超时工单单独列出并标注原因，让统计结果既能反映整体水平，也能指向具体改进点。
用 ONES Desk 管理工单时，SLA 的时限与达标率能直接配置出来吗？
ONES Desk 支持自定义工单属性与工作流，可把受理、等待、解决等状态和对应时间记录下来，并提供工单分析报表汇总处理情况、把控进度；工单涉及研发侧问题时还可一键关联到 ONES Project 的需求或缺陷工作项持续跟踪。至于按服务类型设定响应与解决时限、自动计时与暂停、达标率指标口径这些 SLA 专用配置，需要结合自身协议在实施时逐项确认，以实际产品能力核验为准。
