2 分钟，搞懂 SLO 最佳实践

本文是《SRE，Google运维解密》读书笔记，连载第三篇。微信公众号修改了推文逻辑，尤其是 iOS，建议对本公众号 SRETalk 加星标，以免错过后续系列推文。

本文介绍 SLO，曾经我发过一个短时间讲解我们做监控最应该监控的是什么，短视频讲了上篇，这篇算是下篇。当时的短视频可以在这里查阅：

SLI、SLO、SLA

先拎清楚几个概念：

SLI：服务质量指标，比如 99 分位的响应时间、99 分位的响应时间、错误率等
SLO：服务质量目标，所谓的几个 9 的目标，比如 99 分位的响应时间小于 200 毫秒，比如错误率小于 0.1%
SLA：服务质量协议，是个承诺，是个合同，比如公有云就会提供 SLA，不达标就会有赔付

SRE 在制定 SLx 时的职责

SRE 不参与构建 SLA，因为这通常涉及退款赔付之类的，是个商业行为，但是 SRE 要帮助业务确立 SLI，帮助业务达成 SLO。

SLI 相关的一些实践

首先，千万不要把能监控到的一坨指标都确立为 SLI，SLI 一般也就是四五个，再多就有问题了。不同的服务的 SLI 举例：

用户可见的服务系统：可用性、延迟、吞吐。即：是否能正常处理请求？每个请求花费的时间是多少？多少请求可以被处理？
存储系统：延迟、可用性、数据持久性。即：读写数据需要多少时间？我们是否可以随时访问数据？一段时间之后数据是否还能被读取？
大数据系统：比如数据处理流水线系统，关注吞吐量和端到端延迟。即：处理了多少数据？数据从进来到产出需要多少时间？
所有系统都应该关注：正确性。比如是否返回了正确的结果？当然，正确性更关注系统内部的数据而非系统本身，所以SRE通常不会关注这块。

总结：SLI 应该是一些上层业务或用户关注的体验指标，这些指标如果出问题了，一定是服务出了大问题了。

另外，一般 SLI 都是分钟级的汇总，比如成功率是每分钟产出一个值，延迟也是，延迟尽量不要用平均延迟和50分位，会掩盖一些长尾问题，比如下图：

50th, 85th, 95th, and 99th percentile latencies for a system. Note that the Y-axis has a logarithmic scale.

从 10:30 开始，长尾请求的延迟变得频繁了，尤其是 99 分位和 95 分位，但是 50 分位的值，几乎不变，如果我们只关注 50 分位的值，就没法发现这个问题了！

定义 SLO 的一些建议

实际制定 SLO 的时候，对内对外通常是两个值，对内更严格，对外更宽松。而且，即使有能力达成 SLO，也不要做的过高，适当的搞挂一下非常有必要。比如某个服务当前季度（SLO 一般按季度统计）的 SLO 是 99.95%，季度末了，100% 可用，此时建议做个放火演练之类的，即使搞出纰漏，对 SLO 的影响也不会太大。其次，上层业务也会充分认识到你这个下游服务不是 100% 可靠的，会有针对性的增强冗余设计。

大部分公司都做错了

大部分公司的稳定性体系都是从指标监控开始的，这个没问题，但是完成了机器、中间件的监控就认为基本完活了，就是大错特错。实际还有两个东西必须要做好监控，一个是短视频里提到的业务北极星指标的监控，另一个是本文提到的 SLO 的监控。

扩展阅读