SRE的一个公开目标是保持每个SRE的工作时间中运维工作（即琐事）的比例低于50%。SRE至少花 50%的时间在工程项目上，以减少未来的琐事或增加服务功能。增加服务功能包括提高可靠性、性能，或利用率，同时也会进一步消除琐事。

SRE公开50%这个目标是因为如果不加以控制，琐事会变得越来越多，以至于迅速占据我们每个人100%的时间。减少琐事和扩大服务规模的工作就是SRE 中的E （Engineering）。对工程工作的关注使SRE 可以在服务规模扩大的同时减少人数，并且比单纯的研发团队和单纯的运维工作团队能更有效地管理服务的秘诀。

不仅如此，招聘新的SRE时，我们也会引用上文提及的50%规则，承诺新员工不会专门进行运维工作。我们通过禁止SRE组织或者其中任何小团队退化为专门从事运维工作的组织来实现这个承诺。

琐事的计算

如果我们想要将一个SRE花在琐事上的时间限制在50%，应该如何分配时间呢?

任何一个SRE在参与on-call时都会承担一定程度的琐事。一个典型的SRE每个周期中会有一周主on-call和一周副on-call的工作。（主on-call和副on-call的讨论，请参见第 11 章）。因此，在一个六个人的轮值周期中，每六周中至少有两周需要专注于on-call和中断性事务的处理，这意味着潜在的琐事的最小值是一个SRE的工作时间的 2/6，也就是33%。如果是八人轮值，那么最小值就是 2/8，即25%。

与此计算相一致，来自SRE的数据显示，琐事的最大来源就是中断性工作（即与服务相关的非紧急的邮件和电子邮件）。另一个主要来源是 on-call（紧急的），紧随其后的是发布和数据更新。即使 Google的发布和数据更新过程通常是高度自动化的，这个部分仍有许多改进的空间。

Google SRE的季度调查显示，琐事的时间占用大约在33%，所以我们其实目前比总体目标 50% 做得更好。然而，这个平均值没有显示出其中的异常情况∶一些SRE 琐事比例为 0%（纯开发项目而不参加on-call），而其他人宣称他们在琐事上花费了80% 的时间。当某个SRE报告自己承担了过量的琐事时，这通常意味着管理者需要在团队中更均衡地分布琐事负荷，同时应该鼓励该 SRE找到自己满意的工程项目。

SRE的一个公开目标是保持每个SRE的工作时间中运维工作（即琐事）的比例低于50%。SRE至少花 50%的时间在工程项目上，以减少未来的琐事或增加服务功能。增加服务功能包括提高可靠性、性能，或利用率，同时也会进一步消除琐事。

SRE公开50%这个目标是因为如果不加以控制，琐事会变得越来越多，以至于迅速占据我们每个人100%的时间。减少琐事和扩大服务规模的工作就是SRE 中的E （Engineering）。对工程工作的关注使SRE 可以在服务规模扩大的同时减少人数，并且比单纯的研发团队和单纯的运维工作团队能更有效地管理服务的秘诀。

不仅如此，招聘新的SRE时，我们也会引用上文提及的50%规则，承诺新员工不会专门进行运维工作。我们通过禁止SRE组织或者其中任何小团队退化为专门从事运维工作的组织来实现这个承诺。

琐事的计算

如果我们想要将一个SRE花在琐事上的时间限制在50%，应该如何分配时间呢?

任何一个SRE在参与on-call时都会承担一定程度的琐事。一个典型的SRE每个周期中会有一周主on-call和一周副on-call的工作。（主on-call和副on-call的讨论，请参见第 11 章）。因此，在一个六个人的轮值周期中，每六周中至少有两周需要专注于on-call和中断性事务的处理，这意味着潜在的琐事的最小值是一个SRE的工作时间的 2/6，也就是33%。如果是八人轮值，那么最小值就是 2/8，即25%。

与此计算相一致，来自SRE的数据显示，琐事的最大来源就是中断性工作（即与服务相关的非紧急的邮件和电子邮件）。另一个主要来源是 on-call（紧急的），紧随其后的是发布和数据更新。即使 Google的发布和数据更新过程通常是高度自动化的，这个部分仍有许多改进的空间。

Google SRE的季度调查显示，琐事的时间占用大约在33%，所以我们其实目前比总体目标 50% 做得更好。然而，这个平均值没有显示出其中的异常情况∶一些SRE 琐事比例为 0%（纯开发项目而不参加on-call），而其他人宣称他们在琐事上花费了80% 的时间。当某个SRE报告自己承担了过量的琐事时，这通常意味着管理者需要在团队中更均衡地分布琐事负荷，同时应该鼓励该 SRE找到自己满意的工程项目。