社区译者：Eric Li
审校：Kalid
原作者：Eric Harvieux
原文地址：https://cloud.google.com/blog/products/management-tools/identifying-and-tracking-toil-using-sre-principles
Google 站点可靠性工程师(SRE)用来验证有效性的关键指标之一就是衡量我们如何利用每一天的时间。我们希望有足够的时间来进行长期性项目的工作,但鉴于我们也负责 Google 服务的持续运营，有时候也需要做一些手工工作。我们的目标是将少于一半的时间花在所谓的“琐事”上。那什么是琐事，怎样才能阻止它干扰工程师的工作速度？我们将在这篇文章中讨论这些问题。
首先，我们先来定义琐事，在《站点可靠性工程手册》第五章中是这样定义:
“琐事是一类手工的，可重复的，可自动化的，短效的，缺乏持久价值，并且随着服务增长呈线性增长的工作。”
一些琐事的例子包括:
- 处理配额请求；
- 申请数据库架构更改；
- 检查非关键监控告警；
- 从剧本复制粘贴命令。
这些例子都有一个共同点，它们不需要工程师的人工判断，该工作容易但又不会给你很大回报，而且它会打断我们服务扩容和发布新功能的进展。
接下来谈谈如何带领团队一步一步识别、衡量和消除琐事的过程。
识别琐事
处理琐事最困难的部分是识别它。如果你没有明确跟踪它，那么团队中可能会发生很多你不了解的工作。琐事通常来自于发给你的一个短信或电子邮件，你勤勉地完成了工作但没有其他人注意到。我们从澳大利亚悉尼的 CRE Jamie Wilkinson 那里听到了一个很好的例子，他分享了他在管理 Google 数据存储服务之一的团队中担任 SRE 的经历。
杰米(Jamie)的 SRE 团队分散在悉尼和加利福尼亚山景城（Mountain View）之间，两个站点的工作之间存在很大的脱节。悉尼的部门感到沮丧的是，他们依赖于山景城的项目工作从来没有被完成。悉尼的一位工程师走访了山景城的团队，发现那里的团队全天经常被打扰，处理开发人员的临时造访和即时信息。
尽管定期召开会议讨论紧急事件和项目工作，并且抱怨山景城方面工作过度饱和， 但悉尼的团队还是因为不知道这些请求的上下文帮不上忙。因此，团队决定要求将所有请求作为错误提交。山景城团队也开始接受培训，以便于迅速介 入并为每位客户的紧急问题提供帮助，前后花了三个月的时间才完成文化的变革。之后一旦发生类似情况，他们终于可以在两个站点之间建立人员轮岗以分配负载， 查看有关工作量和所需时间的统计信息，并确定需要修复的重复性问题。
杰米说:“从中得出的一个结论是，当你开始衡量正确的指标时，你可以向人 们展示正在发生的事情，然后他们会同意您的看法。”“向团队中的每个人显 示收到和完成工单的比率是一个分水岭。”
当以这种方式跟踪你的工作时，它有助于在你选择的跟踪系统中收集一些轻量级的元数据，例如:
- 它是什么类型的工作(配额更改，生产环境的发布，访问控制列表（ACL）更新等)?
- 困难程度是多少:容易(<1 小时);中(小时);难(天)(基于人工时间而不是经过的时间)?
- 谁做的工作?
这些初始数据使得你能评估琐碎工作的影响。但是请记住，此步骤的重点是轻量级，极高的精度在这里几乎没有价值。如果需要捕获许多细节，实际上会给团队带来更多负担，并使他们感到受微观管理。
成功识别琐事的另一种方法是对团队进行调查。另一个 Google CRE Vivek Rau 定期调查 Google 的整个 SRE 组织，由于不同的 SRE 团队之间琐事的大小和特性不同，因此对整个公司层面的工单指标很难统一进行分析。他每三个月对 SRE 进行一次调查，以找出在整个 Google 占用项目时间的通用问题。可以从以下调查问题开始:
-
在过去的四个星期中，您平均花在琐事上的时间比例是多少?
- 比例0-100%
-
您对花费在琐事上的时间有多满意?
- 不开心/可以/完全没有问题
-
排名前三的琐事来源是什么?
- 值班响应/中断/推送/容量/其他/等
-
您的季度目标中是否有长期的工程项目?
- 是/否
-
如果是这样，那么在过去四个星期中，您平均花在工程项目上的时间大约占 总时间的一部分?(估计)
- 比例0-100%
-
在您的团队中，是否存在有些琐事可以通过自动化解决，但却不能这样做，因为琐事占用太多时间以至于无法脱身做长期的工程项目?如果是这样，请在下面说明。
- 开放性回答
衡量琐事
一旦你识别了所有应完成的工作，如何确定工作是否过多?这很简单:定期(我们发现每月或每季度是一个不错的间隔)，估算出在各种类型的工作上花费了多少时间。 在故障单，调查和应急事件响应中查找模式或趋势，并根据花费的总人力时间确定优先级。在 Google SRE 中，我们的目标是将琐事工作的时间保持在每个 SRE 时间的50%以下，并保留其余50%的时间用于工程项目工作。如果估算结果表明我们已经超过了50%的琐事门槛，那么我们会明确地将减少工作量并使工作平衡回到健康状态定为新的目标。
消除琐事
既然已经确定并衡量了琐事，现在是时候将其最小化了。正如已经提示的那样，解决方案通常是使工作自动化。这并不总是那么简单，目的不应该是消除所有琐事。
将不经常执行的任务(例如，在新站点部署服务)自动化可能很棘手，因为在这种情况下你再次执行同一任务时，你的步骤或在自动化时所做的假设可能会发生变化。如果你花费大量时间在这种工作上，请考虑如何更改基础体系架构以适应这种可变性。你是否使用基础架构即代码 (IaC) 解决方案来管理系统?可以多次执行该过程而没有负面影响吗?是否有测试来验证执行过程?
像对待其他生产系统一样对待你的自动化。如果你有 SLO 实践，把一些错误预算用在自动化上来消除琐事。当你的自动化失败时，需要及时做事后检查，并像处理任何面向用户的系统一样对其进行修复。你希望在任何情况下(包括生产事故)都能使用自动化，以使人员能够自由地完成他们擅长的工作。
如果你的用户已经习惯建立工单以请求帮助，请使用工单系统作为自动化的 API，从而使工作完全自助。
另外，由于琐事不仅限于技术层面，也体现在是文化上，所以确保只有被分配到的人才需要处理琐事。这个人可以是值班人员，或者是被轮岗处理 “故障单”或“服务中断”的工程师。这样可以保证其余成员的时间来进行项目工作，并强化了一种对琐事公开和负责的文化。
复杂性和琐事的区别
有时，工程师和领导层会误将技术上或组织中的复杂性看作琐事。他们对人的影响很相似，但复杂性引发的工作没有满足本文一开头对琐事的定义。即琐事通常缺乏长久的价值，而复杂性是让非常有价值的工作变得很费力。
Google SRE Laura Beegle 一直在 Google 内部进行调查，并提出了另一种识别复杂性的方法:尽管设计简单，健壮的系统令人非常满意，但它可能是部署在分布式环境中，被各种不同类型的用户使用，又或随着时间的推移开始提供更多的功能，这些都足以让它变得日渐复杂。我们希望我们的系统随着时间的推移而发展，同时也减少我们所谓的“复杂体验”,任务完成时间或难度与我们期望不吻合而带来的负面感觉。量化系统的主观体验还有另外一个名称:用户体验。在这些情况下，SRE 自己就是用户，通过良好管理系统复杂事务可以带来一些可观测结果，进而带来更好的用户体验。
解决运维的用户体验是一项具有持久价值的工程工作，因此与琐碎的工作不一样。如果发现复杂性正在威胁系统的可靠性，请采取措施。通过遵循一个不指责的事后分析，或团队调查，你可以识别一些由于复杂性导致意外结果或恢复时间长于预期的情况。
我们不可避免地需要对系统进行一些手动维护，但是所需的人员数量不应随虚拟机，用户或请求的数量线性增长。工程师都知道使用计算机完成日常任务的好处，但是往往发现自己还是手工完成了很多工作。 通过识别，测量和减少琐事，我们可以降低运营成本，并确保有时间专注于困难而有趣的项目。
更多关于 SRE 的信息, 请参考《SRE 基础知识》或浏览《SRE》一书.
