第六章 减少琐事

Google SRE花费大量时间对系统进行优化，哪怕是很少的性能收益，也会通过工程化方法，与开发一起协同努力，追求卓越。但优化范围不仅局限于服务器资源，SRE的工作耗时也是重点。首先，SRE工作不是琐事，（关于琐事请参阅《SRE：Google运维解密》第5章内容）。本章我们将琐事定义为与维护服务相关的重复的、可预测的、持续的任务流。

对于任何产品运维团队来说，琐事不可避免。运维不可避免地需要处理部署、升级、重启、告警处理等工作。如果放纵不管，这些工作将很快耗尽整个团队精力。Google将SRE团队日常操作的耗时占比限制在50%（包括琐事和非劳动密集型工作）以内（这样做的原因，请参阅《SRE：Google运维解密》书中第5章内容）。虽然这个目标可能不适合所有团队，但对花费在琐事上的时间设置上限仍然很重要，因为识别和量化琐事是团队时间优化的第一步。

 

琐事的定义？

琐事往往具有如下特征：这在我们的中上一本书中（《SRE：Google运维解密》译者注）有所阐述。在这里，我们举一个具体的例子来解释琐事的特征：

手动性的

当web服务器上的tmp目录的磁盘占用达到95%时，工程师Anne登录到服务器并在文件系统中查找要删除的无关日志文件。

重复性的

打满/tmp目录的事情不太可能是一次性的，因此我们需要反复去处理它。

可以被自动化的

假设修复文档的工作包括如下几个步骤：“X登录，执行此命令，检查输出，执行命令，并通过命令的输出来判断是否需要重启Y”。这些指令流本质上就是伪代码！在上面这个例子中，解决方案实际上已经可以部分自动化了。如果不需要人来运行脚本，自动化的问题检测和修复就更好了。如果想做的更好，我们提交一个补丁使软件不再因为文档损坏的问题中断。

非技术性的

“磁盘打满”和“服务宕机”之类的警告会分散工程师的注意力，从而忽略高价值的事情，并可能掩盖其他高严重性的警告。大量类似的告警造成的后果是服务健康状况受到影响。

没有持久的价值

完成一项任务会带来一种令人满意的成就感。但长远来看，这种重复的满足感不能让工程师一直认为有价值。比如，处理警报能够确保用户查询持续进行，确保HTTP请求状态码< 400以便可以让应用提供持续的服务，这些很好。然而，今天解决的问题并不能防止将来不再出现类似的问题，所以这样做的回报只是短期的。

与服务同步增长

许多业务工作量的增长速度与基础设施规模的增长一样快(或许更快)。 例如，可以预期你花费在修复硬件故障的时间会随着服务器集群规模的增加而增加。但是相关的辅助任务(例如，软件/配置更改)不一定是这个趋势。

我们并不能将带来琐事的原因规范化和标准化，但是我们需要知道琐事有多种特征。除了以上特征外，还要考虑某项工作对团队士气的影响。人们乐于完成一项觉得会有回报的任务，还是会处理无益的琐碎和无聊的任务？答案显而易见，琐事会慢慢地降低团队士气——时间往往花在琐事上而不是花在批判性思考或者是表达创造力上了；只有减少琐事，工程师才能更好地将时间用于思考和进行创造的领域。

案例：人工处理琐事

作者：John Looney，Facebook资深 SRE

哪一部分工作内容是琐事，通常是模糊的。有时候，一个“创造性”的解决方案 ，可能使问题得到最优解决，因此，SRE团队应奖励那些对根因分析并解决的人，而不是那些掩盖问题的人。

我加入Google后的第一个任务（2005年4月）是追查一批机器死机原因并修复，如果确认是硬件原因，则转交给硬件技术人员维修。但当注意到需在截止日期前处理超过20,000台机器时，这个任务就没那么简单了！

第一台机器死机原因是，Google网络驱动补丁不断打印毫无意义的日志，导致文件系统根目录写满，还有一千台机器是同样问题。

我和同事沟通了解决这个问题的方案：编写一个脚本，ssh到所有异常机器，如果根目录已满，则清空/var/log中大文件日志，并重启syslog。 我的同事对此方案不认可，他说最好找到根因并修复。如果掩盖了问题，在后续一段时间内，可能会引起更多严重性问题。

理论上，每台机器每小时的成本约为1美元。我的想法是，成本是运维工作很重要的衡量指标，应该高优让机器提供服务，利用起来。但我并没有考虑：如果只是解决了这个表象，就没有机会去追查根因，内核团队的测试用例也不会覆盖系统日志量。

在高级工程师指导下，我翻阅了内核源码，找到导致此问题的可疑代码，并且记录了bug，帮助内核团队完善了他们的测试用例。从成本来看，解决这个网络补丁问题，每花费一小时，Google将为此付出1,000美元。

那天晚上就发布了新的内核版本，第二天我就把它升级到所有受影响的机器，内核团队在第二周更新了他们的测试用例。这个问题的处理，我很满意，因为找到了根因并成功修复，而不是每天上班后清理日志。

琐事的度量

运维工作是辛苦的。一旦决定为了减少琐事你要做些什么时，如何知道你做的努力是成功的？许多SRE团队是结合经验和直觉来回答这个问题。经验和直觉会产生好的效果，但是我们还可以将方法上升到一个理论的维度。

经验和直觉是因人而异、非客观的。根据场景的不同，琐事的定义也不同。比如说，同一团队的不同成员会根据工作的投入产出比来判断一件事情是否可以定义为琐事。此外，为了减少琐事所做的工作可能会持续几个季度甚至几年的时间(本章的一些案例研究就证明了这一点)，在此期间团队的人员主要任务可能会发生改变。所以，为了保证减少琐事的工作能够长期进行，一般的，团队必须从几个确定的琐事中选择一个琐事来消灭它。我们应当将这件事上升为一个项目，并且需要建立起这个项目的长期的客观的度量机制以保证我投入得到回报。

在开始减少工作负载的项目之前，重要的是分析成本与收益，并确认通过减少琐事所节省的时间(至少)与第一次开发和维护自动化解决方案所投入的时间成正比(图6-1)。从节省的时间与投入的时间的简单比较来看，那些看起来“无利可图”的项目可能仍然值得进行，因为自动化有许多间接或无形的好处。潜在的好处包括:

项目越大，对于劳动力减少的效果越明显。

提高团队士气，减少团队流失和成员的厌倦情绪

更少的中断性工作，从而提高团队工作效率

提高流程清晰度和标准化

增强团队成员的技术技能和拥有更全面的职业发展

缩短新成员的培训时间

减少人为错误导致的问题

提高安全性

缩短用户投诉的响应时间

图 6-1 预测在消除琐事的工作上花费的时间，并确保其收益大于投入

琐事的计算方法

1.识别它。第一本SRE书的第5章提供了如何识别琐事。最能够识别琐事的人取决于团队本身。理想情况下，SRE团队既是利益相关方，也是实际操作方。

2.选择适当的计量单位来量化人力成本。我们可以选择“分钟”或者“小时”这么一个客观和普遍能够理解的计量。务必还要考虑琐事转自动化的成本。有些人力成本具有分散性和碎片化的特征，所以我们从成员工作的内容来衡量更为合适。度量单位应该要能够很好的度量如下工作：为应用增加的补丁，完成的票证，手动生产环境的变更，电子邮件交换或者是一些对硬件的操作。总的来说，只要度量单位客观，一致且易于理解，它就可以作为工作的衡量标准。

3.在消除琐事项目的整个项目周期内我们需要连续跟踪并记录度量的指标。我们可以使用工具或脚本来简化度量指标的测量过程，使得收集这些测量值不会产生额外的工作！

琐事分类法

琐事，就像一座摇摇欲坠的桥梁或一座漏水的大坝，日复一日地隐藏在广阔无垠的大地之中。 本节中的类别并不能够详尽无遗，但代表了一些常见琐事的类别。 这些类别中许多类似“正常”的工程工作，但是它们实际上就属于琐事。 将琐事视为一个频谱而不是简单的用二元分类来区别它是有必要的。

商业流程

这可能是最常见的琐事来源。也许您的团队管理一些计算机资源 —— 计算，存储，网络，负载平衡器，数据库等，以及为该资源提供支持的硬件资源。您可以处理用户登录，配置修改和计算机安全维护，软件更新以及缩扩容。你还可以最大限度地降低成本避免计算机资源的浪费。你的团队是计算机的人机界面，通常与为其需求提交票证的内部客户进行交互。您的组织甚至可能拥有多个票务系统和工作系统。

票务系统属于“狡猾”一类的琐事，因为其驱动的业务流程通常是我们需要完成的目标。用户得到了他们想要的东西，并且因为琐事通常分散在整个团队中，所以琐事并不能明显地显现出来。 在存在票据驱动过程的任何地方，都有可能悄悄地积累这琐事。 即使你没有明确的自动化流程，仍然可以执行流程改进工作，例如简化流程，使其更容易在以后自动化起来，同时更加容易管理。

工作中断

中断是一类为了保证系统运行的时间敏感类管理任务。 例如，你可能需要通过手动释放磁盘空间或重新启动泄漏内存的应用程序来解决某些资源（磁盘，内存，I/O）的严重短缺。 你可能正在提交更换硬盘驱动器，“踢”出无响应的系统或手动调整容量以满足当前或预期的负载请求。 通常，中断会将注意力从更重要的工作上移开。

发布监管

在许多组织中，部署工具从发布到生产需要SRE进行监管。 即使有自动化，全面的代码覆盖，代码审查和多种形式的自动化测试，这个过程并不总是顺利进行。 根据工具和发布节奏，发布请求，回滚，紧急补丁以及重复或手动配置更改，发布扔产生琐事。

迁移

技术迁移也是我们经常要处理的一类事情。 你可以手动或使用有限的脚本来执行此工作，而且希望只需要迁移一次。 迁移有多种形式，包括有数据存储，云供应商，源代码控制系统，应用程序库和工具的更改。 如果你手动迁移大规模的工程，迁移很可能涉及到“琐事”。 对于大规模的迁移，你可能倾向于手动执行迁移，因为这是一次性的工作。 并且我们甚至会将其视为“项目”的一部分而非“琐事”，但迁移工作的很多特征与“琐事”的特征是吻合的。 从技术上讲，修改一个数据库的备份工具以便与另一个数据库可以协同工作是软件开发的范畴，但这项工作本质上只是重构代码，用一个接口替换另一个接口。 这项工作是重复的，并且在很大程度上，备份工具的业务价值与之前是相同的。

压缩成本和容量规划

无论是拥有硬件还是使用基础架构提供商（云），压缩成本和容量规划通常是一些劳动密集型的工作。例如：

•在计算，内存或IOPS（每秒输入/输出操作）等资源的未来规划中要确保成本效益和突发情况的扩容能力。这可能转化为采购订单，AWS预留实例或云/基础设施即服务合同协商。

•应对（并从中恢复）关键的高流量事件，如产品发布或者假期。

•排查下游和上游服务水平和限制情况。

•针对不同的配置优化工作负载。 （你想买一个大盒子，还是四个小盒子？）

•根据专有云服务产品的计费细节优化应用程序（适用于AWS的DynamoDB或适用于GCP的Cloud Datastore）。

•重构工具以便更好地利用现有资源。

•处理超额预订资源，无论是基础设施提供商的上游还是与下游客户之间。

不透明体系结构的故障排除 分布式微服务架构现在很常见。随着系统更加分散，出现了新的故障模式。团队可能没有能力来构建复杂的分布式跟踪，高保真监控或详细的仪表板。 即使企业确实拥有这些工具，它们也可能不适用于所有系统。故障排除甚至可能需要登录到各个系统并使用脚本工具来对日志进行实时地查询分析分析。 故障排除本身并不是坏事，但你应该把精力集中在新的故障模式上 - 而不是每周都发生的由脆弱系统架构导致的故障。随着可用度为“P”的新关键上游依赖性服务的上线，系统可用性将下降（1-P）倍。 一个可用度为4个9的服务增加了9个关键的4个9的核心组件，现在就变为了是一个三个9的服务。

琐事管理战略

任何规模的生产系统，人力管理都是至关重要的。 一旦确定并量化了琐事，就消除它的计划就要提上日程。这个工作可能需要数周才能完成，因此制定一个完善的计划是至关重要。首先，从源头上消除琐事是最佳的解决方案，但是对于源头上无法消除的琐事，必须通过其他方式来消除它。在我们深入研究两个案例之前，本节提供了此方面工作的通用性准则。正如下文中两个案例中看到的那样，琐事的细微差别是因团队而异，但无论如何，一些常见的准则是适用于任何规模或风格的组织中。在后续案例中将以具体方式说明了以下每种模式。

琐事的识别和量化衡量

采用数据驱动的方法来识别琐事，并配合客观的成本控制策略，获得此类项目最优的投入产出比。如果你的团队正在被琐事缠身，并将减少琐事作为了一个长期的项目。Google SRE团队根据多年的经验，在控制项目投入产出比方面是一个不错的借鉴。 有关技术和指导，请参见第96页的“量化琐事”一节。

SRE工程师从琐事中解脱出来

减少琐事的最佳策略是从源头杜绝琐事。在进行系统设计和为生产环境制定流程之前，工程师要优化产品和系统来减少甚至消除琐事。

真正了解生产环境的痛点和知道导致系统出现琐事原因的那部分人正是SRE工程师，因为只有他们是和生产环境紧密联系的人。SRE工程师应该在与产品开发团队合作的过程中，将自己的运维经验与产品开发团队共享从而开发出人机交互友好型的软件，从源头减少琐事，并且使产品具有更好的扩展性和弹性。

拒绝琐事

一个被琐事缠身的团队应该尽早的做出“消除琐事”决策。第一种策略是对琐事说“不”，对于每个琐事，量化它并以此为原则决定是否要做，但是根据Google的经验，这一种策略可能会适得其反。另一种策略是故意拖延这些琐事，直到我们可以通过批处理或并行处理来解决它。将琐事集中在一起一并处理它们，这种方式可以减少工作中的中断，并帮助你们识别琐事的特征，并将它们作为下一个消除目标。

使用SLO减少琐事

如第2章所述，服务系统应具有文档化的SLO。明确定义SLO才能使工程师做出明智的决策。例如，如果某项工作即使做也不会减少服务的错误预算，你就可以考虑忽略某项工作。随着服务的增长，专注于整体服务的可用性而不是单个设备的SLO，这样做是非常有利的，也是可持续的。有关编写有效SLO的指导，请参阅第2章。

从部分自动化开始

如果你的业务特别复杂，请将“部分自动化”方法视为实现“完全自动化”的临时步骤。在这种方法中，你的服务通常可以通过定义的API接收结构化数据。工程师也可以进行一些操作从而得到想要的结果。虽然这样做需要一些手动的操作，但是这种“幕后工程师”方法是逐步实现全自动化的前提。使用“客户端输入”来统一收集数据；通过确定的请求格式，你可以更容易的以编程的方式对请求进行处理。这种方法让客户也能够明白你需要的信息和指标，并在你完全理解系统服务之前避免使用大型的解决方案而产生的未知问题。

提供一种自助的服务方法

一旦你们提供了交互型界面的服务产品，请进一步的为用户提供自助式的服务方法。你可以提供Web表单，二进制，脚本，API，甚至只是告诉用户如何向服务的配置文件发出拉取请求的文档。例如，软件开发工程师要求SRE工程师为其开发工作配置新虚拟机，我们为他们提供一个简单的Web表单或脚本来触发配置，而不是让他们提交相关票证来进行这件事。如果发生了特殊的情况，我们也允许使用“票证”的方式替代自助的服务，这是可接受的。部分自动化是一个良好的开端，但服务SRE工程师应该始终要致力于尽可能让服务自动化起来。

获得管理层和同事的支持

在短期内，减少琐事的项目需要投入人力成本，反之会减少处理其他日常任务的人员数量。但长远来看，如果项目达到了减少琐事的目标，团队将更加健康，并有更多的时间进行更重要的工程改进。对于团队中的每个人来说，“减少琐事”作为一个共同的价值目标是很重要的。管理层的支持对于减少工程师的干扰是至关重要。制定琐事评估的客观指标来说明项目的推进情况可以让管理层更加支持项目的进行。

减少琐事作为提高服务稳定性一部分

要为减少琐事的项目创建一个强大的业务案例支持，将你的目标与其他业务目标相结合。 如果有一个补充性的目标，例如，安全性、可扩展性或可靠性——这对客户来说是具有吸引力的，他们会更愿意放弃当前充满琐事的系统，转向更加亮眼的新系统。这样来看，减少琐事也可以提高用户服务的质量，这也是另一个角度来看待琐事的认识。

从简单的琐事开始并持续改善，不要试图设计没有琐事的系统。面对一个充满琐事的系统，首先自动化一些高优先级的项目，然后通过评估这个项目所花费的时间来改进你的解决方案，总结获得的经验和教训。在项目开始之前，选择一个明确的指标，如MTTR（平均修复时间）来评估你的项目的进展和效果。

提高系统的一致性

从规模上看，多样化的生产环境是难以管理的。特殊的生产环境容易出错，管理能力会降低，事故的处理能力也会降低。你可以使用“宠物与牛”方法（https://www.engineyard.com/blog/pets-vs-cattle）来添加系统冗余并在你的生产环境中实施增加一致性的决策。是否选择“牛”取决于组织的需求和规模。将网络链路、交换机、机器、机架，甚至整个集群评估为可互换单元也是合理的。将设备转换为“牛”的理念可能会带来较高的初始成本，但会减少中长期的维护成本，增强灾难恢复能力和提高资源利用能力。为多个设备配置相同的接口意味着它们具有相同的配置，是可互换的，维护成本就降低了。各种设备的界面一致（转移流量，恢复流量，执行关机等）使系统更加灵活和更加的可扩展。谷歌鼓励工程团队将不断发展的内部技术和工具包进行统一，并有相应的鼓励机制。无论团队用什么样的方法，但他们不得不承认一些不受支持的工具或遗留的系统是产生琐事的根源。

评估自动化带来的风险

自动化可以节省人力成本，但是也会出现未知的错误，严重时会造成停机。一般情况下，防御性软件可以控制这类事情的发生。当管理级别的行为被自动化之后，防御性软件会显得至关重要。在执行前应对每项行为的安全性进行评估。在实施自动化时，我们建议采用以下做法：

•防御性地处理用户输入，即使这个输入来自于上游的系统 ——换句话说，要对上下游的输入进行仔细的校验。

•构建告警机制，使得工程师可以接收到相关告警以进行处理。安全措施可能与命令超时一样简单，也可能是对当前系统指标或当前中断次数的更复杂检查。因此，监控，报警和仪表系统应由机器和操作人员共同使用。

•请注意，即使是简单的读取操作也可能会导致设备负载过高和触发服务中断。随着自动化的扩展，这些安全检查的工作量是可控的。

•最大限度地减少因自动化安全检查不完整导致服务中断的影响。如果操作员遇到不安全的情况，自动化操作应该默认为人工操作。

琐事自动化之后要做什么

一旦你可以将一个工作自动化起来，这个自动化的工作就值得更深层次的被发掘。进一步的将自动化的任务按照人工处理的流程优化下去。但请注意，自动化不应该使工程师任务不会出错。 在完成上述优化后，你还可以尝试将自动化的工作分解为可单独实现的组件，并用于创建可组合的软件库，其他自动化项目可在以后重复使用。正如下文中的“数据中心维修案例”研究所示，自动化提供重新评估和简化人工工作流程的机会。

使用开源和第三方工具

有时你不必做所有的工作来减少琐事。像一次性迁移这样的工作可能自己无法建立定制型的工具，但你可能并不是第一个遇到这个任务的工程师。寻找第三方或开源库以降低开发成本，或者说，至少可以帮助你过渡到部分自动化。

反馈并改进

积极寻求反馈，这些反馈可以来自于工具、工作流程和自动化交互相关的其他人，这是非常重要的。你的用户将根据他们对底层系统的理解将你的工具在不同使用情景下进行使用。你的用户对这些工具越不熟悉，就越要积极地寻求用户的反馈。利用用户调查，用户体验（UX）和其他机制来了解你的工具被如何使用，并整合这些反馈，以便在未来实现更有效的兼容性。 人的输入只是你应该考虑反馈中的一个方面。我们还可以根据延迟，错误率，返工率和节省的人工时间等指标（跨过流程中涉及的所有组）来衡量自动化任务的有效性。能够获得在自动化工作部署之前和之后两种状态的对比是最明确的衡量方式。

扩展：遗留系统

大多数SRE工程师在他们的工作中都会遇到过遗留系统。这些旧系统经常在用户体验，安全性、可靠性或可伸缩性方面有问题。他们倾向于将遗留系统看作一个神奇的黑匣子，因为系统“大部分组件是在工作中的”，但很少有人了解它们是如何工作的。贸然的调整它们是可怕的，也是昂贵的，并且保持它们的运行通常需要大量繁琐操作步骤。 远离遗留系统通常遵循以下路径：

1.避免：我们可以为不去解决这个问题找到许多理由：可能是没有资源来替换这个系统；判断业务成本和风险发现不值得替换；可能没有找到商业上更好的解决方案。避免选择的是接受风险并从SRE转向系统管理。

2.封装/扩充：你可以使用SRE来构建一个抽象API的外壳，自动化，配置管理，监视和测试这些遗留系统，这些系统将卸载SA的工作。遗留系统仍然很难改变，但现在你至少可以识别它并在适当时有回滚策略。这种策略仍然可以避免，但这是将风险引入到的更好的系统中。这通常是准备增量替换的权宜之计。

3.替换/重构：替换遗留系统可能需要大量的决心、耐心、沟通成本和文档，最好是逐步进行。一种方法是定义位于遗留系统前面并对其进行抽象的公共接口。此策略可帮助你使用发布工程技术（如canarying或蓝绿色部署）将用户缓慢安全地迁移到其他安全的架构中。通常，遗留系统的“规范”实际上只是通过其历史用途来定义，因此有助于构建生产大小的历史预期输入和输出数据集，以建立新系统不会偏离预期行为的信心（或正在以预期的方式发散）。

4.退出/保管所有权：最终，大多数客户或功能被迁移到一个或多个备选方案。这个需要激励措施，没有迁移的用户可以承担遗留系统遗留物的保管所有权。

案例分析

以下两个案例讨论是如何将减少琐事的策略应用到具体的项目中。案例都来自于Google基础设施体系中的重要领域。在这些领域中，Google建设的规模已经达到了顶峰并且很难再进行次线性扩展；对于SRE工程师来说，随着时间的推移，工作导致该投资的回报减少。现在我们有统一的认识是这里面的大部分的努力都是在处理琐事。对于每个案例，我们详细说明了工程师如何识别，评估和减轻琐事的。在案例中我们还讨论了在此过程中学到的经验教训。

在第一个案例研究中，Google的数据中心网络存在扩展问题——虽然Google拥有大量自研的组件来监控，缓解和修复这些问题。但是我们需要一种策略来最大限度的减少数据中心技术人员处理琐事所花费的时间。

第二个案例研究主要介绍的是：一个团队运维“”专用”的一批硬件，以支持一种已经被长时间使用的业务流程中，这部分的硬件带给团队许多的琐事。本案例阐述了重新评估和替换运营成本高昂的业务流程的好处。表明即使受到大型组织的制度惯性的限制，只要坚持下去，就有可能转向替代方案。

总之，这两个案例都死对前面我们提到的减少琐事策略的具体应用。每个案例都在开头将应用的策略列举出来。

案例研究1：利用自动化减少数据中心的工作量

案例研究1中应用的了减少琐事的战略：

•SRE工程师从琐事中解脱出来

•从部分自动化开始

•提高系统的一致性

•使用SLO减少琐事

•评估自动化带来的风险

•反馈并改进

•提供一种自助的服务方法

背景

此案例来源于Google数据中心。与其他的数据中心类似，Google的计算机连接到交换机，交换机连接到路由器。流量通过链路流入和流出这些路由器，而链路又连接到互联网上的其他路由器。随着谷歌处理互联网流量的要求越来越高，服务该流量所需的交换机数量急剧增加。为了能够应对大流量的情况，我们的数据中心在规模和复杂性方面都有所增长。这种增长迫使数据中心改变了进行手动维修的状态。（从偶尔和有趣到频繁和死记硬背两种信号。）

早期，谷歌在运行数据中心时，每个数据中心的网络拓扑都包含少量网络设备，可以管理大量服务器的流量。单个网络设备故障可能会显着影响网络性能，但是一个小规模的工程师团队就可以处理设备的故障。在早期阶段，工程师调试故障设备并手动将流量切换到其他正常组件。 而我们下一代的数据中心拥有更多的机器，并引入了折叠Clos拓扑结构的软件定义网络（SDN），交换机数量显著增加。图6-2展示的是一个小型数据中心Clos交换机网络的流量复杂性。如果将这个比例放大，意味着设备数量更多，发生故障的组件也更多。虽然可能说，每个单独的故障对网络性能的影响比以前更小，但是大量的问题同时并发也会压倒工程师们。 调试问题的过程同时也会引入大量新的问题，复杂的布局也让工程师感到困惑：需要检查哪些链接？需要更换哪个线卡？为什么是Stage 2开关，而不是Stage 1或Stage 3开关？关闭交换机会给用户带来哪些问题？

图6-2. 一个小型Clos网络，Stage1 支持480台机器连接

修复故障的线卡是一个随着系统网络增长而任务量不断增长的琐事，因此我们将此工作作为“创建数据中心网络修复自动化”项目的的第一阶段的目标。 本案例阐述了我们如何在第一代线卡（名为Saturn）系统上开始维修自动化的过程， 并以此为基础，我们讨论了如何对自动化工作进行改进已适应下一代线卡(木星光纤网络)。

如图6-3所示，在自动化项目开始之前，数据中心线卡修复工作的每个流程都需要工程师执行如下几个操作：

1.确定从故障交换机切走流量是否是安全的。

2.切走流量至其他交换机（“drain”操作）。

3.执行重新启动或修复（例如更换线卡）。

4.将流量转移回本设备（“undrain”操作）。

排水，不排水和修理设备的这种工作是不变的和重复性的工作，是“琐事”的典型范例。这些重复性的工作本身就会带来一些问题——例如，工程师在进处理此类故障时会并行处理其他更有挑战性的工作，分心工程师可能会意外地将未配置的交换机带入网络中。

图6-3. 自动化之前的数据中心（Saturn）线卡修复工作流程：所有步骤都需要手动工作

问题陈述

数据中心修复线卡问题具有以下几个维度：

•团队增长的速度跟不上系统增长的速度（故障数量也在增长），使得我们无法快速解决问题以防止对系统带来负面的影响。

•人为错误一定会在步骤的重复执行中发生。

•并非所有线卡故障的影响都是一致的。我们无法办法对线卡故障划分优先级。

•一些故障是暂时的，这时我们会选择直接重新启动线卡或重新安装交换机作为修复过程的第一步。并且，我们可以用编程方式捕获这写问题，如果它再次发生，则用设备进行替换。

•新的拓扑环境要求我们在采取行动之前手动评估隔离容量的风险。每次的人工风险评估都有可能带来人为错误，并可能带来严重影响。系统工程师和技术人员也没有好的方法来判断有多少设备和链接会受到修复过程的影响。

我们要如何解决这个问题？

我们决定创建一个自动化框架，并与适当的现场技术人员配合使用，已达到最好的效果，与而将每个问题分配给工程师进行风险评估，流量切换，维修和验证等人工操作的传统思路相比，我们决定创建一个自动化框架，并与适当的现场技术人员配合使用，已达到最好的效果。

自动化的第一步：木星光纤网络的修复自动化

我们的最高目标是构建一个能够检测、分析并处理网络设备故障的系统来代替工程师的故障分析故障处理。 我们的程序是直接切换流量并告知工程师，而不是向工程师发送“线卡”故障的告警。 新系统有一些值得注意的特点：

•我们最好是利用现有工具。 如图6-3所示，我们的告警已经可以检测到布线卡上的问题; 所以我们可以配置告警以触发自动修复。 新的工作流程还应改变票务系统，以便支持自动提交的维修请求。

•我们建立自动风险评估的机制，以防止在流量切换期间意外的隔离设备，并在需要时触发安全机制。 此机制可以杜绝人为错误。

•我们编写程序用于跟踪告警以便作出不同的处理操作：第一次告警仅重启了该线卡并重新安装了该软件； 第二次出现告警则直接请求更换线卡并告知供应商。

执行自动化操作

新的自动化工作流程（如图6-4所示）进行如下：

1.检测到有问题的线卡，并将故障特征添加到数据库的特定组件中。

2.维修服务组件会解决问题并对交换机进行维修。该服还会执行风险评估以确认操作不会隔离任何容量，然后：

a. 从故障交换机中切出流量。

b.关闭线卡。

c. 如果这是第一次告警，则重新启动线卡，将流量恢复到此交换机。此时，工作流程已完成。

d。如果这是第二次失败，则工作流程进行到步骤3。

3.流程管理器检测到新案例并将其发送到故障维修池，供系统工程师处理。

4.系统工程师对故障做出相应，在UI界面中看到红色的“停止”（表示在开始修理之前需要切出流量），并分三步执行修复步骤：

a.系统工程师通过UI界面中的“准备组件”按钮启动流量切换。

b.流量切换完成后表示交换机可操作。

c.关闭交换机并维修线卡。

5.自动修复系统再次启动线卡。完成修复后，启动交换机，待初始化后，流程管理器会触发恢复操作，切回交换机流量并关闭故障单。 新的自动化系统将团队从大量的琐事中解放出来，使他们有更多时间在其他地方开展更高效的项目。

自动化项目的第二步：土星线卡修复与木星线卡修复

数据中心的容量需求几乎是每12个月翻一番。因此，我们的下一代数据中心结构Jupiter比以前任何的Google的数据中心的六倍还要大，所以故障的数量也会增加六倍多。Jupiter提出了自动化故障修复的挑战目标，这个目标的难度在于每层的数千个光纤链路和数百个线路卡都可能出现故障。幸运的是，随着潜在故障点的增加系统也会伴随增加更大的冗余，这对我们的自动化任务是有利的。如图6-5所示，我们保留了系统的一些常规工作流程，并添加了一些重要的修改：

•在自动流量切换和交换机关闭后确定我们要更换的硬件，并将硬件故障单发送给系统工程师。这个过程我们不需要系统工程师通过按下“”预备按钮来排放开关”来启动排水，而是在发生故障时自动排空整个开关。

•我们添加了自动化，用于安装和推送组件更换后的配置。

•我们启用自动化功能，以便在取消开关之前验证修复是否成功。

•除非绝对必要，否则我们将注意力集中在恢复开关而不涉及技术人员。

履行

我们为Jupiter交换机上的所有的线卡故障采用了简单而统一的工作流程：操作告知，流量切换，开始修复。 自动化执行如下：

1.故障检测，并将故障特征添加到数据库中。

2.维修服务解决故障并对交换机进行维修：流量切换并将执行操作的原因添加到数据库中。

a.如果这是六个月内的第二次故障，请继续执行步骤4。

b.否则，请继续执行步骤3。

3.尝试（通过两种不同的方法）重启交换机。

a.如果重启成功，请运行自动功能验证服务，然后安装并配置交换机；记录修复过程，从数据库中将故障单删除。

b.如果先前的功能检查失败，请将故障单发送给相关的系统工程师。

4.如果这是第二次故障告警，请将故障单直接发送给系统工程师请求新的硬件设备。硬件更新后，运行自动验证服务，然后安装和配置交换机。记录修复过程，从数据库将故障单删除。 这种新的工作流程管理完全重写了以前的修复系统。同样的，我们要尽可能利用现有工具：

•配置新交换机（安装和验证）的操作与验证已更换的交换机所需的操作相同。

•快速部署新的硬件需要以编程方式进行（BERT7和cable-audit8）。在切换流量之前，我们可以使用该程序在已经修复的链路上运行功能测试。这些测试需要能够识别错误链接以进一步提高了修复的效果。 如果能够自动缓解和修复Jupiter交换机线卡上的内存错误也是一个更高一个水平的目标。 如图6-6所示，在开始自动化修复之前，此工作流程在很大程度上取决于工程师来判定故障是硬件导致还是软件导致，然后再执行流量切换，交换机重启等工作，并适时地安排修复。

图6-6. 自动化之前的Jupiter内存错误修复工作流程

我们的自动化过程不再尝试对内存错误进行故障排除从而达到简化修复工作流程的目的（请参阅第119页的“有时不完美的自动化就足够了”，了解为什么这样做是有意义的）。相反，我们处理内存错误的方式与处理故障线卡的方式相同。为了将自动化覆盖到内存错误引起的故障，我们只需在配置文件中添加一个特征，使其对新的故障类型起作用。 图6-7描述了内存错误的自动化工作流程。

图6-7. Jupiter内存错误修复工作流程与自动化

总结

此案例让我们学到了许多如何有效减少琐事的经验和教训。

使用UI的目的是让流程更简单 更换线卡需要关停整个交换机。我们在UI中增加一个“准备组件”的按钮，允许技术人员在准备更换线卡之前从整个交换机中切走流量，从而消除了交换机不必要的停机时间（请参阅“按下准备按钮” 切出流量的开关“见图6-5）。

UI和维修工作的流程带来了许多意想不到的问题：

· 按下切走流量的按钮后，技术人员得不到切流的进度反馈，只能等待结果才能继续进行。

· 该按钮可能无法反馈真实的状态。造成的结果是，有时切流量开关出问题但并没有被维修，或者技术人员可能通过其他方式中断了进程但是并没有告知系统。

· 出现问题时，没有消息反馈系统。新的技术人员可能无法找到确切的原因。

为尽快响应用户反馈和由于功能的复杂性导致的回归问题，我们需要在未来对流程进行改进，以确保在技术人员更换交换机之前，能够确保交换机是可以进行维修的。

不要依赖经验

我们过于依赖有经验的数据中心技术人员来识别系统中的错误（例如，当程序认为可以安全地进行维修，但实际上交换机并没有完成流量切换的动作）。而且这些技术人员还必须手动执行多项工作才能定位问题，并且往往缺乏自动化的提示。

经验是难以复制的。在一个复杂的情节中，有经验的技术人员决定在等待数据中心维修的过程中，启动并发流量的切换来加速“按下按钮并等待结果”的过程，从而导致了网络拥塞和用户可见的数据包丢失。而我们的软件并没有去阻止这种行为，因为我们并没有测试过这种操作的影响。

设计可重复使用的组件

尽可能避免集成设计的软件。使用组件来构建复杂的自动化工作流，每个组件处理一个独特且定义明确的任务。我们可以轻松地重复使用或调整早期Jupiter自动化的关键组件，用于下一代的软件设计。当我们重新构建程序时，可以更容易添加新功能。Jupiter类型结构的连续变体可以利用迭代来完成的升级的工作。

不要过分分析问题

我们过度分析了Jupiter线卡内存错误问题。我们试图区分软件错误（可通过重新启动修复）与硬件错误（需要更换卡），以及识别影响流量的错误与未发生的错误。我们花了将近三年（2012-2015）收集超过650个离散内存错误的数据，然后才意识到这个分析是过头了，或者至少不应该成为修复自动化项目不能开展的原因。

一旦我们决定对检测到的任何错误都要采取必要的措施，就可以直接使用我们现有的修复自动化来实现整个流程，这种策略也可以用于响应内存错误的问题。如果问题再次出现，我们可以认为，故障很可能是基于硬件的，并立即要求更换组件。

我们花费了整个项目四分之一的时间来收集数据，发现大多数的错误是暂时的 ——大多数交换机在重新启动和重新安装后都恢复了。我们不需要额外的数据来执行修复，因此实施自动化的三年延迟是不必要的。

有时不完美的自动化就已经足够了

虽然在解除链接之前验证与BERT链接能力是不难的，但BERT工具不支持网络管理链接。 我们将这些链接添加到现有的链接修复自动化中，并允许跳过验证。我们很愿意绕过验证的，因为链接并没有带来客户流量，如果验证结果很重要，我们可以稍后添加此功能。

保证维修自动化项目的持续性和可继承性

自动化项目可以有很长的使用寿命，因此确保在人员的流动不会干扰项目开展的连续性。 新工程师应该接受旧系统的培训，以便他们能够修复错误。由于木星线卡部件的短缺，但是基于土星线卡的系统在其目标寿命结束后很长一段时间内还是存在的，所以仍然需要我们在土星线卡系统的整体寿命中开展一些改进。

一旦采用，自动化可能会长期陷入困境，产生积极和消极的后果。如果可能，以灵活的方式设计你的自动化程序。不灵活的自动化会使系统变得脆弱。使用基于策略的自动化可以明确地将意图与通用实现引擎分离，从而使自动化更加可持续的发展。

深入开展风险评估和防御措施

在为Jupiter构建新工具之后，确定执行切流操作的风险，我们遇到问题的复杂性要求我们引入二次检查的深度防御。二次检查确定了受影响链路数量的上限，以及受影响设备的限制。 如果我们超过任一阈值，则会自动启动请求来进一步定位并跟踪错误。随着时间的推移，我们调整了这些限制，以减少误报。虽然我们最初认为这是一项临时措施，但是直到主要风险评估稳定下来后，二次检查已被证明可用于识别由于停电和软件错误导致的维修问题（如，请参阅“自动化：在规模上实现规模失效”工程）。

获得失败预算和经理支持

修复自动化有时会失败。尤其是在首次使用时。管理支持对于保护项目和赋予团队坚持不懈的动力是至关重要的。我们建议为antitoil自动化项目建立错误预算。还应该向外部的利益相关者进行解释：尽管存在故障风险，但自动化仍然是必不可少的，并且可以持续提高可靠性和效率。

整体考虑

最终，要实现自动化在复杂场景的可用性是要克服的真正障碍。在引入自动化系统之前重新对系统进行评审——是否可以先简化系统或简化工作流程再考虑引入自动化的问题？ 注意这个工作流程是指流程的各个方面，而不仅仅是造成琐事的部分。与参与系统维护的人员共同进行自动化的测试，并积极寻求他们的反馈和帮助。如果他们在使用过程中出现操作问题，请了解原因用于用户界面的改进，或者增加额外的安全检查。确保自动化不会带来新的操作——例如，需要人工关注的不必要的票证。因为给其他团队创造问题将增加自动化推进的难度。

案例研究2：退役Filer支持的主页目录

案例研究2中强调了减少琐事的战略：

•考虑淘汰旧系统

•促将减少琐事作为一项工程

•获得管理层和同事的支持

•拒绝琐事

•从部分自动化开始

•提供一种自助的服务方法

•从小处开始然后改进

•反馈并改进

背景

在谷歌的早期，公司数据存储（CDS）SRE团队为所有Google员工提供home目录服务。 与企业IT中常见的Active Directory漫游配置文件类似，Google员工可以跨工作站和平台使用相同的home目录。CDS团队还为共享存储空间中的跨团队协作提供“团队共享”服务。我们通过NFS / CIFS（或“文件管理器”）上的Netapp存储设备提供home目录和团队共享。 这种存储系统是很昂贵的，但Google员工对此类服务的需求是必须的。

问题陈述

随着时间的推移，这些文件管理系统解决方案的优势被其他更好的存储解决方案所超越：我们的版本控制系统（Piper / Git-on-borg），Google Drive，Google Team Drive，Google云端存储以及全球内部共享分布式ilesystem（x20）。这些替代方案的优越性体验在如下方面：

· NFS / CIFS协议并不适用于在WAN上运行，造成即使有几十毫秒的延迟，用户体验也会迅速降低。这为远程工作人员或全球分布的团队带来了问题——因为数据只能存在于一个位置。

· 与替代品相比，原系统的设备运行和规模都是昂贵的。

· 要使NFS / CIFS协议与Google的Beyond Corp11网络安全模型兼容，需要做大量的工作。

与本章最相关的是，home目录和团队共享会频繁的使用。存储配置的许多方面都是票据驱动的。虽然这些工作流程通常是部分编写的，但它们代表了相当数量的CDS团队的工作成果。我们花了很多时间创建和配置共享，修改访问权限，解决最终用户问题，以及执行启动和调整以管理容量。除了配置、更新和备份之外，CDS还需要管理专用硬件的配置，机架和布线过程。由于延迟要求，我们经常不得不部署在远程办公室而不是在Google数据中心 – 这有时需要花费团队成员相当长时间。

我们决定做什么

首先，收集数据：CDS团队开发了一个名为“Moonwalk”的工具来分析员工使用此的服务的场景。我们确定收集如下通用的指标，如每日活跃用户（DAU）和月活跃用户（MAU），并询问了诸如“哪些用户实际使用他们的home目录？”和“哪些人每天使用此系统？他们最常访问的文件是什么？“Moonwalk与用户调查相结合，验证了文件管理器当前服务的业务需求可以通过低运营开销和成本的可替代方案代替。另一个引人注目的原因促使我们放弃现有的文件系统：如果我们可以将大多数文件管理器用例迁移到G Suite / GCP，那么我们可以利用我们学到的经验来改进这些产品，从而为其他大型企业迁移到GSuite/ GCP提供支持。

没有一种替代方案可以满足所有当前的文件管理器用例。然而，通过将问题转化为若干小的需求来寻找可替代系统，我们发现少数备选方案可以涵盖我们所有的使用场景。替代解决方案更专业，并且每个解决方案都带来比旧的解决方案更好的用户体验。例如：

x20

全局共享静态文件对于团队来说是很好的方式，比如二进制文件。

G Suite Team Drive

适用于办公文档协作，与NFS相比，用户更能容忍此延迟。

谷歌的巨像文件系统

比NFS更安全，更可靠地共享大型数据文件

Piper/Git-on-Borg

可以更好地同步dotfiles（工程师的个性化工具首选项）

一种新的“历史服务”工具

可以托管跨工作站命令行的历史记录

在我们编制用例并找到替代方案时，旧计划的退役计划已经开展

设计与实施

下线旧的文件管理系统是一项持续的、迭代的、需要多年的进行的工作。需要多个子项目催的开展：

Moira

home目录下线

Tekmor

迁移home目录用户的长尾

Migra

团队共享下线

Azog

下线home目录/共享基础架构和相关硬件

本案例研究重点关注第一个项目Moira。后续项目的开展是在Moira的学习和开展的基础上开始的。 如图6-8所示，Moira由四个阶段组成。

图6-8. Moira项目的四个阶段

下线系统的第一步是停止或减少新的用户使用（这是更现实的）。从用户那里取走一些东西要比从未提供过一些东西所带来的痛苦要大得多。Moonwalk数据显示，非工程Google员工使用他们的共享home目录的频率最低，因此我们的初始阶段针对这些用户开展。随着阶段范围的扩大，我们对替代存储解决方案以及迁移流程和工具的信心也在增强。项目的每个阶段都有一个相关的设计文档，该文档按照安全性、可伸缩性、测试和启动等维度来审查相关工作。我们还特别关注了用户体验，我们的目标是确保每个阶段受影响的用户应该能了解项目下线的原因以及归档、迁移数据的最简单的方法。

关键组建

太空步

虽然我们有关用户共享（例如共享大小）的基本统计数据，但我们仍需要了解用户的工作流程，以帮助旧系统下线的业务决策。我们建立了一个名为“Moonwalk”的系统来收集和统计这些信息。 Moonwalk存储了谁正在访问哪些文件以及何时使用BigQuery的数据，这使我们能够做出统计报告以便更好地了解用户。在BigQuery的帮助下，我们汇总了25亿个文件，共计300 TB的数据的用户访问模式。该数据来自于全球60个地理站点的124个NAS设备，共计600,000个磁盘卷，共收集了60,000名POSIX用户的使用信息。

Moira Portal 我们庞大的用户群使得基于手动票证的流程无法维持home目录的下线。我们需要在整个过程（调查用户，告知项目下线原因，归档数据或迁移到替代系统）尽可能提供地接触服务（低接触服务是指这样的服务模式： 销售服务人员在向顾客提供服务时，保持较少的面对面的接触机会。 相对于高接触服务而言，低接触服务需要更多的机器和固定资产 固定资产 。 因为通常需要由它们来自动完成顾客服务 顾客服务 ，如自动售货机、自动柜员机 自动柜员 机 、自动加油机等，译者注）。 我们的最终要求是： •描述项目的登录页面 •不断更新对常见问题的解答 •与当前用户共享关联状态和使用信息 •提供请求，停用，存档，删除，扩展或重新激活共享的选项

至此，我们的业务逻辑变得相当复杂——因为我们必须考虑许多用户场景。例如，用户可能会从Google离职，短暂离职，或者在诉讼状态（需要保留其拥有的数据）。图6-9提供了一个示例图，说明了其复杂性。

图6-9. 基于用户场景的业务逻辑

系统主程序的技术相对简单。使用Flask框架用Python编写，它读取并写入Bigtable，并使用大量后台作业和调度程序来管理其工作。

归档和迁移自动化

我们需要大量的辅助工具来将门户和配置管理粘合在一起，并与用户进行通信和用于用户查询。我们还需要确保不同的用户使用不同的通信方式。误报（错误地报告所需行动）或漏报（未通知用户您正在取走某些东西）都是不可接受的，这里发生错误将意味着失去用户可信度和带来客户服务的额外工作。

我们与其他存储系统所有者合作——为新系统添加我们需要的功能。因此，随着项目的进展，不太成熟的替代品变得更适合了。我们还可以使用和扩展其他团队的工具。例如，我们使用其他团队内部开发的工具将数据从Google云端存储迁移到Google云端硬盘，作为门户网站自动存档功能的一部分。这项工作需要在整个项目期间进行长期的软件开发。我们构建并迭代了每个组件--Moonwalk报告管道，门户和自动化，以便更好地管理下线和归档共享， 以响应下一阶段的要求和用户反馈。我们在第三阶段（差不多两年）才接近达到一个功能健全的系统。即便如此，我们还需要额外的工具来处理大约800名用户的“长尾”。这种低速和慢速的方法有一定的好处。因为它允许我们：

•维持一个精炼的团队（平均三名CDS团队成员）

•减少对用户工作流程的干扰

•减少Techstop的琐事（谷歌内部技术支持组织）

•根据需要构建工具，以避免将时间浪费在工程工作中

与所有工程决策一样，存在如下权衡：项目将长期存在，因此团队在设计解决方案时必须忍受与文件管理器相关的琐事。 该计划于2016年正式完成。在撰写本文时，我们已将home目录从65,000个减少到约50个（目前的Azog项目旨在淘汰这些最后用户并彻底下线文件管理系统的硬件。）我们的用户体验有所改善，CDS已停止运营成本高昂的硬件。

总结

虽然没有任何一种替代方案可以替代Google员工已使用14年以上的文件管理系统，但我们并不一定需要批量更换。通过有效地将堆栈从通用但有限的文件系统解决方案升级到多个应用程序共同组成的解决方案，我们增加了系统的灵活性，以提高可扩展性、延迟容忍性和安全性。Moira团队不得不预测各种用户的行为，并考虑不同阶段的可替代方案。我们必须围绕这些替代方案来调整我们的期望：总的来说，它们可以提供更好的用户体验，但实现这一目标并非是毫无痛苦的。我们学到了以下关于有效减少琐事的策略。

发现旧系统的不足并下线昂贵的业务流程

业务需求不断变化，新的解决方案不断涌现，因此定期评估旧的业务流程是值得的。正如我们在第101页的“琐事管理策略”中所讨论的那样，拒绝琐事（决定不执行）通常是消除它的最简单方法，即使这种方法并不总是快速或简单的。通过用户分析和业务理由来改变你的业务工作内容，而不仅仅是减少琐事。文件管理系统下线的主要业务理由归结为Beyond Corp安全模型的优势。因此，虽然Moira是减少CDS团队琐事的好方法，但强调下线系统的原因如果是考虑到了新系统诸多的许多安全优势，这些优势将带来更具吸引力的商业需求。

构建自助服务接口

我们为Moira建立了一个自定义门户（相对昂贵），但通常有更便宜的选择。Google的许多团队使用版本控制来管理和配置他们的服务，以拉取请求（称为更改列表或CL）的形式处理请求。这种方法几乎不需要服务团队的参与，但为我们提供了代码审查和持续部署的优势，便于验证、测试和部署内部服务配置更改。

从人工支持的界面开始

在几个方面，Moira团队采用了“幕后工程师”的方法，将自动化与工程师的人工操作相结合。例如，用户的请求出现BUG，系统对BUG进行追踪，我们在处理错误时对自动化系统进行更新。系统还对用户进行告知，以提醒他们共性问题得到了解决。票据可以作为自动化系统的应急的GUI：它们保存工作日志，更新利益相关者的数据，并在自动化出错时提供简单的人工干预机制。在我们的示例中，如果用户需要迁移数据工作的帮助，或者如果自动化无法处理其请求，则该错误会自动路由到SRE手动处理的队列中。

处理特殊请求

自动化系统要求请求合规。Moira的工程师选择重新调整我们的自动化，以专门处理共享的边缘场景请求，或者删除/修改不合格的共享以符合系统的期望。这使我们能够在大多数迁移过程中实现零接触的自动化。

推动新系统的使用

寻找方法来推动新用户采用更好的替代方案。在这种情况下，Moira需要升级系统配置以便应对新的请求和下线旧的系统。在服务设置中，新系统使用最佳实践和用户如何配置系统也很重要。Google团队经常使用codelabs或cookbook为用户提供常见用例设置和指导如何使用他们的服务。因此，大多数用户入职都不需要额外的团队的指导。

有趣的事实：在谷歌，用正确的代码改变现实而不是去“购买侏儒”。这句话引用了一个关于Froogle的传奇，这是一个很早就开展的购物搜索引擎服务。在Froogle的早期阶段，一个严重的搜索质量错误导致搜索“跑鞋”返回花园侏儒（穿跑鞋）作为一个精确匹配的结果。在几次修复错误的尝试失败之后，有人注意到gnome不是批量生产的商品，而是一个带有“一口价”选项的eBay商品。他们购买了侏儒（图6-10）。

图6-10. 花园侏儒不会消失

结论

与生产服务运行相关的琐事会随着系统复杂性和规模的增长而线性增长。自动化通常是消除琐事的黄金法则，并且可以与其他策略相结合。即使琐事不值得完全自动化，你也可以通过部分自动化或改变业务流程等策略来减少操作的负担。本章中描述的消除琐事的模式和方法可以推广到其他个各种大规模生产服务中。消除琐事可以节省工作时间，以便工程师专注于服务的更重要的方面，并允许团队将手动任务保持在最低限度。随着现代服务架构的复杂性和规模不断增加，此策略尤其重要。

但是要注意，消除琐事并不总是最好的解决方案。如本章所述，你应该考虑成本，识别，设计和实施流程或自动化解决方案都需要投入成本。一旦决定减少琐事，就必确立指标，进行投资回报率（ROI）分析，风险评估和迭代开发来确定是否减少了工作量。

琐事通常是从小事开始积累的，并且可以迅速成长最终消耗整个团队的人力资源。SRE团队必须坚持不懈地消除琐事——因为即使减少琐事的项目看起来令人生畏，但其好处通常也是会超过成本的。我们所描述的每个项目都需要各自团队的坚持不懈和奉献精神，他们有时会面对质疑或者需要于制度进行斗争，并且总是面临竞争这种高优先级的任务。我们希望这些案例鼓励你识别工作中的琐事，量化它，然后努力消除它。即使今天不能开展一个大项目，你也可以从一个小概念开始，这可以帮助改变你的团队处理琐事的方式。