再读 Google SRE 运维揭秘

[lzh2nix]

2022年做告警时看过一遍, 最近再去看部分章节的时候依然发现了一些宝贝, 计划再整体看一遍(学习Google方式). 8月份技术书籍就他了.

Google 确实是开放自己系统的先行者, 从开放BigTable, GFS, MapReduce 再到k8s, 一直走在前列.

Content

• 赞序(2023.07.28)
• PART I 概述-CH1 介绍(2023.07.29)
• PART I 概述-CH2 Google 生产环境: SRE视角(2023.07.29)
• PART II 指导思想-CH3 拥抱风险(2023.08.01)
• PART II 指导思想-CH4 服务质量目标(2023.08.04)
• PART II 指导思想-CH5 减少琐事(2023.08.04)
• PART II 指导思想-CH6 分布式系统的监控(2023.08.05)
• PART II 指导思想-CH7 Google 自动化系统的演进(2023.08.05)
• PART II 指导思想-CH8 发布工程(2023.08.08)
• PART II 指导思想-CH9 简单化(2023.08.09)
• PART III 具体实践-CH10 基于时间序列进行有效告警(2023.08.10)
• PART III 具体实践-CH11 OnCall 轮值(2023.08.11)
• PART III 具体实践-CH12 有效的故障排查手段(2023.08.12)
• PART III 具体实践-CH13 紧急事件响应(2023.08.12)
• PART III 具体实践-CH14 紧急事故管理(2023.08.13)(2023.08.12)
  PART III 具体实践-CH15 事故总结:从失败中学习(2023.08.13)
  PART III 具体实践-CH16 跟踪故障(2023.08.13)
• PART III 具体实践-CH18 SRE 部门中的软件工程实践(2023.08.16)
• PART III 具体实践-CH19 前端服务器的负载均衡(2023.08.21)
• PART III 具体实践-CH20 数据中心内部的负载均衡系统(2023.08.21)
• PART III 具体实践-CH 21 应对过载(2023.08.22)
• PART III 具体实践-CH22 处理连锁反应(2023.08.26)
• PART III 具体实践-CH23 管理关键状态, 使用分布式共识来提供可靠性(2023.08.27)
  
• PART III 具体实践-CH24 分布式周期性任务系统(2023.08.27)
• PART III 具体实践-CH27 可靠的进行产品的大规模发布(2023.08.27)
• 完结(2023.08.27)

[lzh2nix]

赞序(2023.07.28)

SRE 其实代表着一套全新的运维理念, 以及这套理念对应的运维体系以及最佳实战
SRE 主要职责:

• 保证线上系统的稳定性
• 各项服务的性能
• 深度参与开发阶段的工作, 对应用程序的设计实现方式, 依赖库,运行时的资源消耗都有严格的规约
• 本身也开发工具来解放自己

SRE 目标: 在一定的错误预算(容错率)下, 即能保证用户体验又不影响创新和部署的速度

可以关注一下SRECon

sre in pragmatic:

• 在设计评审中不断推演各种灾难场景
• 在例会上讨论如何消除和防范事故, 以及优化各种报警策略和提高自动化
• 精心维护各种文档和源代码

以"日拱一卒"的态度来不断的解决根问题, 从而提升服务质量

使用计算机科学和软件工程的手段来设计和研发大型分布式系统

• 开发通用系统在多个产品之间复用(告警/发布系统, 基础组件)
• 软件系统架构是设计
• 运维流程的优化
  目标: 使系统运行的更可靠, 扩展性更好, 能更有效的利用资源

概述--->指导思想--->具体实践--->管理

最近看书发现一个技巧, 在看书之前一定要了解一下作者的章节安排, 然后再跟着作者的思路一步步往前走, 这样不容易走丢(知道目的是什么).

Back To Top

[lzh2nix]

概述-CH1 介绍(2023.07.28)

传统模式:
开发--->快速的开发新的功能到线上
运维--->减少问题处理, 完全手动(大部分故障是发布导致的)
关键点在于两个团队的目标是冲突的, 没有人来整体负责开发速度和线上质量, 而且无法scaling up, 好多东西都需要手动操作.

Google SRE 模式:
通过软件系统来替代传统的人工模式, 解放人员, 去做更多自动化是的事情

SRE构成:

• 50%~60% 标准的软件工程师
• 40%50% 满足google 标准的软件工程师(unix内部细节和13层网络知识)
  保证能将人肉工作快速自动化, 通过软件工程的方法来结局复杂的运维问题

sre 团队的两个特点

• 对重复性, 手工性的操作天然的排斥感
• 有足够的技术能力快速开发出软件系统以替代手工操作

指导思想:
用软件工程思维和方法论完成之前的手动操作, 通过解放人力来做更多有意义的事情

保证50%的时间是在做真实的开发工作

Error Budget 统计

SRE 方法论:

1. 确保长期关注研发工作

   • 确保团队有足够的时间去关注效率的事情(开发工具)
   • 运维支处理oncall(确保8~12小时最到2次oncall)的事情, 其他事情能研发自主完成(或者需要人参与能系统自动化完成)
   • 让出更多的时间来反思和改进系统

2. 在保障服务SLO的前提下最大化迭代速度
   通过引进"错误预算"的概念来解决开发和运维之间的组织架构冲突. SRE团队的目标不再是"0事故运行", SRE和研发目标保持一致, 在保障业务服务可靠性需求的同时尽可能的快速迭代产品上线.

3. 监控系统
   一个需要人工阅读邮件和分析告警来决定是否需要采取行动的系统本质上是错误的. 监控系统不应该依赖人来分析告警信息, 而是应该由系统来完成自动分析, 仅当需要用户操作时才执行通知用户. 监控系统的三类输出:

   • 紧急告警(alert): 收到告警需要立即处理, 目标是解决真正发生的事情或者阻止正在发生的事情.
   • 工单(ticket): 不需要立即处理, 但是需要记录下来, 可以作为一个长期任务
   • 日志(logging): 留着以备后用

4. 应急事件处理
   SRE一个主要考核指标是MTTR(故障平均恢复时间).
   任何需要人工参与的操作只会延长故障恢复时间, 一个自动恢复的系统及时有更多的故障发生, 也要比事事需要人工参与的系统可靠性更高. 通过将常见故障写到运维手册上来降低MTTR.

5. 变更管理
   70%的故障都是由部署变更触发. 变更管理的几个最佳实战.

   • 采用渐进式的发布机制
   • 迅速而准确地检测到问题的发生
   • 当出现问题时, 安全快速的回退

6. 需求预测和容量规划
   满足未来业务的发展需求, 容量规划的几个步骤:

   • 必修有一个准确的自然增长的预测模型
   • 规划中必须有准确的非自然增长的需求来源统计
   • 必须有周期性的压测,以便将系统原始资源和业务容量对应起来

7. 资源部署

8. 效率与性能
   高效地利用各种资源. 不断的改进系统性能来提供资源的利用率

第一章绝对是精华中精华, 一个全局的视角.

Back To Top

[lzh2nix]

概述-CH2 Google 生产环境:SRE视角(2023.07.29)

google 最大的特点是自己有一套独立的系统:

• B4:覆盖全球的骨干网络
• 动态管理网络带宽(bwE) https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/43838.pdf
• Borg: 集群管理系统(任务的编排和管理)
  • 根据需求(3C 2G)动态调度
  • 服务和具体机器IP解耦出来(BNS)
  • 异常机器自动kill掉, 让他重启
• GFS/Colossus 提供全局可靠的存储系统
• 大三层的负载均衡 DNS--->服务层面--->RPC层面
• Chubby: 分布式锁
• BorgMon 监控报警系统
  • 对真实问题进行监控
  • 服务更新前后对比
  • 检查资源使用量随着时间的变化情况(目的是合理制定资源更新计划)

Back To Top

[lzh2nix]

指导思想-CH3 拥抱风险(2023.08.01)

要求太高的可用性会增加两个维度的成本:

• 资源成本: 更好的可用性也就意味着更多的资源冗余
• 机会成本: 提供更多的资源来构建风险较少的系统, 从而占用了一些功能开发的时间

管理服务的可用性---> 管理风险--->在可以接受的情况下提高研发效率

度量可用性的两位维度:
公式1 可用性 = (系统正常运行时间)/(正常运行时间+故障时间) 也就是经常听到的 99.999% 计算公式, 基于时间的可用性.
公式2 成功请求数 / 总请求数 通过请求成功率在计算系统可用性
Google 内部更多的是使用公式2来计算可用性(大多数非服务性的系统不合适用公式1来计算)

辨别消费者对服务可用性的容忍度:

• 需要的可用性水平是什么?
• 不同类型的失败对服务有哪些不同的影响?
• 如何通过服务成本来帮助在风险曲线是那个定位这个服务?
• 有哪些服务指标需要考虑?

错误预算的构建过程:
基于服务SLO计算出一个季度错误预算(错误预算提供了一个明确的,客观的指标来决定服务在一个季度中能接受多少可靠性)

google的做法:

1. 产品管理层定义一个SLO, 确定一项服务在每个季度预算的正常运行时间.
2. 通过监控系统计算实时在线时间
3. 这两个数字之间的差值就是剩余的可靠性预算
4. 还有可靠性预算就可以计算发布,否则冻结发布

好处:

1. 激励研发和SRE一起找出创新和可靠性之间的合理平衡点
2. 利用错误预算识别出定义了太高的可用性(可用性的有效性), 从而降低了开发的速度, 这时可以降低SLO来提供创新速度

Back To Top

[lzh2nix]

CH4 指导思想-服务质量目标(2023.08.05)

在一个服务质量的目标下运维一个系统, 不断的优化去满足这个质量目标
SLI: 服务质量指标, 服务的具体量化指标
几个常用指标:

1. 请求延时(系统处理消耗的时间)
2. 错误率(请求处理失败的百分比)
3. 系统吞吐(每秒请求数)
4. 可用性(服务可用时间百分百)

SLO: 服务质量目标, 服务具体SLI的目标值 SLI <= 目标值, 最关键的还是可用性
Chubby 计划内停机: 通过演练来发现不合理的依赖

SLA: 服务质量协议 服务与用户之间的协议

SLO在实践中的应用
从目标---->推到出----->对应的指标
通过SLO来指导告警, 避免出现指标不满足SLO的情况出现

SLO 选择原则:

1. 不要已目标的状态为基础选择目标(从全局出发不要局限在当前系统上)
2. 保持简单(SLI中过于复杂的汇总模式可能会掩盖某种系统性能的变化)
3. 避免绝对值(避免空想, 阈值定的太高)
4. SLO越少越好(仅仅选择足够的SLO来覆盖系统属性, 确保SLO, 不可进一步删减)
5. 不要追求完美
6. SLO来指导SLI的告警,定义告警出来之后的action

Back To Top

[lzh2nix]

CH5-减少琐事(toil)(2023.08.05)

琐事的几个特征:

• 手动性的
• 重复性的
• 可以被自动化的
• 战术性(突然出现的,应对式的工作,而非策略驱动和主动安排的, 紧急告警时琐事,无法完全消除此类工作, 我们必须努力减少它)
• 没有持久价值的工作
• 随着服务呈线性增长
  减少琐事, 然后花多的精力工程工作(自动化)

Back To Top

[lzh2nix]

CH6-分布式系统的监控(2023.8.05)

为什么要监控:

• 分析长期趋势
• 跨时间范围的比较,或者观察实验组和控制组的区别
• 告警
• 构建监控台页面
• 临时性的问题回溯

告警很容易引发 “狼来了”, 告警太多很容易忽略掉真实发生的故障.

监控系统本身是一个很复杂的工程项目, 需要考虑指标收集, 显示, 以及告警, 需要专人去做.

监控系统应该解决的两个问题:

• 什么东西出故障? ----> 告警规则
• 为什么出故障? ------> 根因分析

黑盒监控: 相向现象的监控, 从外部监控系统
白盒监控: 更偏向通过内部来监控系统

监控的四个黄金指标:

• 延迟 TP99的延时
• 流量 QPS, 系统负载的流量
• 错误 错误状态码响应
• 饱和度 服务有多"满"

告警系统系统要做的简化, 直到不能再简化

• 最能反映真实故障的规则应该越简单越好, 可预测性强, 非常可靠
• 不常用的监控项, 数据应该定期删除

增加一个监控项时需要考虑一下几点:

• 该规则是否已经被当前的规则覆盖到了, 紧急的, 有操作性的
• 是否可以忽略这条告警? 什么情况下会导致用户忽略这条告警, 如何避免?
• 这条告警出来时候是否意味着用户正在收到影响? 是否存在用户没有收到影响, 这条告警规则也会触发的场景?
• 收到告警后是否有可执行的操作? 该操作是否可以自动化

onCall告警的一些理念:

• onCall 必须很少
• 收到onCall时必须要做某种操作
• onCall的告警必须要某种智力分析过程
• 每个紧急告警都应该是一个新的问题, 不应该彼此重叠

紧急监控应该关注现象, 针对原因的一些启发性分析应该作为调试分析的补充, 而不应该进行告警.

Back To Top

[lzh2nix]

CH7 Google 自动化系统的演进(2023.08.05)

采用系统自动化解决系统中的常见问题 降低一些常见故障的平均修复时间(MTTR)

通过一些常见的程序来构架自动化系统(Puppet, Chef, cfengine, Perl, Python).

Back To Top

[lzh2nix]

CH8 发布工程(2023.08.08)

发布工程: 专注于构建和交付软件

源代码管理-->编译器--->构建配置语言--->自动化构建工具--->包管理--->安装

发布工程的四个指导思想:

• 自服务模型:整体构建+发布是自动化的, 只有出问题才需要人为干预
• 追求速度: 测试通过即可发布(Push On Green)
• 密闭性: 构建工具必须保证一执性和可重复性
• 前强调策略和流程: 多层把关保证线上代码的安全性
  • 批准源代码的改动是合理的
  • 指定发布流程中需要执行的具体动作
  • 创建新的发布版本
  • 批准初始的集成测试
  • 实际部署某个版本
  • 修改某个项目的构建配置

google 通过 Rapid(Blaze开源)来构建整个自动化的发布系统

每个Rapid 都是一个工作流, 定义发布中的具体动作. 整体运行在Borg 系统上.
典型的发布流程:

• Rapid使用集成版本号(自动生成), 创建新的发布分支
• Rapid使用Blaze编译所有二机制文件, 同时执行单元测试(两者是并发执行)
• 构建的包做集成测试, 同时进行灰度部署
• 每一步结果都有日志记录, 生成和上次发布的diff

到一定规模之后的开发效率很关键(一个人/每天 在CI/CI上话费半个小时, 10000人的 5000小时的工作量)

Back To Top

[lzh2nix]

CH9 简单化(2023.08.09)

SRE的职责: 让系统的在灵活性和稳定性上维护平衡

必要复杂度: 给定情况所固有的复杂度(问题本身就是一个复杂问题)
意外复杂度: 不固定的,可以通过工程上的努力来解决

尽量将事情简单化:

• 删除 "负代码"
• 最小化API
• 模块化

软件的简单性是可靠性的前提条件.

Back To Top

[lzh2nix]

CH10 基于时间序列进行有效告警(2023.08.10)

监控一个大型系统的挑战:

• 大型系统的组件特别多, 分析工作繁杂繁重
• 监控系统本身的维护成本要求必须非常低

在大规模的系统中, 任何单机问题的报警都是没有意义的(报警次数太频繁, 没有可操作性)

探针模型-----> 时序数据库模型

时序数据库的实现可以直接看promtheus多实现

告警中心的几个功能:

• 当其他某些告警触发时, 抑制某些告警
• 将多个告警进行合并重排
• 多个告警进行合并

重要不紧急的告警生成工单, 减少onCall的次数, 然后整体告警情况展示在dashbord上.

borgmon 监控数据流:
一个全局borgmon 和一个数据中心级别的borgmon

将监控模版化:

• 在框架层如何收集prom指标模版化
• 如何将单实例监控数据汇聚到全局范围模版化

监控系统系统时一个复杂的系统需要花费, 很大的精力去维护和开发这样的系统. 避免出现监控告警随着业务规模线性增长.

Back To Top

[lzh2nix]

CH11 onCall 轮值(2023.08.11)

SLO 来指导onCall 以及进一步做action的基础

人在压力大的时候会按照直觉来操作(出问题先重启, 直接切走)
- 跟着直觉很容出错(直觉一般都不是基于数据的)
- 直觉执行的动作一般没有经过详细考虑, 又可能将灾难扩大

必须减少onCall的数量,减少不断的打断,减少压力

on-call 几个关键点:

• 清晰的问题升级路线
• 清晰定义应急事件处理步骤
• 无指责, 对事不对人的文化氛围

onCall 触发之后相同的告警在修复在不可以再次通知

Back To Top

[lzh2nix]

CH12 有效的故障排查手段(2023.08.12)

值得警惕的是, 理解一个系统如何工作并不能使人成为专家. 只有靠调查系统为何不能正常工作才行 --BRain Redman

系统正常,只是无数异常中的一种特例 --John Allspaw

常规故障排查流程:

故障排查的一个陷阱: "相关性" != "因果性"
加速排查的手段:

• 增加可观测性. 在实现之处就给每个组件增加白盒监控指标和结构化日志
• 利用成熟的, 观测性好的组件接口设计系统

尽量缩短故障恢复时间(MTTR)是第一目的

Back To Top

[lzh2nix]

CH13 紧急事件响应(2023.08.12)

如何在紧急下如何处理需要不断的进行实战训练, 应该将演练作为日常的一部分(日常就需要对这部分进行投入(人力)).

当系统出现问题时怎么办?
这个不是世界末日, 你也不是一个人在战斗. 应该按照应急流程一步步来

主动进行灾难处理和应急演练(Chaos engineer)

向过去学习而不是重复它

Back To Top

[lzh2nix]

CH14 紧急事故管理(2023.08.13)

没有紧急事故处理流程SOP, 很容易导致失控.

在没有SOP的情况下很容易出现的一件事情就是,大家都在尝试着解决问题,这样反而会使得问题更糟. 容易失控的几个原因:

• 过于关注技术问题(尝试各种方式试图去恢复, 所以没有时间去思考如果通过其他手段缓解当前服务的问题)
• 沟通不畅(原因1导致的没有及时沟通导致问题变的更糟)
• 不请自来(有些人认为做某些事情可能会缓解问题, 结果更糟)

紧急事故流程管理要素:

• 嵌套式职责分离, 在事故处理的, 让每个人清楚自己的职责, 然后分头行动
  • 事故总控: 控制事故的概要信息, 负责组建事故处理团队, 按需将任务分派给团队
  • 事故处理团队:具体的执行, 在事故中唯一能对系统做修改的团队
  • 发言人: 对外更新故障进度
  • 规划负责人: 对事故处理团队进行support
• 控制中心 war Room进行紧急处理
• 实时故障状态文档更新
• 明确公开的职责交接
  

Back To Top