基本概念

概念

SRE 稳定性保障的规划图

SRE 需要跨团队协作

  • 很多事情要依赖运维自动化，像容量扩缩容，会与运维团队有交集
  • 增加弹性与监控结合，就要与监控团队有合作
  • 依赖 DevOps 提供持续交付、配置变更，以及灰度发布这些基础能力，就要与开发和效能团队有交集

两个关键指标

  • MTBF，Mean Time Between Failure，平均故障时间间隔
  • MTTR，Mean Time To Repair， 故障平均修复时间。

MTTR 细分的 4 个指标

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

SRE 的目标
提升 MTBF，降低 MTTR

衡量标准

衡量系统可用性的 2 种方式

  • 时间维度：Availability = Uptime / (Uptime + Downtime)
  • 请求维度：Availability = Successful request / Total request

两个不同的维度

  • 时长维度，是从故障角度出发对系统稳定性进行评估
  • 请求维度，是从成功请求占比的角度出发，对系统的稳定性进行评估
  • SRE 更多偏向 请求维度

衡量的三个要素

  • 衡量指标，比如 5xx，体温超过37.2就是发烧
  • 衡量目标，比如 5xx 的总体比列，10 次测量多少次超过 37.2
  • 影响时长

故障一定意味着不稳定，但是不稳定，并不意味着一定有故障发生
SRE 关注的稳定性是系统的整体运行状态，而不仅仅只关注故障状态下的稳定性，在系统运行过程中的任何异常，都会被纳入稳定性的评估范畴中

设定系统稳定性目标要考虑的 3 个因素

  • 成本因素，4个9 成本很高，要考虑 ROI(回报率)，是否值得
  • 业务容忍度
  • 系统当前的稳定性状况，一步一个脚印，从99% 慢慢提升

SLI和SLO

设定稳定性衡量标准的 SLI 和 SLO

  • SLI 就是我们要监控的指标
  • SLO 就是这个指标对应的目标

常见的监控指标

指标分层 包含的指标
系统层面 CPU使用率、Load值、内存使用率、磁盘使用率、磁盘IO和网络IO等
应用服务器层面 端口存活状态，JVM的GC状况等
应用运行层面 请求返回的状态码、时延、应用层QPS、TPS以及连接数等
PaaS层面 MySQL、Redis、Kafka、MQ和分布式文件存储等组件，也都会有类似应用运行层的QPS、TPS及时延指标
数据层面 这里特指大数据类的平台，会有批处理任务或流处理任务，包含吞吐率、及时率和准确率等指标
业务层面 以电商为例，有在线用户数、新注册用户数、下单数、交易数、支付笔数以及业务层面的成功率等指标

选择 SLI 指标的两大原则

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

快速识别 SLI 指标的方法：VALET(Volume、Availability、Latency、Error 和 Ticket)

指标 含义
Volume-容量 是指服务承诺的最大容量是多少。比如，一个应用集群的 QPS、TPS、会话数以及连接数等等
Availablity-可用性 代表服务是否正常。如请求调用的非 5xx 状态码成功率，就可以归于可用性
Latency-时延 是说响应是否足够快。这是一个会直接影响用户访问体验的指标 通常会以类似“90% 请求的时延 <= 80ms，或者 95% 请求的时延 <=120ms ”这样的方式来设定时延 SLO
Errors-错误率 错误率有多少？这里除了 5xx 之外，我们还可以把 4xx 列进来
Tickets-人工介入 一个周期内需要人工介入才能恢复的次数，比如20

通过 SLO 计算可用性

  1. 直接根据成功的定义来计算
  • Successful = （状态码非 5xx） & （时延 <= 80ms）
  1. SLO 方式计算
  • SLO1：99.95% 状态码成功率
  • SLO2：90% Latency <= 80ms
  • SLO3：99% Latency <= 200ms
  • Availability = SLO1 & SLO2 & SLO3

错误预算

落地 SLO，先转化为 Error Budget
错误预算其实和驾照记分制是一样的，最大的作用就是“提示你还有多少次犯错的机会

错误预算：通过 SLO 反向推导出来

trade_cart 购物车这个应用为例
假设在 4 周的时间，这个应用所有的请求次数是 4,653,680
通过 SLO 反向推导的 错误预算

SLO Error Budget
99.95% Availability 23,268
90% Latency <= 80ms 465,368
99% Latency <= 200ms 46,536

应用 Error Budget

  • 稳定性燃尽图
    • 比如 4个自然周一个单位，配置额度
    • 需要考虑到新闻突发流量，双 11 这种大流量场景
  • 故障定级
    • trade_cart 请求成功率 SLO 对应的错误预算是 25,000 次
    • 如果一个问题产生的错误请求数超过了 5000 次，就是 P2 级别
    • 消耗 50% 以上，定为 P0 级
  • 稳定性共识机制
    • 剩余预算充足或未消耗完之前，对问题的发生要有容忍度
    • 剩余预算消耗过快或即将消耗完之前，SRE 有权中止和拒绝任何线上变更
    • 从推行的角度来讲，建立稳定性共识机制一定是 Top-Down，也就是自上而下，至少要从技术 VP 或 CTO 的角度去推行
    • 一定要自上而下推进周边团队或利益方达成共识
  • 基于错误预算的告警
    • 告警太多，如频繁报 CPU 使用率过高是没有意义的，时间久了就变成了狼来了
    • 第一，相同相似告警，合并后发送，比如同一应用集群内同一时间内，同一异常告警，就先合并，对外只发送一条
    • 第二，基于错误预算来做告警，也就是说我们只关注对稳定性造成影响的告警，比如我们前面提到的，当单次问题消耗的错误预算达到 20% 或 30% 等某一阈值时，就意味着问题非常严重
    • 基于错误预算的告警就会涉及到 AIOps 相关的领域
Error Budget - 错误预算 单次消耗比例 (Single Consumption Ratio) 故障等级 (Failure Level)
25,000 比例 <= 5% P4
5% < 比例 <= 20% P3
20% < 比例 <= 30% P2
30% < 比例 <= 50% P1
50% < 比例 P0

Google 给出的一个错误预算的燃尽图

衡量 SLO 的有效性

  • SLO 达成情况。我们用达成（Met），或未达成（Missed）来表示
  • “人肉”投入程度，高，或者低
  • 用户满意度，高，或者低

三种维度在不同情况下的应对策略

SLO Toil Customer Satisfaction Action
Met Low High Choose to (a) relax release and deployment processes and increase velocity, or (b) focus engineering time on reliability.
Met Low Low Tighten SLO.
Met High High If alerting is generating false positives, reduce sensitivity. Otherwise, loosen SLOs (or offload toil) and improve mitigation.
Met High Low Tighten SLO.
Missed Low High Loosen SLO.
Missed Low Low Increase alerting sensitivity.
Missed High High Loosen SLO.
Missed High Low Offload toil and fix product and/or improve automated fault mitigation.

针对这 8 种情况，分别给出对应策略。总结一下，应对方式可以分为 3 类

  • 第一类，收紧 SLO，目标定的太低，SLO 达成，但用户不满意
  • 第二类，放宽 SLO，目标太高，总是达不成，但是用户满意
  • 第三类，保持现状，对有问题的维度采取有针对性的优化措施
    • 比如表格第一行，是我们期望的最理想状态，SLO 能达成，人肉投入又低，客户满意度又很高，也没有特别的优化空间
    • 这时我们就可以增加发布和变更次数，更大程度地释放生产力

落地 SLO

先设定核心链路的 SLO，然后根据核心链路进行 SLO 的分解
核心链路：确定核心应用与强弱依赖关系

以电商的购物车，详情页，下单，购买为例，核心链路如下

确认强弱依赖关系

  • 核心应用之间的依赖关系，我们称之为强依赖
  • 而其它应用之间的依赖关系，我们称之为弱依赖

设定 SLO 的原则

  1. 核心应用的 SLO 要更严格，非核心应用可以放宽
  2. 强依赖之间的核心应用，SLO 要一致
  3. 弱依赖中，核心应用对非核心的依赖，要有降级、熔断和限流等服务治理手段
  4. Error Budget 策略，核心应用的错误预算要共享，就是如果某个核心应用错误预算消耗完，SLO 没有达成，那整条链路，原则上是要全部暂停操作的

如何验证核心链路的 SLO

  • 容量压测
    • 确保这核心链路完全正常，通过容量压测来确保正常，非核心业务需要熔断、降级、熔断
    • 之后可以考虑多链路，全链路压测
  • Chaos Engineering- 混沌工程
    • 混沌工程是 SRE 稳定性体系建设的高级阶段
    • 一定是 SRE 体系在服务治理、容量压测、链路跟踪、监控告警、运维自动化等相对基础和必需的部分非常完善的情况下才会考虑的
    • 核心就是错误预算充足就可以尝试，尽量避开错误预算不足的时间段
    • 还要评估故障模拟带来的影响，比如，是否会损害到公司收益？是否会损害用户体验相关的指标？

实践

On-Call 机制

聚焦 MTTR，故障处理的关键环节

从分布式系统的实际情况来看，整个 MTTR 的时间占比分布大致是这样的

MTTI：从发现故障到响应故障

  • 第一件事，判断出现的问题是不是故障
    • 靠基于 SLO 的告警，更加精准地告知我们当前系统的稳定性出现的问题
    • 并根据对 SLO 的影响程度，也就是错误预算的消耗情况作出判断，是否定性成故障
    • 如果是故障，我们就要启动应急响应，而高效快速的应急响应，是要靠 On-Call 的流程机制来保证的
  • 第二件事，确定由谁来响应和召集

这两件事，对应于 SRE 就是 On-Call 机制

On-Call 的流程机制建设

  1. 确保关键角色在线
  2. 组织 War Room 应急组织
  3. 建立合理的呼叫方式
  • 熟悉某个系统的最快最好的方式就是参与 On-Call，而不是看架构图和代码
  1. 确保资源投入的升级机制
  • 如果故障等级偏高，一下无法明确具体找哪些人员投入的时候，SRE 或运维可以直接上升到自己的主管或相关主管那里，要求上级主管协调资源投入
  • 必要时，还可以上升到更高级主管，甚至 CTO 或技术 VP 来关注。所以，授权非常关键
  1. 与云厂商联合的 On-Call

故障处理

在故障处理过程中采取的所有手段和行动，一切以恢复业务为最高优先级

一次典型的故障

  • 第一个，故障隔离手段缺失，所以从根本上就不具备业务恢复的技术手段
  • 第二，关键角色和流程机制缺失
    • 分工不明确，关键角色缺失，没有决策、反馈和通报机制，导致整个过程混乱失控
  • 第三，没有演练
    • 如果在相对比较宽松的氛围下，都不敢演练不敢操作，那真正出问题的时候就更不敢乱动
    • 另一种就是整个应急流程基本跑不起来，很多团队不配合，导致真正出故障的时候肯定更乱

建立有效的故障应急响应机制

关键角色分工

  • Incident Commander，故障指挥官，简称为 IC
    • 一开始是 SRE，等故障升级了可能是主管，甚至再高一级的 VP
  • Communication Lead，沟通引导，简称 CL
    • 负责对内和对外的信息收集及通报
  • Operations Lead，运维指挥，简称 OL
    • 负责指挥或指导各种故障预案的执行和业务恢复
  • Incident Responders，简称 IR，具体做事的人
  • 客服、PR 以及商家和其它各类合作代表
    • 如果故障特别大，需要他们来处理微博上的公关问题，安抚客户情绪

流程机制

  1. 故障发现后，On-Call 的 SRE 或运维，最一开始就是 IC，有权召集相应的业务开发或其它必要资源，快速组织 War Room
  2. 如果问题和恢复过程非常明确，IC 仍然是 SRE，就不做转移，由他来指挥每个人要做的具体事情，以优先恢复业务优先
  3. 如果问题疑难，影响范围很大，这时 SRE 可以要求更高级别的主管介入，比如 SRE 主管或总监等，一般的原则是谁的业务受影响最大，谁来牵头组织

反馈机制

  • 我们一般要求以团队为单位，每隔 10～15 分钟做一次反馈
  • 没有进展也是进展，也要及时反馈
  • 一般要求团队 Leader 来收集反馈并传递 IC 的指令
  • 快速恢复业务，信息同步的及时和透明也非常关键
  • 以尽量业务化的语言描述，并且要给到对方大致的预期
  • 如果故障的影响范围很广，那我们就要考虑得尽量周全，这时的故障处理在一定程度上，就不单单是技术团队的问题了，而是需要整个公司都投入资源的

故障复盘

故障复盘的黄金三问

  • 第一问：故障原因有哪些？
  • 第二问：我们做什么，怎么做才能确保下次不会再出现类似故障？
  • 第三问：当时如果我们做了什么，可以用更短的时间恢复业务？

故障根因不止一个
复盘的时候，不允许出现相互指责和埋怨的情况
要明确到底应该由谁来承担主要的改进职责

故障判定的三原则

  1. 健壮性原则
  2. 第三方默认无责
  • 对内谁的服务受影响谁改进，并对外推进第三方改进
  • 比如第三方 CDN 可以随时切换，云存储有备份
  1. 分段判定原则

互联网典型的SRE组织架构

技术架构图
职责

  • 基础设施层，IDC，物理机，虚拟机，存储，网络，偏传统运维，可以上云简化运维
  • 技术中台，如缓存、消息队列、数据库、对象存储、大数据产品等，这层都是有状态的
  • 业务中台，如用户、产品、交易、支付、风控、优惠券等
  • 业务前台，如 淘宝、天猫、盒马、聚划算这样的，基本都是无状态
  • 接入层，跟基础设施放在一起，但里面有很多业务层规划配置，会跟中台、前台一起运维
  • 技术保障平台，基于技术中台的能力之上生长出来的，技术中台的一部分
  • 运维能力一定是整个技术架构能力的体现，而不是单纯的运维的运维能力体现
  • 工具平台团队，负责效能工具的研发，比如实现 CMDB、运维自动化、持续交付流水线以及部分技术运营报表的实现，如 Git、Maven、代码扫描、自动化测试以及安全等平台
  • 稳定性平台团队，负责稳定性保障相关的标准和平台，比如监控、服务治理相关的限流降级、全链路跟踪、容量压测和规划，能力比 工具平台要求更高

明确

  • 第一，组织架构要与技术架构相匹配
  • 第二，SRE 是微服务和分布式架构的产物

云原生架构

想要引入 SRE 体系

  • 对应的组织架构调整首先要看我们的技术架构是不是在朝着服务化和分布式的方向演进
  • 如果架构还没这么复杂，其实也没有必要引入 SRE 这么复杂的运维体系
  • 要想在组织内引入并落地 SRE 这套体系，原有技术团队的组织架构，或者至少是协作模式必须要做出一些变革才可以

组织架构图

SRE = PE + 工具平台开发 + 稳定性平台开发

高效的SRE组织协作机制

以赛带练
一定要先考虑自己的业务系统应对的极端场景到底是什么，然后基于这些场景去设计和规划

SRE 的各个角色如何协作

  • 第一步，大促项目开工会
    • 指定负责人，明确团队分工和团队接口人，根据日期，倒排全链路压测计划
  • 第二步，业务指标分解及用户模型分析评审会
    • 共同分析出核心链路，QPS情况，大致判断要扩容的资源需求
    • PE 会更多地从全局角度关注线上真实的运行状态
  • 第三步，应急预案评审会
    • 准备好限流、降级和熔断策略
    • 具体的限流值是多少、降级和熔断的具体条件是怎样的
    • PE 更多地是负责平台级的策略，如Nginx 怎么限流，缓存失效怎么降级
    • 业务开发则要更多地考虑具体业务逻辑上的策略，如评论故障是否可以不显示
  • 第四步，容量压测及复盘会
    • 压测过程会分为单机、单链路和全链路几个环节
    • 压测过程中和每次压测结束后，都要不断地总结和复盘，然后再压测验证、扩容和调优
    • 这个过程一般要持续 2～3 轮，时间周期上要 3～4 周左右

赛场上的优化

  • 第一项，核心应用变更及新上线业务的稳定性评审工作
  • 第二项，周期性技术运营工作

参考