《SRE：Google 运维解密》读书笔记06: 少琐事 - SRE的隐形敌人

作者: andylin02

学习章节：第5章 减少琐事（Eliminating Toil）
关键词：琐事、Toil、自动化、50%规则、工程工作、职业发展

一、引言：琐事——SRE的隐形敌人

在日常运维工作中，总有一些反复出现、消耗大量精力却又无法带来长期价值的工作。这些工作看似"必须做"，却在不知不觉中吞噬了工程师的时间、扼杀了创造力，最终导致团队士气低落、人员流失。

Google SRE 团队用了一个专门的词来定义这类工作——琐事（Toil）。本章的核心就是要教会我们：如何识别琐事、量化琐事、并最终用工程的方法消灭琐事。

核心观点：如果系统正常运转中需要人工干预，应该将此视为一种Bug。

琐事不仅仅代表"我不喜欢做的工作"，它也不能简单地等同于行政杂务加上其他脏活累活。本章将帮助我们建立一套系统的方法论，把工程师从琐事中解放出来，投入到真正有价值的工程工作中去。

二、核心观点速览

三、详细内容拆解

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 中的E（Engineering）。

工程工作的核心价值：

• 工程工作有助于使该团队或是整个 SRE 组织在维持同等人员配备的情况下接手更大或者更多的服务

• 对工程工作的关注使 SRE 可以在服务规模扩大的同时减少人数，并且比单纯的研发团队和单纯的运维工作团队能更有效地管理服务的秘诀

5.2 自动化：最直接有效的手段

琐事可以被自动化是其核心特征之一——如果软件程序可以和运维人员一样能够很好地完成某个任务，或者通过某种设计变更来彻底消除运维人员手动、重复的处理某项工作，就应该被自动化。

Google SRE 的组织目标是把时间花在自动化上：创建一个将人类排除在外的系统，这样我们就能专注于有价值的工作。

自动化的指导原则：

5.3 管理策略和战术

以下是减少琐事的实用管理策略：

1. 作为项目识别和度量：把减少琐事当成一个正式项目来管理，而不是随意的优化

2. 工程师撤出琐事系统：从全局角度出发，从源头消灭琐事，而不是在末端被动处理

3. 拒绝琐事密集型任务：故意拖延一次性处理——有些琐事如果"慢一点处理"，反而会暴露其可消除性

4. 关注服务整体健康度而不是某一部分：不要陷入局部优化陷阱

5. 逐步自动化：小步快跑，持续迭代

6. 提供自助服务：让用户自己完成常规操作

7. 获得管理层和同事支持：减少琐事需要团队共识和组织支持

8. 大力推广消减琐事：让团队意识到这是 SRE 的核心职责

9. 从高优先级的小处着手改善：找到 ROI 最高的琐事优先处理

10. 增加一致性：标准化可以减少认知负担和执行成本

11. 评估自动化风险：避免自动化带来的新问题

12. 形成组件和库便于复用：减少重复开发

13. 使用开源和第三方工具：不要什么都自己造轮子

14. 使用反馈进行改进：持续迭代优化

5.4 流程改进

• 建立工单系统：让所有请求可见、可追踪，暴露琐事的真实规模

• 标准化变更流程：减少临时性的、一次性的变更操作

• 自助服务：让用户自己完成常规操作，减少 SRE 的人工介入

六、琐事与工程工作的平衡

6.1 50% 规则的深层意义

SRE 公开 50% 这个目标不仅是一个数字，更是一个承诺：

• 对团队的承诺：SRE 不会沦为一个纯运维组织

• 对新员工的承诺：招聘时引用 50% 规则，承诺新员工不会专门进行运维工作

• 通过禁止 SRE 组织或者其中任何小团队退化为专门从事运维工作的组织来实现这个承诺

6.2 平衡的挑战

在实际工作中，维持 50% 的平衡并不容易：

• 琐事并不会自然消失，需要我们从事工程性工作岗位的人主动"对抗"

• 琐事往往看起来"重要且紧急"，而工程工作属于"重要但不紧急"——容易被延迟

• 文化阻力：传统组织可能不理解为什么要"花时间减少工作"，认为这是"偷懒"

一个实用的思维转变：琐事过多需要主动抱怨，发现有琐事影响工程时间的投入了要主动提出。工程性的工作是为了未来的发展，国内讲的是"磨刀不误砍柴工"，国外总结四象限工作法——工程性工作归属于"重要但不紧急"，不能总是让位于"不重要但是紧急"的琐事。

6.3 架构价值与琐事的关系

琐事与系统架构价值有着深刻的关联。正如《架构整洁之道》中提出的观点：一个软件系统的价值应当由两部分组成——业务价值和架构价值。随着业务的增长，架构价值往往被忽略，逐渐下滑，这不可避免会导致琐事的增加。

核心洞察：琐事恰恰是众多架构价值减分项中最容易被解决的部分。因此，从琐事入手，分析架构下滑的原因并解决，积极主动地为"重要不紧急"的琐事优化争取机会，既是 SRE 岗位的工作需求，也是架构师们的工作重点。

一个实践建议：可以建立技术债列表，在列举技术债的时候，往往从日常运维出发，思考有什么工作是需要经常运维的，这些工作有没有办法可以通过研发新的功能来解决。这就是有意识地以"工程性"工作来解决"琐事"，也是在主动提升整个系统的架构价值。

6.4 识别和管理琐事的检查清单

七、第5章知识点脑图总结

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

琐事 = 手动、重复、可自动化、战术性、无持久价值、线性增长的工作；SRE 的目标是用 50% 的时间做工程工作，从根本上消灭琐事。

行动建议：

1. 本周内完成：花 15 分钟回顾过去一周的工作，标记哪些属于琐事，初步计算琐事占比

2. 一个月内完成：为团队建立轻量级工单追踪系统，记录琐事的类型、耗时和频次

3. 一个季度内完成：从高频低价值的琐事中选 1-2 项进行自动化改造

4. 长期坚持：每季度进行团队琐事调查，确保每人琐事占比 < 50%；将减少琐事纳入团队 OKR

九、高频考点自测

问题1：什么是琐事？请用六个特征描述。

参考答案：琐事是运维服务中具有以下特征的工作：

• 手动性：需要人工执行

• 重复性：不停反复出现，不是一次性工作

• 可自动化：软件程序可以同等或更好地完成

• 战术性：突发性、应对式，非策略驱动

• 无持久价值：完成后服务状态没有永久性改善

• 线性增长：工作量随服务规模线性增加

一个工作满足上述一个或多个特征即可视为琐事。

问题2：为什么 SRE 要设定 50% 的时间用于工程工作？

参考答案：如果不加以控制，琐事会越来越多，最终占据工程师 100% 的时间。50% 规则有三个核心作用：

1. 防止退化：确保 SRE 组织不会沦为一个纯运维团队

2. 职业承诺：招聘时以此承诺新员工不会只做运维工作

3. 规模化能力：工程工作可以让团队在维持人员规模甚至减少人员的情况下接手更大的服务

问题3：琐事和流程负担有什么区别？

参考答案：

• 琐事：与运维服务直接相关的重复性手工劳动，如清理日志、处理告警、手工执行变更等

• 流程负担：与运维服务不直接相关的行政工作，如招聘、会议、工作总结、培训等

两者都不是工程工作，但性质不同——琐事直接与服务运维相关，流程负担来自组织管理的需求。SRE 需要识别并减少的是琐事；流程负担则需要从组织层面优化。

问题4：Google SRE 如何实践减少琐事？

参考答案：Google SRE 通过以下方式减少琐事：

1. 识别：通过工单系统追踪琐事，让不可见的工作变得可见

2. 量化：通过季度调查统计琐事占比，发现异常值并及时调整

3. 轮岗机制：在多地团队间建立轮岗，公平分配琐事负载

4. 工程优先：将至少 50% 时间用于工程工作，从根本上消除琐事根源

5. 数据驱动：向团队展示工单的传入率和传出率，用数据说服团队

6. 架构优化：从琐事入手，分析架构下滑的原因，通过工程手段提升系统架构价值

问题5：琐事过多会给团队带来哪些负面影响？

参考答案：琐事过多会带来五个主要负面影响：

1. 职业停滞：花在工程项目上的时间太少，职业发展变慢甚至停滞

2. 士气低落：过度劳累、厌倦和不满

3. 生产力下降：团队被琐事淹没，无法思考如何改善系统

4. 人才流失：最好的工程师会寻找更有价值的工作机会

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 章"监控分布式系统" —— 如何设计有效的监控体系，以及四个黄金指标的使用方法。

本文为个人学习笔记，仅用于知识分享。如有错误，欢迎指正。

👍🏻 点赞 + 收藏 + 分享，让更多开发者看到这篇深度解析！❤️ 如果觉得有用，请给个赞支持一下作者！