当前位置：首页 > news >正文

《SRE：Google 运维解密》读书笔记19: SRE中的软件工程 - 当SRE从“运维”走向“开发”

news 2026/4/25 23:21:52

作者: andylin02
学习章节：第18章 SRE中的软件工程（Software Engineering in SRE）
关键词：SRE软件工程、Auxon容量规划、内部工具开发、产品化思维、SRE职业发展

一、引言：当SRE从“运维”走向“开发”

在前面的章节中，我们学习了SRE如何应对生产故障、如何制定SLO、如何监控系统、如何管理事后总结。然而，一个容易被忽视但至关重要的问题是：SRE团队本身在做什么？

如果让外人列举Google的软件工程成果，他们会脱口而出Gmail、Google Maps这类明星产品；资深一点的可能还会提到Bigtable或Colossus这些底层基础设施。但在这些光环背后，还有一个规模巨大的“隐形软件工程”世界，其中的许多产品并非面向普通消费者，而是在SRE内部开发的。

本章正是要揭示这个“隐形世界”。Google SRE团队并非传统意义上的“运维人员”，而是一支由软件工程师组成的、以编写软件的方式来解决运维问题的队伍。本章探讨的核心命题是：SRE组织为何以及如何进行软件开发？如何将SRE的知识和经验产品化、平台化，从而在全组织内推广和复用？

核心观点：SRE通过内部软件开发，将运维知识与经验固化为可复用的产品和平台，从而以团队规模的线性增长支撑服务规模的指数级增长。这不仅是技术选择，更是组织战略。

二、核心观点速览

维度	核心要点
隐形软件工程	Google有大量消费者从未见过的幕后软件工程，其中很多是在SRE内部开发的
SRE开发软件的三大优势	① 拥有独特的生产知识深度；② 是工具的直接使用者；③ 能获得高质量的用户反馈
产品化思维	SRE开发的工具不是一次性脚本，而是成熟的软件工程项目，有路线图、有内部客户
服务增长与团队规模	SRE的核心原则之一：团队规模不应随服务增长而线性扩展
Auxon案例	将容量规划从“预测驱动”升级为“意图驱动”的工具化案例
职业发展双通道	软件开发项目为SRE提供职业发展机会，平衡on-call工作与工程工作
团队多样性	SRE团队需要同时配备有软件工程经验和系统工程经验的人才

三、详细内容拆解

3.1 隐形软件工程：被忽视的SRE贡献

“如果让别人说出Google软件工程的名字，他们很可能会列出面向消费者的产品，如Gmail或Google Maps；有些人甚至会提到底层基础设施，如Bigtable或Colossus。但事实上，有大量的幕后软件工程是消费者从未见过的。其中很多产品都是在SRE内部开发的。”

Google的生产环境是“人类有史以来最复杂的机器之一”。SRE对错综复杂的生产环境有着第一手的经验，这使他们非常适合开发适当的工具来解决内部问题和与保持生产运行相关的用例。

SRE开发的工具类型多样，例如：

二进制推出机制（如渐进式发布系统）
监控系统（如Borgmon/Prometheus的前身）
基于动态服务器组成的开发环境
容量规划系统（如Auxon）

这些工具大多与维持正常运行时间和降低延迟的总体目标有关，但其形式和技术栈多种多样。

3.2 SRE为何适合做软件工程？

SRE在有效开发内部软件方面具有独特的优势，主要体现在以下三点：

优势①：独特的生产知识深度

SRE组织内所拥有的Google特有的生产环境构建知识的深度和广度，使得SRE工程师可以设计和实现出能够应对大规模部署、能够在灾难中优雅降级、可以与其他基础设施项目和工具良好集成的软件。

这意味着：只有真正经历过生产大规模故障的人，才知道软件需要具备哪些能力才能优雅地降级。

优势②：工具的直接使用者

SRE是自己工具的直接使用者，所以SRE能够深刻理解要开发工具的重点在哪里。

很多情况下，开发工具的人和使用工具的人是分离的（例如，产品经理设计需求、开发人员实现、运维人员使用）。但在SRE的场景中，这三者是同一批人——他们最清楚痛点在哪里，最清楚什么样的功能最有价值。

优势③：高质量的用户反馈

与这些工具的直接用户——其他SRE——的密切联系使得获取直接的和高质量的用户反馈变得很容易。向一个对问题和解决方案都很熟悉的内部团体发布工具可以让开发团队更快地进行迭代。

一个容易被忽视的优势：内部用户对UI的不足和alpha版本的问题有很强的包容性，这为快速试错和迭代创造了理想的环境。

3.3 为什么SRE内部软件开发是必要的？

“通过精心设计，SRE支持的服务增长率超过了SRE组织的增长率；SRE的指导原则之一是‘团队规模不应直接随服务增长而扩展’。”

在Google服务呈指数级增长的情况下，要实现团队的线性增长，就必须持续开展自动化工作，并努力简化工具、流程和服务的其他方面，因为这些方面会给生产的日常运营带来低效。

这个原则的深层含义：

服务增长率	理想团队增长率	如果没有工具化会怎样
指数级（如×10）	线性（如+20%）	团队规模也会指数级增长（不可持续）
非线性增长	持平或微增	需要持续自动化来消化新增负载

正因为很少有第三方工具的设计规模能够满足Google的需求，因此内部软件开发成为必要。

3.4 产品化思维：从“脚本”到“产品”

“总体而言，这些SRE开发的工具都是成熟的软件工程项目，有别于一次性解决方案和快速黑客，开发这些工具的SRE都采用了基于产品的思维方式，既考虑到了内部客户，也考虑到了未来计划的路线图。”

“脚本思维” vs “产品思维”：

维度	脚本思维	产品思维
生命周期	一次性或短期使用	长期维护、持续迭代
用户群体	自己或少数人	其他SRE团队、内部客户
规划方式	解决眼前问题	有路线图、有计划
质量标准	“能用就行”	可靠性、可扩展性、可维护性
文档与支持	很少或没有	完善的文档和用户支持

这个转变对于SRE团队至关重要：当工具被视为“产品”，它就会被持续投入、持续改进，而不是在创始人离开后迅速荒废。

3.5 SRE软件工程的双向价值

SRE驱动的软件开发不仅对组织有价值，对SRE个人和团队同样具有双向价值。

对组织的价值

支撑规模化：通过软件工程手段，让团队规模的线性增长支撑服务规模的指数级增长
提升可靠性：将运维知识和最佳实践固化为代码，确保一致性
降低琐事：自动化取代人工操作，释放SRE的精力

对个人和团队的价值

职业发展机会：为SRE提供了一条从“运维”到“开发”的职业发展通道
技能保鲜：为那些不希望自己的编码技能生疏的工程师提供了出路
工作平衡：长期的项目工作为中断工作和on-call工作提供了急需的平衡
工作满足感：为希望职业生涯在软件工程和系统工程之间保持平衡的工程师提供满足感
团队多样性：不同背景和解决问题的方法有助于防止盲点

3.6 Auxon案例研究：从“预测驱动”到“意图驱动”的容量规划

本章通过Auxon案例研究，展示了SRE如何将软件工程方法应用于一个具体的运维难题——容量规划。

3.6.1 传统容量规划的问题

传统的容量规划方法通常包含以下步骤：

收集对未来项目需求的预测
制定资源的采购、构建和分配计划
评审，并且批准这个计划
部署和配置对应的资源

这种方法存在两大核心缺点：

缺点	具体表现
不可靠性	计划会因微小的变化而全盘失效：服务效率下降、用户需求增加、集群上线推迟、产品设计决策变化（如每个视频存两份而非一份）
耗时	整个周期长，响应速度慢

3.6.2 Auxon的创新：基于意图的容量规划

Auxon由SRE内部开发，用于自动化Google生产中运行的服务的容量规划。其核心创新是从“预测驱动”升级为“意图驱动”。

维度	传统方式	Auxon方式
输入	需求预测（不可靠）	服务意图（我想要什么）
执行	人工制定计划	自动调整资源分配
反馈	慢	快速、持续
韧性	脆弱（易被小变化破坏）	弹性（自动适应变化）

3.7 SRE团队的人员构成

“谷歌一直努力为SRE团队配备具有传统软件开发经验的工程师和具有系统工程经验的工程师。”

SRE团队的多样性不是偶然的，而是有意为之的战略选择：

传统软件开发背景：带来工程方法论、架构设计、代码质量意识
系统工程背景：带来系统内核、底层网络、生产运维的实战经验

两种背景的工程师相互配合，可以避免团队陷入单一视角的“盲点”，在解决复杂问题时产生更全面的方案。

3.8 本章与SRE其他核心原则的呼应

核心原则	本章的体现
50%研发时间规则	软件开发项目是SRE履行50%研发时间承诺的主要途径
减少琐事	软件开发（自动化工具）是消除琐事的最直接手段
拥抱风险/错误预算	工具化容量规划（Auxon）帮助更精准地管理资源风险
简单化	将复杂的运维逻辑封装在工具中，对外提供简单接口
自动化	本章的软件工程实践正是第7章“自动化演进”的组织级落地

四、第18章知识点脑图总结

五、总结：一句话记住本章

SRE中的软件工程 = 将生产运维的知识和经验固化为可复用的内部产品，以团队规模的线性增长支撑服务规模的指数级增长，同时为SRE工程师提供职业发展的工程通道。

关键点	一句话概括
隐形软件工程	Google有大量消费者看不见的软件工程，很多在SRE内部完成
三大开发优势	生产知识深度 + 直接使用者 + 高质量反馈
产品化思维	SRE工具不是一次性脚本，而是有路线图的成熟项目
核心原则	团队规模不应随服务增长而线性扩展
Auxon案例	将容量规划从“预测驱动”升级为“意图驱动”
职业发展双通道	软件开发为SRE提供技能保鲜和工作平衡的出路
团队多样性	软件工程+系统工程背景，防止团队盲点

行动建议：

本周内完成：审视团队中是否存在“一次性脚本”式的自动化工具，评估将其升级为成熟软件项目的可行性；记录下团队最近一个月花费最多时间手工处理的运维问题
一个月内完成：选择1-2个高频运维痛点，规划将其转化为有路线图的工具开发项目，并分配至少20%的团队时间用于开发；在团队内部建立一个“工具集市”或知识共享机制
一个季度内完成：评估团队的人员构成，识别是否存在技能单一化的风险；为SRE工程师建立软件开发能力提升计划（如代码审查、设计文档、架构评审）
长期坚持：将“产品化思维”融入SRE团队的日常工作，每个工具都应有明确的所有者和路线图；定期评估工具的使用率和用户满意度，持续优化；关注SRE工程师的职业发展需求，确保既有on-call实践也有工程开发机会

六、高频考点自测

问题1：为什么SRE团队非常适合进行内部软件开发？

参考答案：SRE在有效开发内部软件方面具有三大独特优势：①生产知识深度：SRE组织拥有Google特有生产环境知识的深度和广度，能够设计出应对大规模部署、优雅降级、与其他工具良好集成的软件；②直接使用者：SRE是自己工具的直接使用者，深刻理解工具的重点和痛点；③高质量用户反馈：与其他SRE的密切联系使获取坦诚、高信号的反馈变得容易，内部用户对alpha版本的问题有很高的包容性，支持快速迭代。

问题2：什么是“产品化思维”？为什么它对SRE的软件开发很重要？

参考答案：“产品化思维”是指SRE开发的工具不是一次性脚本或快速解决方案，而是成熟的软件工程项目，开发者考虑了内部客户和未来计划的路线图。它之所以重要，是因为：① 有路线图的工具会得到持续投入和改进，不会因创始人离开而荒废；② 以“产品”的标准要求工具（可靠性、可扩展性、文档），能够真正支撑服务规模的指数级增长；③ 产品化思维确保工具可以被其他团队复用，放大单个团队的知识价值。

问题3：传统容量规划存在哪些问题？Auxon是如何创新的？

参考答案：传统容量规划的问题在于不可靠性和耗时——计划可能因微小变化（服务效率下降、用户需求增加、集群上线推迟、产品设计决策变化）而全盘失效，且响应速度慢。Auxon的创新是从“预测驱动”升级为“意图驱动”，通过编程方式表达服务意图并自动调整资源分配，替代了传统的手工预测和规划流程。

问题4：SRE软件工程对组织和SRE个人分别有哪些价值？

参考答案：

对组织的价值：支撑规模化（团队线性增长支撑服务指数级增长）、提升可靠性（知识固化为代码）、降低琐事（自动化取代人工）
对SRE个人的价值：职业发展通道、技能保鲜（防止编码生疏）、工作平衡（项目工作平衡on-call压力）、工作满足感
对SRE团队的价值：多样性（不同背景防止盲点）、留住人才

问题5：SRE团队为什么需要“多样性”的人才构成？

参考答案：Google一直努力为SRE团队配备具有传统软件开发经验的工程师和具有系统工程经验的工程师。不同背景和解决问题的方法有助于防止“盲点”——如果团队只有一种背景的工程师，可能会用单一视角看待复杂问题，错过更优的解决方案。多样性还能帮助团队更全面地理解生产系统的挑战：软件工程背景带来工程方法论和架构设计，系统工程背景带来系统内核和底层网络的实际经验。