共计 1384 个字符，预计需要花费 4 分钟才能阅读完成。
本文是《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 的监控。
扩大浏览
- 面向故障定位止损、稳定性治理的可观测性体系建设
- 夜莺专业版，提供加强监控的能力，提供可观测性专家教训
- 告警事件对立 OnCall 核心，解决告警降噪、排班、认领、降级、协同的需要
- 可观测性、稳定性体系建设相干的白皮书，收费查阅
