第20章

SRE团队生命周期


由大卫·弗格森(David Ferguson)和普拉珊特·拉汉(Prashant Labhane)与Shylaja Nukala撰写



本书的序言设定了一个目标，以”消除仅在‘Google规模’或‘Google文化’下可以实施SRE的想法。”本章列出了使SRE组织成熟的路线图，从人手不足但有抱负的人，到成熟的各个阶段，再到强大的(可能是)全球分布的SRE团队。不论您身在SRE组织中的哪个阶段，本章都将帮助您确定发展SRE组织的策略。

我们讨论了在此旅程的每个阶段都需要制定的SRE原则。虽然您自己的旅程会因组织的规模，性质和地理分布而异，但我们描述的成功应用SRE原则和实施SRE做法的路径应可推广到许多不同类型的组织。

没有SRE的SRE实践

即使您没有SRE，也可以通过使用SLO来采用SRE做法。如第2章所述，SLO是SRE实践的基础。因此，它们告知了我们SRE的第一个原则:

-w100 原则 ＃1 SRE需要具有结果的SLO。

相对于SLO的服务性能应指导您的业务决策。

我们认为，以下实践-您甚至不需要一个SRE就可以实现-是实施SRE实践的关键步骤:

即使组织没有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的初始任务是加快服务速度。为了产生积极影响，SRE需要了解服务的当前问题，所需的工作量(请参阅第6章)以及将系统保留在SLO中所需的工程技术。如果您的组织还没有遵循原则 \＃1的SLO和错误预算，则您的第一个SRE需要执行设计和实施这些工具所需的工程。至此，我们的第二个SRE原则开始发挥作用:

-w100 原则 ＃2

SRE必须有时间使明天比今天更好。

没有这个原理，琐事只会随着服务使用的增加而增加，并且系统相应地变得更大和更复杂。在运维责任和项目工作之间保持健康的平衡至关重要-如果琐碎的工作变得繁重，有才华的工程师将逃离团队。有关SRE团队如何获得平衡的更多指导，请参阅第17章。

最初的项目工作可能集中在以下其中一项:

SRE发挥独特作用，并使他们的项目使整个团队受益，这至关重要。留意SRE工作进展不佳的迹象:

分布式SRE

如果您的组织没有(或不打算拥有)离散的SRE团队，那么为分布式SRE构建社区很重要。该社区应倡导SRE的独特作用，并推动团队中以可靠性为中心的技术或实践的不断变化。没有社会团体，各个SRE可能会感到非常孤立。

您的第一个SRE团队

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

最适合您的组织的方法是高度受环境影响的。团队需要足够的SRE来处理运行服务所需的操作任务。解决这一工作量使我们遵循了第三项原则:

-w100 原则 ＃3

SRE团队有能力调节其工作量。

在大型SRE组织之外，团队从一开始就可能无法接受这个概念。该原则易于解释，可能难以在组织上付诸实践。这也是我们三项原则中最微妙的，并且经得起推敲。以下各节使用塔克曼的绩效模型以及组建，激荡期，规范和表现的阶段来逐步进行团队建设。1

组建

您组建的团队应具有丰富的经验和专业知识，其中包括:

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

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

您可能会为一个大型项目创建一个新的SRE团队，该团队的规模足以证明新员工的数量，并且已将可靠性和运维能力确定为项目风险。例如，可能包括创建新服务或技术发生重大变化(例如，迁移到公共云)。

组建水平的SRE团队

通过这种方法(在第一本书的第27章中有充分记录)，由SRE组成的小型团队会跨多个团队进行咨询。该团队可能还会为配置管理，监控和警报建立最佳实践和工具。

将团队转换到位

您也许可以将现有团队转换为SRE团队。现有团队可能不是产品开发团队。典型的候选人包括运维团队或负责管理组织大量使用的流行开源组件的团队。请注意避免在未先应用SRE惯例和原则的情况下将团队从”运维”重命名为”SRE”！如果您的品牌重塑工作失败，那么将来您的组织可能会完全不顾SRE的整个概念。

震荡期

组建后，团队需要开始协作:团队成员需要彼此之间以及与其他团队一起良好地工作。

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

在此阶段中，鼓励您的新SRE团队进行自我扩展。您的新SRE应该轻松地讲出组织中不适合的SRE做法，以及是否值得进行更改以使其适合。

风险和缓解措施

在SRE旅程的初期阶段，团队可能会采用多种方式失败。接下来，我们介绍一些风险和可能的缓解策略，并按新团队的组成方式对其进行细分。对于每种风险，您可以使用一种或多种缓解策略。

新团队是重大项目的一部分

风险

团队:

— 一支不断战斗的团队没有时间以更持久的方式应对风险。

— 例如，在开发完美的SLO定义时，团队可能会变得精疲力尽，同时忽略了服务的需求。

— 团队每天被呼叫100次。由于呼叫并不表示需要立即干预，因此它们会忽略页面。

— 捍卫SLO的可靠性改进(例如体系结构更改)可能永远不会实现，因为它们会延迟开发时间表。

— 如果没有编程能力，SRE可能无法对产品进行仪器测量以测量其可靠性。

缓解措施

团队:

另外:

横向SRE团队

风险

团队被认为是一个新的”召唤”组织，没有任何实际工作或没有任何实际价值。

缓解措施

团队:

一支已转换的团队

风险

团队:

缓解措施

团队:

规范化

规范需要解决第405页”风险和缓解”中提出的问题，并就组织SRE团队的最佳实践达成广泛共识。团队需要就可接受的琐事水平，适当的警报阈值以及重要和相关的SRE做法达成共识。团队还需要自给自足，以主动识别服务之前的挑战，并设定中期和长期目标以改善服务。

在规范阶段，团队应达到以下成熟度级别:

将现有团队转变为SRE团队

由《纽约时报》的Brian Balser撰写

当《纽约时报》成立其交付和站点可靠性工程部门时，我们由具有SRE类型技能的工程师组建了SRE团队，例如工具和运维生产系统团队。有些团队是”有潜力的”:他们在人才，远见和责任方面考虑了SRE。其他团队已经存在了几年，由于技能，兴趣和机会的结合，最终运行了生产架构。

挑战

过渡到SRE的现有团队之一处于非常具有挑战性的位置。多年来，该团队已拥有所有权和责任来管理配置，更改请求以及我们整个站点范围体系结构的核心组件的操作。他们有效地成为了支持我们所有产品开发团队的服务团队。他们的工作受到故障单和生产问题的驱动，并且处于连续反应模式。他们没有时间进行改进，创新或其他高价值的战略工作。

尽管团队有很多好主意，但工作量很大，而且通常与产品发布相关的许多高优先级”阻止程序”服务请求也是如此。这种模式是不可持续的，因此团队需要与产品线性增长一同成长以跟上这种支持负担。为了加剧这种情况，这支小团队多年来积累了丰富的机构知识。庞杂的信息对团队进行了大量的打扰，加剧了团队的负担，公共要素笼罩着团队。

以第一原则为基础

我们的SRE组织的一项指导原则是使自己摆脱关键的道路，并赋予产品开发团队自助服务解决方案的能力。考虑到这一点，我们的目标变得很明确:反转责任模型，使产品开发团队能够推动自己的变革。此策略将:

流程改进

我们通过几个变更阶段改进了流程:

  1. 我们在开发团队中嵌入了SRE，以帮助缓解压力。

  2. 为了使产品开发团队能够独立获取其服务配置的所有权，我们将每种服务配置分为一个基于团队的存储库。

  3. 我们将每项服务从传统CI系统迁移到我们的标准Drone CI/CD管道。开发人员友好的工作流程完全由GitHub事件驱动。

  4. 我们将每个产品团队加入了新的工具和工作流程，以便他们可以提交自己的变更请求，而不会受到服务单的阻塞。

尽管这些改进是向前迈出的一大步，但我们尚未达到理想的最终状态。审核拉取请求仍然经常需要SRE专业知识。为了使耗时的审核中断更易于管理，我们安排了每天的办公时间。这种一致的做法使我们能够以更具预测性的方式来批处理问题和讨论，还为与正在加入的团队共享知识提供了场所。

最终结果和后续步骤

现在，SRE团队正在实现其最初目标:> 50％的项目工作(与支持相关的工作相比)。团队仍然拥有丰富的机构知识，但是现在知识正在更广泛地传播，从而逐渐改善了公共因素并减少了中断。

现在我们已经为项目工作腾出了空间，我们的下一步将集中在添加更多高级功能上，例如金丝雀部署，更好的测试工具以及可观察性和弹性功能。这样做将使产品开发团队更加自信地对其服务配置行使完全自主权，而无需依赖SRE进行变更管理。与您的产品开发团队建立健康的关系是许多缓解策略的基础。团队应根据您组织的计划周期来计划工作。

在继续下一步之前:停下来，庆祝这次成功，并写一篇回顾您迄今为止的旅程的回顾。

表现

SRE团队到现在为止的生产和工作经验，应该赢得了更广泛组织的尊重和关注，并为战略性前进奠定了基础。在塔克曼绩效模型的最后阶段，表现，您应该期望:

所有架构设计和变更的合作伙伴。

从最初的设计阶段开始，SRE应该定义用于构建和构造软件以确保可靠性的模式。

具有完整的工作量自决。

团队应始终遵循原则3，以确保系统的整体健康。

在架构层合作

产品开发团队应开始与合作伙伴SRE团队联系，以寻求有关所有重大服务变更的建议。SRE团队现在有机会发挥一些最大的影响。

例如，SRE团队可能会为新服务架构的设计提供早期投入，以减少日后进行高成本重新设计的可能性。产品开发和SRE团队可以承认他们在体系结构决策方面的差异，以达到良好的设计过程。成功的参与可以通过以下方式增加价值:

自我调节的工作量

随着时间的流逝，体系结构上的伙伴关系应该有机地融合在一起，而SRE团队则必须向其伙伴明确提出原则＃3。这样做需要强大的团队领导能力和高级管理层的明确，前期承诺。调节自己的工作负载的能力确保了SRE团队作为工程团队的地位，该团队可以使用与组织产品开发团队同等的组织最重要的服务。

实际上，SRE团队如何确定自己的工作量取决于SRE与之交互的团队。在Google，SRE团队通常与独特的产品开发团队互动。在这种情况下，该关系具有以下特征:

并非所有SRE团队都有合作伙伴产品开发团队。一些SRE团队还负责开发其运行的系统。一些SRE团队打包第三方软件，硬件或服务(例如，开源软件包，网络设备，即服务)，并将这些资产转化为内部服务。在这种情况下，您将无法选择将工作转移回另一个团队。相反，请考虑以下策略:

组成更多SRE团队

一旦第一个SRE团队启动并运行，您可能想组建一个额外的SRE团队。您可能由于以下原因之一而这样做:

服务复杂度

随着服务获得用户和功能，单个SRE团队无法有效地支持它变得越来越复杂和困难。您可能需要将团队划分为专门负责服务部分的子团队。

SRE推广

如果您的第一个SRE团队已经成功并取得了明显的成就，那么在更多服务中采用这种方法可能会对组织产生兴趣。

按地理位置划分

您想将团队分成两个不同的时区，并转移到12小时的值班时间。

在创建新的SRE团队时，我们建议您执行以下操作:

服务复杂度

哪里拆分

如果一项服务变得过于复杂而无法由一个团队进行管理，则可以采用多种方法来拆分工作。考虑以下选项以简化团队成员的认知负担:

基础设施分离

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

语言拆分

SRE原则不依赖于编程语言。但是，如果您的SRE深入地参与了源代码，那么按照这些思路进行拆分可能会带来一些好处。

位置拆分

如果您组织的工程跨越多个办公室，则可能需要使SRE团队位置与应用程序开发保持一致。

陷阱

当团队拆分时，有时新团队都不会对原团队拥有的组件负责。为了减轻这种风险，您可以:

SRE推广

如果最初的SRE团队成功，则您的组织可能需要更多。我们建议您仔细确定获得SRE支持的服务的优先级。请考虑以下几点:

地理上分离

正如我们第一本书的第11章中所述，Google通常会为不同大陆的姐妹SRE团队配备人员。我们这样做的原因有很多:

服务可靠性

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

值班压力

将值班轮换分为12小时轮班，以便为待命工程师提供适当的休息时间。

招聘和留住人才

与正常工作日重叠的值班时间扩大了我们可以招聘到SRE职位的工程师的基础，并强调了我们职位的工程部分。

生产成熟度

随着对文档，培训和标准化的需求变得越来越重要，将服务责任划分给两个办公室往往会导致成熟度的提高。

如果您的组织很幸运能够在多个大洲拥有工程团队，我们建议为多站点SRE团队配备人员。可以将SRE团队与开发团队设在不同的办公室，但是根据我们的经验，集中办公可以通过健康而强大的团队间对话的形式带来好处。否则，SRE很难了解服务的发展方式或技术基础架构的使用方式，产品开发人员对基础架构的改进持乐观态度也很难。

布局:团队应该相隔几个时区？

假设您有选择的余地，则时区分离是确定两支队伍的位置时的重要考虑因素。不幸的是，目标是互斥的:

夏令时使情况变得复杂。

根据我们的经验，时区间隔为六到八个小时的工作人员团队可以很好地工作，并且避免了凌晨12点至早上6点的值班时间。您可以使用https://www.timeanddate.com/worldclock/meeting.html等在线资源来可视化各个位置的时区重叠。

人员和项目:为团队播种

当您按地理位置划分团队时，新办公室中的第一个SRE团队将为以后的SRE团队设定规范。如果您可以确定一个或多个愿意暂时或长期从原始站点迁移以建立SRE实践并招募和培训新团队的SRE，则成功的可能性会更高。新团队还应执行一项高价值的项目，该项目应促进团队内部的协作，并需要与其姊妹团队进行互动。

平衡:在办公室之间分配工作并避免”夜班”

通常，两个姐妹SRE团队之一与产品开发团队(或称为”办公室1”)一起(至少在同一时区)。如果是这种情况，请保持警惕，以确保不在同一地点的团队(“Office 2”)不会成为夜班，而该夜班与产品开发团队的联系很少，所付出的辛苦超过其应有的工作份额，或者仅分配给那些不太有趣或影响较小的项目。这两个办公室的工作量会有一些自然的差异:

您可以通过以下做法帮助保持平衡:

布局:三班倒怎么办？

我们试图将SRE团队分散到三个地点的尝试导致了各种问题:

时间选择:团队的两半都应该同时开始吗？

您可以使用以下任一模型来组建姐妹团队:

经费:差旅预算

为团队的两半之间的高质量互动创造机会非常重要。尽管视频会议在日常会议中非常有效，但我们发现，定期的面对面互动对于促进健康的关系和信任大有帮助。我们建议:

领导力:共同的服务所有权

如果您有多个SRE站点，则每个办公室中可能都有决策者。这些各方应定期面对面并通过视频会议开会。只有建立牢固的个人关系，他们才能:

建议管理多个团队的做法

随着您的组织积累更多的SRE和SRE团队，出现了新的挑战。例如，您必须:

本节介绍了Google在处理这些问题时采用的许多做法。根据您组织的具体情况，一些或许多也可能为您工作。

任务控制

Google的Mission Control计划使来自产品开发团队的工程师有机会在SRE团队中度过六个月的时间。我们通常将这些工程师与SRE团队相匹配，他们的工作范围与他们的专业知识截然不同。该软件工程师接受了生产系统和实践方面的培训，并最终为该服务上线。六个月后，一些工程师决定留在SRE。其他人则回到他们的旧团队，对生产环境和SRE实践有了更好的理解。SRE团队可以从其他工程资源中受益，并且可以深入了解培训材料和文档中的差距和不准确性。

SRE交换

Google的SRE Exchange计划允许SRE与其他SRE团队一起工作一个星期。来访的SRE观察宿主团队的工作方式，并分享其归属团队的实践，这可能对宿主团队有用。在交流结束时，来访的SRE编写了旅行报告，描述了他们的星期，观察结果以及对两个团队的建议。该计划对Google很有用，因为我们的SRE团队非常专业。

培训

培训对于SRE操作系统的能力至关重要。尽管大多数都是以团队形式提供的(请参阅第8章第150页的”培训路线图”)，但请考虑为所有SRE建立标准的培训课程。在Google，所有新的SRE都会参加SRE EDU，这是一个为期一周的沉浸式培训，其中介绍了几乎所有SRE都可以使用的关键概念，工具和平台。这提供了所有新SRE的基础知识水平，并简化了特定于团队和特定于服务的培训目标。几个月后，SRE EDU团队还将举办第二系列的课程，涵盖了我们用于管理重大事件的通用工具和流程。我们的绩效管理流程特别认可促进培训的SRE。

横向项目

由于SRE团队与一组服务紧密结合，因此团队倾向于构建专有的解决方案以应对他们所遇到的挑战-例如，监控，软件推广和配置工具。这可能导致团队之间的工作大量重复。虽然允许多种解决方案竞争”市场”有价值，但在某些时候，融合到以下标准解决方案是有意义的:

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

SRE移动性

Google尽最大努力确保工程师积极参与他们各自的团队。为此，我们确保SRE能够(并且能够知道)在团队之间转移。假设没有性能问题，SRE可以自由转移到其他开放招聘的SRE团队。还通过了我们的软件工程师职位招聘标准的SRE可自由转移到产品开发团队(请参阅http://bit.ly/2xyQ4aD)。

出于多种原因，这种移动性对于个人和团队而言非常健康:

此策略还具有使您的SRE经理专注于健康快乐的服务和团队的副作用。

旅行

除了维持地理位置分散的团队健康所需的差旅费用外(请参阅”财务:”旅行预算”(第417页)，请考虑为以下项目提供资金:

启动协调工程团队

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

卓越生产

随着组织中SRE团队数量的增长，将会出现许多最佳实践。每个SRE团队的发展都不同，因此评估他们需要高级SRE并具有对多个团队的洞察力。

在Google，我们会进行定期的服务审核，称为”卓越生产”。SRE高级领导者会定期审查每个SRE团队，并根据许多标准措施(例如，值班负载，错误预算使用，项目完成，错误关闭率)对他们进行评估。审查既赞扬了出色的表现，又为表现欠佳的团队提供了建议。

经验丰富的SRE可以评估细微的场景。例如，要弄清由于团队合并或团队分裂而造成的项目完成率下降与真正的团队绩效问题相比可能具有挑战性。如果团队有不堪重负的风险，那么审阅者可以并且应该利用其组织地位来支持团队的领导者来纠正这种情况。

SRE资金和招聘

在Google，我们采用两种做法来确保每个SRE都贡献可观的价值:

简而言之，您的SRE应该少于组织想要的数量，并且只有足够的SRE才能完成其专门工作。

在Google，产品开发团队中SRE与工程师的比例从大约1:5(例如，底层基础设施服务)到大约1:50(例如，具有大量使用标准框架构建的面向消费者的应用程序)。许多服务以大约1:10的比率处于此范围的中间。

结论

我们认为，任何规模的组织都可以通过应用以下三个原则来实施SRE实践:

自Google开始公开谈论SRE以来，它已从Google特定的生产实践发展为许多公司所从事的职业。这些原则通常被证明是正确的-在我们多年的大规模直接经验中，以及在我们最近与客户合作采用SRE做法的经验中。因为我们已经看到这些做法在Google内部和外部都可以使用，所以我们认为这些建议对于各种类型和规模的组织都非常有用。



  1. 布鲁斯·塔克曼(Bruce W. Tuckman)，”小组中的发展顺序”，《心理公报》 * 63，第1期。 6(1965): 384–99。 ↩

  2. Shylaja Nukala和Vivek Rau，”为什么SRE文件很重要”，* ACM队列*(2018年5月至6月): 即将出版。 ↩