一、SLA 概述：从概念到落地
各位好，我是老赵。今天咱们聊聊 SLA——服务等级协议。这词儿在 IT 圈里听得多了，但真正能把它讲清楚、用明白的人，说实话不多。
我刚开始做运维那会儿，觉得 SLA 就是合同里的一堆数字——99.9%、99.99%，看着挺唬人。后来踩过几次坑才明白，SLA 不是写给人看的，是写给系统看的，更是写给信任看的。
1.1 什么是 SLA？
SLA，全称 Service Level Agreement，服务等级协议。说白了，就是你和客户之间的一份「服务承诺书」。
它明确规定了：你提供什么服务、服务要做到什么程度、没做到怎么办。不是那种「我们会尽力保证系统稳定」的虚话，而是「系统可用性不低于 99.9%，否则按比例退款」的硬指标。
核心三要素：
- 服务范围——哪些功能、哪些时段、哪些地域
- 度量指标——可用性、响应时间、吞吐量、错误率
- 违约补偿——没达标怎么赔，赔多少
举个例子。我参与过一个金融项目，客户要求核心交易系统可用性 99.995%。当时团队觉得这数字差不多就行，结果真上线后，一个月内宕了两次，每次 15 分钟。算下来可用性 99.93%，离目标差一截。客户直接按合同扣了当季 20% 的服务费。嗯，从那以后，没人再敢对 SLA 含糊了。
1.2 SLA 的核心价值
你可能会问：搞这么复杂，图啥？
我个人习惯把 SLA 的价值归纳为三点：
| 价值维度 | 具体体现 | 我见过的反面案例 |
|---|---|---|
| 对齐预期 | 客户知道能拿到什么水平，团队知道要做到什么程度 | 某项目口头承诺「秒级响应」，合同写的是 5 分钟，上线后天天扯皮 |
| 量化管理 | 用数据说话，而不是「我感觉系统挺稳的」 | 运维说系统 99.9% 可用，一查监控实际只有 98.7%——没度量就没真相 |
| 风险控制 | 明确违约后果，倒逼团队把质量当回事 | 没有罚则的 SLA 就是一张废纸，没人会认真对待 |
说白了，SLA 不是用来限制你的，是用来保护你的。它让「好服务」有了可衡量的标准，也让「差服务」有了可追责的依据。
1.3 SLA 与 OLA / UC 的关系
这里有个常见的混淆点。很多人以为 SLA 就是全部，其实它只是冰山一角。
我画了张图，帮你理清这三者的关系：
简单来说：
- SLA 是对外的，面向客户。承诺的是最终服务效果。
- OLA 是对内的，面向内部团队。比如运维团队承诺 15 分钟内响应告警，开发团队承诺 2 小时内修复 P0 故障。
- UC 是对下的，面向供应商。比如云厂商承诺基础设施可用性 99.99%，CDN 厂商承诺边缘节点延迟低于 50ms。
避坑指南： 我曾经见过一个团队，SLA 写得漂漂亮亮，但内部 OLA 全是「尽力而为」。结果客户投诉时，内部互相甩锅——运维说网络没问题，开发说代码没问题，最后谁也说不清问题出在哪。记住：没有 OLA 和 UC 支撑的 SLA，就是一张空头支票。
1.4 SLA 在 IT 服务管理中的位置
在 ITIL 框架里，SLA 属于「服务设计」阶段的核心产出。但它不是孤立的，它贯穿了整个服务生命周期。
我习惯用这张表来理解它的位置：
| ITIL 阶段 | SLA 相关活动 | 我的经验 |
|---|---|---|
| 服务策略 | 定义服务价值、目标客户、服务级别目标 | 先想清楚「客户到底需要什么」，别急着写数字 |
| 服务设计 | 设计 SLA 结构、度量方法、评审流程 | 这里最容易犯的错是「指标太多」，抓不住重点 |
| 服务过渡 | 验证 SLA 是否可度量、可达成 | 我建议上线前先跑一个月模拟数据，看看指标能不能真实采集 |
| 服务运营 | 监控 SLA 达标情况、处理违约、持续改进 | 运营阶段最怕「没人看」，SLA 报告发出去没人读 |
| 持续改进 | 根据 SLA 数据优化服务、调整目标 | 每年至少 review 一次 SLA，业务变了指标也得跟着变 |
你看，SLA 不是写完了就完事的。它是个活的东西，需要持续维护、持续优化。
警告： 别把 SLA 当成「一次性交付物」。我见过太多团队，合同签完就把 SLA 文档扔进共享文件夹吃灰。等到客户投诉时才翻出来看——结果发现指标定义模糊、数据采集缺失、补偿条款无法执行。SLA 的价值在于「用」，不在于「有」。
小结
这一章我们聊了 SLA 的基本概念、核心价值、与 OLA/UC 的关系，以及它在 IT 服务管理中的位置。说白了，SLA 就是服务质量的「度量衡」——没有它，你说服务好，客户说服务差，谁也说服不了谁。