《SRE：Google 运维解密》读书笔记03: SRE 理念 - 从“零故障”到“理性风险”

作者: andylin02学习章节第2章 SRE 理念关键词SRE定义、软件工程、50%规则、对事不对人、自动化、简化一、引言当软件工程师开始做运维传统的运维Ops模式通常会陷入一个死循环系统越复杂运维工作量越大只能靠不断堆人来维持而创新和自动化却迟迟无法落地。Google 的 SRE 团队给出了一种截然不同的解法让软件工程师来负责运维工作然后用开发软件的方式来解决运维问题。SRE 本质上是一种用软件工程的思维和方法论来管理和运维大规模分布式系统的实践。正如 Google 工程师 Ben Treynor Sloss 在 2003 年首次定义的那样SRE 的核心就是“当你要求软件工程师设计一个运维职能时所得到的结果”。二、核心观点速览传统运维OpsGoogle SRE手工操作依赖经验和脚本软件工程化编写代码解决运维问题运维人员只负责维持运行SRE 同时负责运维 开发50%时间用于开发故障追责互相推诿对事不对人故障是改进的机会追求 100% 可靠畏惧变更拥抱风险用错误预算做决策被动响应故障主动预防用自动化消除琐事运维和开发是割裂的两个团队产品 SRE、基础设施 SRE、共享平台 SRE 三种组织形态三、详细内容拆解3.1 SRE 的定义与起源什么是 SRE书中没有直接给出 SRE 的定义而是通过职责描述来阐明SRE 团队负责所辖服务的可用性、延迟、性能、效率、变更管理、监控、应急响应和容量规划等工作。更通俗地讲SRE 就是用软件工程的思维和方法论来管理和运维大规模分布式系统的实践。Google SRE 团队的核心是雇佣软件工程师通过编写代码来自动化运维工作而不是通过堆人来手工操作。Google 在 SRE 指南的前言中给出了一个惊人的数据系统总成本的 40% 到 90% 是在系统诞生后产生的。这意味着上线之后才是真正的战场——SRE 的价值就在于此。SRE 的起源2003 年Google 工程师 Ben Treynor Sloss 组建了第一支 SRE 团队。最初的动机很简单Google 的业务规模增长太快了传统运维通过堆人来解决问题的方式已经完全行不通了。关键洞察当服务器规模达到百万级别时手工运维从物理上就不可能实现。SRE 的诞生本质上是一种规模倒逼出来的必然选择。3.2 SRE vs 传统运维本质区别在哪里对比维度传统运维OpsGoogle SRE角色定位侧重解决当前问题更注重预防问题产生工作方式多依赖于手工操作通过编写代码实现自动化目标导向保持系统运行追求更高系统可靠性持续改进能力要求系统管理、脚本编写软件开发 系统内核 网络精通价值取向稳定压倒一切用工程方法在创新与稳定间找平衡团队协作运维与开发割裂SRE 嵌入开发团队紧密协作国内目前只有少数几家顶尖互联网公司才会出现真正的 SRE。这并非偶然——SRE 的门槛确实很高。Google SRE 的招聘标准根据书中披露的数据50-60% 的 SRE 是通过标准软件工程师招聘流程录用的其余 40-50% 是接近软件工程师标准的候选人同时还必须精通 Unix 系统内核和底层网络1-3层。这意味着传统运维SA 或 NE想直接转型 Google SRE几乎不可能必须经历极其艰难的技能重构。3.3 SRE vs DevOps是替代还是互补很多人会把 SRE 和 DevOps 混为一谈但两者其实存在清晰的差异。对比维度DevOpsSRE本质定位文化理念 跨团队协作的框架工程化落地稳定性的具体方法论关注范围覆盖软件全生命周期聚焦部署后的运行阶段以稳定性优先平衡迭代速度关键工具CI/CD、容器化、IaCSLO/SLA/SLI、错误预算、混沌工程量化管理关注部署频率、变更失败率等关注服务水平指标SLIs、服务水平目标SLOs和错误预算核心机制打破开发与运维壁垒错误预算预算充足→快速迭代耗尽→暂停新功能两者关系紧密DevOps 是 SRE 的理念基础SRE 是 DevOps 最落地的实践抓手。DevOps 解决跨团队协同的顶层问题SRE 聚焦稳定性保障的具体执行。DevOps 问需要做什么SRE 问如何去做。在国内互联网公司中SRE 通常分为两个层级PaaS-SRE维护平台基建服务质量和业务 SRE维护业务服务质量稳定性后者与业务运维比较接近。四、SRE 的七大核心原则书中为 SRE 指定了 7 个原则是对运维文化的革命和最佳实践的总结。原则1拥抱风险虽然 SRE 高度关注管理和限制停机时间但这并不意味着目标是要让服务保持 100% 可用的完美可靠性。事实上100% 的可靠性不仅不现实甚至不一定是首选结果。为什么不能追求 100% 可靠性当可靠性接近 100% 时降低风险的难度和成本会呈指数级增长从 99.99% 提升至 99.999%比从 80% 提升至 99% 困难得多超过特定阈值后用户通常无法感知可靠性的提升不仅成本高昂而且收效甚少理想的情况是制定并实现目标但不要过分超标取而代之的是错误预算Error Budget机制——团队设定一个可接受的不可靠程度并据此进行决策。原则2服务水平目标SLO选择目标并衡量其成效和原因对于 SRE 团队至关重要。SLO 是一个具体且可衡量的目标代表 SRE 团队设定的质量等级。SLO 可采用多种形式的指标但可用性、查询率、错误率和响应时间均为常见指标。团队需要回答允许多少停机时间不同类型的故障对用户体验会产生怎样不同的影响超出限度需要投入多少成本平衡点在哪里原则3消除琐事SRE 将琐事toil定义为无聊、重复性的运维工作这些工作通常不具有长期价值而且会随着服务规模的扩大而增长。琐事的典型特征手工操作、重复性、无长期价值、随服务规模线性增长。消除琐事的核心手段是自动化——利用脚本和自动化工具实现软件部署、系统配置等操作减少人工干预提高效率和准确性。原则4监控监控的 4 个黄金指标延迟、流量、错误数、饱和度。现象 vs 原因监控系统应关注用户可见的现象如请求失败而非底层技术原因如 CPU 负载。监控系统的主要用途包括对真实问题进行报警、对比服务更新前后的状态变化新版本是否让服务变得更快、检查资源使用量随时间的变化情况容量规划的基础。原则5自动化Google 数以万计的服务器数量使得工程师无法一台一台管理SRE 需要通过开发自动化工具来完成工作。自动化的价值包括消除琐事、提高一致性、加速变更、缩短恢复时间等。在变更管理方面SRE 强调自动化渐进式发布、自动化检测定位问题、自动化回退。原则6发布工程发布工程关注持续构建与部署的标准化和自动化。Google 的发布工程哲学包括建立标准化的发布流程、自动化构建和测试、渐进式发布和自动回滚。SRE 团队负责确保所有变更都能以可控的方式推向生产。原则7简单性系统越复杂越难以理解和维护出故障的概率也越高。SRE 通过最小 API、模块化设计、删除无用代码等方式追求系统的简单性。负代码行作为一个指标鼓励团队删除不必要的代码——代码减少本身就是一种胜利。乏味是一种美德——在基础设施层面创新的空间有限采用成熟稳定的方案往往比过度设计更可取。五、SRE 团队构成与组织结构5.1 Google SRE 团队构成人员构成比例能力要求合格软件工程师SWE50-60%通过 Google SWE 标准招聘流程接近 SWE 标准的候选人40-50%具备 SWE 85%以上技能外加 Unix 内核/底层网络特长5.2 SRE 的十大基本原则SRE 团队必须将50% 精力花在开发上每 8-12 小时 on-call 时最多处理 2 个事件保障有时间跟进紧急事件针对事件进行总结对事不对人不追求 100% 可靠建立合理的错误预算最大化迭代速度监控系统输出告警、工单和日志将MTTR平均恢复时间作为评价团队系统恢复正常的指标尽量自动恢复写好运维手册在变更管理方面自动化渐进式发布、自动化检测定位问题、自动化回退合理的规划系统容量并周期性进行压力测试资源部署和配置必须快速完成高效的利用各种资源与研发团队一起监控和优化整个系统的性能5.3 SRE 的三种组织结构Google 的 SRE 团队并非铁板一块而是分为三种形态类型定位示例产品 SRE嵌入在产品开发团队Search、Photos 等产品的 SRE基础设施 SRE嵌入在基础设施开发团队Bigtable、Spanner、Borg 的 SRE共享平台 SRE专注 SRE 工具开发监控、事件管理工具、发布平台关键洞察这三种 SRE 团队都在相同的组织内彼此协作共同支撑 Google 的可靠性体系。六、Google 生产环境SRE 视角SRE 的日常工作基于 Google 庞大的生产环境主要包含以下层次硬件层物理服务器/虚拟机网络Jupiter 虚拟交换机、CLOS 架构、SDN 技术、骨干网 B4系统软件层管理物理服务器Borg 集群操作系统Kubernetes 的前身存储系统D 服务、ColossusGFS 改进版、Bigtable、Spanner、Blobstore网络系统SDN/OpenFlow、带宽控制器BwE负载均衡GSLB 在三个层面进行负载均衡——域名解析、用户服务、RPC 调用分布式锁服务Chubby使用 Paxos 协议可用于 Master 选举等监控与告警系统监控系统的三种主要用途对真实问题进行报警对比服务更新前后状态变化新版本是否更快检查资源使用量随时间的变化情况容量规划的基础七、第2章知识点脑图总结八、总结一句话记住本章SRE 用软件工程的方法论来规模化运维核心是拥抱风险、消除琐事、以50%开发时间为底线。关键点一句话概括SRE 定义让软件工程师用工程方法解决运维问题50% 规则SRE 必须将一半精力投入开发不能沦为纯手工运维对事不对人故障总结的目标是改进系统而非惩罚个人七大原则拥抱风险、SLO、消除琐事、监控、自动化、发布工程、简单性三种组织形态产品 SRE、基础设施 SRE、共享平台 SREGoogle 生产环境Borg 集群管理 Colossus/Bigtable/Spanner 存储 GSLB 负载均衡行动建议审视团队当前的运维工作识别并量化琐事toil占比为关键服务建立 SLO引入错误预算机制将至少 50% 的运维能力投入开发自动化工具建立对事不对人的事后总结文化在变更管理中实施渐进式发布和自动回滚机制九、高频考点自测问题1SRE 和传统运维的核心区别是什么参考答案SRE 用软件工程的思维和方法论来运维大规模分布式系统而传统运维多依赖于手工操作。SRE 更注重预防问题强调通过编写代码实现自动化传统运维侧重解决当前问题更多依赖经验和手工操作。SRE 团队要求 50% 以上成员是软件工程师背景且必须具备软件开发能力。问题2为什么说 DevOps 是 SRE 的理念基础SRE 是 DevOps 的实践抓手参考答案DevOps 提供的是文化理念 跨团队协作的顶层框架解决的是开发与运维如何协同的问题SRE 则提供具体的工程化方法论通过 SLO/SLI、错误预算等量化机制落地稳定性保障。两者目标一致但定位不同——DevOps 搭框架SRE 填细节。问题3SRE 的七大核心原则是什么请简要说明。参考答案拥抱风险100%可靠性不现实且成本高昂用错误预算做决策服务水平目标 SLO量化服务可靠性目标消除琐事识别并消除重复性、无长期价值的运维工作监控用 4 个黄金指标延迟、流量、错误、饱和度度量系统健康自动化用代码替代人工操作发布工程标准化持续构建与部署流程简单性追求最小 API、模块化设计鼓励删除无用代码问题4Google SRE 团队如何保证 50% 精力花在开发上参考答案通过三项关键机制来保障① 严格限制 on-call 工作量每 8-12 小时最多处理 2 个事件② 将琐事识别和消除作为团队的重要工作用自动化替代手工操作③ 在组织层面明确将开发工作工具、自动化、架构改进作为 SRE 的核心职责而非额外工作。十、延伸阅读推荐SRE 官方书籍网站https://sre.google/SRE Workbookhttps://sre.google/workbook/Google SRE 视频系列https://www.youtube.com/playlist?listPLIivdWyY5sqJrKl7D2u-gmis8h9K66qoj《SRE 生存指南》基于金字塔模型介绍监控、事故响应、测试发布、容量规划等 SRE 核心实践SRE 中文社区https://sre.tech学习下一章预告第 3 章拥抱风险管理 —— 如何管理风险、度量服务风险容忍度、设计错误预算。本文为个人学习笔记仅用于知识分享。如有错误欢迎指正。