SRE：Google运维解密

纯阳书评（公众号:纯阳书评／微信号:chimbusco88）谷歌不愧是创新公司中的佼佼者！它的创新能力不止体现在产品和服务，还体现在了组织、人力资源、管理、商业模式等各个方面，而这本书讲的则是它在IT运维工作方面的创新。这本书的主题是谷歌公司突破传统IT运维工作模式和形态，将其发展到一个叫做sre的阶段，使这项工作拥有了新的内涵和组织形式，从其变化的幅度来看，已经超越变革的范畴，堪称正在引领一场包含软件工程要素的运维革命！ 传统IT运维工作存在两大难题。 一是IT运维团队与软件工程团队的摩擦问题一直无法有效协调解决。软件工程团队希望能够不断地对在线系统进行迭代升级，所谓求新求快。而it运维团队则希望系统上线以后永不改变，所谓求稳求安，所以两个团队总是存在摩擦。 二是IT运维团队人员的软件工程技能无法得到培养和发挥，员工的工作成就感无法有效得到满足。 以上两点都不利于系统的稳健部署和可靠运行，阻碍了系统可用性、可靠性的稳步提升。 谷歌公司的sre本质上是一种开发运维一体化的理念，一方面强调软件工程师参与运维工作，与运维工程师共保系统的稳定可靠运行；另一方面运维工程师既要参与系统的研发工作，以在产品阶段就提高系统的质量属性，也要通过开发运维工具，提高运维工作的自动化水平，消除运维工作中的琐事，让运维工程师超过50%的时间用于工程开发工作。 通过sre的创设，谷歌成功的破解了传统运维工作中存在的难题，提高了运维工作的自动化水平，控制了运维团队的规模，改善了运维工程师的工作状态，实现了开发与运维的一体化，有力的提升了系统可靠性和服务质量水平。 本书以论文集的形式阐述了谷歌关于sre的理念、实践和管理经验，内容新颖，读起来令人振奋，所以建议所有IT工作者不管是否从事运维工作都要抽时间读一读。 可能书中有些理念过于超前，实际工作中不一定具备实施的条件，但是作为it工作实践发展的一个新方向，我们要心向往之。

运维干了15年，搞技术8年，搞流程、管理7年。初读了这本谷歌SRE运维方法论，发现这套理论本质并没有发明新工作，而是又重新思考定义了一套预防、应对和解决系统故障的体系。这套体系包括： 1. 从“救火英雄”到“消防工程师”的转变传统运维（Ops）的范式：反应式： 故障发生 -> 紧急响应 -> 排查修复 -> 恢复服务。运维团队常常被视为“救火队”。英雄主义： 依赖个别资深工程师的个人经验和临场发挥，这不可复制，也无法规模化。指标模糊： 对“稳定”和“可用”的定义模糊，通常是“没报警就是正常”。SRE的范式：前瞻式： 核心是预防。通过设计、自动化、容量规划等手段，在故障发生前就尽可能地消除风险。工程化： 用软件工程的方法解决运维问题。自动化一切可以自动化的（如发布、扩缩容、故障处理），将人力从重复劳动中解放出来，投入到更高价值的工程项目中。数据驱动： 引入 SLO（服务水平目标） 和 SLI（服务水平指标） 等概念，精确地定义“多稳定才算稳定”，并用 Error Budget（错误预算） 来量化风险，科学地平衡新功能发布与系统稳定性。本质： SRE不是发明了“防火”这件事，而是重新定义了角色——从被动等待火灾发生的“救火员”，变成了主动设计防火系统、制定消防规范、进行防火演习的“消防工程师”。 2. 重新定义“故障”：从二元对立到连续光谱传统上，我们认为系统“正常”或“故障”。但SRE通过SLO和错误预算，引入了一个灰度概念。错误预算： 允许的不可用时间。例如，99.9%的SLO意味着一个月有43.2分钟的不可用时间是“被允许的”。意义： 这让稳定性和创新速度不再是零和游戏。只要错误预算没有耗尽，开发团队就可以放心地发布新功能。如果预算即将耗尽，则整个团队（而不仅仅是SRE）都需要集中精力提升稳定性。这本质上是将技术风险转化为一种可管理、可度量的资源。 3. 文化变革：共同的责任制这是SRE最核心、也最难被模仿的部分。传统模式： 开发（Dev）写代码，运维（Ops）保稳定。两者目标常有冲突：开发想快速迭代，运维想减少变更。SRE模式： “You build it, you run it.” 开发团队需要对服务的全生命周期负责。SRE团队则作为顾问、赋能者和“强制函数”，通过提供平台、工具和最佳实践，并监督SLO的达成情况，来帮助开发团队更好地“运行”自己的服务。本质： SRE不是把“运维”的职责从开发身上拿走，而是将“运维”的理念和能力赋予开发。它是一种工作文化和责任划分的重构。 4. 对“应急响应”的再思考：从慌乱到演练SRE没有发明“应急响应”，但它将其系统化了。应急预案： 针对预期内的故障，有预先写好的、经过验证的应对方案。非相关事件模拟： 通过故意在线上制造故障（如混沌工程），来持续检验系统的韧性和团队的响应能力。复盘文化： 强调Blameless Postmortem（免责事后复盘），焦点是找出导致故障的系统性根源并修复它，而不是追究个人责任。这确保了组织能从每一次故障中学习并进化。 谷歌的SRE可以看作是对“如何管理复杂软件系统”这一经典问题的一次集大成的、系统性的回答。• 它没有发明新工作，而是重新组合并升华了已有工作（监控、部署、变更管理、应急响应）的目标和方法。• 它的核心贡献在于引入了一系列可操作的工程框架（SLO/Error Budget）和深刻的文化原则（共享责任、工程导向、免责复盘），将原本依赖个人经验的“运维艺术”，转变成了可衡量、可复制、可规模化的“运维科学”。 最终，SRE提供了一套通用的语言和思维模型，让开发、运维、产品经理等不同角色能够在一个统一的框架下，就系统的可靠性目标进行沟通和决策。这正是它能够超越谷歌，成为整个行业标杆的原因。

《SRE:google运维解密》，正如书名，这是一本以SRE为视角的介绍google运维过程的书。在实践中SRE集运维和开发双重角色为一身，既是操作员又是设计师，这一点是google SRE和普通的运维人员最大的区别。 google SRE的核心指导思想可以分为4大类： ● 灾难预案与演习 ● 书写事后总结的文化 ● 自动化与降低日常运维负载 ● 结构化的、理智的决策 以上几个部分基本上是全书的概要，其中“自动化与降低日常运维负载”部分是google运维的真正秘密，也是本书的精华所在，可惜关键点没有展开说，需要结合其他相关书籍来加深了解。再者，google SRE反复强调的事故总结“对事不对人”确实让人羡慕，但也要结合国情来分析。对事不对人，知易行难，特别是在我国以计划经济为主的体制下，尤甚！静态组织架构更注重稳定和控制，资源分配和控制更为集中，有助于实现规模经济和效率最大化‌，而动态组织结架构则适用于变化快、竞争激烈的环境，能够快速调整策略和资源配置，但需要较高的管理水平和协调能力。google的事后总结模式可能只适用于google，毕竟各个行业有所不同，不同的行业内部进行事后总结的原动力各有不同。另外，能够像google那样实现高度智能化的公司也不多，假如是人工负责的环节出了问题，如果没有问责机制，对于某些没有责任心的人而言就没有约束力。

通过这本书，快速地大致了解了 SRE 和普通交付运维的区别，以及 SRE 在团队中应该扮演的角色。 谷歌是一家伟大的公司，但它之所以伟大，是由一个一个优秀的个体支撑起来的。谷歌的 SRE 团队构建了令人惊叹、稳固且可扩展的软件基础设施，能够支撑谷歌各产品线的快速发布与上线，以及线上运维；同时这个团队也有自己独特的文化，积极拥抱并参与到谷歌研发团队的研发流程中去。 SRE 既是运维系统的设计者，又是这个系统的一线使用者！ 感觉在国内落地是有一定难度的，只能将其中关键的精髓部分逐步引入并注入团队中。道阻且长，行则将至。

大概浏览了本书，感觉SRE核心思想和古代军事理论孙子兵法有些类似，核心做好三点庙算能力，突发事件处理能力，复盘总结能力。最后形成自动化机制，达到良性循环的闭环效果。最最后补充一句：三分天注定，七分靠运维。

2200年前，西西里岛东南端叙拉古城外蜿蜒的沙滩上，给我一个支点撬起地球的阿基米德，以这样的方式思考着他想描绘的世界：眼前的沙滩，天下所有沙漠中的沙砾，能不能用一个数字表达出来。他给出了这样一个表述：十的一百次方。后来的科学证明了阿基米德智慧的超凡卓著。实际上，世界上的沙砾的确没有那么多，甚至宇宙中以分子、粒子、原子存在事物的总和都没有这样的量。人们将这个人类不可企及的理想量，命名为googol。 2200年后，两位斯坦福大学的年轻人产生了一个堪比阿基米德的人生理想，他们想要收集和整理无尽的信息海洋里的所有信息，帮助需要的人快速准确地找到这片汪洋中的任意一滴水。googol的同音词google，在汉语中被翻译为“谷歌”。

应该有一种职业是专注于整个软件系统的生命周期管理。对于Google，就是SRE。 内容很不错，作为Google长期运维经验的总结，满满干货，运维必读，五星推荐。 从一个运维工程师的角度来看，书中的各种内容都是羡慕嫉妒恨。 花了两个月的时间，终于看到结语了，感觉自己终于松了一口气，这么厚的一本书终于看完了。当然是带着复杂的心情——远超于我们水平的Google分享出它的运维经验，甚是惊喜；书中介绍到他们的运维人员为企业或是世界所作出的贡献，十分羡慕；在阅读过程中，处处感受到我们和他们的差距，五味杂陈；当看到某些地方我们原本可以采用更好的方式时，只能叹息。 对我们来说，运维，依旧有很长的一条路要走。虽然国内的企业，在运维方面，发展也是相当迅速的，尤其是互联网公司。但还是期盼着什么时候，国内的运维也能达到世界级领先的水平，带领运维界进行下一次变革。

读了好几遍，每一遍都有新的收获 SRE需要管理层的认可和支持，这个非常重要，如果管理层都不理解，发生在质疑sre在干什么？SRE是不是可以更少人员，SRE是不是就是干发布的，是不是干脏活累活的初级工程师， 那就完了，赶紧跑路吧

纸质书读过一遍，电子书读过一遍，今天闲来无事又速读了一遍划线笔记。经典就是经典。

技术部分看不太懂，理念方面的经验值得学习。