2 分钟,搞懂 SLO 最佳实践

原创
2023/05/26 17:00
阅读数 453
AI总结

本文是《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分位,会掩盖一些长尾问题,比如下图:

20230526162220

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 的监控。

扩展阅读

展开阅读全文
加载中
点击引领话题📣 发布并加入讨论🔥
0 评论
0 收藏
0
分享
AI总结
返回顶部
顶部