SRE 中如何消除琐务：提升工程效率与服务可靠性的实践方法

在 SRE，也就是站点可靠性工程中，我们希望把时间投入长期的工程项目，而不是日常运维工作。由于“运维工作”这个说法容易引起误解，我们使用一个更精确的术语：琐务。

琐务管理是 SRE 实践中的核心议题。识别并减少琐务，不仅能提升工程效率，也能帮助团队更好地保障服务可靠性、扩展系统规模，并避免工程师长期陷入重复性运维工作。

什么是 SRE 中的琐务？

琐务并不只是指“我不喜欢做的工作”，也不能简单等同于行政杂务或脏活累活。不同的人对工作满足感和乐趣的来源各不相同，有些人甚至喜欢体力劳动或重复性工作。有些行政事务虽然必须完成，但不应归类为琐务，而应视为间接成本。间接成本通常指与生产服务运行没有直接关系的工作，例如团队会议、目标设定与评估、工作总结、人事文档等。

脏活累活有时也可能具有长期价值。在这种情况下，它并不属于琐务。例如，全面清理某项服务的告警配置、删除冗余信息，过程或许繁杂，但如果它能带来长期收益，就不应被视为琐务。

那么，什么是琐务？琐务是指与生产服务运行相关，通常具有手动性、重复性、可自动化、战术性、缺乏持久价值，并且会随着服务规模增长而线性增长的工作。并非所有琐务都同时具备这些特征，但一项工作越符合以下描述，就越可能被归类为琐务。

手动性

手动性包括手动运行脚本来完成某些自动化任务。运行脚本可能比逐步手工执行脚本中的每个操作更快，但人实际花在启动、监督或处理脚本上的时间，仍然属于琐务时间；脚本自身运行所花的时间则不计入其中。

重复性

如果你是第一次做某项任务，甚至只是第二次做，它通常还不能算作琐务。琐务是你一遍又一遍重复执行的工作。相反，如果你正在解决一个全新的问题，或设计一种全新的解决方案，这项工作就不属于琐务。

可自动化

如果机器能够像人一样出色地完成某项任务，或者可以通过重新设计系统来消除执行这项任务的必要性，那么这项任务就具有琐务属性。若完成任务必须依赖人的关键判断，它通常就不属于琐务。[21]

战术性

琐务往往是被动的、应急式的、容易打断人的，而不是主动的、策略性的。例如，处理值班告警就是典型的琐务。我们或许永远无法彻底消除这类工作，但必须持续努力将其降到最低。

缺乏持久价值

如果完成某项任务后，服务状态没有获得持久改善，那么这项任务很可能只是琐务。反之，如果一项任务能够为服务带来永久性改进，即使其中包含一些繁杂工作，例如深入梳理遗留代码和配置并加以整理，它也未必属于琐务。

随服务规模呈 O(n) 增长

如果一项任务的工作量会随着服务规模、流量或用户数量线性增长，那么它很可能是琐务。理想情况下，一个经过良好管理和设计的服务，应当能够在只需一次性增加少量资源的前提下，至少扩展一个数量级，而不需要额外增加同等比例的人力工作。

为什么 SRE 团队要减少琐务？

SRE 团队公开设定的目标是：将运维工作，也就是琐务，控制在每位 SRE 总工作时间的 50% 以下。每位 SRE 至少应将 50% 的时间投入工程项目，用于减少未来的琐务，或为服务增加功能。功能开发通常侧重于提升可靠性、性能或资源利用率，而这些改进往往也会间接减少琐务。

之所以设定 50% 这个目标，是因为如果不加控制，琐务往往会持续膨胀，并很快占据每个人 100% 的工作时间。减少琐务、支撑服务规模扩展，正是站点可靠性工程（SRE）中“工程”二字的含义所在。工程工作使 SRE 团队能够随着服务规模扩大而实现亚线性增长，并且比纯粹的开发团队或传统运维团队更高效地管理服务。

在具体落地时，团队往往需要借助统一的研发管理工具，将目标、需求、评审、排期、开发、测试、发布和知识沉淀串联起来。例如 PingCode 这类智能化研发管理工具，可以帮助团队把研发过程中的数据和经验沉淀下来，减少信息断点和重复沟通，让减少琐务不只停留在理念层面，而能真正转化为可持续的工程能力。

此外，在招聘新的 SRE 工程师时，团队通常会向候选人承诺：SRE 并不是传统意义上的运维团队，并会明确说明前面提到的 50% 规则。团队必须兑现这一承诺，不能让 SRE 团队或其任何子团队退化为传统运维团队。

如何计算 SRE 琐务时间？

如果我们希望将 SRE 花在琐务上的时间限制在 50% 以下，那么这些时间通常是如何被消耗的？

对于任何需要参与值班的 SRE 来说，琐务工作量都有一个天然下限。典型的 SRE 在每个值班周期中，会有一周担任主值班，一周担任副值班。因此，在 6 人轮值制度下，每 6 周至少有 2 周用于值班和故障处理，这意味着 SRE 潜在琐务工作量的下限是 2/6，即 33%。在 8 人轮值制度下，这一下限为 2/8，即 25%。

与这一数据相一致，SRE 工程师报告称，他们最大的工作量来源是各种干扰，也就是非紧急的、与服务相关的消息和邮件。其次是值班期间的紧急响应，再之后是发布与上线。尽管发布和上线流程通常已经实现了相当程度的自动化，但这方面仍有很大的改进空间。

海外某些技术公司的 SRE 季度调查显示，SRE 平均约有 33% 的时间花在琐务上，明显低于 50% 的总体目标。然而，平均值无法反映个体层面的极端情况：有些 SRE 表示自己 0% 的时间用于琐务，也就是完全投入开发项目且无需值班；另一些 SRE 则表示自己 80% 的时间都花在琐务上。当个别 SRE 报告承担了过多琐务时，这通常意味着管理者需要更均衡地分配团队中的琐务负担，并鼓励这些 SRE 寻找更有意义的工程项目。

SRE 中什么才算工程工作？

工程工作具有创新性，本质上需要人的判断。它能为服务带来持久改进，并由策略性目标驱动。工程工作通常富有创造性，强调通过设计来解决问题，并且解决方案越通用越好。它能够帮助你的团队或整个 SRE 组织在不增加人员配置的情况下，承载规模更大、数量更多的服务。

典型的 SRE 活动大致可以分为以下几类。

软件工程

软件工程包括编写或修改代码，也包括相关的设计和文档工作。例如，编写自动化程序、创建工具或框架、添加服务功能以提升可扩展性和可靠性，或修改基础设施代码以增强其健壮性。

系统工程

系统工程包括配置生产系统、修改配置或编写系统文档，并通过一次性投入带来持久改进。例如，设置和更新监控、配置负载均衡、配置服务器、调优操作系统参数，以及设置负载均衡器。系统工程还包括为开发团队提供架构、设计和生产部署方面的咨询。

琐务

琐务是与运行服务直接相关的重复性、手动性工作。

间接成本

间接成本是与服务运行没有直接关联的行政性工作。例如招聘、人事文档处理、团队或公司会议、缺陷队列维护、工作总结、同行评审、自我评估以及培训课程。对于这些团队协作和日常管理工作，也可以借助 Worktile 这类通用项目协作系统，将任务、项目、文档、日历、工时和审批等事项集中管理，降低沟通成本，避免间接成本进一步挤压工程时间。

每位 SRE 都应至少将 50% 的时间投入工程工作，这一比例通常以几个季度或一年为周期进行平均计算。工作量本身会有较大波动，因此对某些 SRE 团队来说，每个季度都稳定保持 50% 的工程时间未必现实。但如果从长期来看，项目投入时间的平均比例显著低于 50%，相关团队就需要认真反思并找出问题所在。