1. SLA 基础概念：什么是 SLA、SLA 与 SLO/SLI 的关系、为什么需要 SLA

聊到 SLA，很多刚入行的朋友第一反应就是「不就是合同里那几行赔偿条款吗？」
嗯，我当年也是这么想的。直到有一次线上事故，客户拿着 SLA 条款找上门来，我们才发现自己连最基本的监控口径都没对齐。
说白了，SLA 不是一张纸，它是你整个运维体系的「天花板」。

1.1 什么是 SLA

SLA，全称 Service Level Agreement，服务等级协议。
它是服务提供方和客户之间的一份正式约定，明确了服务应该达到的质量标准。

我习惯把它拆成三个关键词来理解：

• 服务 —— 你提供的是什么？API、数据库、CDN、还是全托管平台？
• 等级 —— 多好才算好？99.9% 还是 99.99%？
• 协议 —— 没达到怎么办？赔钱、赔时长、还是赔信誉？

举个例子，云厂商的典型 SLA 条款：

阿里云 ECS 单实例：
- 月度服务可用性 ≥ 99.975%
- 如低于 99.975% 但高于 99.0%，赔偿 10% 月度服务费
- 如低于 99.0%，赔偿 30% 月度服务费

你看，SLA 不只是「承诺」，它还绑定了「代价」。
我在项目中见过最离谱的 SLA 是某金融客户要求「全年不可用时间不超过 5 分钟」—— 折算下来是 99.999% 的可用性。当时我们团队评估完直接放弃了，因为基础设施根本撑不住。

1.2 SLA 与 SLO / SLI 的关系

这是新人最容易搞混的一组概念。我画了张图，你看完就明白了：

我再用一句话帮你理清：

• SLI 是你实际测出来的数字 —— 比如「过去 30 天 API 平均延迟 120ms」
• SLO 是你给自己定的目标 —— 比如「99.9% 的请求延迟 < 200ms」
• SLA 是你对客户拍胸脯的承诺 —— 比如「月度可用性 ≥ 99.95%，否则赔钱」

举个例子，我在某电商平台负责监控时，我们的 SLI 是「首页 API 的 P99 延迟」，SLO 定的是「P99 < 300ms」，但对外签的 SLA 只承诺了「P99 < 500ms」。为什么留余量？因为网络抖动、客户端差异这些因素你控制不了，SLA 必须保守。

1.3 为什么需要 SLA

这个问题我问过不少运维同行，答案五花八门。我总结下来，核心原因就三个：

1. 对齐预期 —— 客户觉得「系统应该永远在线」，你觉得「维护窗口停 10 分钟很正常」。没有 SLA，双方永远在扯皮。
2. 驱动改进 —— 有了 SLA 指标，你才知道该优化哪里。我见过一个团队，没有 SLA 之前天天救火，有了 SLA 之后开始做容量规划、故障演练，因为「再出事真要赔钱了」。
3. 商业保障 —— 对客户来说，SLA 是定心丸；对公司来说，SLA 是差异化竞争力。同样卖云主机，你承诺 99.99%，对手承诺 99.9%，客户选谁一目了然。

但这里有个坑，我曾经踩过：SLA 不是越「高」越好。

你想想看，从 99.9% 提升到 99.99%，看起来只多了 0.09%，但每年的不可用时间从 8.76 小时降到了 52.56 分钟。为了实现这 7 个多小时的提升，你可能要多花一倍的硬件成本和两倍的运维人力。值不值？得算账。

最后说一句，SLA 不是运维一个部门的事。它需要产品、研发、运维、法务、销售一起参与。我见过最成功的案例，是每季度开一次 SLA 复盘会，各部门坐在一起看数据、找根因、定改进计划。这才是 SLA 的真正价值 —— 它不是用来罚钱的，是用来让大家往同一个方向使劲的。