SRE 实战手册

这是一篇关于SRE 实战手册的思维导图

SRE 实战手册

• 理解SRE：SRE 一定是靠整个技术和组织体系发挥作用的，单纯从某个技术点或环节出发，都无法呈现出效果，也就是说 SRE 一定要从全局考虑，体系一定要“配套”。
• 根本目的：提升MTBF，降低MTTR
  • MTBF：平均故障时间间隔
  • MTTR：故障平均修复时间
    • MTTI：平均故障发现时间
    • MTTK：平均故障认知时间
    • MTTF：平均故障解决时间
    • MTTV：平均故障修复验证时间
• 衡量系统可用性的方式
  • 定一个合理的标准比定一个更高的标准会更重要。
  • 设定稳定性目标的因素
    • 成本因素
    • 业务容忍度
    • 系统当前稳定性状况
  • 时间维度
    • 公式：availability = uptime / (uptime + downtime)
    • 优点
      • 简单粗暴
    • 缺点
      • 粒度不够精细，比如单次网络抖动，很快自己就恢复了。
    • downtime 判断要素
      • 衡量指标
        • 例如 系统请求状态码
      • 衡量目标
        • 例如 非 5XX 占比，也就是成功率达到 95%
      • 影响时长
        • 持续 10 分钟
  • 请求维度(推荐使用)
    • 故障一定意味着不稳定，但是不稳定，并不意味着一定有故障发生。
    • 公式：availability = successful request / total request
    • 优点
      • 颗粒度精细
    • 缺点
      • 判定标准指定相对复杂
    • successfule 判断要素
      • 衡量指标
        • 例如 请求成功率
      • 衡量目标
        • 例如 成功率达到 95%
      • 统计周期
        • 例如 一周，业内比较标准的是按照四个自然周计算
• 设定稳定性衡量标准
  • SLI
    • Service Level Indicator，服务等级指标，其实就是我们选择哪些指标来衡量我们的稳定性。
    • SLI 选择
      • 常见的监控指标
      • 两个问题，协助选择
        • 我要衡量谁的稳定性？
        • 这个指标能够标识这个实例是否稳定吗？
      • 举例
        • 正面
          • 请求返回状态码
          • 请求处理延迟
        • 反面
          • CPU 使用率
            • CPU 的使用不能完全代表服务是否稳定，比如达到 95% 但是处理能力满足，达到 10% 但网络或其他原因中断导致请求失败，不管 使用率是多少都不能直接反应服务运行状态，所以并不适合作为 SLI 指标
      • 选择 SLI 的原则
        • 选择能够标识一个主体是否稳定的指标，如果不是这个主体本身的指标，或者不能标识主体稳定性的，就要排除在外。
        • 针对电商这类有用户界面的业务系统，优先选择与用户体验强相关或用户可以明显感知的指标。
    • 快速识别 SLI 的指标的方法：VALET
      • Volume：容量
        • 服务承诺的最大容量是多少。比如，一个应用集群的 QPS、TPS、会话数以及连接数等等，如果我们对日常设定一个目标，就是日常的容量 SLO，对双 11 这样的大促设定一个目标，就是大促 SLO。对于数据平台，我们要看它的吞吐能力，比如每小时能处理的记录数或任务数。
      • Availablity：可用性
        • 服务是否正常。比如，我们前面介绍到的请求调用的非 5xx 状态码成功率，就可以归于可用性。对于数据平台，我们就看任务的执行成功情况，这个也可以根据不同的任务执行状态码来归类。
      • Latency：延迟
        • 响应是否足够快。这是一个会直接影响用户访问体验的指标。对于任务类的作业，我们会看每个任务是否在规定时间内完成了。
        • 通常对于时延这个指标，我们不会直接做所有请求时延的平均，因为整个时延的分布也符合正态分布，所以通常会以类似“90% 请求的时延 <= 80ms，或者 95% 请求的时延 <=120ms ”这样的方式来设定时延 SLO，熟悉数理统计的同学应该知道，这个 90% 或 95% 我们称之为置信区间。
      • Errors：错误率
        • 错误率有多少？这里除了 5xx 之外，我们还可以把 4xx 列进来，因为前面我们的服务可用性不错，但是从业务和体验角度，4xx 太多，用户也是不能接受的。
      • Tickets：人工介入
        • 是否需要人工介入？如果一项工作或任务需要人工介入，那说明一定是低效或有问题的。举一个我们常见的场景，数据任务跑失败了，但是无法自动恢复，这时就要人工介入恢复；或者超时了，也需要人工介入，来中断任务、重启拉起来跑等等。
        • Tickets 的 SLO 可以想象成它的中文含义：门票。一个周期内，门票数量是固定的，比如每月 20 张，每次人工介入，就消耗一张，如果消耗完了，还需要人工介入，那就是不达标了。
      • Google 基于 VALET 设计出的 SLO 的看板样例
  • SLO
    • Service Level Objective，服务等级目标，指的就是我们设定的稳定性目标。
    • 通过 SLO 计算可用性
      • SLA 方式计算
        • 计算方式简单直接，规则相对 SLO 宽松，一般用于商业承诺，无法达到要进行赔偿
        • 定义 successful 的公式，比如 Successful = （状态码非 5xx） & （时延 <= 80ms），再结合 Availability = Successful request / Total request 公式
      • SLO 方式计算(推荐)
        • 计算方式精细化，一般用于公司内部对于可用性的衡量标准
        • 定义不同的 SLO 细则 SLO1：99.95% 状态码成功率 SLO2：90% Latency <= 80ms SLO3：99% Latency <= 200ms 最终通过以下公式计算可用率 Availability = SLO1 & SLO2 & SLO3
    • 如何衡量 SLO 的有效性
      • 衡量指标
        • SLO 达成情况：我们用达成（Met），或未达成（Missed）来表示。
        • “人肉”投入程度：需要大量人工投入、重复、繁琐且没有太多价值的事情。我们用投入程度高（High）和低（Low）来表示。
        • 用户满意度：用户感受和体验如何。这个信息可以通过真实和虚拟渠道获得。真实渠道如客服投诉、客户访谈和舆情监控获取；虚拟渠道如真机模拟拨测。我们用满意度高（High）和低（Low）来表示。
      • 判断标准
        • 总结 1. 收紧 SLO：SLO 达成，用户不满意。说明我们的 SLO 设定得太容易达成，没有反馈真实的运行状况。 2. 放松 SLO：SLO 未达成，用户反馈不错。这种就会造成错误预算提前消耗完，导致很多变更暂停，产品延期，甚至会做一些无谓的优化，这时就可以适当松松绑。 3. 保持现状：是我们期望的最理想状态，SLO 能达成，人肉投入又低，客户满意度又很高，也没有特别的优化空间，这时我们就可以增加发布和变更次数，更大程度地释放生产力。
    • 落地 SLO 需要考虑的因素
      • 梳理出业务的核心链路，核心业务、非核心业务、业务之间的强弱依赖关系
      • 设定 SLO 的原则
        • 第一，核心应用的 SLO 要更严格，非核心应用可以放宽。 这么做，就是为了确保 SRE 的精力能够更多地关注在核心业务上。
        • 第二，强依赖之间的核心应用，SLO 要一致。 比如下单的 Buy 应用要依赖 Coupon 这个促销应用，我们要求下单成功率的 SLO 要 99.95%，如果 Coupon 只有 99.9%，那很显然，下单成功率是达不成目标的，所以我们就会要求 Coupon 的成功率 SLO 也要达到 99.95% 。
        • 第三，弱依赖中，核心应用对非核心的依赖，要有降级、熔断和限流等服务治理手段。 这样做是为了避免由非核心应用的异常而导致核心应用 SLO 不达标。
        • 第四，Error Budget 策略，核心应用的错误预算要共享，就是如果某个核心应用错误预算消耗完，SLO 没有达成，那整条链路，原则上是要全部暂停操作的
      • 如何验证核心 SLO：容量压测、混沌工程（SRE 稳定性体系建设的高级阶段）
• 错误预算（Error Budget）
  • SLO 目标定好了，很具体，但实施起来不直观，那我们是不是也可以反过来看，制定出一个允许犯错的次数标准，这样我们就监控这些错误就好了。 错误预算其实和驾照记分制是一样的，最大的作用就是“提示你还有多少次犯错的机会”，并且，错误预算的警示效果比看成功率这种统计数据更直观，感官冲击力更强。
  • 如何计算：根据 SLO 反向推导
    • 假设在 4 周的时间，这个应用所有的请求次数是 4,653,680，按照给出的 SLO 反向推导，就可以得到容许的错误次数，这就是错误预算。
  • 如何应用
    • 稳定性燃尽图
      • 直观的表现出错误预算消耗情况，时刻看到还能有多少犯错的机会，大大增强对生产系统的敬畏之心，消耗到一定比例开始预警，控制变更频率，或投入精力解决影响稳定性的问题。
    • 故障定级
      • 判断是不是故障，影响有多大，除了看时长外，更具操作性的方法就是按照这个问题消耗的错误预算比例来评判。
      • 真正实际工作中，这个具体数值可以根据实际业务情况和容忍度来制定。
    • 稳定性共识机制
      • 剩余预算充足或未消耗完之前，对问题的发生要有容忍度。
      • 剩余预算消耗过快或即将消耗完之前，SRE 有权中止和拒绝任何线上变更。
    • 收敛告警
      • 方式一：相同相似告警，合并后发送，比如同一应用集群内同一时间内，同一异常告警，就先合并，对外只发送一条，这种比较简单直接。
      • 方式二：基于错误预算来做告警，也就是说我们只关注对稳定性造成影响的告警，比如我们前面提到的，当单次问题消耗的错误预算达到 20% 或 30% 等某一阈值时，就意味着问题非常严重了，这种告警信息一旦收到，就要马上做出响应。这样告警数量不多，既达到了收敛效果，又非常精准。