消除琐务：会随规模一起长大的活，才是真正的敌人

一句话

你以为琐务（toil）就是「脏活杂活、我不想干的活」，其实定义里最要命的那一条跟情绪毫无关系：它随服务规模线性增长。这一章把这件事变成一套可执行的纪律——给琐务下一个有六个特征的硬定义，把它与「工程」「杂务」分开，设一条 50% 的上限，并要求持续测量。一句话：琐务不是让人不爽的活，是让人力必须跟着流量一起涨的活；不砍掉它，扩容的代价最终由人头来付。

Glossary · 术语表

坐标

本章属 Part II「原则」，紧跟 Ch3「拥抱风险」与 Ch4「服务质量目标」——那两章定可靠性该做到什么程度，本章管人的时间该花在哪，并把 Ch1 立下的「运维工作不超过 50%」从口号变成可核算的纪律。往下 Ch6「监控」讲告警怎么设计（告警与工单正是琐务的最大来源），Ch7「自动化的演进」讲怎么真正消灭它，Ch9「简单性」讲怎么一开始就少造它。对应现实：任何 SRE / DevOps / 平台团队，以及所有「一半写代码、一半救火」的后端团队。

这章要解决什么

病一：运维工作会自动把时间吃光。它总是急的（有人在等）、总是可完成的（一小时内能划掉一条）、做完还有人道谢；而「重构发布流程」要两个月，期间没有任何反馈。没有强制配额时，急事永远赢过重要的事——这不是纪律问题，是激励结构问题，所以对策不是号召自觉，而是划一条硬线。

病二：这类工作是 O(n) 的，而服务会长大。这才是全章真正的敌人。一件每周吃掉 5 小时的手工操作本身不致命，致命的是流量翻倍时它变成 10 小时、再翻倍变成 20 小时。不需要团队变笨、也不需要多出事故，只要业务成功，它就会自己长到吃掉所有人。算一笔账（按书里的口径自行推演，非书中原数）：8 人团队每周共 320 人时，上限即琐务不超过 160 人时；24×7 双人轮值被打断约 28 小时、每周 3 次发布共 12 小时、配额与权限工单 30 张 ≈ 20 小时，合计 60 人时占 19%，非常健康。可这三项全是 O(n)：规模翻一番约 120 人时（38%），再翻一番 240 人时（75%）就越线了——中间没有任何人做错事。

病三：说不清哪些活该被消灭。「我不爱干的活」这个判据既太宽（把开会、面试算进来）又太窄（漏掉点几下就完事、干着还挺解压的活）。没有共同定义，「我们琐务太多了」就只是一句抱怨——管理者既没法核实，也没法处置。

核心内容，讲透

1. 六个特征：琐务的硬定义，以及它不是什么

书里的定义是一句长句：琐务是那种绑在运行生产服务上、倾向于手工、重复、可自动化、战术性、没有持久价值、且随服务增长而线性变多的工作。六个特征不是「满足其一即是」，而是一组同时逼近的画像，各自挡掉一类误判：

表 1 · 六个特征逐条自检：同一件事，怎样算琐务、怎样不算

更重要的是它不是什么。书开宗明义：琐务不等于「我不喜欢干的活」。三条边界值得记牢：①「脏活」不一定是琐务——花两天把一个乱七八糟的配置彻底清理干净、从此不再出问题，那是有持久价值的工程；② 杂务不是琐务——招聘、开会、写自评占时间，但它们不随服务规模涨，属于另一个桶；③ 干着舒服也可能是琐务——书特意提到小剂量的重复劳动甚至令人平静，风险低、见效快、有成就感。判据是它的增长曲线，不是它给你的感受。

2. 四个桶：把一周的时间分清楚

光有琐务的定义还不够用，否则「剩下那 50% 算什么」永远说不清。书把时间分成四类：软件工程（写自动化、造工具与框架，或为可扩展性 / 可靠性给服务加功能）、系统工程（配置生产系统、改配置、写文档，特点是一次性投入换长期改善，如搭监控、配负载均衡、调系统参数，也包括给开发团队做架构与上线咨询）、琐务、杂务。前两个桶合起来叫「工程」，那条 50% 的下限说的就是它们。

分桶的判据是「做完之后留下了什么」：软件工程留下一段以后能反复用的代码，系统工程留下一次性动手换来的长期改善，琐务什么也没留下——服务回到原样，等下一次。杂务则与「运行这个服务」无直接关系。后两个桶都不计入那 50%，但别把杂务算成琐务去虚报数字。

3. 50% 上限：为什么必须是一条硬线

规矩本身很短：每个 SRE 至少 50% 的时间要花在工程项目上，琐务因此必须低于 50%。关键在后半句——这是上限，不是目标。书里公布的一次内部调查显示，Google SRE 花在琐务上的时间约占 33%，明显低于上限，团队之间差异则极大。把 50% 当「达标线」经营，是最常见的误读。同一份调查还点了名：三大来源是中断（非紧急的服务相关消息与邮件）、on-call 紧急响应、发布与推送——多数团队的琐务不在什么神秘角落，就在工单队列、传呼记录、发布流程这三处，去捞一捞一个准。

那超标了怎么办？这不是「再努力一点」能解决的，书给的是组织层面的处置：管理者度量并干预，把溢出的运维负担退回给产品研发团队（Ch1 立的溢出阀——超出部分回流给写这个服务的开发团队，极端情况把传呼交还给他们），或者补人。正是这条机制的存在，才让 50% 从愿望变成约束。

4. O(n) 才是敌人：为什么这条线迟早会被撞破

前面三节还只是分类学，这一节才是全章的物理规律。琐务的可怕不在于它今天占多少，而在于它的增长曲线跟业务成功挂钩。书给了一个很高的标准：设计与管理良好的服务，应能在只做一次性资源扩充的前提下再长一个数量级，日常工作量基本不变。反过来说——流量翻十倍就得招十倍的人，那不是「业务太好」，是设计问题。

5. 琐务不总是坏的——真正的问题是剂量

这是本章最容易被忽略的分寸。书明确说：少量琐务并不让人痛苦，可预期的重复劳动甚至有安抚作用——低风险、低压力、有成就感、能带来快速的胜利。它变成毒药是因为量。书列的七个后果条条是组织病而非技术病：职业停滞（工程产出太少，成长停摆）、士气低落、角色混淆（团队被当成纯运维队）、拖慢进度、开了先例（SRE 什么都接，开发团队就继续往这边扔）、人员流失、背弃承诺（冲着做工程加入的人天天在干杂活）。

关键权衡与选型

这一章的权衡不在选技术，而在面对一件重复劳动，你把它推到哪一级、以及什么时候干脆不推。

表 2 · 处置一件重复劳动的五级阶梯：越往下一次性投入越大，残余人工越少

那到底该不该自动化？当一道投资题算：年节省 = 单次耗时 × 年频次；投入 = 开发工时 + 每年维护工时。一件每周 5 小时的琐务，一年 260 小时；自动化按 3 人周 ≈ 120 小时、每年维护 20 小时，约半年回本，值得做。而一件每月 1 小时（年 12 小时）的琐务同样投 120 小时，要十年才回本——那就忍着做。还有个常被忘的乘数：服务的剩余寿命，给 9 个月后要下线的系统写自动化，账面再好看也是白干。这也正是 Google 网络维修团队给的第一条建议——先度量，挑最大的那块下手，并用省下的时间算投资回报。

表 3 · 琐务越过 50% 上限时，四种组织级处置及其代价

最后一个权衡：度量本身也要花时间。Google 给的实操口径是「轻量」——记三样就够（哪类工作、难度易 / 中 / 难、谁做的），按月或季度估一次，不追求精确。这条很重要：不少团队把琐务统计做成了一套新的琐务，每周填表半小时，正好把省下的时间又吃回去。

为什么重要 / 落到真实系统

这一章的真正贡献，是给「运维工作」装上了一个管理层看得懂的计量单位。此前「我们太忙了」是无法核实的抱怨，此后它变成「本季度琐务占 62%，其中 70% 来自配额工单」——一个能进 OKR、能要资源、能拒绝新需求的数字。今天平台工程里的「自助化」「工单清零」「无人值守发布」，源头都在这里。它也改写了面试的正确答法：被问「你们怎么做运维自动化」，答「写了很多脚本」不及格；合格的答法是先说怎么度量琐务、占几成、最大的三个来源，再说先动了哪一个、为什么是它、省回来多少小时。

易错点与争议

• 把「我不爱干的活」当琐务。最常见的误用。开会、招聘、写自评是杂务，算进去只会让数字虚高。反过来，「点几下就完事、还挺解压」的活常常正是琐务。
• 把 50% 当目标而不是上限。它是天花板，书里的内部调查是约 33%。长期贴着 49% 运行的团队并不健康，只是还没撞墙。
• 把「自动化」当成唯一解。阶梯的最后一级是设计掉：与其写个机器人替人审批配额，不如把配额做成自助、或干脆取消这道审批。被自动化的坏流程，仍然是坏流程。
• 忘了自动化自己也有成本。书在 Ch7 专门提醒：自动化让错误得以用机器的速度、按机队的规模发生。无人值守修复系统出错时的爆炸半径，远大于一个手忙脚乱的人。
• 「退回给开发团队」严重依赖组织权力。Google 的 SRE 有拒绝接管、交还传呼的实际筹码；多数公司的运维团队并没有，照抄这条上限往往退化成贴在墙上的口号。没有溢出阀的 50% 不是约束，是许愿。
• 一个值得知道的反方视角：这套框架天然偏袒「能写代码的人」——它把值班、排障、跨团队沟通这些高度依赖经验与判断的工作，一并放进了「该被机器接管」那一栏。书自己留了余地，但实践中「消除琐务」很容易被简化成「看不起运维」。
• 时代局限：2016 年成书时云托管、基础设施即代码、Kubernetes 生态都还没到今天的形态；而它们在消灭一批琐务的同时造出了新的一批（谁来运维那套自动化？）。2018 年的《The Site Reliability Workbook》第 6 章才补上实施细节与案例——本章给的是判据与纪律，不是工具清单。

要点