作者: andylin02学习章节第5章 减少琐事Eliminating Toil关键词琐事、Toil、自动化、50%规则、工程工作、职业发展一、引言琐事——SRE的隐形敌人在日常运维工作中总有一些反复出现、消耗大量精力却又无法带来长期价值的工作。这些工作看似必须做却在不知不觉中吞噬了工程师的时间、扼杀了创造力最终导致团队士气低落、人员流失。Google SRE 团队用了一个专门的词来定义这类工作——琐事Toil。本章的核心就是要教会我们如何识别琐事、量化琐事、并最终用工程的方法消灭琐事。核心观点如果系统正常运转中需要人工干预应该将此视为一种Bug。琐事不仅仅代表我不喜欢做的工作它也不能简单地等同于行政杂务加上其他脏活累活。本章将帮助我们建立一套系统的方法论把工程师从琐事中解放出来投入到真正有价值的工程工作中去。二、核心观点速览维度琐事Toil工程工作Engineering Work性质手动、重复、战术性新颖、主观判断、战略性价值缺乏持久价值带来长久性改善自动化可以被自动化需要创造性设计增长模式随服务规模线性增长越通用越好可规模化复用结果维持现状服务变得更好三、详细内容拆解3.1 什么是琐事Toil琐事就是运维服务中手动性的、重复性的、可以被自动化的、战术性的、没有持久价值的工作而且琐事与服务呈线性关系的增长。一个经典案例运维人员收到磁盘目录满告警后手动登录服务器清理日志文件。这件事手动、重复下次磁盘还会满、可以被自动化、没有持久价值清理完服务状态没有任何改进且随着服务器数量增长这类工作的频次会线性增加。另一个琐事密集场景周期性报表和周期性巡检。这类工作虽然看似有必要但如果每次都需要人工执行就完全符合琐事的定义——重复、可自动化、缺乏持久价值。琐事的六大特征六维识别法特征判断标准典型示例手动性需要人工执行而非系统自动完成手动运行脚本、手动登录服务器、手工执行命令重复性不停反复做不是一次性工作清理日志、周期性报表、周期性巡检可自动化软件程序可以同等或更好地完成告警处理、配置变更、数据迁移战术性突发性、应对式非策略驱动处理紧急告警、响应临时请求无持久价值完成后服务状态没有任何改善抑制告警不能防止未来复发线性增长与服务规模、流量、用户数呈线性关系随服务器数量增加的日常巡检一个工作只要满足上述一个或多个属性就可以被归类为琐事。琐事 vs 非琐事如果某件事是第一次做甚至第二次做都不算琐事。琐事就是不停反复做的工作——如果你正在解决一个新出现的问题或者寻求一种新的解决办法不算琐事。琐事与服务呈线性关系增长如果任务量随服务规模线性增长那就是琐事的强信号。琐事的分类根据《Google SRE工作手册》琐事可以按照来源分为以下几类分类内容典型场景业务流程工单处理、配置变更、开通请求处理配额请求、应用数据库架构变更生产中断告警处理查看非重要监控提醒产品发布发布、回滚、紧急补丁、手动配置变更发布、版本回退迁移手动方式的大规模数据/服务迁移数据搬迁、服务重构迁移工程成本和容量规划容量评估、资源申请扩容操作、资源分配不透明架构的故障排查黑盒排查、技术债务难以定位的间歇性问题3.2 琐事的典型例子以下是一些琐事的典型例子它们的共同特征是无需工程师进行人为判断——内容很简单但回报不高并且常常干扰我们使我们无法在其他高价值工作如扩展服务和发布功能的工程性工作上取得进展处理配额请求用户申请资源配额需要人工审批和配置应用数据库架构变更执行预定义的 SQL 脚本查看非重要监控提醒检查那些可以自动处理的低价值告警从手册上复制粘贴命令按照文档手动执行已知的运维操作手动清理日志文件磁盘空间满时的常规处理手动取数/数据倒换重复性的数据操作周期性报表和巡检定期人工检查系统状态文档类型的预案执行没有自动化的预案文档3.3 什么算作工程工作工程工作是一种新颖的、本质上需要主观判断的工作。它是符合长期战略的会对你的服务进行长久性改善的工作。工程工作通常是有创新性和创造性的着重通过设计来解决问题解决方案越通用越好。工程工作有助于使该团队或是整个 SRE 组织在维持同等人员配备的情况下接手更大或者更多的服务。典型的工程工作例子编写自动化脚本创造工具或框架增加可扩展性和可靠性的服务功能修改基础设施代码以使其更稳健与研发团队进行的架构、设计和生产环境方面的咨询工作3.4 SRE 的典型活动分类书中将 SRE 的日常活动分为四类分类定义示例是否工程性软件工程编写或修改代码及所有相关的设计和文档编写自动化脚本、创造工具/框架、增加服务可扩展性✅ 是系统工程配置生产系统、修改配置、书写系统文档监控部署/更新、负载均衡配置、服务器配置、操作系统调优、架构咨询✅ 是琐事与运维服务相关的重复性、手工劳动手动清理日志、周期性报表、巡检❌ 否流程负担与运维服务不直接相关的行政工作招聘、会议、工作总结、评价、培训❌ 否关键点前两项软件工程和系统工程属于工程性工作后两项不属于。最好能有 50% 的时间花在工程性工作上。琐事 vs 流程负担琐事是运维相关的手工劳动而流程负担是与运维无关的行政杂务。两者都不是工程工作但性质不同——琐事直接与服务运维相关流程负担则来自组织管理的需求。3.5 为什么琐事越少越好如果不加以控制琐事会变得越来越多以至于迅速占据我们每个人 100% 的时间。Google SRE 团队公开设定 50% 规则正是为了防止这种恶性循环。SRE 至少花50% 的时间在工程项目上以减少未来的琐事或增加服务功能。增加服务功能包括提高可靠性、性能或利用率同时也会进一步消除琐事。琐事过多的负面影响1. 职业停滞花在工程项目上的时间太少你的职业发展会变慢甚至停滞。工程师如果长期只做琐事技能无法成长最终会成为有 10 年经验还是 1 年经验重复了 10 年的那类人。2. 士气低落过多的琐事会导致过度劳累、厌倦和不满。工程师不是来当人肉运维机器的长期处理琐事会让人怀疑自己的职业价值。3. 生产力下降琐事过多会导致团队生产力下降——一个被琐事淹没的团队根本没有精力去思考如何让系统变得更好。4. 人才流失如果团队中引入了太多的琐事其实就是在鼓励团队里最好的工程师开始寻找其他地方提供的更有价值的工作。顶尖工程师不会甘于做重复性劳动。5. 团队摩擦和边界模糊如果 SRE 过于愿意承担琐事研发同事就更倾向于加入更多的琐事有时甚至将本应由研发团队承担的运维工作转给 SRE。其他团队也会开始指望 SRE 接受这样的工作这显然是不好的。量化说明50% 规则与琐事计算Google SRE 公开 50% 这个目标是因为如果不加以控制琐事会变得越来越多。对工程工作的关注使 SRE 可以在服务规模扩大的同时减少人数。琐事的实际计算任何一个 SRE 在参与 on-call 时都会承担一定程度的琐事一个典型的 SRE 每个周期中会有一周主 on-call 和一周副 on-call在一个六人轮值周期中至少 2/6 ≈33%的时间需要专注于 on-call 和中断性事务如果是八人轮值最小值约为25%来自 Google SRE 的数据显示琐事的最大来源是中断性工作与服务相关的非紧急邮件和请求其次是on-call紧急处理再然后是发布和数据更新。Google 的实际情况季度调查显示琐事的时间占用大约在 33%整体优于 50% 的目标。但需要注意的是这个平均值掩盖了内部差异一些 SRE 琐事比例为 0%纯开发项目而另一些人宣称他们在琐事上花费了 80% 的时间。当某位 SRE 报告自己承担了过量的琐事时通常意味着管理者需要在团队中更均衡地分布琐事负荷。四、如何识别琐事——Google 的实践经验4.1 识别琐事最难但最关键的一步处理琐事最困难的环节是识别琐事。如果您没有明确地对琐事进行定义与追踪那么很可能您的团队在无意识中被很多琐事纠缠。琐事通常以请求的形式通过短信或电子邮件发给您或其他人收到的人会尽职尽责地完成工作而这个过程其他人注意不到。4.2 案例Google 数据存储服务团队的经验Google SRE 团队分享了一个非常典型的例子背景SRE 团队分散在悉尼和山景城两地悉尼团队依赖山景城团队的项目工作但后者从未按时完成问题发现悉尼的一位工程师到访山景城后发现山景城团队每天频繁被打扰要处理来自开发者的当面询问和即时消息——琐事在无形中吞噬了工程时间解决方案将所有请求以 Bug 形式提交并设立轮岗机制培训与转变经过三个月的培训与适应山景城团队可以在客户出现紧急情况时迅速介入并提供帮助成效团队文化改善两地之间建立人员轮岗制度可以分配工作量、统计所需时间、识别需要修复的重复问题关键结论当您开始正确衡量事情时也可以同时向人们展示正在发生的状况人们在了解后也会赞同您的看法。——Jamie Wilkinson向团队中的每个人展示工单的传入率和传出率是一个重要的转折点。4.3 量化追踪琐事在追踪系统中收集一些轻量级的元数据例如是什么类型的工作配额变更、将发行版上线、ACL 更新等工作难易程度容易1 小时、中小时、难天谁做的工作注意事项此步骤的重点是轻量级极高的精度在这里几乎没有价值。如果需要捕获许多细节实际上会给团队带来更多负担并使他们感到受微观管理。4.4 调查法另一个 Google 的有效做法是定期对团队进行问卷调查估算团队花在琐事上的时间百分比当这个数字超过 50% 时就要着手减少琐事。Google 的 SRE 团队会定期调查整个组织了解不同成员的琐事占比发现异常值后及时介入——比如某人琐事占比过高可能意味着管理者需要在团队中更均衡地分配琐事负荷同时鼓励该 SRE 找到自己满意的工程项目。4.5 琐事识别清单如果你不确定某项工作是否属于琐事可以用以下问题自查问题是否这项工作是否每次都需要手动执行⬜⬜这项工作是否反复出现不是一次性任务⬜⬜这项工作能否用软件程序同等或更好地完成⬜⬜这项工作是否是突然出现的救火式工作⬜⬜完成这项工作后服务状态有永久性改善吗⬜⬜这项工作的工作量是否随着服务规模线性增长⬜⬜得分越高说明越可能是琐事越需要被消除或自动化。五、减少琐事的策略和方法5.1 根本性策略工程思维SRE 减少琐事的核心方法是工程思维——不是简单地多招人而是通过设计和构建自动化工具从根本上减少对人工干预的依赖。减少琐事和扩大服务规模的工作就是 SRE 中的EEngineering。工程工作的核心价值工程工作有助于使该团队或是整个 SRE 组织在维持同等人员配备的情况下接手更大或者更多的服务对工程工作的关注使 SRE 可以在服务规模扩大的同时减少人数并且比单纯的研发团队和单纯的运维工作团队能更有效地管理服务的秘诀5.2 自动化最直接有效的手段琐事可以被自动化是其核心特征之一——如果软件程序可以和运维人员一样能够很好地完成某个任务或者通过某种设计变更来彻底消除运维人员手动、重复的处理某项工作就应该被自动化。Google SRE 的组织目标是把时间花在自动化上创建一个将人类排除在外的系统这样我们就能专注于有价值的工作。自动化的指导原则原则说明不要自动化错误的流程自动化一个错误的流程只会让你更快地犯错逐步推进自动化从高优先级的小处着手改善形成组件和库便于复用避免重复造轮子评估自动化风险不是所有事情都适合自动化需要权衡成本和收益提供自助服务让用户自己完成一些操作而不是依赖 SRE5.3 管理策略和战术以下是减少琐事的实用管理策略作为项目识别和度量把减少琐事当成一个正式项目来管理而不是随意的优化工程师撤出琐事系统从全局角度出发从源头消灭琐事而不是在末端被动处理拒绝琐事密集型任务故意拖延一次性处理——有些琐事如果慢一点处理反而会暴露其可消除性关注服务整体健康度而不是某一部分不要陷入局部优化陷阱逐步自动化小步快跑持续迭代提供自助服务让用户自己完成常规操作获得管理层和同事支持减少琐事需要团队共识和组织支持大力推广消减琐事让团队意识到这是 SRE 的核心职责从高优先级的小处着手改善找到 ROI 最高的琐事优先处理增加一致性标准化可以减少认知负担和执行成本评估自动化风险避免自动化带来的新问题形成组件和库便于复用减少重复开发使用开源和第三方工具不要什么都自己造轮子使用反馈进行改进持续迭代优化5.4 流程改进建立工单系统让所有请求可见、可追踪暴露琐事的真实规模标准化变更流程减少临时性的、一次性的变更操作自助服务让用户自己完成常规操作减少 SRE 的人工介入六、琐事与工程工作的平衡6.1 50% 规则的深层意义SRE 公开 50% 这个目标不仅是一个数字更是一个承诺对团队的承诺SRE 不会沦为一个纯运维组织对新员工的承诺招聘时引用 50% 规则承诺新员工不会专门进行运维工作通过禁止 SRE 组织或者其中任何小团队退化为专门从事运维工作的组织来实现这个承诺6.2 平衡的挑战在实际工作中维持 50% 的平衡并不容易琐事并不会自然消失需要我们从事工程性工作岗位的人主动对抗琐事往往看起来重要且紧急而工程工作属于重要但不紧急——容易被延迟文化阻力传统组织可能不理解为什么要花时间减少工作认为这是偷懒一个实用的思维转变琐事过多需要主动抱怨发现有琐事影响工程时间的投入了要主动提出。工程性的工作是为了未来的发展国内讲的是磨刀不误砍柴工国外总结四象限工作法——工程性工作归属于重要但不紧急不能总是让位于不重要但是紧急的琐事。6.3 架构价值与琐事的关系琐事与系统架构价值有着深刻的关联。正如《架构整洁之道》中提出的观点一个软件系统的价值应当由两部分组成——业务价值和架构价值。随着业务的增长架构价值往往被忽略逐渐下滑这不可避免会导致琐事的增加。核心洞察琐事恰恰是众多架构价值减分项中最容易被解决的部分。因此从琐事入手分析架构下滑的原因并解决积极主动地为重要不紧急的琐事优化争取机会既是 SRE 岗位的工作需求也是架构师们的工作重点。一个实践建议可以建立技术债列表在列举技术债的时候往往从日常运维出发思考有什么工作是需要经常运维的这些工作有没有办法可以通过研发新的功能来解决。这就是有意识地以工程性工作来解决琐事也是在主动提升整个系统的架构价值。6.4 识别和管理琐事的检查清单阶段行动项识别建立工单系统让琐事变可见定期进行团队琐事调查记录每次中断性工作的类型和时间分类按六大特征判断是否属于琐事区分琐事类型业务流程/告警/发布/迁移/容量/排查量化跟踪每类琐事的时间占比计算团队整体琐事比例识别琐事占比过高的个体消除/自动化从高频低价值的琐事开始评估自动化方案并逐步实施提供自助服务选项监控定期回顾琐事占比变化确保 50% 规则不被打破关注团队士气和人员流失率持续改进建立定期审查机制将减少琐事纳入团队 OKR分享自动化成果和经验七、第5章知识点脑图总结八、总结一句话记住本章琐事 手动、重复、可自动化、战术性、无持久价值、线性增长的工作SRE 的目标是用 50% 的时间做工程工作从根本上消灭琐事。关键点一句话概括琐事的六个特征手动性、重复性、可自动化、战术性、无持久价值、线性增长——满足其一即可认定为琐事工程工作的本质新颖、主观判断、长期战略、持久改善、越通用越好50% 规则SRE 至少花 50% 时间在工程工作上防止退化减少琐事的方法识别→量化→自动化→标准化用工程思维解决问题Google 经验让琐事变可见用数据驱动决策建立工单系统和轮岗机制核心洞察琐事是架构价值下滑的最直接体现解决琐事就是提升系统架构价值行动建议本周内完成花 15 分钟回顾过去一周的工作标记哪些属于琐事初步计算琐事占比一个月内完成为团队建立轻量级工单追踪系统记录琐事的类型、耗时和频次一个季度内完成从高频低价值的琐事中选 1-2 项进行自动化改造长期坚持每季度进行团队琐事调查确保每人琐事占比 50%将减少琐事纳入团队 OKR九、高频考点自测问题1什么是琐事请用六个特征描述。参考答案琐事是运维服务中具有以下特征的工作手动性需要人工执行重复性不停反复出现不是一次性工作可自动化软件程序可以同等或更好地完成战术性突发性、应对式非策略驱动无持久价值完成后服务状态没有永久性改善线性增长工作量随服务规模线性增加一个工作满足上述一个或多个特征即可视为琐事。问题2为什么 SRE 要设定 50% 的时间用于工程工作参考答案如果不加以控制琐事会越来越多最终占据工程师 100% 的时间。50% 规则有三个核心作用防止退化确保 SRE 组织不会沦为一个纯运维团队职业承诺招聘时以此承诺新员工不会只做运维工作规模化能力工程工作可以让团队在维持人员规模甚至减少人员的情况下接手更大的服务问题3琐事和流程负担有什么区别参考答案琐事与运维服务直接相关的重复性手工劳动如清理日志、处理告警、手工执行变更等流程负担与运维服务不直接相关的行政工作如招聘、会议、工作总结、培训等两者都不是工程工作但性质不同——琐事直接与服务运维相关流程负担来自组织管理的需求。SRE 需要识别并减少的是琐事流程负担则需要从组织层面优化。问题4Google SRE 如何实践减少琐事参考答案Google SRE 通过以下方式减少琐事识别通过工单系统追踪琐事让不可见的工作变得可见量化通过季度调查统计琐事占比发现异常值并及时调整轮岗机制在多地团队间建立轮岗公平分配琐事负载工程优先将至少 50% 时间用于工程工作从根本上消除琐事根源数据驱动向团队展示工单的传入率和传出率用数据说服团队架构优化从琐事入手分析架构下滑的原因通过工程手段提升系统架构价值问题5琐事过多会给团队带来哪些负面影响参考答案琐事过多会带来五个主要负面影响职业停滞花在工程项目上的时间太少职业发展变慢甚至停滞士气低落过度劳累、厌倦和不满生产力下降团队被琐事淹没无法思考如何改善系统人才流失最好的工程师会寻找更有价值的工作机会团队边界模糊研发团队可能将更多本应自己承担的运维工作转嫁给 SRE十、延伸阅读推荐《Google SRE 工作手册》提供更多具体工作示例和实操指导USENIX 文章《Invent More, Toil Less》包含 Bigtable SRE 团队减少琐事的详细案例研究Google Cloud Blog《Identifying and Tracking Toil Using SRE Principles》SRE 中文社区https://www.srenow.cn学习下一章预告第 6 章监控分布式系统 —— 如何设计有效的监控体系以及四个黄金指标的使用方法。本文为个人学习笔记仅用于知识分享。如有错误欢迎指正。 点赞 收藏 分享让更多开发者看到这篇深度解析❤️ 如果觉得有用请给个赞支持一下作者