400-8615-123 ITIL中的SLA（Service Level Agreement，服务级别协议）是IT服务管理中界定“服务商该交付什么水平、没做到怎么办”的一份正式约定，它把抽象的IT服务变成可测量、可问责、可改进的具体承诺。简单说：没有SLA，IT服务好坏全凭感觉；有了SLA，双方按同一把尺子验收。
SLA解决什么问题
问“SLA是什么意思”的人，通常在IT服务采购或运维中遇到两类麻烦：服务出了问题，说不清是谁的责任；或者供应商口头承诺很好，实际响应很慢。SLA就是用来解决这两个问题的——它把服务范围、性能指标、责任边界、违约后果写清楚，让IT服务从“人情账”变成“合同账”。
SLA包含哪些核心要素
一份能落地的SLA，至少要回答六个问题：
- 服务范围：具体提供哪些服务，不包括什么。
- 量化指标：如工单响应时间、解决时长、系统可用性百分比（这些数字因需求而异，以双方约定为准）。
- 责任归属：客户负责提供什么（如网络环境、接口权限），服务商负责什么。
- 测量方式：用什么工具、多长时间统计一次绩效。
- 例外条款：计划内维护、第三方故障等特殊情况怎么豁免。
- 复审机制：多久回顾一次，怎么调整指标。
SLA在ITIL里处于什么位置
ITIL把服务生命周期分为战略、设计、转换、运营、持续改进几个阶段。SLA横跨两个关键环节：
- 服务设计阶段：SLA是设计输出物，定义“我们要承诺什么”。
- 服务运营阶段：SLA是管理抓手，用来监控“我们是否兑现了承诺”。
ITIL还区分三种SLA类型：
| 类型 | 适用场景 |
|---|---|
| 基于客户 | 面向某个具体客户定制 |
| 基于服务 | 同一服务对所有客户统一标准 |
| 多层 | 底层标准+客户特定补充，兼顾效率与个性化 |
SLA和OLA、UC的区别是什么
很多人把SLA和内部协议混为一谈。记住一条线：SLA是对外的，OLA和UC是对内的。
- SLA：IT部门与业务客户之间的服务质量约定。
- OLA（Operational Level Agreement）：IT内部各支持团队（如网络组、服务器组）之间的协作约定，目的是支撑SLA达成。
- UC（Underpinning Contract）：IT部门与外部供应商（如云厂商、硬件商）签订的合同，把SLA里的部分指标转嫁给第三方。
三者需要联动：SLA承诺“故障4小时修复”，OLA就要约定“网络组30分钟内响应”，UC则要确保供应商的备件到场时间不拖后腿。缺了内层协议，外层SLA就是空头支票。
怎么制定一个能执行的SLA
很多SLA写得很漂亮，执行起来却形同虚设。问题通常出在指标定得“虚”或“高”。按这四步走，能少走弯路：
- 先摸清业务底数：问业务方“哪些系统中断影响最大？能容忍多久？”而不是直接套模板。
- 再对照历史数据：看过去半年实际响应和解决时长是多少，承诺指标要比现状略高，但别脱离现实。
- 指标必须可测量：避免“尽快处理”“优质服务”这类词，改用“严重故障2小时内响应”“月度可用性不低于99%”等可验证表述。
- 预留复审周期：业务在变，技术也在变，每季度或每半年回顾一次SLA达成情况，必要时调整指标。
SLA怎么监控才不是摆设
定完SLA，重点在持续跟踪。常见做法是：用ITSM工具自动计时（比如工单从创建到首次响应的时间），临近违约阈值自动提醒负责人，月底生成合规率报告。真正执行到位的团队还会做两类复盘：
- 违约原因分析：是人员不够、流程卡壳，还是第三方拖累？找到根因再改。
- 趋势预判：如果某类工单的解决时长连续三个月上升，即使这个月没违约，也要提前干预。
哪些情况可以不算违约
SLA不是铁板一块，通常要约定豁免条件。典型场景包括：计划内维护窗口（提前通知客户）、客户自身变更导致的故障、不可抗力（自然灾害、大规模电力中断）、第三方服务（如公有云整体宕机）且非服务商可控。这些例外写清楚，能避免事后扯皮。
SLA今后会怎么变
传统SLA侧重“系统可用性”，现在更多企业开始把“用户体验”纳入指标，比如页面加载速度、关键业务流程完成成功率。另外，云环境下的SLA越来越复杂——涉及多云、混合云时，责任边界需要拆分到每个云服务商。Servicehot（永服科技旗下的不开源ITSM工具）的SLA管理模块支持自动计时、预警和合规报告，能帮企业把上述流程固化到系统里。但工具只是辅助，SLA真正有效，靠的是业务方和IT方坐下来把话说清楚，并愿意每月花时间看数据、改指标。
