3. SLA 体系设计：从承诺到赔偿的完整闭环
聊到全链路监控，最终都会落到一个核心问题上：你的系统到底有多可靠？ 这个问题不能靠感觉回答，得有一套量化的语言。这套语言就是 SLA、SLI 和 SLO。
我见过不少团队，一上来就拍脑袋定 SLA：“我们 99.9%！” 结果真出了故障，一算账发现根本达不到，赔偿金赔得肉疼。说白了，SLA 体系不是写几个数字，而是一套从定义、测量到违约处理的完整机制。今天咱们就把这事掰开揉碎了讲。
核心观点： SLA 是合同承诺，SLO 是内部目标，SLI 是测量指标。三者缺一不可，共同构成可靠性管理的基石。
3.1 SLA / SLI / SLO：别再傻傻分不清
这三个缩写长得像，但职责完全不同。我习惯用一个比喻来理解：
- SLI（Service Level Indicator） —— 你测什么？比如请求延迟、错误率。
- SLO（Service Level Objective） —— 你希望达到多少？比如 99.9% 的请求在 200ms 内完成。
- SLA（Service Level Agreement） —— 你跟客户签了什么？比如达不到 99.9% 就赔钱。
你看，SLI 是原始数据，SLO 是内部目标，SLA 是商业合同。我在项目中遇到过不少团队，把 SLO 当 SLA 直接写在合同里，结果内部一个版本迭代没跟上，赔了三个月利润。嗯，这里要注意：SLA 一定要留余量。
| 概念 | 定义 | 典型例子 | 谁关心 |
|---|---|---|---|
| SLI | 服务质量的具体度量指标 | 请求延迟 P99、错误率、吞吐量 | 开发、运维 |
| SLO | SLI 的目标值或范围 | P99 延迟 ≤ 200ms，可用性 ≥ 99.95% | 技术团队、PM |
| SLA | 对客户承诺的服务水平及违约后果 | 月度可用性 ≥ 99.9%，否则赔偿 10% 月费 | 法务、商务、客户 |
我的习惯： 内部 SLO 通常比 SLA 严格 0.05% ~ 0.1%。比如 SLA 是 99.9%，SLO 就定 99.95%。这样即使 SLO 偶尔没达标，也不至于触发 SLA 违约。这叫“安全垫”。
3.2 SLA 指标设计原则：别掉进数字陷阱
设计 SLA 指标，最怕的就是“为了指标而指标”。我见过一个团队，把“系统可用性”定成 99.99%，结果每次故障都靠延长统计窗口来“凑”达标。你想想看，这有什么意义？
我个人总结了四条原则，供你参考：
- 可测量性 —— 指标必须能从监控系统里直接拿到。别搞那种需要人工统计的，比如“客户满意度”。
- 可理解性 —— 客户和老板都能看懂。别上来就“P99 延迟”，对非技术人员说“平均响应时间”更友好。
- 可行动性 —— 指标不达标时，团队知道该修什么。比如“错误率”高了，直接看错误日志；但“系统健康度”这种模糊指标，没法修。
- 可达成性 —— 别定一个永远达不到的目标。我建议先跑三个月数据，看看实际水平，再定 SLO。
避坑指南： 我曾经帮一个电商团队复盘，他们的 SLA 里写了“支付成功率 ≥ 99.99%”。结果发现，很多失败是银行网关超时导致的，根本不是他们能控制的。最后不得不重新谈判，把第三方依赖的失败排除在外。所以，SLA 的范围一定要清晰——哪些算、哪些不算，提前说清楚。
3.3 SLA 违约与补偿机制：承诺的代价
定 SLA 容易，赔钱的时候才肉疼。违约补偿机制是 SLA 的“牙齿”，没有它，SLA 就是一张废纸。
常见的补偿方式有几种：
- 服务额度 —— 最常见。比如当月可用性低于 99.9%，赔偿 10% 月费的服务券。
- 现金退款 —— 一般用于严重违约，比如可用性低于 99.0%。
- 合同延期 —— 免费延长服务周期。
- 阶梯式赔偿 —— 违约越严重，赔偿比例越高。
我建议你设计一个阶梯表，这样既保护客户，也给自己留余地。
| 月度可用性 | 违约等级 | 赔偿比例（月费） |
|---|---|---|
| ≥ 99.9% | 无违约 | 0% |
| 99.0% ~ 99.9% | 轻度 | 10% |
| 95.0% ~ 99.0% | 中度 | 25% |
| < 95.0% | 严重 | 50% 或全额退款 |
实操建议： 别忘了定义“排除条款”。比如：计划内维护、第三方依赖故障、DDoS 攻击、客户自身问题。这些情况下的故障，不计入 SLA 计算。否则，你可能会为别人的错误买单。
3.4 SLA 计算与监控：用数据说话
有了指标和补偿机制，怎么算？总不能手动算吧。我习惯用 Prometheus + 自定义 Exporter 来实时计算 SLA。
一个简单的可用性 SLI 计算逻辑：
# 假设我们监控 HTTP 请求
# SLI: 可用性 = 成功请求数 / 总请求数
# PromQL 示例
(
sum(rate(http_requests_total{status=~"2..|3.."}[5m]))
/
sum(rate(http_requests_total[5m]))
) * 100
然后，把这个 SLI 跟 SLO 阈值对比。一旦连续 5 分钟低于 SLO，就触发告警。为什么是 5 分钟？因为偶尔的毛刺不算故障，持续低才需要处理。
下面这张图，是我常用的 SLA 监控流程：
你看，整个流程是闭环的：从采集到计算，从判断到补偿。每一步都要自动化，别等人去查。我见过最惨的案例，故障发生了三天，运维才发现 SLA 已经跌破红线了。那时候客户早就投诉到法务部了。
关键点： SLA 监控要实时，告警要分级。轻度违约发邮件，中度违约打电话，严重违约直接拉群开会。别等到月底算总账，那时候什么都晚了。
3.5 总结一下
SLA 体系设计，说白了就是三件事：定指标、设目标、给承诺。SLI 是眼睛，SLO 是尺子，SLA 是合同。三者配合好了，你的系统可靠性才有据可依。
我个人建议，刚开始做 SLA 的团队，先从简单的可用性指标入手，跑三个月数据再逐步完善。别一上来就搞十几个指标，团队会疯的。记住：好的 SLA 体系，是让客户放心，也让团队有底。