SRE

20221118163214

SRE只有一个目标:提升 MTBF,降低 MTTR

可用性目标

衡量维度:

这两种算法最后都会落脚到“几个 9”上

需要考虑:

稳定性衡量标准

SLI的选择

  1. 够标识一个主体是否稳定
  2. 优先选择与用户体验强相关或用户可以明显感知的指标

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

  1. Volume 容量:服务承诺的最大容量是多少。比如,一个应用集群的 QPS、TPS、会话数以及连接数等
  2. Availablity 可用性:代表服务正常与否
  3. Latency 时延:有针对性地取置信区间内的延迟,而非简单的平均,否则会使问题被隐藏在平均之下
  4. Errors 错误率
  5. Tickets 人工介入频次:一项工作或任务需要人工介入,那说明一定是低效或有问题的

在云服务中提供商SLA中,很少能制定像 SLO 这么细粒度稳定性目标,更多的是使用简单的可用性衡量:成功请求数/总请求数 这种

SLO的设定

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

SLO的验证:

  1. [容量压测](/软件工程/容量保障.html#容量测试)
  2. [混沌工程](/软件工程/架构/系统设计/混沌工程.html),一定是 SRE 体系在服务治理、容量压测、链路跟踪、监控告警、运维自动化等相对基础和必需的部分非常完善的情况下才会考虑

错误预算

在 SLO 落地实践时,SLO 可以被转化为错误预算,即你有多少次出问题的机会,以此来推进稳定性目标达成,为了达成 SLO,就要尽量减少对错误预算的消耗

当错误预算还很多,对异常及错误容忍就比较高,当错误预算快要被耗尽了,就应该尽量解决问题,减少或拒绝变更

故障发现

第一件事,判断出现的问题是不是故障;第二件事,确定由谁来响应和召集

即建立完善的监控体系及 On-Call 机制

On-Call 的流程机制建设:

  1. 确保关键角色在线
  2. 组织 War Room 应急组织
  3. 建立合理的呼叫方式,进行On-Call轮班
  4. 确保资源投入的升级机制,授权非常关键
  5. 与云厂商联合的 On-Call

故障处理

有效的故障应急响应机制:

  1. 角色分工:指挥核心、内外信息收集通报、运维指挥操作、其他人员(事故相关方)
  2. 流程机制:快速组织救火队,以恢复业务为最高优先级,如果问题疑难,必须向上抛
  3. 反馈机制:定时汇报进度,不管有没有,防止故障继续蔓延

故障复盘

由谁来承担主要的改进职责-故障判定三原则:

  1. 健壮性原则:每个部件自身要具备一定的自愈能力,做好对外部依赖的防御
  2. 第三方默认无则:外部是不可靠的,还是做好防御
  3. 分段判定原则:根因不止一个