SRE实战手册-基础篇

让体系发挥出力量，而不是某项技术的能力。

Content

Content
稳定性保障体系
系统可用性
- 描述系统稳定性
  - 时间维度
  - 请求维度
  - 选择合适的 SLI（指标）
  - 设定系统稳定性 SLO（目标）
- 错误预算

稳定性保障体系

稳定性保障规划图：

MTBF，MeanTimeBetweenFailure，平均故障时间间隔，指示了系统正常运行的阶段。
MTTR，MeanTimeToRepair，故障平均修复时间，意味着系统故障状态的阶段。

要提升稳定性，就会有两个方向：提升 MTBF，减少故障发生次数，提升故障发生间隔时长；
降低 MTTR，故障不可避免，那就提升故障处理效率，减少故障影响时长。

MTTR 又可以细分为：

MTTI，MeanTimeToIdentify，平均故障发现时间，也就是从故障实际发生，到我们真正开始响应的时间。这个过程可能是用户或客户反馈、舆情监控或者是监控告警等渠道触发的。
MTTK，MeanTimeToKnow，平均故障认知时间，可以理解为平常说的平均故障定位时间。这个定位指的是 root cause，也就是根因被定位出来为止。
MTTF，MeanTimeToFix，平均故障解决时间，也就是从知道根因到采取措施恢复业务为止。这里的手段就很多了，比如常见的限流、降级、熔断，甚至是重启。
MTTV，MeanTimeToVerify，平均故障修复验证时间，就是故障解决后，通过用户反馈、监控指标观察等手段，来去人业务是否真正恢复所用的时间。

最终的目标就是：提升 MTBF，降低 MTTR

在业务的发展阶段，越早参与业务越好，并不一定参与设计本身，但是要知道在哪里提出稳定性要求。
比如：大促场景，要知道流量可能是怎么样的，限流措施要设定在哪些接口上，限流量多达，通过什么方式验证等等。

系统可用性

没有故障，不代表稳定。

描述系统稳定性

系统可用性衡量方式：

时间维度：Availability = uptime / (uptime + downtime)
请求维度：Availability = successful request / total request

时间维度

什么算是可用时长，什么算是不可用时长？

指标：SLI
目标：SLO

对于 SRE 来说，距离用户越近的指标，越有价值。

需要制定三个要素：衡量指标、衡量目标、影响时长。
比如：系统请求状态码非 5xx 比例低于 95%，已经超过 10 分钟，那么这 10 分钟就要算入 downtime（宕机时间）。这里的衡量指标，系统请求状态码；衡量目标，非 5xx 占比达到 95%；影响时长，持续 10 分钟。

在一个周期内，允许的系统 downtime 是有限的，用这个有限的时间来约束系统稳定性。

根据时长维度计算的可用性最显著的问题就是，稳定性只与故障发生挂钩。
如果一个系统因为网络抖动，短暂的几秒，十几秒异常，后来系统自己恢复了，业务没有中断，如果按照时长维度来判断，这肯定不算做系统故障。但是如果这种短暂的影响频度非常高，一天来个5、6次，持续好几天，就可以判定系统运行状况是不长长的，虽说不是故障，但肯定是不稳定了。

请求维度

请求维度，有三个关键要素：衡量指标、衡量目标、统计周期。
比如：系统一天内有 10w 次请求，期望成功率 95%，如果有 5001 次请求失败，那就认为系统运行状态是不正常的。

选择合适的 SLI（指标）

常见的一些监控指标：

系统层面：CPU 使用率、Load 值、内存使用率、磁盘使用率、IO 等；
应用服务器层面：端口存活状态、JVM 的 GC 状况等；
应用运行层面：响应状态码、时延、应用层 QPS、TPS 以及连接数等；
PaaS 层面：MySQL、Redis、MQ 和分布式文件存储等组件，也会有对应的 QPS、TPS 及时延等指标；
数据层面：吞吐率、及时率和准确率等；
业务层面：在线用户数、新注册用户数、下单数、交易数、业务层面的成功率等。

首先要确定衡量谁的稳定性？先找到稳定性的主体。
这个指标能够标识这个实例是否稳定吗？

选择 SLI 指标的两大原则：
1、选择能够标识一个主体是否稳定的指标，如果不是这个主体本身的指标或者不能标识主体稳定性的，就要排除在外。
2、针对有用户界面的业务系统，优先选择与用户体验强相关或用户可以明显感知的指标。

快速识别 SLI 指标的方法：VALET

Volume - 容量
不同时间段的容量，也是要看不同的平台。

Availability - 可用性
注意对于不同的平台来说，是否可用的描述标准是不一样的。
比如业务上可能是非 5xx 状态码标识可用，但是对于数据平台，需要看任务的执行状态码之类的情况。

Latency - 时延
设置置信区间，比如 “90% 请求时延 <= 80ms 或者 95% 请求时延 <= 120ms”

Errors - 错误率
还可以将业务角度的一些错误码纳入，比如用户登录验证码总是输入错误，或者热门商品总是缺货等。哲哲从用户体验影响上还是较大的。

Tickets - 人工介入
一个周期内，tickets 的数量是有限的，如果消耗完了，还需要人工接入，那就是不达标的了。

设定系统稳定性 SLO（目标）

稳定性目标定“几个9”？

成本因素、业务容忍度、系统当前的稳定性状况。

如何衡量 SLO 的有效性？

SLO 达成情况，使用达成 Met 或未达成 Missed 来标识。
“人肉”投入程度，英文标识 Toil，使用 High 和 Low 来标识。
用户满意度，CustomerSatisfaction，可以理解为用户感受和体验如何，使用 High 和 Low 表示。

3 个维度，每个维度 2 种情况，组合起来 8 种情况。

设定 SLO 有哪些原则？

核心应用的 SLO 要更严格，非核心应用可以放宽。
强依赖之前的核心应用，SLO 要一致。
比如：下游核心业务要求 99.95%，如果依赖的上游业务只有 99.9% 那么这个链路的成功率是达不成目标的。应该提升上游的业务稳定性。
弱依赖中，核心应用对非核心应用的依赖，要有降级、熔断和限流等服务治理手段。
避免非核心影响到核心业务。
ErrorBudget 策略，核心应用的错误预算要共享，如果某个核心应用错误预算消耗完，SLO 没有达成，那整条链路，原则上是要全部暂停操作的。

如何验证核心链路的 SLO？

容量压测
混沌工程

混沌工程是 SRE 稳定性体系建设的高级阶段，一定是在 SRE 体系在服务治理、容量压测、链路跟踪、监控告警、运维自动化等相对基础的必须的部分非常完善的情况下才会考虑的。
引入混沌工程要慎重！

应该在什么时机做系统验证？

预算充足的情况下。

错误预算

SLO 如何知道具体的工作？反过来指定一个允许犯错误的次数标准。

落地 SLO，先转化为 Error Budget，翻译过来就是错误预算，提示你还有多少次犯错的机会。

如何应用 Error Budget？

稳定性燃尽图
在一个周期内，比如 4 个自然周，错误预算被消耗完了，尽管没有出现达到故障标准的问题，这个周期的稳定性要求其实也是不达标的。然后可视化的展示出来。
这个周期为什么是 4 个自然周而不是 1 个自然月呢？主要是因为自然月通常会导致跨州的情况出现，相比于 4 个自然周，在统计上就要考虑额外的边界问题。
还需要考虑到一些特殊场景，比如大促发生在这个周期内，有些场景必然导致消耗很多错误预算，所以应该适当地考虑放大错误预算的值。
故障定级
稳定性共识机制
当驾照剩下 1 分的时候，开车很慢甚至不开车。
- 剩余预算充足或未消耗完之前，对问题的发生要有容忍度。
  不要有一点点波动就钻进去排查问题去了。
- 剩余预算消耗过快或即将消耗完之前，SRE 有权终止和拒绝任何线上变更。
  此时说明系统稳定性可能出了很大的问题，不能再让他“带病工作”。
- 从推行的角度来讲，建立稳定性共识机制一定是 Top-Down，也就是自上而下，至少要从技术 VP 或 CTO 的角度去推行。
基于错误预算的告警
报警收敛，避免出现“狼来了”。
比如：相似的告警合并发送；基于错误预算的告警，单词问题消耗的错误预算达到 20% 或 30% 等某一阈值的时候，就意味着非常严重了，要马上做出相应。