在 Google，站点可靠性工程师 (SRE) 们将工作时间分配作为验证工作效率的关键指标之一。我们希望有足够的时间投入到长期的工程项目中，但仍肩负着保证 Google 服务持续且良好运行的重任，并且偶尔还需要做一些手动工作。
所以，我们的目标是控制每日消耗在日常 “琐事 (Toil)” 上的时间。
那么什么是琐事呢？我们应当如何阻止它干扰我们，降低我们的工程效率呢？我们将在本文中探讨这两个问题。
首先，我们来定义琐事。在《站点可靠性工程》(Site Reliability Engineering) 一书第 5 章中，对于 Toils 的解释如下：
“琐事是一种趋向于手动、重复、可被自动化、具有战术性但缺乏持久价值的工作，并且琐事随着服务的多样化呈线性增长。”
站点可靠性工程
https://landing.google.com/sre/sre-book/chapters/eliminating-toil/
以下是一些琐事的示例：
处理配额请求
应用数据库架构变更
查看非重要监控提醒
从手册上复制黏贴命令
上述示例的共同特征是它们无需工程师进行人为判断。这些工作的内容很简单，但回报不高，并且常常干扰我们，使我们无法在其他高价值工作（如：扩展服务和发布功能的工程性工作）上取得进展。
以下是帮助您的团队如何完成识别、衡量和消除琐事这一过程的方法：
识别琐事
解决琐事中最困难的环节是识别琐事。如果您没有明确地对琐事进行定义与追踪，那么很可能您的团队在无意识中被很多琐事纠缠。
琐事通常以请求的形式通过短信或电子邮件发给您或其他人，收到的人会尽职尽责地完成工作，而这个过程其他人注意不到。
我们曾在澳大利亚悉尼听注册可靠性工程师 (CRE) Jamie Wilkinson 讲述过一个很典型的琐事例子，他同我们分享在管理 Google 数据存储服务团队中担任 SRE 的经历：
Jamie 的 SRE 团队成员分散在悉尼和加利福尼亚州山景城两座城市，两个团队的完成情况存在很大的脱节。悉尼团队依赖于山景城团队承诺完成的项目工作，但山景城团队从未按时完成，这时常让悉尼团队感到沮丧。悉尼团队的一位工程师在到访山景城团队后了解到，他们每天经常受到打扰，要处理来自山景城开发者的当面询问和即时消息。
尽管他们会定期举行会议来讨论 on-call 紧急事件、项目工作以及山景城方面超负荷工作的抱怨，但对于这些事情，悉尼团队无法提供帮助，因为他们不知道这些请求的重要程度。
因此，悉尼团队决定将所有请求以错误 (Bug) 的形式提交，并设立轮岗机制。
之后，经过为期三个月的培训与适应，山景城团队可以在每次客户出现紧急情况时迅速介入并为其提供帮助，团队文化也因此改善。一旦紧急情况发生，两边的团队就可以通过在彼此之间建立的人员轮岗制度，分配工作量、查看工作量和统计所需时间以及识别需要修复问题的重复提交。
“我们从中得出了一个结论：当您开始正确衡量事情时，也可以同时向人们展示正在发生的状况，人们在了解后也会赞同您的看法。”Jamie 说，“向团队中的每个人展示工单的传入率和传出率是一个重要的转折。”
当以这种方式追踪您的工作时，在您选择的追踪系统中收集一些轻量级的元数据，例如：
是什么类型的工作（配额变更、将发行版上线、访问控制表 (ACL) 更新等）？
工作难易程度：简单（小于 1 小时）、中等（几小时）、困难（几天）（基于实际投入的操作时间，而非总共消耗的时间）？
这些工作由谁完成？
这些初始数据可让您衡量琐事的影响。但是请记住，此时不要过于严苛。在这一步过度追求精确几乎没有价值。如果团队成员记录许多细节，这会给团队带来更多负担，而且会使他们觉得受到微管理。
另一种可以识别琐事的方法是向团队发放调查问卷。另一位 Google 注册可靠性工程师 Vivek Rau 会定期对 Google 的整体 SRE 进行调查。由于不同的 SRE 团队之间琐事的频率和状况各不相同，因此在整个公司这一层级用工单指标进行分析会更加困难。Vivek Rau 每三个月对 SRE 们进行一次调查，在 Google 内部找出整个项目工作中花费时间的常见问题。可尝试以下琐事调查样本：
在过去的四周中，您平均花在琐事上的时间比例大约是多少？
范围 0-100%
您是否满意您在琐事上花费的时间？
不开心 / 还行 / 挺好的
三大琐事来源分别是什么？
紧急响应 / 中断 / 推送 / 容量 / 其他 / 等
您的季度目标中是否有长期的工程项目？
有 / 没有
如有长期工程项目，请您大概估计一下，在过去四个星期中您平均花在工程项目上的时间占比是多少？
范围 0-100%
在您的团队中，是否有可以自动化却没有自动化的琐事，而恰恰因为这个琐事，浪费掉大量本应用于长期工程工作的时间？如有，请在下方说明。
开放问题
衡量琐事
识别琐事之后，如何确定花费的时间是否值得？很简单：定期估算在各种类型的工作上花费的时间（月度或季度是一个不错的选择）。
在工单、调查和紧急事件响应中寻找模式或趋势，并根据花费的总人力时间确定优先级。在 Google SRE中，我们的目标是将每个 SRE 的琐事时间占比保持在 50% 以下，并确保剩余 50% 的时间留给工程项目工作。如果估算结果表明我们已经超过 50% 的琐事阈值，那么我们将明确工作安排，以减少这一数值并使工作平衡恢复到健康状态。
消除琐事
既然您已经识别琐事并做出相关衡量，那就开始尽可能消除它吧。正如我们在上文多次提到的那样，消除琐事的解决方案通常是工作自动化。虽然这一过程没那么简单，而且我们的目的也不应该是消除所有琐事。
将执行频率不高的任务（例如在新的地点部署服务）自动化可能会很棘手，因为当您再次执行同一任务时，某些规程或假设无法复用。如果此类琐事频率较高，也许可以考虑应如何更改基础体系结构以消除掉这种干扰：
您是否使用基础设施即代码 (IaC) 解决方案来管理系统？
是否可以多次执行该规程而没有负面作用？
是否有可以验证规程的测试？
像对待其他生产系统一样对待您的自动化。如果您有服务水平目标 (SLO) 实践，请使用您的一些错误预算来实现自动化以消除琐事。当您的自动化失败时，请进行事后调查，并像处理面向用户的系统一样对其进行修复。您希望在任何情况下（包括生产事件）都能使用自动化功能，以便解放人力，让他们完成擅长的工作。
服务水平目标 (SLO) 实践
https://cloud.google.com/blog/products/management-tools/learn-how-to-set-slos-for-an-sre-or-cre-practice错误预算
https://cloud.google.com/blog/products/gcp/building-good-slos-cre-life-lessons
如果您的用户已经熟悉工单请求帮助的流程，那么可以使用工单系统作为自动化的 API，从而使工作完全自助。
另外，琐事不仅是技术上的，也是文化上的，所以请确保分配过程明确且只有被分配到的人员从事琐事工作。可安排处理“工单”或“中断”的工程师随时待命或轮换。这样可以将剩余的时间留给团队从事项目性工作，同时也增强问题解决与了解琐事工作量的团队文。
关于复杂工作和琐事的说明
有时我们会看到工程师和领导层错误地将技术或组织的复杂工作视作琐事。虽然两者对人的影响具有相似性，但复杂工作并不符合本文开头的定义。琐事 是没有持久价值的工作，而 复杂工作 本身存在价值，但会让人感到繁重。
Google SRE Laura Beegle 一直在 Google 内部进行调查，并提出解决复杂工作的不同方法：尽管设计简单、稳定的系统会产生强烈的满足感，但仅仅通过将其置于分布式环境、各种用户使用场景或随着时间的推移提供更多功能，则会不可避免地让系统变得更复杂。我们希望我们的系统随着时间的推移而进化，同时也要减少所谓的“有经验的复杂性”，即对任务完成时间或难度的错误预期而产生的负面感觉。量化系统的主观体验的另一个名称是：用户体验。在本例中，用户是 SRE。对于系统复杂性的良好管理，最直观的结果就是用户体验更好。
提升系统的用户体验是一项具有持久价值的工程工作，因此与琐事不同。如果您发现复杂工作正在威胁系统的可靠性，请采取相应措施。通过遵循没有瑕疵的事后调查流程或进行团队调研，您可以识别出复杂工作导致意外结果或恢复时间长于预期的情况。
没有瑕疵的事后调查流程
https://landing.google.com/sre/sre-book/chapters/postmortem-culture/
我们不可避免地需要对构建的系统进行一些手动的运维，但是所需的人员数量不应随虚拟机、用户或请求的数量呈线性增加。作为工程师，我们当然知道使用计算机能够完成很多日常任务，但是通常的情况是我们最终还是手动完成该项工作。我们可以通过识别、衡量和减少琐事来降低运营成本，并确保有时间专注于困难和有价值的项目。
如要了解有关网站可靠性工程的更多信息，请了解基础知识或完整阅读这本《站点可靠性工程》。
了解基础知识
https://cloud.google.com/blog/products/gcp/sre-fundamentals-slis-slas-and-slos完整阅读这本《站点可靠性工程》
https://landing.google.com/sre/books/
— 推荐阅读 —
