作者: andylin02学习章节第1章 介绍关键词SRE起源、系统管理员模式、Dev vs Ops矛盾、错误预算、50%规则、自动化一、引言一场关于“快”与“稳”的战争在上一本书的共读中我们循序渐进地学习了从风险管理到监控、从消除琐事到自动化发布等SRE的核心方法论。今天让我们回到一切的起点——SRE究竟从何而来它要解决的核心问题是什么如果你在大型科技公司工作过或者身边有朋友在这样的公司任职你一定听过这样的故事开发团队拼命想上线新功能运维团队拼命阻止任何变更上线双方互相抱怨相互拉扯。这背后隐藏着一个根本性的矛盾——开发团队追求“更快”运维团队追求“更稳”。这种Dev与Ops之间的对立在大规模分布式系统时代被无限放大。Google在应对这一挑战的过程中创造性地提出了SRESite Reliability Engineering站点可靠性工程这一全新角色用软件工程的思维和方法论来重新定义运维。本章正是这一旅程的起点。它阐述了传统系统管理员模式的局限性解释了Google为何以及如何创立SRE并系统性地介绍了SRE的核心方法论。核心观点SRE就是让软件工程师来设计一个新型运维团队的结果——当你要求一位软件工程师设计一个运维职能时这就是你得到的答案。二、核心观点速览维度核心要点Dev vs Ops矛盾的本质开发追求功能上线速度运维追求系统稳定性天然存在目标冲突SRE的起源Google用软件工程方法彻底重构运维职能的产物2003年由Ben Treynor Sloss创立SRE的定位用软件工程思维解决运维问题雇佣软件工程师来维护生产系统SRE团队的典型职责可用性改进、延迟优化、性能优化、效率优化、变更管理、监控、应急响应、容量规划八大核心方法论研发关注、SLO最大化迭代、监控、应急事件、变更管理、容量预测、资源部署、效率性能50%研发规则SRE团队必须将至少50%的精力投入真实的开发工作防止退化错误预算可靠性目标的差值1-SLO是Dev和SRE团队共同的“风险额度”监控三输出紧急告警Page、工单Ticket、日志Logging三、详细内容拆解3.1 系统管理员模式Dev与Ops的矛盾根源书中首先剖析了传统系统管理员模式的核心矛盾。两个团队两种目标研发部门Dev最关注的是如何能够更快速地构建和发布新功能。他们希望“今天写的代码今天就能上线”。运维部门Ops更关注的是如何能在他们值班期间避免发生故障。他们希望“系统永远不要出问题”。这两个部门的目标从本质上是互相矛盾的。而问题的根源在于绝大部分生产故障都是由部署某项变更导致的——不管是部署新版本还是修改配置甚至有时只是因为改变了用户的某些行为造成了负载流量的配比变化而导致故障。运维与研发的“攻防战”面对这一矛盾双方各自发展出了一套应对策略团队策略后果运维团队宣称任何变更上线前必须经过运维团队制定的严格流程有助于避免事故流程越来越复杂上线速度越来越慢开发团队宣称不再进行大规模的程序更新转为功能开关调整、增量更新、补丁化用这些名词绕过运维部门的各种流程表面绕过实则加剧了流程混乱这种Dev和Ops分离的模型带来的成本其实远不止表面上的人员投入增加。研发团队和系统运维团队分属两个部门所带来的间接成本就没那么容易度量了但是这些间接成本往往大得多。这些间接成本体现在研发与运维团队背景各异技术能力与工具使用习惯存在差距工作目标不同研发与运维团队对产品可靠程度要求不同具体执行某项操作的危险程度评估与技术防范措施不同。这一切逐渐演变成目标与方向上的分歧及形成沟通问题容易出现信任、尊重等问题。关键洞察Dev和Ops之间的矛盾并非因为某一边的人“不好”而是由组织结构和目标错位造成的系统性冲突。解决这个矛盾需要从组织架构上入手。3.2 Google的解决之道SRE的诞生面对这种困境Google选择了一条与传统运维截然不同的道路。SRE的定义SRE就是让软件工程师来设计一个新型运维团队的结果。SRE团队通过雇佣软件工程师创造软件系统来维护系统运行以替代传统模型中的人工操作。通俗理解SRE 用软件工程师来运维 用写代码的方式解决运维问题。Google SRE的核心是雇佣软件工程师通过编写代码来自动化运维工作而不是通过堆人来手工操作。SRE成员必须同时具备软件开发能力和运维专业技能。目前来看UNIX系统内部细节和13层网络知识是Google最看重的两类额外的技术能力。SRE团队成员的典型特质SRE团队成员具有如下两个核心特点对重复性、手工性的操作有天然的排斥感——当看到重复性工作时第一反应不是“接受它”而是“如何消除它”。有足够的技术能力快速开发出软件系统以替代手工操作——不仅能看到问题还能用代码解决它。3.3 SRE方法论八大核心支柱一般来说SRE团队要承担以下几类职责可用性改进延迟优化性能优化效率优化变更管理监控紧急事务处理以及容量规划与管理。基于这些职责书中提炼了八个核心方法论这也是后续章节详细展开的内容序号方法论一句话解释对应后续章节①确保长期关注研发工作SRE团队必须将至少50%的精力投入真实的开发工作第5章“减少琐事”②在保障SLO的前提下最大化迭代速度通过错误预算平衡创新与稳定第3章“拥抱风险”、第4章“SLO”③监控系统监控系统应只有三类输出告警、工单、日志第6章“监控”④应急事件处理依赖运维手册定期演习提升MTTR效率第11章“应对事故”⑤变更管理自动化渐进式发布、快速检测、安全回退第8章“发布工程”⑥需求预测和容量规划准确预测未来需求确保容量冗余第13章“紧急事件响应”⑦资源部署快速完成资源获取和配置第9章“简单化”⑧效率与性能持续监控和优化资源利用率第20章“数据为中心的负载”3.4 方法详解方法论①确保长期关注研发工作如果SRE团队把时间都花在日常运维上很快就会退化为一个传统运维团队。Google的经验法则是SRE团队必须将至少50%的精力花在真实的开发工作上。这正是前几章我们学习的“减少琐事”和“自动化”的理论基础——如果没有50%的研发投入保障自动化就是空中楼阁。实践建议如果你发现自己在琐事上花费超过50%的时间这是一个必须被优先处理的“坏信号”。方法论②错误预算——平衡创新与稳定的工具如果100%不是一个正确的可靠性目标那么多少才是呢这其实并不是一个技术问题而是一个产品问题。回答这个问题必须从业务角度出发考虑以下因素基于用户的使用习惯服务可靠性要达到什么程度用户才会满意如果这项服务的可靠程度不够用户是否有其他的替代选择服务的可靠程度是否会影响用户对这项服务的使用模式一旦公司商业部门或产品部门建立起合理的可靠性目标“错误预算”就是“1-可靠性目标”。如果一个服务的可靠性目标是99.99%那么错误预算就是0.01%。这意味着产品研发部门和SRE部门可以在这个范围内将这个预算用于新功能上线或者产品的创新等任何事情。关键洞察错误预算的核心理念是——任何产品都不是也不应该做到100%可靠心脏起搏器等特殊系统除外。错误预算让Dev和SRE不再是“对立面”而是共同管理同一笔“风险额度”的合作伙伴。当错误预算充足时可以大胆发布新功能当预算即将耗尽时团队应暂停发布集中精力提升系统稳定性。方法论③监控系统监控系统是SRE团队监控服务质量和可靠性的主要手段。但书中提出了一个重要的警示一个需要人工阅读邮件和分析警报来决定是否需要采取行动的系统从本质上是错误的。监控系统不应该依赖人来分析警报信息而是应该由系统自动分析仅当需要用户执行某种操作时才需要通知用户。一个健康的监控系统应该只有三类输出输出类型含义处理要求典型例子紧急警报Alert / Page需要立即执行某种操作解决已发生或即将发生的问题立即响应目标是在几分钟内介入“首页API P99延迟超过5秒”工单Ticket需要执行某种操作但可以延后处理几天内处理即可系统不受影响“磁盘使用率已达70%建议扩容”日志Logging无需人工关注用于事后分析平时无人关注仅调试和分析时查阅应用访问日志、错误堆栈实践反思现实中有多少监控告警其实应该降级为工单或日志方法论④应急事件处理可靠性是MTTF平均失败时间和MTTR平均恢复时间的函数。长久来看一个手持“运维宝典”经过多次演习的on-call工程师才是正确处理之道。通过事先预案并且将最佳方法记录在“运维手册playbook”上通常可以使MTTR降低3倍以上。因此Google SRE将大部分工作重心放在“运维手册”的维护上同时通过“Wheel of Misfortune”一种模拟故障演习活动等工具不断培训团队成员。关键洞察任何需要人工操作的事情都只会延长恢复时间应尽量减少人工干预。将最佳实践写入运维手册并通过定期演习确保团队成员熟悉流程。方法论⑤变更管理SRE的经验告诉我们大概70%的生产事故由某种部署的变更而触发。因此变更管理是SRE最核心的工作之一。变更管理的最佳实践是使用自动化来完成以下三个核心项目采用渐进式发布机制例如金丝雀发布Canary先让少数实例承接流量迅速而准确地检测到问题的发生通过监控指标自动判断变更是否引入问题当出现问题时安全迅速地回退改动自动化回滚而不是让工程师手动操作数据支撑70%的事故由变更引起这决定了SRE必须在变更管理上投入足够精力。方法论⑥需求预测和容量规划简单来说就是保障一个业务有足够的容量和冗余度去服务预测中的未来需求。一个业务的容量规划不仅仅要包括自然增长随着用户使用量上升资源用量也上升也需要包括一些非自然增长的因素新功能的发布、商业推广等。容量规划有三个必需的步骤必须有一个准确的自然增长需求预测模型需求预测的时间应该超过资源获取的时间规划中必须有准确的非自然增长的需求来源的统计必须有周期性压力测试以便准确地将系统原始资源信息与业务容量对应起来方法论⑦资源部署资源部署的核心目标是快速完成资源获取和配置。当容量规划识别出需要新增资源后部署流程必须足够快不能成为瓶颈。SRE通常通过自动化工具来实现这一目标。方法论⑧效率与性能高效地利用各种资源是任何盈利性服务都要关心的。一个业务总体资源的使用情况是由三个因素驱动的用户需求流量、可用容量和软件的资源使用效率。SRE通过持续监控和优化这三者可以有效地降低系统的总成本。四、本章与其他章节的关联第1章是全书的“总纲”后续各章节都是对这里提出的八个方法论的深入展开本章方法论对应后续章节核心内容确保研发关注第5章“减少琐事”50%规则、识别琐事、自动化SLO与错误预算第3章“拥抱风险”、第4章“SLO”风险容忍度、SLI/SLO定义监控系统第6章“监控分布式系统”四个黄金指标、告警降噪应急事件处理第11章“应对事故”事故响应流程、事后总结变更管理第8章“发布工程”渐进式发布、自动化部署容量规划第13章“紧急事件响应”容量预测模型效率与性能第20章“数据为中心的负载”资源利用率优化学习路径建议第1章建立全局认知后可以按照自己的兴趣深入关注创新平衡的优先读第3、4章关注自动化实操的优先读第5、8章关注监控告警的优先读第6章。五、第1章知识点脑图总结六、总结一句话记住本章SRE 让软件工程师用工程方法规模化运维核心是用50%开发时间消除琐事用错误预算平衡创新与稳定用自动化替代手工操作。关键点一句话概括传统运维的矛盾Dev想快、Ops想稳70%事故由变更导致本质是目标冲突SRE的起源Google让软件工程师来设计运维职能的产物50%规则SRE必须将一半时间投入开发防止退化为纯手工运维错误预算用1-SLO定义“可接受的故障额度”让Dev和SRE共同管理风险监控三输出告警立即响应→ 工单可延后→ 日志仅事后分析变更管理三要素渐进式发布 快速检测 安全回退行动建议本周内完成审视自己团队的Dev和Ops组织关系是否存在目标冲突的迹象一个月内完成计算团队当前的琐事比例如果超过50%识别并优先处理TOP 3的琐事一个季度内完成为关键服务设定SLO建立错误预算机制引入监控三输出分类长期坚持持续推动自动化将70%变更管理自动化作为目标定期进行故障演习Wheel of Misfortune七、高频考点自测问题1Dev和Ops两个团队的根本性矛盾是什么为什么会产生这种矛盾参考答案开发部门最关注的是如何更快地构建和发布新功能而运维部门最关注的是如何避免值班期间发生故障。由于绝大部分生产故障都是由部署某项变更导致的这两个部门的目标从本质上是互相矛盾的。运维团队倾向于用流程限制变更开发团队则用功能开关、增量更新等方式绕过流程形成了“攻防战”。问题2SRE是如何诞生的它的核心定位是什么参考答案SRE诞生于Google应对传统Dev/Ops矛盾的实践。Google让软件工程师来设计一个新型运维团队这就是SRE。其核心定位是用软件工程的方法来解决运维问题通过雇佣软件工程师并让他们编写软件系统来替代传统的人工运维操作。SRE团队成员天然排斥重复性手工操作并有能力快速开发软件来替代手工操作。问题3什么是错误预算它如何帮助平衡创新与稳定参考答案错误预算 1 - SLO服务等级目标。例如如果一个服务的可靠性目标是99.99%错误预算就是0.01%。错误预算的核心理念是任何软件系统都不应该一味追求100%可靠这对最终用户没有实质区别。SRE团队和产品研发团队共同管理这笔“预算”可以在预算范围内进行新功能上线或产品创新。当错误预算充足时可以大胆发布当预算即将耗尽时团队应暂停发布集中精力提升系统稳定性。问题4一个健康的监控系统应该有哪些输出参考答案一个监控系统应该只有三类输出紧急警报Alert/Page收到警报的用户需要立即执行某种操作解决已发生或即将发生的问题工单Ticket接受工单的用户需要执行某种操作但可以延后处理系统不会在几天内受到影响日志Logging平时不需要关注仅用于调试和事后分析核心原则监控系统不应该依赖人来分析警报信息而应该由系统自动分析仅在需要用户执行操作时才通知用户。问题5变更管理的最佳实践是什么为什么变更管理如此重要参考答案SRE的经验表明大概70%的生产事故由某种部署的变更触发。因此变更管理的最佳实践是使用自动化完成三个核心项目采用渐进式发布机制如金丝雀发布迅速而准确地检测到问题的发生通过监控指标自动判断当出现问题时安全迅速地回退改动自动化回滚70%这个数据决定了变更管理是SRE最核心的工作之一——控制了变更就控制了事故的主要来源。八、延伸阅读推荐《Google SRE 工作手册》官方补充读物提供更多实践细节SRE官方书籍网站https://sre.google《SRE 中文社区》https://www.srenow.cnGoogle SRE 官方视频系列https://www.youtube.com/playlist?listPLIivdWyY5sqJrKl7D2u-gmis8h9K66qoj学习下一章预告第2章“SRE理念”——深入阐述SRE的核心哲学、与传统运维的区别以及Google生产环境全景。本文为个人学习笔记仅用于知识分享。如有错误欢迎指正。