SLA、OLA与UC的区别：三种协议各管什么

Q: 在哪里可以看到博迅的目标是怎么设定的？

在SLA页面，里面列出了P1至P5的目标和两种服务时段。如果想把你现有的协议与它对照，欢迎联系我们。 想把这些指标写进合同，而不是停留在 PPT 上？ 博迅的管理型IT外包服务方案把 SLA 和按人头的月费并排公开，覆盖香港、新加坡、中国大陆和美国。查看方案与定价，或联系顾问。

一句话版本： SLA是服务商对客户的承诺。OLA（运营级别协议）是服务商内部各团队之间的承诺，让SLA有可能兑现。UC（支撑合同）是与外部供应商签的合同，作用相同。SLA里的每一项目标，背后都应有一份速度不慢于它的OLA或UC。

向服务商购买IT支持时，你签的是这三份协议中的一份：SLA。另外两份藏在它的背后，看不到，却决定了SLA上的数字是否现实。本文说明三者各是什么、各方是谁、怎样层层叠加，以及当你的IT支持是外包时，这幅图意味着什么。

外部定义我们在2026年10月28日查阅过：维基百科“Service-level agreement”词条、“Operational-level agreement”词条和“Service-level objective”词条（均于2026-10-28查证）。“支撑合同”（underpinning contract）是ITIL的术语，我们当天没有取得ITIL术语表的原文，因此下文对UC的说明是我们自己的白话解读，不是引文。博迅（Brocent）的数字取自我们公开的SLA页面。

SLA、OLA和UC有什么区别？

最简单的区分方法，是问每一份由谁来签。

SLA（服务级别协议）： 服务商与客户之间。它用客户关心的语言写明客户可以期待什么：响应、解决、服务时段、可用性、汇报。
OLA（运营级别协议）： 同一家服务商内部的团队之间，例如服务台与网络工程团队。它写明一个团队对另一个团队承诺做什么、多快做到，好让服务商守住SLA。
UC（支撑合同）： 服务商与外部供应商之间，例如运营商、软件厂商或硬件维保公司。它写明供应商对服务商承诺做什么、多快做到，目的同样是支撑SLA。

三者不是互相替代的选项，而是同一条链上的不同层，客户只看得到最上面一层。

SLA是什么，是写给谁的？

维基百科“Service-level agreement”词条（2026-10-28查证）把SLA描述为服务商与客户之间的协议，通常是有约束力的合同，规定服务的某些方面，如服务质量、可用性和责任。词条还提到，SLA通常包含服务级别目标，也就是针对正常运行时间、首次呼叫解决率等指标的可衡量目标。

SLA是写给客户看的。它回答的是“多快会有人接听？”“什么时候能修好？”“修不好我能得到什么？”。我们的IT支持中的SLA是什么详细介绍了其内容，P1至P4优先级指南说明优先级如何决定目标。

同一词条也提到，大型机构内部同样会签SLA，由一个部门做客户、另一个部门做服务方。这种用法是成立的，但容易与OLA混淆，所以下文把SLA专指面向客户的协议，把OLA专指服务商的内部协议。

OLA是什么？

维基百科“Operational-level agreement”词条（2026-10-28查证）把运营级别协议描述为：规定支撑SLA的各方相互依赖的关系。它写明每个内部支持小组对其他小组的职责，包括交付服务的流程和时限。同一词条还指出，OLA不能代替SLA，它的目的是让多个支持团队所做的支撑工作对齐，以交付约定的SLA。

在实践中，OLA回答的是客户从不过问、却总能感受到的问题：

交接： 服务台修不好工单时，下一个团队必须多快接手？
信息： 工单转出去之前必须写明什么，才能让下一位工程师不必从头开始？
时段： 哪个团队负责哪些时段，夜间谁待命？
升级： 眼看要错过期限时，谁会被呼叫？

没有这些答案，SLA的目标就只是一个希望。词条里还有一个相关的观点：如果支撑的OLA没有事先建立，事后再回头在各支持团队之间补出协议，往往非常困难。我们的L1、L2、L3支持级别和升级矩阵两篇文章，介绍了OLA通常要固化的交接和联系人。

这个名称还有几种变体：organizational-level、operating-level和operations-level agreement。词条说它们含义相同。

支撑合同（UC）是什么？

在ITIL术语里，支撑合同是服务商与外部供应商之间的合同，目的是让供应商的表现支撑服务商对客户作出的承诺。（这是我们的解读，参见上文关于来源的说明。）供应商可能是：

互联网或专线运营商，
提供授权和支持的软件厂商，
提供备件的硬件维保公司，
数据中心或云平台的营运方。

UC是带商业条款的真实合同，所以里面往往也有它自己的SLA。区别在于双方是谁：SLA的一方是最终客户；UC里服务商是客户，外部公司是供应商。

三者怎样配合？

从客户往下画出这条链：

客户与服务商之间有SLA。
服务商的服务台与其工程团队之间有OLA。
服务商与外部供应商之间有UC。

每一层都必须不慢于上一层的承诺。如果SLA写明严重事件20分钟内首次响应，那么负责首次响应的团队的OLA就必须让20分钟是可以做到的。如果SLA写明运营商故障一小时内升级，那么与运营商之间的UC就必须给服务商一条以这个速度联系到对方故障台的途径。

检验的简单办法是做一份时间预算。取一项SLA目标，把其中包含的每一步列出来。以首次响应目标为例，步骤有：

工单到达，由系统登记。
服务台接起并判定优先级。
向客户发出确认。

这三步合计允许的时间，必须落在SLA的数字之内。举例说明（数字为演示算术而虚构，并非博迅的数字）：如果SLA承诺20分钟首次响应，而内部协议允许服务台用30分钟接起严重工单，那么无论大家多努力，SLA都无法达成。算术先于人出了问题。

外包IT支持时，这幅图是什么样子？

外包给这幅图增加了两样东西，签约前都值得问一问。

你自己的人也在链条里

外包工程师在不知道账号归谁解锁时，没法处理账号锁定；没有你的人事联系人批准，也没法给新员工开通权限。这些都是客户一侧的依赖。好的协议会把它们列为客户责任并附上时限，例如谁批准权限申请、多快批准。有的团队会把这部分写成IT、人事和行政之间的简短内部协议，它在你这一侧起的就是OLA的作用。如果客户这边的审批人响应慢，服务商的计时就应当如实说明，写得好的暂停计时条款就能做到。

服务商的供应商也很重要

对于自己无法控制的部分，服务商的SLA最多只能和它的UC一样强。问一问服务商怎样处理运营商线路故障、软件厂商平台故障或备件缺货。诚实的答案通常是“我们会在SLA内响应并向供应商升级，并持续向您通报，但供应商的修复时间不在我们控制范围内”。写下来、并附上通报频率，这是公道的回答。如果SLA对服务商根本修不了的东西也承诺了解决时间，那就有问题。

还要问服务商的目标与供应商的目标是否“背靠背”。如果服务商承诺专线四小时修复，而它与运营商的合同允许24小时，那么这份风险要么体现为未达标，要么藏在免责条款的限制里。

一个例子：办公室断网

这是演示用的场景，不是真实客户。某小型办公室在工作日上午断网。

用户报告断网。办公室与IT服务商之间的SLA写明，影响业务的故障要在规定的分钟数内首次响应。
服务台登记工单，确认原因在楼外，并按OLA转给网络团队，OLA规定网络团队须多快接手。
网络团队依据UC联系运营商的故障台，UC规定了运营商的响应与修复时间。
服务商按约定间隔向客户通报，直到运营商修好线路，然后关闭工单并记录根因。

如果客户问“是谁慢了？”，分层的协议让答案很清楚。第一次回复慢，是服务商的SLA问题；服务商内部交接慢，是OLA问题；运营商修复慢，是服务商要替客户去管理的UC问题。没有这些层次，答案就变成“大家都有份，又都没有责任”。

对影响全公司的事件，请看我们关于重大事件管理流程的文章，其中讲了沟通和角色。

SLA与SLO、KPI、合同有什么区别？

这些术语有重叠，简短对比一下。

SLA与SLO： SLO是SLA里一个可衡量的目标。维基百科“Service-level objective”词条（2026-10-28查证）指出，SLA是规定提供什么服务、如何支持、时间、地点、费用、表现和各方责任的整份协议，而SLO是它具体的、可衡量的特征。
SLA与KPI： KPI是团队用来跟踪自身表现的任何指标。SLA目标则是服务商向客户承诺过的KPI。
SLA与合同： SLA通常是合同里的附件。合同管价格、期限、责任和终止。
OLA与SLA： OLA是内部的，用来支撑SLA，不能代替SLA。

如果你想了解SLA和OLA通常用哪些指标来衡量，请看我们的MTTR、MTBF与MTTA解读和首次呼叫解决率。

买方和服务商常犯哪些错误？

把SLA当成全部。 单看SLA似乎很完整，但可靠与否，取决于它背后的OLA和UC。
对第三方故障承诺解决时间。 服务商可以承诺对供应商的故障响应并升级。自己无法控制的修复时间，应该放进免责条款，并配上通报规则。
OLA定得比SLA还慢。 算术先行崩溃，而被责备的是台前的人。
交接没有负责人。 两个团队都以为对方在处理工单，时钟在走，却没人干活。OLA应写明由谁在何时之前接手。
漏掉客户一侧的延误。 如果客户的审批人不在图里，服务商在等回复时计时仍在走。公平的协议会明确处理这一点。
从不复审。 团队会变、供应商会变，两年前定的目标可能已经不合适。SLA变更时就应复审OLA和UC。
把内部SLA和OLA混为一谈。 如果贵公司在各部门之间签有内部SLA，就按它本来的名字叫，但不要指望它代替服务商自己的OLA。

应该向服务商问哪些OLA和UC的问题？

你不需要看服务商的内部文件，但可以问这些关于结果的问题：

SLA里哪些目标依赖外部供应商，这些故障怎么处理？
工单在各支持级别之间如何转交，接手的最长时限是多少？
非工作时间谁待命，严重工单怎样找到他们？
交接环节怎么计量，会不会出现在发给我的报告里？
供应商慢的时候你们怎么做？有没有带具名联系人的升级路径？
客户一侧的哪些事项会暂停计时，暂停时你们怎么告诉我？
支撑我这份SLA的内部协议和供应商合同，多久复审一次？

能清楚回答这些问题的服务商，多半认真想过SLA背后的这条链。

博迅怎样展示自己的SLA？

我们的SLA与服务优先级页面公布的是面向客户的协议：五个优先级（P1至P5），每级的首次响应、远程支持、上门和解决目标，两种服务时段（8x5和24×7），以及影响度乘紧急度矩阵。截至2026年10月28日，表中P1和P2的首次响应为15分钟，解决目标为P1 8个工作小时、P2 24个工作小时。页面同时注明，数字取决于服务时段和合同条款。

该页面讲的是SLA。我们团队之间的内部协议和供应商合同，不在我们公布的范围之内。你可以要求的，也是每位客户都应该要求的，是SLA确实在被计量的证据：一份对照各项目标的实际表现月报。我们的管理型IT外包服务方案和24×7服务台支持说明服务如何交付，管理型IT外包服务方案与按人头定价则把公布的响应承诺与各档套餐价格放在一起。