Skip to content

Latest commit

 

History

History
718 lines (376 loc) · 39.6 KB

8-4_第20章-SRE团队生命周期.md

File metadata and controls

718 lines (376 loc) · 39.6 KB
Raw

第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实践的关键步骤:

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

-w100 原则 ＃2

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

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

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

  • 改进监控，以便在出现问题时可以更好地了解系统。

  • 处理最近事后总结中确定的任何高优先级操作(请参阅第10章)。

  • 实施自动化以减少运行服务所需的特定琐事。

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

  • 他们的工作混合与其他工程工作没有区别。

  • 如果您的第一个SRE在产品开发团队中，则他们所做的工作远远超出了其公平的运维工作份额，或者他们是唯一进行服务配置更改的人。

  • SLO并没有受到重视，SRE在衡量和捍卫客户体验方面也没有取得进展。

分布式SRE

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

您的第一个SRE团队

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

  • 在重大项目中创建新团队

  • 建立横向SRE团队

  • 转换现有团队(例如，运维团队)

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

-w100 原则 ＃3

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

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

组建

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

  • 更改应用程序软件以提高可靠性和性能。

  • 编写软件至:

    --- 加快发现和缓解生产中的问题。

    --- 自动执行手动过程。

  • 建立并使用强大的软件实践和标准来促进长期可维护性。

  • 采取有条理和谨慎的方法进行业务变更:能够描述为什么某些做法可靠的原因。

  • 了解系统架构(分布式系统设计和操作)。

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

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

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

组建水平的SRE团队

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

将团队转换到位

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

震荡期

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

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

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

风险和缓解措施

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

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

风险

团队:

  • 一次承担太多服务的责任，使自己的业务分散。

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

  • 过于内省地试图理解SRE原理以及如何实现它们。结果，它的交付不足。

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

  • 没有彻底检查其工作。结果，服务管理恢复为以前的行为。

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

  • 放弃SRE原则和实践以达到产品里程碑。

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

  • 由于与现有团队的冲突而分心，他们认为新的SRE团队会失去影响力或力量。
  • 没有必要的技能范围，因此只能提供部分必要的改进。

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

缓解措施

团队:

  • 最初从事一项重要服务。
  • 尽早参与项目，最好是在设计阶段。
  • 参与设计，特别侧重于定义SLO和分析设计固有的可靠性风险。
  • 与产品开发团队合作，致力于特定于可靠性的功能以及与现有运维平台的集成。
  • 预计第一天不承担运维责任。相反，此责任最初由产品开发团队或项目团队负责。这可能是重大的文化变革，需要管理层的支持。
  • 在SRE启用服务之前必须达成明确的协议(请参阅Site Reliability Engineering的第32章)。

另外:

  • 如果项目涉及迁移，则团队应该对当前和将来的环境有深入的了解。如果您需要从外部招聘团队成员，请考虑具有软件工程和未来环境知识的候选人。
  • 继续将新员工人数保持在不到团队的三分之一，以使培训工作不会淹没现有团队成员。

横向SRE团队

风险

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

缓解措施

团队:

  • 拥有具有相关主题专业知识的受人尊敬的工程师。
  • 进行专注于交付工具(用于监控，警报，部署，最佳实践，清单)的项目工作。这些工具应至少对另外两个团队产生短期的有益影响。
  • 交流成功和利益。应该赞扬一个SRE团队，该团队实现了效率突破，自动完成琐事或永久消除了系统不可靠性的根源。
  • 将自己视为推动者，而不是看门人。关注解决方案，而不仅仅是问题。

一支已转换的团队

风险

团队:

  • 意识到随着自动化取代人类，转换过程是缓慢失业的开始。
  • 不支持到SRE团队的变更。
  • 没有平衡的人力来改变团队的日常活动。
  • 几个月后，他们的日常工作没有任何好处。
  • 运维不支持脚本或自动化的系统。
  • 没有软件工程技能来自动化他们当前的工作量。
  • 并非一贯具有发展至SRE所需的技能，或对获得技能的兴趣。

缓解措施

团队:

  • 获得高层领导对变更的支持。
  • 重新协商责任以创造实现变更所需的人力。
  • 非常仔细地管理变更的沟通。
  • 在整个过渡过程中都能获得强大的个人和技术支持。
  • 应对失业问题。在许多环境中，自动化消除了部分工作，但不是整个工作。尽管这可能是迈向失业的一步，但它的确至少可以腾出时间来做比非自动劳动更好的事情(并且对未来的雇主更容易销售)。
  • 可以避免操作过载并产生更大的影响。如果工程师减少了琐事的工作量而需要一个较小的团队，那么他们的经验应该可以在组织中的其他地方高度复用。如果他们的经验不能在内部使用，则应该在其他地方找工作提供优势。
  • 接受培训以获取SRE所需的技能。您的产品开发团队可以提供产品培训，而SRE指导可以利用本书和其他外部资源。
  • 更改绩效评估方式-评估团队和个人的指标。前者应与SLO保持一致，并采用其他SRE做法；后者应与SRE技能的证据保持一致。
  • 将经验丰富的SRE或开发人员添加到团队中。
  • 可以自由(预算或时间)识别并引入新的开源或基于云的监控和警报系统以实现自动化。确定现有系统是否足够应该是当务之急。
  • 定期在内部并与利益相关者一起审查进度。

规范化

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

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

  • 已制定SLO和错误预算，并在发生重大事件后执行错误预算政策。领导层对SLO度量很感兴趣。

  • 值班轮换是可持续的(请参阅第8章)。值班工程师的通话时间得到补偿。有足够的工具，文档2和培训可在重要工单工作中为任何团队成员提供支持。

  • 琐事要被记录，有边界和被管理。结果，SRE完成了具有影响力的项目，从而提高了可靠性和效率。

  • 事后总结文化已经建立。(请参阅第10章。)

  • 该小组展示了第1章中列出的大多数原则。

  • 当团队解决第405页"存储"中列出的初始问题时，他们会捕获所学内容并防止重复出现问题。该团队定期进行培训练习，例如不幸之轮或DiRT(灾难恢复测试)。(有关呼叫培训的更多信息，请参见第一本书的第11章和本书的第18章。)

  • 产品开发团队将从继续参与值班轮换中受益。

  • 团队为利益相关者生成定期报告(例如，季度报告)，涵盖报告期间的重点，不足之处和关键指标。

将现有团队转变为SRE团队

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

当《纽约时报》成立其交付和站点可靠性工程部门时，我们由具有SRE类型技能的工程师组建了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团队选择是否以及何时启用服务(请参阅Site Reliability Engineering的第32章)。

  • 如果出现运营超负荷的情况，团队可以通过以下方式减少工作量:

    --- 降低SLO

    --- 将运维工作转移到另一个团队(例如，产品开发团队)

  • 如果在商定的劳力约束内无法在SLO上操作服务，则SRE团队可以将服务移交给产品开发团队。

  • SRE参与不是永久的-它通过大规模解决问题并提高服务的可靠性来满足自己。如果SRE团队为服务解决了所有此类问题，则您需要:

    --- 有目的地考虑SRE团队需要解决的其他可靠性挑战。

    --- 做出有意的决定，将服务移交给产品开发团队。

    否则，随着SRE转向更多有趣的机会，您的团队将面临人员流失的风险。摩擦造成的缓慢流失可能使生产面临风险。

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

  • 如果服务不符合其SLO，请停止与功能相关的项目工作，而转而关注可靠性的项目工作。

  • 如果在商定的琐事约束内无法在SLO上运维服务，请减少您的SLO，除非管理人员提供更多的能力(人员或基础架构)来处理这种情况。

组成更多SRE团队

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

服务复杂度

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

SRE推广

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

按地理位置划分

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

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

  • 阅读其他团队成立后写的任何事后总结报告。识别并重复进行得很好的事情，并针对不顺利的事情进行修复和探索。

  • 从现有团队中为SRE注入新团队-可能会挑战的一些最佳SRE和潜力最大的SRE。根据我们的经验，很难找到合格的SRE候选人，因此快速发展新员工团队通常是不现实的。

  • 标准化建立团队和入职服务的框架(请参阅第18章)。

  • 缓慢更改值班职责。例如:

    --- 为了避免突然失去熟练的值班工程师，请在过渡期内让团队成员在其先前团队的系统中处于值班状态。

    --- 团队分割后，请等待三至六个月以分割值班轮换。

服务复杂度

哪里拆分

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

基础设施分离

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

语言拆分

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

位置拆分

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

陷阱

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

  • 指定一个小组负责第二小组章程未涵盖的所有事务。

  • 在两个团队中任命高级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")不会成为夜班，而该夜班与产品开发团队的联系很少，所付出的辛苦超过其应有的工作份额，或者仅分配给那些不太有趣或影响较小的项目。这两个办公室的工作量会有一些自然的差异:

  • 您的服务可能每天都有高峰，在该高峰期间将有一个办公室待命。结果，两个站点的值班体验将有所不同。

  • 您的开发过程将产生具有特定节奏的新版本。一个办公室可能会承担与部署和回滚相关的更多负担。

  • Office 1更可能在工作日被产品开发团队的问题打扰。

  • Office 1更容易进行与主要版本相关的项目工作。相反，Office 2更容易进行与近期产品目标分离的项目工作。

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

  • 平衡办公室之间的值班负载。指定故障单百分比较高的办公室承接更低比例的呼叫数。

  • 将开发区域与特定办公室中的SRE团队相关联。这可以是短期的(例如，根据项目)或长期的(例如，根据服务)。否则，产品开发团队可能会依靠Office 1，而不能有效地与Office 2中的SRE接触。

  • 将较高比例的内部服务改进项目(可能需要较少的产品开发团队参与)分配给Office 2。

  • 在两个办公室之间公平地传播最有趣，最有影响力的项目。

  • 在两个办公室之间保持相似的团队规模和资历组合。

  • 在两个站点之间划分项目，以故意促进SRE之间的部门间交互。虽然从一个办公室运行一个主要项目可能会提高效率，但将项目分布在两个站点之间既有助于传播知识，也可以在办公室之间建立信任。

  • 允许工程师定期前往其他办公室。这样可以建立更好的融洽关系，并因此愿意为另一方做好工作。

布局:三班倒怎么办？

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

  • 不可能召开所有SRE都能参加的部门间生产会议(请参阅第一本书的第31章)。

  • 很难确保三个办公室之间知识，能力和运维响应的均等。

  • 如果所有的值班职责仅在办公时间内进行，则没有动力去激励低层次的工作和低价值的呼叫。在办公时间内，成为解决简单问题的英雄很有趣。但是，如果它有一定的个人成本，那么确保它不再发生的动机是敏锐而直接的。

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

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

  • 两个半部同时开始。

  • 首先设置与产品开发团队位于同一地点的站点。这使SRE可以更早地参与产品生命周期。

  • 首先设置与产品开发团队不在同一地点的站点，或者，如果某项服务已经投入生产已有一段时间，则SRE团队和产品开发团队可以共享值班。

  • 根据合适的人在正确的时间开始进行更改。

经费:差旅预算

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

  • 站点1中的每个SRE，产品开发经理和技术主管每年(至少)每年访问站点2，反之亦然。

  • 在站点1中担任管理或技术领导角色的每个SRE每年至少两次访问站点2，反之亦然。

  • 所有SRE每年至少召开一次会议。

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

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

  • 讨论团队面临的挑战的解决方案。

  • 解决意见分歧，并商定共同前进的道路。

  • 代表彼此的团队提倡(以防止"我们与他们对抗"的心态)。

  • 支持彼此团队的健康。

建议管理多个团队的做法

随着您的组织积累更多的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可以在要求更少的值班职责的团队中探索机会。他们可以通过与其他团队交谈并查看团队的值班统计信息来获取此信息。

  • 在团队之间移动的SRE扩大了他们加入的团队的经验。

  • 在办公室之间移动的SRE帮助建立或保持不同办公室之间的文化一致性。

  • SRE不会被迫从事不健康的服务或为不支持个人发展的经理而工作。

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

旅行

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

  • 建立内部感兴趣的公司社区，其中包括来自多个办事处的SRE。这些小组可以通过电子邮件和视频会议进行大量合作，但至少每年进行一次面对面的会面。

  • 参加并参加全行业的SRE和SRE相关会议，以扩大知识，了解其他组织如何解决类似问题，并希望受到鼓舞和激发活力。

启动协调工程团队

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

卓越生产

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

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

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

SRE资金和招聘

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

  • SRE的大部分资金与产品开发团队的资金来自同一来源。类似于测试或安全性，可靠性是产品开发的核心支柱，并为此提供资金。

  • 根据我们的经验，SRE的供应数量总是小于对它们的需求。这种动态机制确保我们定期审查获得SRE支持的服务并确定其优先级。

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

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

结论

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

  • SRE需要具有结果的SLO。

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

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

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



Footnotes

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

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