在 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%相关团队就需要认真反思并找出问题所在。琐务对 SRE 团队一定是坏事吗琐务并不总是令人痛苦尤其是在工作量较小的时候。可预测、重复性的任务有时反而会让人感到平静并带来成就感和即时满足。这类活动通常风险较低、压力较小。有些人天生就喜欢这类需要重复投入的工作甚至能从中获得乐趣。琐务并不总是坏事。每个人都必须清楚地认识到在 SRE 岗位上乃至几乎所有工程岗位上一定程度的琐务都是不可避免的。少量琐务是可以接受的只要它保持在可控范围内琐务本身并不是问题。问题在于琐务过多。若你承担了过量琐务就应当高度重视并明确表达出来。过多琐务之所以有害原因包括以下几点。职业停滞如果你投入工程项目的时间太少你的职业发展就会放缓甚至停滞。海外某些技术公司会认可那些不可避免且影响巨大的底层工作但你不可能只靠这类工作建立一整个职业生涯。士气低落每个人对琐务的承受能力不同但每个人都有极限。过多琐务会导致倦怠、厌烦和不满。此外如果大量时间被琐务占据从而挤压了工程研发时间SRE 组织也会受到以下损害。造成角色混乱团队需要确保所有在 SRE 组织内部工作或与 SRE 组织协作的人都清楚地认识到SRE 是一个工程组织。如果 SRE 组织中的个人或团队过度承担琐务就会削弱这一认知的清晰度并让人们误解 SRE 的角色。拖慢进展过多重复劳动会降低团队效率。如果 SRE 团队忙于繁琐的手动工作和紧急故障处理而无法及时交付新功能产品的功能迭代速度就会放缓。开创不良先例如果你过于主动地承担琐务开发同事就会有动力把更多工作交给你有时甚至会把本应由开发人员负责的运维任务转交给 SRE。其他团队也可能逐渐期望 SRE 承担这类工作而这显然不是一种健康的协作模式。加速人员流失即使你个人并不反感琐务你现在或未来的队友也可能并非如此。如果你在团队流程中设置了过多繁琐步骤就会促使团队中最优秀的工程师离开去寻找更有价值的工作。造成失信如果新员工或转岗人员当初是因为被承诺能够参与工程项目而加入 SRE却在实际工作中长期被琐务占据他们会感到受骗。这会严重打击士气。结论通过工程化手段减少 SRE 琐务如果我们每周都通过优秀的工程实践减少一些琐务就能持续提升服务质量并将团队的集体精力转向可扩展的工程设计、下一代服务架构以及跨 SRE 工具链的建设。对于 SRE 团队来说减少琐务并不是单纯减少工作量而是把重复性运维工作转化为可持续的工程能力。让我们多做创造性的工程工作少做重复性的琐务。