SRE-Google运维解密-第五章减少琐事

前言📖

本章更像是在阐述一种广泛适用的世俗哲理，而非技术理论。其理念不仅可以应用于技术工作，还能延伸到生活的方方面面。 “如果系统在正常运转过程中需要人工干预，那么这应被视作一种缺陷（Bug）。”

琐事的定义 🤔

书中指出，琐事并不仅仅意味着“我不喜欢做的工作”。在工程任务中，每个人或多或少都会遇到琐事，而每个人对工作内容的满意度和喜好亦各有不同。此外，一些管理类的琐事是必须承担的，这类工作被归纳为“流程开销”。流程开销通常是指与运维工作并无直接关联的任务，例如团队会议 、目标的制定与评估 、日报、周报及月报等 。此外，还有一些看似繁琐但具有长期价值的工作，例如调整过高频率的告警 ，这些任务虽重复性高且繁重，但并不属于琐事的范畴。

那么，到底什么是琐事？ 书中指出，琐事是指运维过程中需要手动操作的、重复性的、可以被自动化的、短期战术性的且缺乏持久价值的工作。而且琐事与服务呈线性增长关系，这意味着琐事随服务的规模增大而成比例增加。尽管不是每件琐事都具备以上所有特性，但大多数琐事都符合其中的一个或多个属性。

名词解释 📚

手动性 🤲

手动性是指需要人工操作才能完成的任务。例如，手动运行脚本以执行特定任务。尽管运行一个脚本比逐步手动执行要高效得多，但仍需投入人工操作的时间（与脚本执行时间无关），这部分时间应被视为琐事。在理想情况下，应通过自动化调度，例如定时或触发条件下自动执行任务，来消除手动干预，例如自动释放内存。

重复性 🔄

若一项任务在短期内重复执行不超过三次，这并不属于琐事的范畴。琐事指的是那些需要不断重复的工作，就如同流水线上的拧螺丝 。如果为了某个问题的解决而进行反复实验，这并不属于琐事，因为其目标具有探索性和单次性。

可自动化的 🤖

若某项任务可以被计算机以与人类同样甚至超越人类的水准来执行，或者通过设计变更从根本上消除对该任务的需求，那么这项任务就属于琐事。在工作中有很多此类琐事，例如 DHCP 服务的设置，通过自动化的方式可以更有效地完成。而如果某项任务的主观判断非常关键且不可替代，那么它就不能归为琐事（如流量控制，尽管需要根据用户需求调整流量，但机器无法判断人情世故的优先级，例如为领导设定更高流量阈值）。

战术性 ⚔️

战术性工作是指突然出现的、被动响应的任务，其往往缺乏战略性的规划。例如，处理系统告警是典型的琐事 🚨，虽然这类工作难以完全避免，但应尽力减少其频率和规模。

缺乏持久价值 ⏳

如果一项任务完成后服务的整体状态没有实质性改变，那么这就是琐事。但若该任务能够带来服务的改进与优化，那么它就不再属于琐事的范畴 。

与服务的规模同步增长 📈

书中指出，若某项工作随服务规模、流量或用户数量的增长呈线性增加，则该任务可能属于琐事。一个经过良好管理和设计的服务应至少可以应对数量级的增长，而无需大量额外的手动介入。

为什么琐事越少越好？ 🤔➡️😊

如果琐事不加以控制，其数量将会不断增长，最终占据每个人 100% 的时间 ⏳。书中建议，合格的 SRE 工程师所花费在琐事上的时间不应超过 50%。

统计显示，琐事的主要来源是中断性工作（即与服务相关的非紧急邮件和电子邮件 📧），其次是 on-call（紧急值班）🔔，再之后是发布管理和数据更新等任务。在 Google 的 SRE 团队中，琐事占用了约 33% 的时间。

什么是工程工作 🚀

工程工作是一种创新性且需要主观判断的工作，其通常符合长期战略目标，旨在对服务进行持久性改善。工程工作注重通过设计解决问题，解决方案越具普适性越好。工程工作应有助于在不增加人员的前提下，提升团队的服务能力。

常见的工程工作 🛠️

软件工程 💻

软件工程涉及代码的编写或修改，以及相关的设计和文档工作。例如：编写自动化脚本，开发工具或框架，增加服务的可扩展性与可靠性，或是修改基础设施代码以使其更稳健。

系统工程 🖥️

系统工程包括配置生产环境、修改现有配置，或通过一次性工作产生持久改进的系统文档撰写工作。例如：部署与更新监控系统、配置负载均衡 、服务器配置、操作系统的参数调优及负载均衡器的部署。系统工程还涵盖了与研发团队的架构设计和生产环境相关的咨询工作。

琐事 🧹

与运维服务相关的重复性手工劳动。

流程负担 🗂️

与运维工作无直接关联的行政类工作。例如：招聘、人力资源相关书面工作、团队或公司会议、定期任务系统清理、工作总结、同行评审和自我评估，以及培训课程等。

琐事繁多是否一定不好 ❓

尽管琐事往往令人感到乏味和低效 😒，但适量的琐事也可以带来某种程度上的满足感和秩序感 。尤其是当琐事的数量适中时，已知且重复的工作任务反而可以起到平衡心态的作用，完成这些任务后可能会有一种成就感和短期胜利的愉悦感 。某些琐事也可能是一种低风险和低压力的活动，因此一些员工可能更倾向于完成这些任务。

然而，尽管琐事的存在并非全然负面，但其仍会对团队及个人带来诸多不利影响：

职业停滞 🛑

长期从事低风险、低压力的活动，或处理一些脏活累活，不利于员工的职业成长。通过不断重复低层次的工作，难以获得职业发展的突破。

士气低落 📉

每个人对琐事的承受能力各有不同，但人们的耐心是有限的。过量的琐事将导致员工精疲力竭、产生厌倦情绪，从而影响士气 。

角色模糊 🤷‍♀️

个人或团队若长期专注于琐事，会使自身在组织中的角色定位变得模糊，可能产生“自己并非一名运维工程师”的错觉 。

效率低下 🐢

琐事占据的时间越多，团队完成核心任务的进度就越慢，从而导致整体效率低下，影响工作成果。

开创不良先例 🚧

如果 SRE 团队过于主动承担琐事，研发团队可能会更加依赖 SRE 来处理这些任务，甚至会将原本属于开发职责的运维任务转嫁给 SRE。

增加团队摩擦 ⚡

即使某个员工对琐事毫无怨言，他的同事或团队中其他成员却可能对此感到不满 😠。若团队承担了过多琐事，实际上是鼓励团队中最有才华的工程师去寻找更具挑战性的工作机会。

违背承诺 🤥

那些因工程性工作而加入 SRE 团队的新员工，或内部转岗至 SRE 的员工，可能会觉得受到了欺骗，这对于公司的士气极为不利。

小结 📌

本章阐述了琐事的定义、琐事的利弊以及为何需要减少琐事的存在。在实际工作中，琐事占据了很大部分的内容，因此我们需要通过不断努力来减少琐事，尽量将精力集中于那些有助于个人成长与发展的工作中，以获得更大的职业收益 。