【SRE】Google 运维解密
我们无法按照传统方式运维 Google 系统，必须要思考一种新的模式，但是同事我们也没有时间等待其他人验证和支持我们的理论：系统运维本质上是人与计算机共同参与的一项系统性工程。
更新历史
- 2022.11.26：完成初稿
读后感
Google 的很多实践和经验是非常宝贵和有参考价值的，但是在不同的公司，不同的组织形式，都要有一个摸索的过程，这样才能真正把人的潜力和组织的潜力激发出来。
读书笔记
序言
- SRE 是工程师，使用计算机科学和软件工程手段来设计和研发大型、分布式计算机软件系统
- SRE 的关注焦点在于可靠性
- SRE 的主要工作是运维在分布式集群管理系统上运行的具体业务服务(Service)
- SRE 最重要的理念：对细节的不懈关注，做好充足的灾难预案和准备工作，时刻警惕着，不放过一切机会去避免灾难发生
概览
- SRE 团队成员的特点：
- 对重复性、手工性的操作有天然的排斥感
- 有足够的技术能力快速开发出软件系统以替代手工操作
- SRE 模型成功的关键在于对工程的关注。如果没有持续的、工程化的解决方案，运维的压力就会不断增加，团队也就需要更多的人来完成工作
- SRE 团队必须将 50% 的精力花在真实的开发工作上。
- 首先，必须不断地度量每个团队的工作时间分配
- 一些常见的运维工作交还给产品研发部门，或者从产品研发部门抽调团队轮值值班工作
- DevOps 是 SRE 核心理念的普适版
SRE 方法论
- 要承担的职责
- 可用性改进
- 延迟优化
- 性能优化
- 效率优化
- 变更管理
- 监控
- 紧急事务处理
- 容量规划与管理
- 方法论 1：确保长期关注研发工作
- 所有的产品事故都应该有对应的事后总结，无论有没有触发警报
- 事后总结应包括：事故发生、发现、解决的全过程、事故的根本原因、预防或者优化的解决方案
- 方法论 2：在保障服务 SLO 的前提下最大化迭代速度
- 任何产品都不是，也不应该醉倒 100% 可靠。因为对于最终用户来说，99.999% 和 100% 的可用性是没有实质区别的，从最终用户到服务器之间有很多中间系统，这些系统综合起来可靠性要远低于 99.999%。
- 方法论 3：监控系统
- 监控系统不应该依赖人来分析警报信息，而是应该由系统自动分析
- 一个监控系统应该只有 3 类输出
- 紧急警报 alert：立即执行某种操作，解决问题或者避免问题
- 工单 ticket：在一段时间内（如几天）执行某种操作
- 日志 logging：平时没人阅读，除非有特殊需要
- 方法论 4：应急事件处理
- 任何需要人工操作的事情只会延长恢复时间
- 预案并将最佳方法记录在运维手册 playbook 可以使 MTTR 降低 3 倍以上
- 方法论 5：变更管理。自动化完成以下几个项目：
- 采用渐进式发布机制
- 迅速而准确地检测到问题的发生
- 当出现问题时，安全迅速地回退改动
- 方法论 6：需求预测和容量规划
- 必须有一个准确的自然增长需求预测模型，需求预测的时间应该超过资源获取的时间
- 规划中必须有准确的非自然增长的需求来源的统计
- 必须有周期性压力测试，以便准确地将系统原始资源信息与业务容量对应起来
- 方法论 7：资源部署
- 是变更管理与容量规划的产物，必须能够非常迅速地完成
- 方法论 8：效率与性能
- 一个业务总体资源的使用情况是由以下几个因素驱动：用户需求（流量）、可用容量和软件的资源使用率
Google 的生产环境：SRE 视角
概念区分：
- 物理服务器 machine：代表具体的硬件（有时候也代表一个 VM 虚拟机）
- 软件服务器 server：代表一个对外提供服务的软件系统
典型的 Google 数据中心拓扑结构：
- 约 10 台物理服务器组成了一个机柜 Rack
- 数台机柜组成一个机柜排 Row
- 一排或者多排机柜组成了一个集群 Cluster
- 多个集群形成一个数据中心 Datacenter
- 多个相邻的数据中心组成了一个园区 Campus
指导思想
高昂的成本主要存在于以下两个维度：
- 冗余物理服务器/计算资源的成本
- 机会成本
选择目标 SLO 不是一个纯粹的技术活动，还涉及产品和业务层面的决策，SLI/SLO/SLA 的选择都应该直接反映该决策：
- 不要仅以目前的状态为基础选择目标
- 保持简单
- 避免绝对值
- SLO 越少越好
- 不要追求完美
监控系统的 4 个黄金指标分别是延迟、流量、错误和饱和度(saturation)：
- 延迟。服务处理某个请求所需要的时间，需要区分成功请求和失败请求
- 流量。对于 Web 服务器来说，一般是每秒 HTTP 请求；针对流媒体系统来说，一般是网络 I/O 速率；对于 KV 存储来说，一般是每秒交易数量，或每秒的读取操作数量
设计监控系统时一定要追求简化：
- 那些最能反映真实故障的规则应该越简单越好，可预测性强，非常可靠
- 那些不常用的数据收集、汇总，以及警报配置应该定时删除
- 收集到的信息，但是没有暴露给任何监控台，或者被任何警报规则使用的应该定时删除
自动化：允许大规模故障发生。
软件的简单性是可靠性的前提条件。
具体实践
事故流程管理最佳实践
- 划分优先级：控制影响范围，恢复服务，同时为根源调查保存现场
- 事前准备：事先和所有事故处理参与者一起准备一套流程
- 信任：充分相信每个事故处理参与者，分配职责后让他们自主行动
- 反思：在事故处理过程中注意自己的情绪和精神状态。如果发现自己开始惊慌失措或者感到压力难以承受，应该寻求更多的帮助
- 考虑替代方案：周期性地重新审视目前的情况，重新评估目前的工作是否应该继续执行，还是需要执行其他更重要或者更紧急的事情
- 练习：平时不断地使用这项流程，直到习惯成自然
- 换位思考：上次你是事故总控负责人吗？下次可以换一个职责试试。鼓励每个团队成员熟悉流程中的其他角色。
协作和知识共享
事后总结文档使用同一个模板。努力确保下列功能：
- 实时协作：使得写作过程可以很快地收集数据和想法。这在事后总结早期很有帮助。
- 开放的评论系统：使大家都可以参与进来提供解决方案，以及提高对事故处理细节的覆盖程度
- 邮件通知：可以在文档中给其他用户发消息，或者引入其他人来共同填写文档
建立事后总结文化
虽然管理层可以鼓励建立“对事不对人”的氛围，但是由工程师自主驱动，效果会更好，SRE 经常搞一些集体学习活动，示例如下：
- 本月最佳事后总结：可以是分享会，可以是邮件和帖子
- 事后总结聊天小组
- 事后总结阅读俱乐部
最佳实践
- 避免指责提供建设性意见
- 所有的事后总结都需要评审
- 公开奖励做正确事的人
- 收集关于事后总结有效性的反馈
管理
SRE 培训课程
推荐的培训方式
- 设计一个具体的、有延续性的学习体验，以便学员跟进
- 鼓励反向工程，利用统计学来思考问题，以及多思考问题本质
- 鼓励学员分析失败的案例，分享好的事后总结来阅读
- 创造一些受控的，但是逼真的场景让学员利用真实的监控环境和工具来修复
- 在团队内以角色扮演的形式演习理论上可能发生的问题，让大家在这个过程中交流彼此的解决问题的方式
- 给学员创造条件让他们参与见习 on-call，和实际轮值的 on-call 工程师交流经验
- 让学员与 SRE 老手一起共同修订培训计划中的某个部分
- 帮许愿一起找到一个具有一定复杂度的项目，帮助他们在整个技术栈内建立自己的地位
错误的培训方式
- 通过给学员安排一些繁琐的工作（处理警报/工单）来培训
- 要求严格按照现有的操作过程，检查列表，或者手册来执行命令进行训练
- 在学员还没有对服务有全面认识的情况下，就要求他们成为主 on-call
- 将新项目全部分配给 SRE 老手，新手 SRE 只能做一些零工
有抱负的 on-call 工程师的 5 个特点
- 对事故的渴望：事后总结的阅读和书写
- 故障处理分角色演习
- 破坏真的东西，并且修复它们
- 维护文档是学徒任务的一部分
- 尽早、尽快见习 on-call
发布协调检查列表
架构
- 架构草图，服务器类型，客户端请求类型
- 编程性客户端的请求
物理机与数据中心
- 物理机数量与带宽数量，数据中心，N+2 冗度，网络 QoS
- 新的域名，DNS 负载均衡
流量预估、容量以及性能
- HTTP 流量与带宽预估，发布时的峰值，流量的组成，6 个月的预测
- 压力测试，端到端测试，每个数据中心最高延迟下的容量
- 对其他我们关注的服务的影响
- 存储容量
系统可靠性与灾难恢复
- 当下列情况发生时，服务会怎么样：
- 物理机故障，机柜故障，集群故障
- 两个数据中心之间的网络故障
- 对每种需要联系其他服务器（后端）的服务器来说
- 如何检测后端故障，后端故障如何处理
- 如何在不影响客户端和用户的情况下重启服务器
- 负载均衡，速度限制，超时，重试，以及错误处理
- 数据备份/恢复，灾难恢复
监控与服务器管理
- 监控内部状态，监控端到端行为，警报的管理
- 监控监控系统
- 有关财务的警报和日志
- 在集群环境下运行服务的的技巧
- 不要再代码中给自己发送海量邮件，会导致服务器崩溃
安全
- 安全设计评审，安全代码评审，垃圾邮件风险，验证，SSL
- 发布之前的可见/可访问性控制，各种类型的黑名单
自动化与人工任务
- 更新服务器、数据，配置文件的方式和变更管理
- 发布流程，可重复的构建过程，金丝雀测试，分阶段发布
增长问题
- 空余容量，10 倍增长，增长型的警报
- 扩展性的瓶颈，线性扩展，与硬件性能的同步扩展，所需要的变更
- 缓存，数据分片/重新分片
外部依赖
- 第三方系统，监控，网络条件，流量配比，发布时的流量峰值
- 优雅降级，如何避免意外对第三方服务造成过载
- 与合作伙伴、邮件系统，以及 Google 内部服务良好对接
发布时间与发布计划
- 不可改变的截止日期，外部事件，星期一或者星期五
- 该服务标准的运维流程，以及其他服务的运维流程