📚 课程目录第4章稳定性度量指标

稳定性度量指标：SLA、SLO、SLI

聊到流程稳定性，大家首先想到的是什么呢？

我猜很多人关注的是——你凭什么说一个流程是稳定的？

就凭直觉说“我觉得最近挺稳的”？

当然不行。做工程的人，讲究的是数据说话。要度量稳定性，我们需要一套统一的语言。这套语言，就是SLA、SLO、SLI。

先搞明白一个问题：为什么要量化？

举个例子，线上买了个云服务，供应商承诺「99.9% 可用」。

结果隔三岔五宕机，你说它不行，对方说「我们系统跑得好好的啊」。

为什么会这样？因为没有统一的定义。你觉得「可用」是用户能正常下单，他觉得「可用」是服务器没断电。

量化，就是把这种模糊的争论，变成可测量的数字。

    核心逻辑：没有度量，就没有改进；没有标准，就没有共识。

定义三兄弟：SLA、SLO、SLI

这三兄弟是Google SRE 体系掏出来的核心概念。说白了，它们描述的是同一个事情的不同视角。

SLI：我怎么看数据？

SLI，全称 Service Level Indicator，服务等级指标。

它是具体的一个测量值。比如：

流水线构建成功率
端到端测试通过率
部署失败恢复时间

举个例子，我看到某个CI流水线跑了200次，失败了8次。那它的成功率SLI就是 (200-8)/200 = 96%。

# 假想的一份 SLI 报告
pipeline_build_success_rate = 0.96
end_to_end_test_pass_rate = 0.982
mean_time_to_recover = 120  # seconds
deployment_failure_rate = 0.03

SLO：我希望它达到多少？

SLO，全称 Service Level Objective，服务等级目标。

它是你给团队定的一个目标门槛。比如：

构建成功率 >= 95%
端到端测试通过率 >= 99%
平均恢复时间 <= 300秒

目标不能拍脑袋定。我早期做服务时，SLO定得很粗糙，写了个99.9%就交上去了。结果上线一看，SLI长期在99.4%徘徊。

这不叫目标，叫空想。好的SLO，是要垫垫脚能够到的。

SLA：我对外承诺什么？

SLA，全称 Service Level Agreement，服务等级协议。

这是写进合同里的东西。对外承诺给客户、给供应商、给上下游的。

SLA 一般比 SLO 更宽松，因为你得留够安全余量。你内部的 SLO 可能是 99.9%，但对外承诺 99.5% 就够了——万一真出事了，还有缓冲。

记住一个原则：你承诺的（SLA）一定要比你内部的（SLO）低。

我个人的习惯：SLO 定在 SLA 基础上加 0.5~1 个 9。比如对外签 99% 可用，内部目标就定 99.5%。这样就算偶尔出点小问题，也不会直接打破承诺。

三者的关系

理解了，我们看看它们是怎么串起来的。

你想想看，从SLA拆出SLO，从SLO拆出SLI。反过来，SLI的实测数据告诉我：SLO能不能守住？SLO守不住了，SLA还有没有余量？

这是一个闭环。我负责过的团队，最怕的就是SLA和SLO脱节，或者SLO和SLI不匹配。说白了，内部目标定得太高太低都没意义。

如何衡量流程稳定性

有了这三个概念，衡量流程就有抓手了。

针对 CI/CD 测试空间，我一般重点关注这么几个指标：

指标名称	类型	定义说明	典型阈值
流水线成功率	SLI	流水线绿色通过次数 / 总触发次数	>= 95%
构建失败率	SLI	编译/打包阶段失败次数 / 总构建次数	<= 5%
测试通过率	SLI	通过测试用例数 / 总执行用例数	>= 99%
平均恢复时间 MTTR	SLI	从流水线失败到恢复发送的平均耗时	<= 10分钟
测试环境可用率	SLO	环境正常提供服务质量的时间占比	>= 99.5%

注意：阈值不是固定的。团队小、迭代快的时候，可以先松一点。我记得有一次，团队刚接手新项目，流水线成功率不足80%。我们没有立即提高标准，而是先稳定到90%，再提到95%。步子太大容易扯着。

一个实践案例

拿我之前维护的一个支付核心流水线来说吧。

我们对外的 SLA 是：核心链路部署成功率 >= 99.5%。

内部呢？我们定的 SLO 是 99.9%。这意味着额外的 0.4% 就是我们的安全余量。

落实到 SLI 上，我们每天统计：

2025-03-21 核心链路部署成功 SLI: 99.92%
2025-03-22 核心链路部署成功 SLI: 99.98%
2025-03-23 核心链路部署成功 SLI: 99.85%  ← 触发告警

3月23号的 SLI 掉到了 99.85%，虽然还高于 SLO 的 99.9% 吗？不，已经低于 SLO 了。

这时候我们启动了预案——不是对外发故障，而是内部排查问题。

找到原因后发现，是环境资源争抢导致的随机失败。调整了资源分配策略后，SLI 回到 99.97%。

经验之谈：SLO 是触发预警的，SLA 是触发响应的。你希望在最坏情况到来之前，就被 SLO 喊醒，而不是等 SLA 被打破。

常见陷阱

最后聊几个常见的坑。嗯，这里要注意：

SLI 选太少：只盯着成功率，忽略了恢复时间。你成功率 99.9% 又怎样？一次故障恢复用了 2 小时，照样被投诉。
SLO 定得太激进：不建议上来就写 99.999%。五个九的代价和维护成本，小团队扛不住。
SLA 和 SLO 同名不同义：我见过一个项目，合同里写的「可用性」是 API 响应时长 < 2秒，内部定的「可用性」是服务不宕机。那客户投诉了，你按照 99.9% 算达标了，客户说「你响应都超 3 秒了还达标？」

我曾经在一个支付项目中吃过这个亏。SLA里写的是「交易成功率 >= 99.99%」，但内部 SLI 测的是「系统错误率」。结果交易因风控拒绝导致的失败，全部被客服算成我们的问题。那次之后，我们就把合同中可测量的口径和内部 SLI 严格对齐了。