第二十章 SRE：团队生命周期

本书的前言就设定了一个目标，即“消除SRE只能在谷歌场景中实现”。本章给出了一个从无人值守到成熟SRE组织的路线图。无论你的SRE团队中处于什么阶段或位置，本章都将帮助你如何发展SRE团队。

针对SRE的不同阶段，本章讨论了SRE理论。虽然SRE根据自己团队的规模、性质和地理分布而有所不同，但我们描述的SRE理论和实践适用于许多不同类型的团队。

没有SRE的SRE实践

即使没有SRE，也可以使用SLO。如第2章所述，SLO是SRE实践的基础。因此，SRE的第一条理论：

理论1：SRE需要SLO评估影响。

用SLO来评估服务性能，将会引导你的业务决策。

即使没有SRE，如下SRE的实践也可以实现。

承认你不需要100%的可靠。
设置合理的SLO目标，此SLO应衡量对用户最重要的可靠性。
同意有助于保护用户体验的错误预算政策，使用错误预算来帮助指导： –减少停机等之类的管理措施以此来保障你的系统达到可靠状态。 –更长期的工作优先顺序，使系统更可靠，使用更少的错误预算。
测量SLO并承诺遵循错误预算策略。这一承诺需要得到公司领导层的同意。

即使团队没有SRE，为关键客户服务设置SLO并实施错误预算是应该的，只是因为隐含的100％SLO意味着团队只能被动反应。此SRE理论允许你就如何确保应用程序的可靠性做出数据知情决策。

开始一个SRE角色

找到你的第一个SRE

有可能你的第一个SRE员工不会有明确的SRE经验。我们发现以下几个方面与SRE的角色有关，因此适合在面试中进行交谈：

运维
在生产中运行应用程序提供了非常宝贵的见解，否则很难获得。

软件工程
SRE需要了解他们支持的软件，并有权改进它。

监控系统
SRE原则要求可以衡量和解释的SLO，生产自动化扩展操作需要自动化。

生产自动化
扩展操作需要自动化。

系统架构
扩展应用程序需要良好的架构。

你的第一个SRE可能会在速度和可靠性目标之间处于一个困难和模糊的位置。他们需要有弹性和灵活性，以便在实现产品开发和维护客户体验之间提供适当的平衡。

安排你的第一个SRE

一旦雇佣了你的第一个SRE，你现在需要决定将他们嵌入到你的团队中。你有三个主要的选择:

在产品开发团队中
在运维团队中
在一个横向角色中，跨多个团队进行咨询

在阅读本章之后，我们建议你评估这三个选项的利弊，考虑：

你自己的角色和影响范围。
如果你能够有效地影响产品开发团队，那么在运维或横向工作中嵌入一个SRE可以帮助尽早解决生产问题。

你面临的直接挑战。
如果挑战需要实际工作来减轻技术问题或业务风险，那么将SRE嵌入到运维或产品团队中可能是有利的。这样做可以消除团队孤岛，便于团队成员之间的沟通。

你期望在未来12个月内面临的挑战。
例如，如果你关注的是发布，那么将SRE嵌入到产品开发团队中可能是有意义的。如果你关注的是基础架构的更改，那么将SRE嵌入到运维团队中可能更有意义。

你计划如何改变你的团队。
如果你计划转向集中式的SRE团队，那么你可能不希望在产品开发团队中首先嵌入SRE——以后可能很难将他们从这些团队中删除。

你已确定为第一个SRE的人。
根据他们的背景和技能来决定第一个SRE在哪里最有生产力。

在确定哪种方法最适合你时，尝试使用不同的模型可能是有意义的。但是，我们强烈建议长期坚持使用一个稳定且连贯的模型；否则，不稳定性将破坏SRE的有效性。

引导你的第一个SRE

你的第一个SRE的首要任务是加快服务速度。为了产生积极影响，SRE需要了解服务的当前问题、所需的工作（参见第6章）以及将系统保持在SLO中所需的工程。如果你的组织尚未按照理论1拥有SLO和错误预算，那么你的第一个SRE需要执行设计和实现这些工具所需的工程。基于这点，第二条SRE理论：

理论2：SRE必须有时间做明天比今天更好的事情。

如果没有这个原则，辛劳只会随着服务使用的增加而增加，系统也会相应地变得更大、更复杂。运维责任和项目工作之间的健康平衡是非常重要的——如果繁重的工作变得过于繁重，有才华的工程师就会离开团队。有关SRE团队如何获得这种平衡的更多指导，请参阅第17章。

最初的项目工作可能集中于以下之一:

改进监控，以便在出现问题时更好地了解系统。
解决在最近的事后调查中发现的任何高优先级的行动（见第10章）。
实现自动化，以减少运行服务所需的特定工作。

至关重要的是，SRE有一个独特的角色，他们的项目有利于整个团队。留意SRE工作进展不顺利的迹象：

S他们的工作组合与其他工程工作难以区分。
S如果你的第一个SRE是在一个产品开发团队中，那么他们所做的工作超出了他们的职责范围，或者他们是唯一一个在服务配置更改方面工作的人。
SLO没有受到重视，SRE也没有在衡量和维护客户体验方面取得进展。

分布式SRE

如果你没有离散的SRE团队，那么为分布式SRE构建一个社区是很重要的。这个社区应该提倡SRE的独特作用，并在团队之间推动以可靠性为中心的技术或实践的一致变化。如果没有社交分组，个体SRE可能会感到非常孤立。

你的第一个SRE团队

你可以通过多种方式组建一个SRE团队。我们在Google中使用的方法，从最小到最复杂，包括：

S创建一个新团队作为主要项目的一部分
建立横向SRE团队
转换现有团队（例如，运维团队）最适合你的方法是因地制宜。一个团队需要足够的SRE来处理运行服务所需的运维任务。处理这种工作量使我们想到我们的第三个理论：

理论3：SRE团队有能力调节工作负载。

在大型SRE团队之外，团队可能无法从第一天起就接受这个概念。这一原则易于解释，但很难有组织地付诸实施。它也是我们三个原则中最微妙的一条，也需要一些梳理。下面的部分将介绍如何构建团队，使用Tuckman的表现模型：形成、攻坚、规范和表演四个阶段。

形成

你组建的团队应该具备以下经验和专业知识：

修改应用软件以提高可靠性和性能。
编写软件，来达到如下目的： –产品中问题的的发现和快速解决 –自动化手动操作
建立并使用强大的软件实践和标准来促进长期的可维护性。
采用有条不紊和谨慎的方法进行操作。
了解系统架构（分布式系统设计和操作）。

理想情况下，你的团队将准备采用一种新的工作方式，并在技能上与其他团队建立的个人关系之间取得平衡。如果可能的话，我们建议你通过内部转移为团队提供支持。这可以减少团队的启动和运行所需的时间。

创建一个新的团队作为主要项目的一部分

你可以为一个大的项目创建一个新的SRE团队，这个团队大到足以证明新的人员编制是合理的，并且已经将可靠性和操作能力确定为项目风险。示例可能包括新服务的创建或技术的重大更改（例如，服务迁移到公共云）。

组建横向SRE团队

在这种方法中（在我们第一本书的第27章中有详细的记录），一个SRE小组在多个团队之间进行咨询。这个团队还可能建立配置管理、监视和警报的最佳实践和工具。

正确地转换团队角色

你可以将现有的团队转换为SRE团队。现有的团队可能不是产品开发团队；典型的候选人包括：操作团队、使用流行开源组件的团队。如果没有首先应用SRE实践和原则，要小心避免将团队从“运维”重新命名为“SRE”！如果你的重命名工作失败了，你的组织将来可能会对整个SRE概念造成毒害。

攻坚

新组建的团队一开始就需要考虑协作的问题：团队成员需要互相配合，也需要与其他团队合作。

你可以使用任何策略来促进这种凝聚力。在Google，我们已经成功地提供了一个定期论坛来学习和讨论SRE实践，并反思团队的表现。例如，你可能会定期举办一场电视午餐，在那里你会播放一段来自SREcon的视频，或者是一个读书俱乐部，在那里你可以提前阅读一些相关内容，然后讨论如何应用它。

在此阶段，鼓励你的新SRE团队进行扩展。你的新SRE应该乐于说出不适合你的组织的SRE实践，以及是否值得进行更改以使它们适合你的组织。

风险和缓解

在SRE旅程的初期阶段，团队可能会以多种方式失败。接下来，我们将介绍一些风险和可能的缓解策略，这些策略根据新团队的组成进行了细分。你可以针对每种风险使用一个或多个缓解策略。

新团队作为重大项目的一部分

风险

团队:
- 一次承担太多服务的责任，会让自己过于分散。——一个经常处理报警的团队没有时间以更持久的方式处理风险。
- 试图理解SRE原则和如何实现它们变得过于内省。结果，它未能实现预期目标。——例如，团队可能会忙于开发完美的SLO定义，同时忽略了服务的需求。
- 没有彻底检查其工作。因此，服务管理恢复到以前的行为。——团队每天有100个工单。由于这些工单并不需要立即干预，因此被忽略。
- 放弃SRE原则和实践，以满足产品里程碑。——保护SLO的可靠性改进（例如架构更改）可能永远不会实施，因为它们会推迟开发时间。
- 由于与新SRE团队失去影响力或权力而与现有团队发生冲突而分散注意力。
- 没有必要的技能广度，所以只提供了必要的部分改进。——例如，如果不能进行编程，SREs可能无法测量产品的可靠性。

缓解措施

团队：
- 从事单一重要服务开始。
- 尽可能早地参与项目，最好是在设计阶段。
- 对设计有投入，特别关注于定义SLO和分析设计中固有的可靠性风险。
- 与产品开发团队合作，致力于可靠性和与现有操作平台集成的特性。
- 在第一天不需要承担运维责任。相反，这种责任最初由产品开发团队或项目团队承担。这可能是一个需要管理层支持的重大文化变革。
- 就服务必须满足的条件与SRE达成明确的协议(参见《现场可靠性工程》第32章)。
  此外：
- 如果项目涉及到迁移，团队应该对当前和未来的环境有充分的了解。如果你的团队成员需要从外部招聘，请考虑具有软件工程和未来环境知识的候选人。
- 继续将新员工的数量控制在团队的三分之一以下，这样培训工作就不会压倒现有的团队成员。

横向SRE团队

风险团队被视为一个新的“门控”组织，不做真正的工作，也不增加真正的价值。

缓解措施

团队：
- 由具有相关专业知识的受人尊敬的工程师组成。
- 进行项目工作，集中于交付工具(用于监视、警报、推出、最佳实践、检查列表)。这些工具应该至少对另外两个团队有短期的有益影响。
- 传达成功和利益。应该庆祝一个能够实现效率突破，自动化工作，或永久消除系统不可靠性的来源的SRE团队。
- 将自己视为推动者，而非看门人。专注于解决方案，而不仅仅是问题。

一个团队转换到位

风险

团队：
- 认识到转换过程是自动取代人类的失业之旅的开始。
- 不支持对SRE团队的更改。
- 他们没有足够的能力来改变团队的日常活动。
- 几个月后，他们的日常工作毫无益处。
- 适用于不支持脚本或自动化的系统。
- 没有软件工程技能来自动化他们当前的工作量。
- 不具备向SRE发展所需的技能，或者对获得技能的兴趣。缓解措施
团队：
- 确保高层领导对变革的支持。
- 重新协商责任，以创建实现变革所需的空间。
- 非常谨慎地管理变更的沟通。
- 在整个过渡过程中能够获得强大的个人和技术支持。
- 直面对失业的担忧。在许多环境中，自动化消除了部分工作，但不包括整个工作；虽然这可能是走向失业的一步，但它至少有一个优点，那就是腾出时间去做一些比非自动化劳动更好的事情(也更适合未来的雇主)。
- 可以避免运维过载，并具有更大的影响。如果工程师减少了繁重的工作量，需要一个更小的团队，那么他们的经验应该在组织的其他地方得到高度重用。如果他们的经验不能在公司内部使用，那么在其他地方找工作应该会有优势。
- 接受培训以获得SRE需要的技能。你的产品开发团队可以提供产品培训，而SRE定位可以利用这本书和其他外部资源。
- 改变绩效评估的方式——评估团队和个人的指标。前者应与SLO和采用其他SRE做法相一致；后者应该与SRE技能的证据相一致。
- 向团队中添加一个有经验的SRE或开发人员。
- 具有识别和引入新的开源或基于云的监控和警报系统以实现自动化的自由度（预算或时间）。确定现有系统是否足够是早期的优先事项。
- 定期审查内部和利益相关方的进展情况。

规范化

规范化需要克服405页“风险和缓解”中提出的问题，并就组织的SRE团队的最佳实践达成广泛一致。团队需要就可接受的工作量水平、适当的警报阈值以及重要的和相关的SRE实践达成一致。团队还需要充分主动地识别服务前的挑战，并制定中长期目标来改进服务。

团队应该在规范化成熟度达到以下水平：

SLO和错误预算已经到位，错误预算政策在重大事件发生后执行。领导对SLO测量感兴趣。
值班的轮换是建立和可持续的(参见第8章)。on-call工程师可以对他们待命时间进行补偿。在重大事件中，有足够的工具，文档，和培训来支持任何团队成员。
有文档记录，有禁止事项，有管理。因此，SRE完成了有影响力的项目，提高了可靠性和效率。
事后分析文化已经确立。(参见第十章)。
团队展示了第一章列出的大部分原则。
当团队解决了405页“攻坚”中列出的初始问题时，他们会抓住他们所学到的知识并防止重复的问题。该团队定期进行演练，如不幸之轮或DiRT(灾难恢复测试)。(有关on-call培训的更多信息，请参阅我们第一本书的第11章和本书的第18章。)
产品开发团队从持续参与值班循环中获益。
团队为他们的利益相关者制作定期报告(例如，季度报告)，涵盖了报告期间的重点、亮点和关键指标。

与产品开发团队建立健康的关系是许多缓解策略的基础。团队应该根据组织的计划周期一起计划工作。

在继续下一步之前:停下来庆祝这一成功，写一篇回顾你到目前为止的经历。

执行

SRE团队的经验应该赢得更广泛的尊重和关注，并为战略的制定奠定基础。在Tuckman的performance model的最后阶段你应该期望:

成为架构设计和变更的顾问
从最初的设计阶段开始，SRE应该为软件的构建和结构可靠性定义模式。

主观能动性
团队应始终如一地应用原则3，以实现系统的整体健康。

产品架构方面

所有重大服务的变更，产品开发团队应该向SRE团队寻求意见。

例如，SRE团队会在新服务体系结构设计早期介入以减少日后进行高成本改造的几率。产品开发和SRE团队需要认识到他们在架构决策方面上观点的不同，但是目的都是要达到良好的产品设计。SRE的参与在如下方面可以为产品增加价值:

提高可靠性、可伸缩性和可操作性
更好地重用现有模式
更简单的迁移(如果需要的话)

自动调节工作负载

尽管随着时间的推移，产品架构负责人应该以某种有机的方式出现，但是SRE团队必须明确地向其伙伴维护原则3。要做到这一点，需要强有力的团队领导能力和高层管理人员的明确承诺。管理自己的工作负载的能力确保了SRE团队作为一个工程团队的地位，该工程团队与产品开发团队一样，在组织最重要的服务上工作。

在实践中，SRE团队如何确定自己的工作负载取决于与SRE接口的团队。在谷歌中，SRE团队通常与不同的产品开发团队进行交互。在这种情况下，关系具有以下特点:

SRE团队选择是否和何时上线服务(参见站点可靠性工程第32章)。
在运维超负荷的情况下，团队可以通过以下方式减少工作量:
–降低SLO
–将运营工作转移到另一个团队(如产品开发团队)
如果在约定的辛劳限制下无法在SLO上运行服务，SRE团队可以将服务交还给产品开发团队。
SRE参与不是永久的——它通过系统问题的解决和服务可靠性的提升来满足自身发展的需要。如果一个SRE团队已经解决了一个服务稳定性的问题，那么你需要:
–有意识地为SRE团队寻求其他靠性挑战。
–有意识地决定将服务交还给产品开发团队。
否则，随着SRE转向其他领域，团队可能会面临人员流失的风险。造成的缓慢流血可能会危及生产。

并不是所有的SRE团队都有合作的产品开发团队。一些SRE团队还负责开发他们运行的系统。一些SRE团队将第三方软件、硬件或服务打包(例如，开源包、网络设备等)，并将这些资产转换为内部服务。在这种情况下，您没有将工作转移回另一个团队的选项。相反，考虑以下策略:

如果服务不符合其SLO，停止与特性相关的项目工作，转而支持以可靠性为中心的项目工作。
如果在约定的工作量限制下无法在SLO上运行服务，请减少懒惰——除非管理层提供更多的能力(人员或基础设施)来处理这种情况。

组建更多的SRE团队

一旦你的第一个SRE团队开始步入正轨，基于如下的原因我们可能还要建设另一个SRE团队：

服务的复杂性

随着服务复杂度的提升，单个SRE团队无法有效的支持服务的运维工作。你可能希望将团队分成专门处理服务部分的子团队。

SRE上线

如果你的第一个SRE团队取得了成功并有明显的不同，那么在更多的服务中采用这种方法是必要的。

在地理上分离

你想要在不同的时区将团队分成两部分，并改为12小时on-call的轮班制。

当创建一个新的SRE团队时，我们建议执行以下操作：

阅读其他团队成立后的总结报告。找出重复做得好的事情，修复并探索那些做得不好的事情。
将现有的SEE团队成员加入到新的团队中，这些SRE新团队的骨干，以便应对挑战和风险。根据我们的经验，要找到合格的SRE候选人是很困难的，所以在新员工的帮助下快速发展团队通常是不现实的。
标准化建立团队和入职服务的框架(见第18章)。
慢慢改变值班的职责。例如： –为了避免核心on-call工程师离职，让团队成员在一个过渡时期内为他们以前的团队系统值班。 –在团队分离后，等待三到六个月的时间来分离值班轮换。

服务复杂性

如何分割

如果一个服务对于单个团队来说过于复杂而难以管理，那么有很多方法可以将工作分开。考虑以下选项来简化团队成员的认知负荷：

结构分割

例如，计算、存储和网络；前端和后端；前端和数据库；客户端和服务器；前端和管道。

代码分割

SRE原则不依赖于编程语言。但是，如果你的SRE深入到源代码中，那么沿着这些代码进行拆分可能会有一些好处。

管理分割

如果你所领导组织的工程跨越多个办公室，你可能希望将SRE团队的布置与应用程序开发联系起来。

隐患

当一个团队分裂时，有时新的团队中不会为原来团队所拥有的组件承担责任。为了减轻这种风险，你可以：

指定一个团队对第二团队章程之外的所有事情负责。
任命一个高级SRE在两个团队中担任一个全面的技术领导角色。

SRE上线

如果你最初的SRE团队成功了，那你的组织可能需要更多的SRE团队。我们建议对获得SRE支持的服务进行仔细的优先排序。考虑以下几点：

优先考虑可靠性对财务或声誉有很大影响的服务。影响越大，优先级越高。
定义最小可行的服务集，这些服务集是为了使产品能够正常工作而需要提供的。对这些服务进行优先级排序，并确保其他服务优雅地降级。
服务不应该成为SRE的优先级，因为它不可靠。在与业务最相关的领域，SRE应该在战术上得到应用。你也不希望在SREs投入使用之前让开发人员忽略可靠性。

地理分割

正如我们第一本书的第11章所述，Google通常在不同大洲的姐妹SRE团队中工作。我们这样做有很多原因：

服务可靠性

如果一个重大事件(如自然灾害)阻止一个团队工作运维服务，另一个团队可以继续支持服务。

值班压力

将值班轮班分成12小时轮班，为值班的工程师提供了适当的休息时间。

招聘和留住人才

与正常工作日重叠的值班轮班，扩大了我们可以招募到SRE工程师的基础，并强调了我们角色中的工程部分。

生产期限

随着文档、培训和标准化的需求变得越来越重要，跨两个办公室划分服务职责通常会促进成熟度的提高。

如果你的组织足够幸运，已经在多个大洲拥有了工程团队，我们建议配备多站点SRE团队。在不同于开发团队的办公室中有一个SRE团队是可行的，但是根据我们的经验，主机托管为健康和健壮的团队间对话提供了好处。否则，SREs就很难理解服务如何发展或技术基础设施如何使用，产品开发人员也就很难对基础设施的改进感到乐观。

位置：团队之间应该跨多少时区?

假设你有一些选择，时区分隔是决定两支队伍位置时的一个重要考虑因素。不幸的是，目标是相互排斥的：

尽量减少值班人员在正常办公时间以外的工作时间
最大化两个团队在线时的重叠时间，这样他们就可以定期互动

根据我们的经验，在相隔6至8个小时的时区工作的员工团队工作得很好，避免了12点到6点的值班轮班。你可以使用https://www.timeanddate.com/worldclock/meeting.html等在线资源来可视化不同位置来减少重叠。

人员和项目：建立团队

当你在地理上划分团队时，新办公室中的第一个SRE团队将为未来的SRE团队设置规范。如果你能识别出一个或多个愿意在临时或长期的基础上从原来的站点迁移来建立SRE实践、招募和培训新团队的SRE人员，你成功的可能性就会大大提高。新团队还应该承担一个高价值的项目，促进团队内部的协作，并需要与姐妹团队进行交互。

平均：在办公室之间分配工作，避免“夜班”

通常，两个姐妹的SRE团队中的一个与产品开发团队(我们将其称为“Office 1”)相关联(或者至少在同一个时区)。如果是这种情况，要保持警惕，以确保没有被配置的团队(“office2”)不会变成一个与产品开发团队几乎没有联系的夜班，承担过多的工作量，或者只分配给不太有趣或影响不大的项目。

这两个办公室的工作量会有一些自然的差异：

你的服务可能每天都有高峰，在高峰期间会有一个办公室内的人员随时待命。因此，这两个站点的on-call体验将有所不同。
开发过程将以特定的节奏生成新版本。一个办公室人员可能会承担更多的与推出和回滚相关的负担。
Office 1在工作日更容易被产品开发团队的问题打断。
Office 1更容易承担与主要版本相关的项目工作。相反，Office 2更容易承担与即时产品目标脱钩的项目工作。

你可以使用以下方法来维持平衡：

平衡办公室之间值班的工作量。分配较大比例的报警及较小比例的工单到办公室。
将开发区域与特定办公室的SRE团队联系起来，这可以是短期(例如，根据项目)或长期(例如，根据服务)的。否则，产品开发团队很可能会依赖于Office 1，而无法有效地与Office 2中的SREs打交道。
将更高比例的内部服务改进项目(这些项目可能需要较少的产品开发团队参与)分配给Office 2。
在两个办公室之间公平地传播最有趣、最有影响力的项目。
在两个办公室之间保持相似的团队规模和资历组合。
将项目分散到两个站点，有意促进两个办公室SREs之间的交互。虽然从一个办公室运行一个主要项目可能会获得一些效率，但是将两个站点的项目分开有助于传播知识并在办公室之间建立信任。
允许工程师定期去其他办公室。这可以创造更好的和谐关系，从而，愿意与对方合作。

工作地点：三个地点怎么样?

我们试图将SRE团队分成三个站点，结果导致了各种问题：

不可能有一个所有SREs都能参加的跨办公室生产会议(见我们第一本书的第31章)。
很难在三个办公室之间确保知识、能力和操作响应的一致性。
如果所有on-call的工作都是在办公时间内完成的，那么自动化低级工作和低价值页面的动机就会减少。在工作时间做一个解决简单问题的英雄是很有趣的。但如果它有一定的个人成本，确保它不再发生的动机是尖锐和直接的。

工时机：两队应该同时首发吗?

你可以使用以下任何一种模型来组建姐妹团队：

两半同时开始。
首先建立与产品开发团队合作的网站。这允许SREs更早地参与到产品生命周期中。
首先建立一个不与产品开发团队合作的站点，或者，如果一个服务已经投入生产一段时间，SRE团队和产品开发团队可以共享on-call。
根据合适的人选在合适的时间开始做出改变。

财务：差旅预算

为团队两部分之间的高质量交互创造机会是非常重要的。尽管视频会议对日常会议很有效，但我们发现，定期面对面的交流有助于促进健康的人际关系和信任。我们建议：

每个SRE，产品开发经理，和技术领导在站点1访问站点2每年(至少)，反之亦然。
在站点1中担任管理或技术领导角色的每个SRE每年至少访问站点2两次，反之亦然。
所有SREs至少每年召开一次会议。

领导能力：共同拥有一项服务

如果你有多个SRE站点，那么可能每个办公室都有决策者。这些聚会应该定期面对面和通过视频会议。只有建立牢固的个人关系，他们才能：

讨论团队面临的挑战的解决方案。
解决意见分歧，同意共同前进的道路。
为对方的团队辩护(防止“我们与他们对抗”的心态)。
支持彼此团队的健康发展。

运行多个团队的实践建议

当你的组织积累了更多的SREs和SRE团队时，新的挑战就会出现。例如，你必须:

确保你为SREs提供他们需要的职业机会。
鼓励操作和工具的一致性。
处理那些不适合完全参与SRE的服务。

本节描述了我们在Google中为处理这些问题而采用的一些实践。根据你的组织的具体情况，有些或许多组织可能也为你工作。

任务控制

Google的任务控制计划使产品开发团队的工程师有机会在SRE团队中工作六个月。我们通常会将这些工程师与他们专业领域截然不同的SRE团队进行匹配。软件工程师接受生产系统和实践方面的培训，并最终随叫随到。6个月后，一些工程师决定留在SRE；其他人返回到他们的老团队，对生产环境和SRE实践有了更好的认识。SRE团队从额外的工程资源中获益，并对培训材料和文档中的漏洞和错误获得有价值的见解。

SRE交换

Google的SRE交换计划让SRE与不同的SRE团队一起工作一周。来访的SRE将观察主队的工作方式，并与主队分享可能对主队有用的来自主队的实践。在交流结束时，来访的SRE会写一份旅行报告，描述他们的一周，他们的观察，以及他们对两个团队的建议。这个程序在Google很有用，因为我们的SRE团队是高度专业化的。

培训

培训对于SRE操作系统的能力至关重要。虽然大多数培训是在团队中进行的(参见第8章第150页的“培训路线图”)，但是考虑为所有SREs建立一个标准的培训课程。在Google，所有新的SREs参加SRE EDU，一个沉浸式的为期一周的培训，介绍了几乎所有SREs工作的关键概念，工具和平台。这提供了所有新SREs的基本知识水平，并简化了特定于团队和特定于服务的培训目标。几个月后，SRE EDU团队还运行了第二系列课程，介绍了用于管理重大事件的常用工具和流程。我们的绩效管理流程特别认可为本次培训提供便利的SREs人员。

横向项目

因为SRE团队与一组服务紧密结合，所以对于团队来说，构建专有的解决方案来应对他们遇到的挑战是一种诱惑——例如，监控、软件推出和配置工具。这可能导致跨团队工作的重大重复。虽然允许许多解决方案竞争“市场”采用是有价值的，但在某些时候，将标准的解决方案聚合在一起是有意义的：

满足大多数团队的需求
提供一个稳定的、可扩展的平台，在此基础上构建下一层创新

Google通过使用横向团队来完成这些工作，横向团队通常由经验丰富的SREs人员组成。这些横向团队构建并运行标准解决方案，并与其他SRE团队合作以确保顺利采用。(有关横向软件开发的更多信息，请参阅第21章第432页的“案例研究2：SRE中的通用工具采用”。)

SRE流动性

Google尽最大努力确保工程师积极地想成为各自团队的一员。为此，我们确保SREs能够（并意识到他们能够）在团队之间进行转移。假设没有性能问题，SREs可以自由地转移到其他人员开放的SRE团队。SREs也通过了我们软件工程师职位的招聘标准，他们可以自由地转到产品开发团队(参见http://bit.ly/2xyQ4aD)。

这种流动性水平对于个人和团队来说是非常健康的，原因有很多：

工程师能够识别并占据感兴趣的角色。
如果个人情况发生变化，on-call的职责变得不切实际，SREs可以在要求较少on-call职责的团队中探索机会。他们可以通过与其他团队交谈和查看团队值班的统计数据来获得这些信息。
在团队之间移动的SREs扩大了他们加入的团队的经验。
SREs在办公室之间流动有助于建立或保持不同办公室之间的文化一致性。
SREs不会被强迫去做不健康的服务，或者为那些不支持个人发展的经理工作。

这个策略还有一个副作用，就是让你的SRE经理专注于健康快乐的服务和团队。

团建

除了保持地理上分散的团队健康所需的旅行（见第417页的“财务：旅行预算”一节），考虑以下方面的资金：

建立公司内部感兴趣的社区，包括来自多个办公室的SREs。这类团体可以通过电子邮件和视频会议进行广泛的合作，但至少每年面对面交流一次。
参加并出席全行业的SRE和与SRE相关的会议，以拓宽知识，了解其他组织如何处理类似问题，并希望得到启发和激励。

启动协调工程小组

正如我们第一本书的第27章所描述的，启动协调工程(LCE)团队可以将SRE原则应用到更广泛的产品开发团队中——这些团队构建的服务不需要引起值得SRE参与的注意级别。就像其他的SRE团队一样，LCE团队应该积极地参与日常操作的自动化。例如，开发标准工具和框架使产品开发团队能够在生产环境中设计、构建和启动他们的服务。

卓越生产

随着组织中SRE团队数量的增长，将出现许多最佳实践。每个SRE团队的发展都是不同的，因此评估它们需要深入了解多个团队的高级SREs。

在Google，我们定期进行名为Production Excellence的服务评估。高级SRE领导定期检查每个SRE团队，评估他们的一些标准度量(例如，工单负载、错误预算使用、项目完成、bug关闭率)。该评论既赞扬出色的表现，也为表现不佳的团队提供建议。

经验丰富的SRE可用于评估细微差别。例如，将团队合并或拆分导致的项目完成率下降与真正的团队性能问题相比，是一项具有挑战性的工作。如果一个团队有被淹没的风险，评审员可以也应该利用他们的组织地位来支持团队的领导来纠正这种情况。

SRE资金和招聘

在Google，我们使用两种做法来确保每个SRE都贡献了显著的价值：

大部分SRE资金来源于产品开发团队的资金来源。与测试或安全类似，可靠性是产品开发的核心支柱，并为此提供资金支持。
根据我们的经验，SREs的供应总是小于需求。这一动态确保我们定期审查和优先考虑得到SRE支持的服务。

简而言之，你应该有比组织想要的更少的SREs，并且只有足够的SREs来完成他们的专业工作。

在Google中，产品开发团队中SREs与工程师的比例从1:5左右(例如，低级基础设施服务)到1:50左右(例如，使用标准框架构建大量微服务的面向消费者的应用程序)。许多服务在这一范围的中间，比率约为1:10。

结论

我们相信任何规模的组织都可以通过以下三个原则来实施SRE实践：

SRE需要带有结果的SLOs。
SRE必须有时间让明天比今天好。
SRE团队有能力调整他们的工作量。

自从Google开始公开谈论SRE，它已经从Google特有的生产实践发展成为许多公司的专业实践。这些原则经常被证明是正确的——无论是在我们多年的大规模直接经验中，还是在我们最近与客户一起采用SRE实践的经验中。因为我们已经看到这些实践在Google内部和外部都起作用，我们认为这些建议应该在不同类型和规模的组织中被证明是有用的。