作者: 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的创新是从“预测驱动”升级为“意图驱动”通过编程方式表达服务意图并自动调整资源分配替代了传统的手工预测和规划流程。问题4SRE软件工程对组织和SRE个人分别有哪些价值参考答案对组织的价值支撑规模化团队线性增长支撑服务指数级增长、提升可靠性知识固化为代码、降低琐事自动化取代人工对SRE个人的价值职业发展通道、技能保鲜防止编码生疏、工作平衡项目工作平衡on-call压力、工作满足感对SRE团队的价值多样性不同背景防止盲点、留住人才问题5SRE团队为什么需要“多样性”的人才构成参考答案Google一直努力为SRE团队配备具有传统软件开发经验的工程师和具有系统工程经验的工程师。不同背景和解决问题的方法有助于防止“盲点”——如果团队只有一种背景的工程师可能会用单一视角看待复杂问题错过更优的解决方案。多样性还能帮助团队更全面地理解生产系统的挑战软件工程背景带来工程方法论和架构设计系统工程背景带来系统内核和底层网络的实际经验。七、延伸阅读推荐《Google SRE工作手册》第20章“SRE Engagement Model”SRE如何与产品团队协作的详细指南《Google SRE工作手册》第29章“Service-Level Objectives in Practice”容量规划与SLO的衔接《The SRE Mindset Engineering for Reliability》SRE软件工程的核心理念Google SRE官方书籍网站https://sre.google《Auxon A Tool for SRE Capacity Planning》Google技术博客本章Auxon案例的深度扩展《SRE 中文社区》https://www.srenow.cn学习下一章预告第19章“前端负载均衡”——深入Google全球负载均衡系统GSLB的设计原理探讨DNS负载均衡如何与用户服务、RPC负载均衡协同工作。本文为个人学习笔记仅用于知识分享。如有错误欢迎指正。 点赞 收藏 分享让更多开发者看到这篇深度解析❤️ 如果觉得有用请给个赞支持一下作者