编者按：当您开始在公司中运行许多应用程序或服务时，您将开始遇到您的主要SRE（或Ops）团队所能支持的极限。在本期CRE生活课程中，我们将探讨您如何做出正确的、有原则的、合理的决定，即您应该为您的SRE提供哪些应用程序和服务，以及如何决定该子集何时需要更改。

在Google中，我们很幸运有网站可靠性工程（SRE）团队支持我们的横向基础设施，如存储、网络和负载平衡，以及我们的主要应用程序，如搜索、地图和照片。尽管如此，该职位所需的软件工程和系统工程技能的结合使得很难找到和招募SRE，而且对他们的需求稳步超过了供给。

随着时间的推移，我们发现SRE团队能够支持的应用程序数量存在一些实际限制，并了解了比其他应用程序更难支持的应用程序的特性。如果您的公司运行许多生产应用程序，您的SRE团队不太可能支持所有这些应用程序。

Q:我如何知道我公司的SRE团队何时处于极限？如何选择要支持的最佳应用程序子集？SRE团队应该在什么时候放弃对应用程序的支持？

所有问题都很好；让我们更详细地探讨这些问题。

SRE支持的实际限制

在任何时候，通常都会有一个指定的主要负责人对页面做出响应，而次要负责人会抓住掉下来的页面，例如，如果主要负责人暂时失去联系，或者正在处理一个事件。一级和二级处理正常的ops工作，将团队的其他成员释放出来进行项目工作，例如提高可靠性、建立更好的监控或增加ops任务的自动化。因此，每个工程师在六个星期中有两个星期专注于操作工作——一个是主要的，一个是次要的。Q： 当然12到16个工程师可以处理开发团队可以编写的所有应用程序的支持？

事实上，没有。我们的经验是，一个SRE团队能够有效管理多少不同的应用程序或服务，有一个明确的认知限度；任何一个工程师都需要对每个应用程序足够熟悉，以便对每个应用程序的大多数生产问题进行故障排除、诊断和解决。如果你想一次轻松地支持许多应用程序，你就应该让它们尽可能地相似：设计它们以使用通用模式和后端服务，标准化操作任务的通用工具，如推出、监视和警报，并按类似的计划部署它们。这减少了每个应用程序的认知负荷，但并不能消除它。

如果你有足够的SRE，那么你可以考虑组建两个团队（同样，受2 x 6的最低人员限制），并赋予他们单独的职责。在谷歌，单个SRE团队分成前端和后端碎片并不罕见，随着规模的增长，每个团队只负责支持系统的那一半。（我们称之为团队有丝分裂。）

您的SRE团队的最大支持服务数量将受到以下因素的强烈影响：

Q:在六个星期中，有四个星期SRE没有进行运营工作，那么我们是否可以利用这段时间来增加我们的SRE团队的支持服务能力？

你可以这样做，但在谷歌，我们认为这是"吃你的种子玉米"。目标是让机器做所有机器可能做的事情，要做到这一点，你需要为你的SRE留出喘息的空间来做项目工作，如为你的服务生产新的自动化。根据我们的经验，一旦一个团队跨过50%的运营工作门槛，它就会很快下滑到100%的运营。在这种情况下，你将失去工程的努力，这将给你中长期的运营效益，如减少频率，持续时间和未来事件的影响。当您将您的SRE团队转移到几乎全职的运营工作中时，您将失去其工程设计和开发技能的好处。

请特别注意，SRE工程项目工作可以通过解决上述许多因素来降低运营负荷，这限制了SRE团队能够支持的服务数量。

鉴于上述情况，您可能会发现自己处于这样一种境地：您希望您的SRE团队提供一项新服务，但实际上他们无法在可持续的基础上支持该服务。

您的SRE支持能力不足，现在怎么办？

Q：我们希望开发人员编写的下一个应用程序是什么？他们不会忙着支持当前的应用程序吗？

这可能是真的-由于警报过多或缺乏自动化，当前应用程序可能会产生很高的操作负载。然而，这给了开发团队一个实际的激励，让他们花时间让应用程序更容易支持——调整警报，把开发人员的时间花在自动化上，降低功能更改的速度。

当开发人员的操作工作负担过重时，SREs也许能够提供操作方面的专业知识和开发工作，将开发人员的工作量降低到可管理的水平。然而，SREs仍然不应该为服务承担运营责任，因为这并不能解决根本问题。

当一个团队开发一个应用程序，而另一个团队则首当其冲地为它承担运营工作时，道德风险就会滋生。开发人员需要高的开发速度；花上几天的时间运行并消除每一个偶尔会导致服务器内存不足并需要重新启动的错误，这不符合他们的利益。与此同时，运营团队每天都要被呼召进行几次重启-