SLA、OLA、UC有什么区别？一文讲清三种服务协议如何配合

SLA、OLA和UC是ITIL流程中三种相互关联的服务协议：SLA（服务水平协议）是IT部门对业务用户的承诺，OLA（运营水平协议）是IT内部不同团队之间的承诺，UC（支持合同，Underpinning Contract）则是IT与外部供应商之间的承诺。 三者像一条"承诺链"：用户得到的服务质量，取决于内部团队的配合，也取决于外部供应商的支持。只定SLA而不管OLA和UC，承诺很可能在内部或供应商环节断裂。

不少团队只关注SLA，却没有想过：如果承诺"两小时恢复"，而负责网络的内部团队没有相应的响应要求，或者运营商的维修时限是八小时，这个SLA就是一句空话。本文梳理三者的区别、关系，以及在 ITSM系统 与 工单系统 中如何落地。

一、三种协议的核心区别

可以用一个简单的比喻理解：SLA是餐厅对顾客的承诺"二十分钟内上菜"；OLA是前厅与后厨之间的约定"收到订单后几分钟内开始制作"；UC是餐厅与食材供应商之间的约定"每天几点前送到新鲜食材"。顾客只看到SLA，但SLA能否兑现，取决于后两者。

二、为什么三者必须配合设计

1. SLA的时限要能被拆解

一个"四小时内解决"的SLA，需要拆解为内部各环节的时间：服务台受理多久、转给二线多久、二线处理多久、必要时供应商介入多久。这些拆解后的时间，就是OLA与UC需要约定的内容。

2. 内部协作需要明确的规则

事件常常需要跨团队处理：服务台、网络、数据库、应用团队相互转派。如果没有OLA，转派后各团队按自己的节奏处理，工单可能在不同队列之间"踢皮球"，最终SLA违约，却找不到责任环节。

3. 外部依赖要有保障

许多IT服务依赖外部厂商，如网络运营商、云服务商、软硬件维保商。如果与他们的合同没有明确的响应与修复时限，内部再努力，也无法保证对用户的承诺。

4. 责任划分更清晰

当SLA违约时，三份协议能帮助快速定位原因：是服务台受理慢，是某个内部团队超时，还是外部供应商没有按合同响应。有了数据，才能有针对性地改进，也便于与供应商沟通。

5. 避免做出无法兑现的承诺

在制定SLA之前，先了解内部团队和供应商的实际能力。如果支撑环节的能力只能做到八小时，却对用户承诺两小时，只会制造违约。先摸清底座，再对外承诺。

6. 一个典型例子

假设承诺"核心业务系统故障，一小时内响应，四小时内恢复"。服务台受理并初步判断：十五分钟内；转给应用团队处理：应用团队需在三十分钟内响应（OLA）；若涉及云服务商的底层问题，云服务商需在一小时内响应并给出处理方案（UC）。各环节加总，才能保证整体四小时恢复的承诺。一旦某个环节没有对应协议，整个承诺链就出现缺口。

三、如何在ITSM系统中落地

1. 先梳理服务与依赖关系

明确每项服务由哪些内部团队、哪些外部供应商支撑。借助 CMDB 记录服务与配置项、团队、供应商之间的关系，后续制定协议才有依据。

2. 为不同协议设置不同的计时规则

在 工单系统 中，SLA关注用户视角的总时长；OLA关注工单在各内部团队的停留时间；UC关注供应商处理环节的耗时。通过不同的计时节点与规则，可以分别统计。

3. 区分"暂停计时"的场景

等待用户提供信息、等待用户确认的时间，通常可以暂停SLA计时；但内部团队之间的转派、等待供应商响应，则应当继续计时并纳入OLA、UC的统计。暂停规则要有清晰的原因和上限，避免滥用。

4. 为SLA违约设置阶梯预警

结合升级机制，在SLA、OLA接近时限时提醒相关团队，在违约前通知负责人。预警越早，补救的空间越大。

5. 用报表识别瓶颈

按团队、供应商、工单类型统计耗时与违约次数，找出最常"卡住"的环节。比如某团队的OLA违约率长期偏高，可能是人手不足或知识缺口；某供应商的UC经常不达标，则需要沟通或考虑更换。

6. 定期回顾与更新

业务变化、系统升级、团队调整、供应商变更，都会影响协议内容。建议至少每年回顾一次，确保协议仍然符合现实，而不是一份被遗忘的文件。

7. 先从关键服务开始

不必一开始就为所有服务定义完整的三层协议。可以优先选择核心业务系统和高影响服务，逐步建立，积累经验后再扩展。

四、常见问题解答（FAQ）

Q1：小团队需要OLA吗？
如果团队很小、协作紧密，可以先不制定正式的OLA，但仍应明确转派的基本规则和时间预期。规模扩大后再逐步正式化。

Q2：OLA和SLA可以合并吗？
不建议。两者的对象和目的不同，SLA面向用户，应简洁易懂；OLA面向内部，可以包含更多技术细节。混在一起会让两边都难以使用。

Q3：UC的违约怎么处理？
应在合同中明确违约后的补偿或处理方式，并在日常通过数据记录供应商的响应与修复表现，作为续约和谈判的依据。

Q4：SLA是不是越严格越好？
不是。过于严格的SLA需要更高成本来支撑，也更容易违约。应根据业务的实际需要，在成本与服务水平之间取得平衡。

Q5：三份协议由谁负责？
通常由服务水平管理的负责人牵头，各团队负责人和采购或供应商管理人员参与。关键是有明确的责任人和定期回顾机制。

Q6：OLA需要多正式？
可以是简单的文档，内容包括服务范围、响应与处理时限、沟通渠道和升级路径，并经过双方负责人确认。重点在于双方都清楚且愿意遵守。

Q7：用户能看到OLA和UC吗？
通常不需要。用户关心的是SLA，OLA和UC属于内部与供应商管理的范畴，但它们的执行情况会通过SLA的达成率体现出来。

五、结语：用承诺链保证最终的服务体验

SLA、OLA与UC 共同构成了服务承诺的完整链条：对外承诺要有内部协作支撑，内部协作又需要外部供应商托底。把三者对应起来设计，并借助 ITSM系统 的计时、预警和报表持续监控，ITIL流程 里的服务水平管理才能真正落到实处。

如果你正在梳理服务水平管理，可以了解一下 ManageEngine ServiceDesk Plus。它支持SLA与OLA的配置、阶梯式升级与预警，并提供相关报表，同时可通过CMDB记录服务依赖关系，适合作为搭建服务水平管理体系时的参考选项之一。