主讲：老孙
适用：2026年下半年系统规划与管理师考试
预计阅读时间：55分钟
一、上节回顾
上一讲我们把 ITIL 四大核心流程讲透。事件管理负责"救火"，把服务尽快恢复回来；问题管理负责"防火"，把根因挖出来沉淀成已知错误；变更控制负责"改造"，让 IT 系统在最小风险下持续进化；发布管理负责"投产"，把一组变更打包安全上线。四个流程相互衔接，构成 IT 运营的主战场。
我反复强调一句话："没有度量就没有管理"。前面两讲我们把"做什么、怎么做"讲清楚了，但有一个根本问题没有回答——做到什么程度才算合格？业务部门怎么知道 IT 服务是好还是坏？这就是今天要解决的问题。
1.1 SLA 的"江湖地位"
SLA（服务级别协议）是 IT 服务管理领域使用频率最高、争议最大、误解最多的概念之一。
很多组织以为"SLA 就是签个合同条款"。这是个浅认知。真正的 SLA 体系包括：服务目录定义、指标体系设计、监控与度量、定期复盘、违约处理、持续改进。它是 IT 与业务双方"长期博弈"的契约规则。
ITIL v3 把 SLA 放在"服务设计阶段"，ITIL 4 把"服务级别管理"列为 17 个服务管理实践之一，重要性始终未变。
1.2 没有 SLA 的"三大乱象"
我做过的几十家中型组织诊断里，没有 SLA 体系的组织都呈现三大乱象。
乱象一：承诺无边界。业务部门要求"立刻、马上、当下"全部解决，IT 部门疲于奔命。任何小问题都是"高优先级"，结果真正的高优先级被淹没。
乱象二：评价无依据。业务部门凭感觉打分，IT 部门凭印象自评。一个月下来双方都觉得对方不行，但拿不出客观数据。
乱象三：改进无方向。出了问题大家都说"下次改进"，但"改什么、改到什么程度"没人能说清。改进沦为口号。
SLA 体系的核心价值，就是把"模糊的承诺"变成"清晰的契约"。
二、本讲导读
2.1 学习目标
学完这一讲，你应该能够：
- 【是什么】 准确说出 SLA、OLA、UC 三类服务级别协议的定义、适用场景、典型条款，以及它们之间的层级关系
- 【为什么】 理解为什么"服务级别管理"是 IT 与业务"长期契约"的核心抓手——没有它，IT 永远是被埋怨的成本部门
- 【怎么用】 能为一个组织从零设计一套 SLA 体系——服务目录定义、指标设计、监控落地、违约处理、定期复盘
2.2 本讲在课程地图中的位置
本讲对标教材 第 12 章"IT 服务管理" 中"服务级别管理"小节。
ITIL 三讲（28-30）至此完整收官：
- 第 28 讲：服务理念（已完成）
- 第 29 讲：四大流程（已完成）
- 第 30 讲（本讲）：SLA 与服务级别管理
2.3 一句话理解 SLA
SLA = 把"我尽力"变成"我保证 X 小时内 Y 概率达成 Z 水平"——这是 IT 部门从"成本中心"升级为"服务提供方"的关键一跃。
【虚构案例提示】 本讲涉及"智慧邻里2.0项目""清华园物业""北京知知致用信息技术有限公司"均为培训教学所用的虚拟项目与虚构人物（详见第01讲首次案例声明）。
三、服务级别管理的核心概念体系
3.1 服务级别管理（SLM）的定义
服务级别管理（Service Level Management, SLM） 指通过 SLA、OLA、UC 三层协议建立、监控、维护服务质量目标的一系列管理活动。
它的目标有四条：
第一，为每项 IT 服务建立清晰、可测、可达成的服务级别目标。这意味着每个服务都必须有可量化的指标，比如响应时长、解决时长、可用性百分比、性能阈值等等。"尽快""及时""高质量"这种模糊语言不能进入 SLA。
第二，确保服务级别目标与业务需求对齐。SLA 不是 IT 部门关起门来定的，必须经过业务部门确认，体现真实业务诉求。业务部门说"我们需要核心系统年度可用性 99.95%"，IT 部门评估技术与成本可行性，双方协商达成共识。
第三，持续监控服务级别达成情况，及时识别和纠正偏差。SLA 签了不是一劳永逸，每天、每周、每月都要看数据。低于阈值就要预警、整改、复盘。
第四，通过定期复盘与改进迭代，让服务级别与业务需求共同进化。业务在变，技术在变，SLA 也要跟着变。一份 3 年没改过的 SLA 一定是"僵尸协议"。
3.2 三类协议：SLA、OLA、UC
服务级别管理体系里有三类协议，必须分清。
SLA（Service Level Agreement，服务级别协议）：IT 服务提供方与业务客户（内部或外部）之间签订的服务级别承诺。它面向的是"业务客户"，回答的是"客户能享受到什么水平的服务"。比如清华园物业 IT 对业主承诺"缴费 APP 7×24 可用，年度可用率 99.5%"。
OLA（Operational Level Agreement，运营级别协议）：IT 内部不同团队之间为支撑 SLA 而签订的协议。它面向的是"内部协作团队"，回答的是"内部各组之间怎么分工、谁该响应什么"。比如清华园物业 IT 内部，应用组与网络组签 OLA：网络故障网络组 30 分钟响应，应用组配合排查。
UC（Underpinning Contract，支持合同）：IT 服务提供方与外部供应商之间为支撑 SLA 而签订的合同。它面向的是"外部供应商"，回答的是"外部资源能为我们的 SLA 提供什么底层保障"。比如清华园物业与某云厂商签 UC：云主机年度可用性 99.9%，违约赔付服务费 10 倍。
三层关系：UC 支撑 OLA，OLA 支撑 SLA，SLA 面对业务客户。任何一层垮掉，上一层都达不成。
很多组织只签 SLA，不签 OLA 和 UC，结果出了事各部门互相推诿，外部供应商两手一摊。三层协议必须齐备。
3.3 服务、服务目录、服务组合
理解 SLA 前必须理解"服务"这个概念在 ITIL 里的精确含义。
服务（Service）：通过促进客户期望达到的成果，向客户提供价值的手段，使得客户不必承担特定成本和风险。这个定义是 ITIL 4 官方定义，看着拗口，其实就是说"我帮你实现业务结果，你不用操心底层技术"。
服务目录（Service Catalog）：组织当前正在向客户提供的所有服务的清单。它必须公开、清晰、可检索，让业务部门一目了然"IT 能提供什么服务"。
服务组合（Service Portfolio）：包括正在规划、当前运行、已经退役的全部服务清单。它是服务目录的"全生命周期视图"——服务目录只是其中"运行中"那一部分。
清华园物业的服务目录大致 25 项服务，分缴费类、报修类、安防类、增值类四大块；服务组合除此之外还包括 5 项正在规划的服务（如智能门禁 2.0、社区团购联营平台）和 3 项已退役的服务（如纸质账单递送、人工电话报修热线）。
四、SLA 的核心要素与典型结构
4.1 SLA 必备的 8 大要素
一份合格的 SLA 必须包含八大要素。少一个都不算完整。