后端开发要学习的SRE｜介绍服务质量指标，以及如何处理服务告警（简单总结）

最近在整理自己工作上用到的知识，所以想跟大家聊服务质量指标，以及实际系统出现错误时排查的思路。

服务质量指标

SLI，SLO，SLA这三个分别是什么？

SLI（service level indicator）

定义：服务质量指标，表示服务的某项服务质量的一个具体量化指标。
那么什么样的指标才能称得上 一个服务的SLI？

• 服务可用性：服务是否可以成功响应请求。可以用成功率/错误率
  • 运行时间
  • 成功率（失败率）
• 性能
  • 请求延迟：即处理请求所消耗的时间。（注意：响应时间是指请求时间+网络延迟+排队延迟等）
  • QPS：每秒查询数，包括成功qps和失败qps
  • 实效性：比如交易系统的实际业务成功率（实时性要求比较高的系统）
• 质量
  • 准确性
  • 正确性
  • 可靠性
  • 覆盖性
  • 相关性

SLO（service level object）

定义：服务质量目标，某个sli的目标值或范围。用公式表示就是：SLI ≤ 目标值，或者 范围下限 ≤ SLI ≤ 范围上限。比如 请求延迟<=40ms；服务在99.95%时间内可用（服务通常用百分位数来定目标值，而不是平均值。因为平均值反映不了多少用户经历了xx， 而百分位数（有长尾效应）能直接影响用户总体服务体验）
额外补充：
error budgets：错误预算
错误预算是SLO的反向指标。也就是SLO+错误预算=100%

SLA（service level agreement）

定义：指服务和用户之间一个明确的协议，描述了达到或者没有达到SLO之后的后果。
与SLO的区别：SLA有明确后果，如果没有明确后果就是SLO。

三者关系

这三者是什么关系呢？
就是首先定指标SLI，然后明确指标目标范围SLO，然后描述达到或没达到SLO的后果也就是SLA。
比如调用失败率作为SLI，明确调用失败率要小于0.1%作为SLO，当调用失败率要>0.1%，就说明超出slo了，这时候就要给出事故了，你需要说明事故原因（赔偿）作为SLA了。

指标在实践中的应用

运维人员和最终用户关心的是什么？

注意：不应将监控系统中的所有指标都定义为SLI，只有理解用户对系统的真实需求才能真正决定哪些指标是否可用。一般四五个具有代表性的指标就够了。
常见服务的SLI分类：

• 用户可见的服务系统：可用性、延迟、吞吐量
• 存储系统： 可用性、延迟、数据持久性
• 大数据系统：端到端的延迟、吞吐量
  所有系统：关注正确性（废话但有用。。）

指标统计

大部分指标用“百分比分布”，而非平均值来定义。因为长尾效应比算数平均值更有特点。比如p99请求延迟<20ms，意思是99%的请求在xx时间内响应时间小于20ms。

处理服务告警

如果你需要随时随地知道服务的运行状况，那么你需要构建一个适合自己业务的监控系统。
度量指标不是目的，需要为所度量指标设置合适的阈值，以在指标不符合预期的时候，能迅速做出反应，缩小影响范围，这才是重点。

如果你负责的系统是个要保证高吞吐、高可用的系统？你有自己的运维手册吗？

针对要求高吞吐、高可用的系统，当出现大批量的请求error怎么处理？
1.首先日常要关注服务可用性、请求qps、请求延迟指标。

2.当出现error时，根据报错内容判断。

• 一般是对某个接口报错，然后看报错的错误码。有些是访问qps过高，被限流了；有些是服务本身的错误，比如用户写入数据格式有问题，导致读取出来不正常， 还比如数据库突然有故障，导致访问出错；有些是网络问题，网络请求超时。
• 然后看报错这段时间内的具体报错日志+请求的上游和下游。
  特例： 也存在很多方法一起报错的，如果一个服务访问量突然猛增。则会将服务打爆，影响其他服务访问。这个要加一些措施保障的，比如对访问服务设置一个访问qps上限。

3.根据错误内容，选择不同方法处理

• 根据错误码，如果是功能使用错误问题，就按照规范格式写好就行
• 上游访问qps过高且服务资源不够，为了我们服务的正常运行，现对上游做点限流，等资源充足后再放开限制。
• 下游报错，及时通知下游处理。（熔断降级：当服务A的下游 服务B突然可用性降低或不可用，服务A可以自动切换与服务B的交互，从而保护自己可用。这个我没用过，还是不能盲目切断，尽量联系下游处理报错，或者让上游或者你的服务减少对下游的访问）。

建议：

1. 积累常见的服务的业务错误码和框架错误码
2. 多在实践中积累经验，有空可以学点运维知识。

参考文献：

《SRE Google运维解密》