1. SLA 基础概念：什么是 SLA、关键指标与 SLO/SLI 的关系
大家好，我是这次课程的主讲。在数据运维这行摸爬滚打了十几年，我见过太多因为 SLA 没搞清楚就上线的惨案。今天咱们就从最基础的东西聊起——SLA 到底是什么，它为什么那么重要。
1.1 什么是 SLA？
SLA，全称 Service Level Agreement，服务等级协议。说白了，就是你和客户之间的一份“承诺书”。你承诺你的数据产品在多长时间内必须能用，客户根据这个承诺来付费或者决定是否继续用你。
我习惯把 SLA 理解成“合同里的技术条款”。它不是一份法律文件那么简单，而是实实在在的技术指标。比如你承诺“数据查询接口 99.9% 的时间可用”，那你就得在架构设计、监控告警、故障恢复上投入对应的资源。
核心要点：SLA 是商业承诺 + 技术指标的混合体。没有 SLA，客户不敢用你的产品；有了 SLA 但达不到，客户会索赔甚至起诉。
1.2 SLA 的关键指标
一个完整的 SLA 通常包含三个核心指标：可用性、延迟、吞吐量。这三个指标缺一不可，它们共同决定了数据产品的服务质量。
| 指标 | 定义 | 常见度量方式 | 我踩过的坑 |
|---|---|---|---|
| 可用性 | 服务正常运行的时间占比 | 99.9%（三个9）、99.99%（四个9） | 曾经只算工作日，结果周末挂了没人管 |
| 延迟 | 从请求发出到收到响应的时间 | P50、P95、P99 分位延迟 | 只看平均值，P99 飙到 10 秒才发现 |
| 吞吐量 | 单位时间内能处理的请求数 | QPS、TPS、RPS | 压测时正常，上线后被突发流量打爆 |
1.2.1 可用性
可用性是最直观的指标。你想想看，如果一个数据产品三天两头挂掉，谁还敢用？
可用性的计算公式很简单：可用性 = (总时间 - 不可用时间) / 总时间 × 100%。但这里有个坑——什么算“不可用”？是服务完全挂掉，还是响应变慢也算？
注意：定义“不可用”的标准必须在 SLA 里写清楚。我见过一个案例，客户认为响应超过 5 秒就算不可用，但 SLA 里写的是“服务完全不可访问才算”，最后扯皮扯了三个月。
常见的可用性等级：
- 99%（两个9）：每年允许宕机 87.6 小时，适合非关键业务
- 99.9%（三个9）：每年允许宕机 8.76 小时，适合大多数数据产品
- 99.99%（四个9）：每年允许宕机 52.56 分钟，适合金融、交易类
- 99.999%（五个9）：每年允许宕机 5.26 分钟，适合核心基础设施
1.2.2 延迟
延迟是用户体验的“生命线”。数据产品不像网页，用户等 3 秒可能就放弃了。我个人习惯把延迟分成三个维度来看：
- P50（中位数延迟）：一半请求在这个时间内完成，反映“大多数用户”的体验
- P95（95分位延迟）：95% 的请求在这个时间内完成，反映“大部分用户”的体验
- P99（99分位延迟）：99% 的请求在这个时间内完成，反映“最差情况”的体验
为什么不能只看平均值？我记得有一次，某个数据接口的平均延迟只有 200ms，但 P99 延迟高达 8 秒。这意味着每 100 个用户里就有 1 个要等 8 秒以上——这 1% 的用户可能就直接流失了。
1.2.3 吞吐量
吞吐量决定了你的系统能扛多大压力。对于数据产品来说，常见的吞吐量指标有：
- QPS（Queries Per Second）：每秒查询数，适合读多写少的场景
- TPS（Transactions Per Second）：每秒事务数，适合写操作较多的场景
- RPS（Requests Per Second）：每秒请求数，通用指标
这里有个经验之谈：吞吐量不是越高越好，而是要和延迟做 trade-off。我曾经为了追求高吞吐量，把数据库连接池调得很大，结果延迟反而飙升了——因为连接太多导致上下文切换开销过大。
1.3 SLA、SLO、SLI 的关系
这三个概念经常被混用，但它们的层次完全不同。我画了一张图来帮你理解：
1.3.1 SLI（Service Level Indicator）
SLI 是实际测量出来的数据。比如“过去 30 天，数据查询接口的可用性是 99.97%”，“P99 延迟是 280ms”。这些都是实实在在的数字，从监控系统里拿到的。
SLI 的选择很关键。不是所有指标都值得监控，我建议只关注那些直接影响用户体验的指标。比如对于数据产品，查询成功率、查询延迟、数据新鲜度就是核心 SLI。
1.3.2 SLO（Service Level Objective）
SLO 是你给自己定的“内部目标”。它通常比 SLA 更严格。为什么？因为你要留出安全余量。比如 SLA 承诺 99.9% 可用，那 SLO 可以定 99.95%。这样即使出了点小问题，只要没突破 SLO，就不会触发 SLA 违约。
我的经验：SLO 的设定要“跳一跳够得着”。定得太松，团队没有压力；定得太紧，天天报警，团队会疲劳。我一般建议 SLO 比 SLA 高 0.05%~0.1%。
1.3.3 SLA（Service Level Agreement）
SLA 是最终对外承诺的“底线”。它包含三个要素：
- 承诺指标：比如可用性 99.9%，P99 延迟 < 500ms
- 度量方式：怎么算可用？怎么算延迟？统计周期是多久？
- 违约后果：达不到怎么办？赔偿多少？服务抵扣还是现金赔付？
这里有个容易忽略的点：SLA 里一定要写清楚“排除项”。比如计划内维护、不可抗力（机房断电、光缆被挖断）等，这些时间不应该算在不可用时间里。我见过一个团队没写排除项，结果机房断电 2 小时，客户要求按 SLA 赔偿，最后赔了十几万。
1.4 三者关系总结
用一句话概括：SLI 是“测出来”的，SLO 是“想达到”的，SLA 是“承诺出去”的。
它们的关系就像三层漏斗：
- 从海量监控数据中筛选出关键 SLI
- 基于 SLI 设定合理的 SLO
- 将 SLO 的一部分（留有余量）作为 SLA 承诺给客户
避坑指南：千万不要把 SLA 和 SLO 混为一谈。我曾经见过一个团队，把内部 SLO 直接写进合同，结果因为一次小故障导致 SLA 违约，赔了半年利润。记住：SLA 是底线，SLO 是目标，两者之间必须有缓冲。