第十八章 SRE：参与模式

我们的第一本书的第32章，描述了SRE团队分析和提高服务可靠性的技术和方法。其中包括：生产成熟度评审（PRR）、早期参与和持续改进。

简而言之，SRE的目标是在保证产品可靠性的前提下，最大限度的提高开发团队的项目进度。这对用户和公司而言都是有益的。但是，即使最好的SRE团队所能完成的工作也是有限的，并且当范围太大且过于复杂时，SRE模型就不那么的有效了。当前，小公司拥有微服务的个数通常比单个SRE团队能处理的要多。鉴于生产环境较大，并且无法涵盖所有服务，SRE团队必须将注意力集中在能够获得最佳效果的地方。产品开发和SRE团队可以一起确定正确的关注目标。

本章采用某SRE团队的视角，该团队准备为新服务提供支持。我们着眼于如何与负责该服务的开发和产品团队一起有效地提供服务。虽然SRE通常“参与”一个或多个服务，但“参与”所涉及的内容远不止服务本身——它侧重于理解开发和产品团队的目标，并找到支持他们的正确方法。

以下的大多数讨论适用各种组织规模。虽然我们经常使用团队这个词，但理论上“团队”也可以从单人开始（尽管会很忙）。无论团队规模如何，主动定义SRE的角色以及管理与产品开发的沟通和协作十分重要。

服务生命周期

正如《Google SRE运维解密》的前言所述，SRE团队对服务可靠性的贡献贯穿于服务生命周期的所有阶段。在任何SRE为服务提供on-call之前，他们对于生产知识和经验的应用，都可以大大提高服务的可靠性。

图18-1显示了服务生命周期中SRE参与的理想情况。但是，SRE团队可能在服务生命周期的任何阶段参与服务。例如，如果开发团队计划将SRE所支持的服务进行替换，则SRE可能很早就会参与新服务。又或者，服务可用数月或数年，且现在面临可靠性或可伸缩性的挑战时，SRE团队可能会正式参与该服务。本节提供有关SRE团队如何在每个阶段实现自身价值的方针。

图18-1: 服务生命周期中SRE的参与程度

阶段1：架构和设计

SRE可以以多种方式影响软件系统的体系结构和设计：

提供开发团队在构建新产品时可以采用的最佳实践，例如单点故障自我恢复的能力。
(基于经验）记录特定基础设施系统的注意事项，以便开发人员可以正确的选择并使用构建模块，避免已知陷阱。
参与前期讨论，详细讨论具体架构和设计选择，并在目标原型的帮助下验证假设。
加入开发团队参与开发工作。
协调部分服务。

到了开发周期的后期，是很难修复由架构选型导致的错误的。SRE在早期参与有助于避免在系统与实际用户交互时需要进行高成本的重新设计，或根据服务增长进行扩展。

阶段2：积极发展

随着产品在积极开发过程中完成，SRE便可以开始“生产化”服务——使其成型并投入生产。生产化通常包括容量规划，为冗余设置额外资源，规划尖峰和过载处理，实施负载均衡，以及实施可持续运维实践，如监控，报警和性能调优。

阶段3：有限的可用性

随着服务向Beta发展，用户数量，用例的多样性，使用强度以及可用性和性能需求都会增加。在此阶段，SRE可以帮助衡量和评估可靠性。我们建议在常见可用性（GA）之前先定义SLO，以便服务团队客观的衡量服务的可靠性。产品团队可以选择撤回无法达到目标可靠性的产品。

在此阶段，SRE团队还可以通过构建容量模型，为即将到来的启动阶段获取资源以及自动化调整和弹性调整扩展系统。SRE需要确保合适的监控范围，帮助即将到来的的服务创建与其SLO相匹配的报警配置。

服务使用情况一直在变化，且SRE团队仍需要了解服务如何工作以及如何管理其故障模式，所以团队在事件响应和运维操作期间的工作量仍是增加的。我们建议开发人员和SRE团队能共同承担此项工作。这样，开发团队就可以获得服务的运维操作经验，且SRE可以获得常见的服务经验。运维工作和事件管理将在GA之前告知系统变更并发布服务所有者需要进行的变更。

第4阶段：一般可用性

在此阶段，该服务已通过生产准备审核（详细信息请参阅《Google SRE运维解密》中的第32章），并被所有用户接受。虽然SRE通常执行大部分的操作工作，但为了保险起见，开发人员团队需要继续完成所有操作和事件响应工作的小部分内容。可以在on-call轮值中安排一名开发人员，帮助开发人员持续跟踪业务负载。

在GA的早期阶段，由于开发人员专注于服务的成熟以及发布第一批新功能，因此需要进行轮值来了解实际负载下的系统属性。在GA的后期阶段，开发人员主要提供小的新增功能以及一些bug修复，其中的一些功能和bug恢复需求来源于操作需求和已发生的生产事件。

第5阶段：弃用

没有系统能一直运行。如果有更好的替代系统，那么现有系统将对新用户关闭，所有工作都侧重于将用户从现有系统转换到新系统中。在没有开发团队参与的情况下，SRE将运维现有系统，并支持开发和运维工作的过渡。

虽然减少了现有系统所需的SRE工作量，但SRE实际上是同时支持两个完整系统，所以需要适当调整人员以及人员配置。

第6阶段：被遗弃

一旦服务被遗弃，通常，开发团队将接手运维工作。在此过程中，SRE会尽力提供支持。对于具有内部用户的服务，SRE将服务管理权限移交给这些用户。本章提供了两个案例研究，说明SRE如何将服务归还给开发团队。

第7阶段：停止支持

没有用户且服务已关闭时。SRE会帮助删除生产配置和文档中引用服务的部分。

建立联系

服务不是凭空存在的：需要SRE团队与构建服务的开发团队以及确定发展方向的产品团队合作。本节介绍了与这些团队建立和维持良好工作关系的方法和策略。

交流业务和生产优先事项

你在帮助别人之前肯定需要了解其需求。同理，SRE也需要了解产品开发人员期望SRE参与实现的目标。在与开发团队合作时，SRE应深入了解产品和业务目标，了解自身角色以及如何参与帮助开发人员实现这些目标。

团队需要定期就业务和生产优先事项进行沟通。理想情况下，SRE和开发领导团队应该作为一个整体进行工作，定期开会交流技术和优先级问题。SRE领导甚至可以加入产品开发领导团队。

识别风险

由于SRE团队专注于系统可靠性，能很好的识别潜在风险。由于中断开发的成本和功能流对产品和工程师很重要，因此要尽可能准确的衡量这些风险的可能性和潜在影响。

目标一致

开发人员和SRE团队都很关注可靠性、可用性、性能、可扩展性、效率、功能和发布速度。然而，SRE的主要目标和动力是为了支持服务在新功能发布后的长期可靠性。

根据我们的经验，开发人员和SRE团队既可以通过维护自身团队的目标来达到平衡，也可以通过支持对方团队的目标实现平衡。SRE可以设立明确的目标来支持开发团队的发布上线，并确保所有已审批通过的版本上线成功。例如，SRE可能会表明：“我们将尽可能快的支持你安全发布上线”，其中“安全”通常意味着保持在错误预算范围内。开发人员应该投入一定的时间去修复或预防一些有损可靠性的事情上：解决设计和实施层面的在线服务问题，解决遗留技术问题，尽早在新功能开发时让SRE参与设计。

共同目标：纽约时报的SRE

作者：Surya Prashanth Sanagavarapu (New York Times)

当涉及到云迁移，生产过渡期或向容器部署应用时，我们对SRE资源的需求会很大。此外，SRE团队还有自身积压的工作要解决。面对有限的资源，SRE团队的成功在于合理的安排互不兼容的事务的优先级。虽然雇佣SRE是解决SRE时间需求的一种方式，但并非每个团队都有额外的成本、足够的经验或时间。

“纽约时报”SRE职能的核心使命是为产品开发团队提供工具和流程,最大程度的支持新闻编辑室的应用的可靠性和弹性，从而为读者提供高质量的新闻报道。我们采用了共享目标模型，在减少自身工作积压和团队合作之间获取平衡。

在与团队合作之前，我们会审核当前季度/年度的总体积压，明确定义工作项目和类别。例如，我们的待办事项可能包括：

通过点击应用的服务状态按钮，添加自动化设置基础监控和报警。

实施更可靠和/或更快的构建管道。

当有团队向SRE寻求帮助时，我们确定请求优先级时考虑的因素之一是参与进去是否有助于减少我们的工作积压。

定义参与度

我们的SRE根据两种不同的模型与产品开发团队合作：

全职模型

相对简短和受限制项目的兼职模型

我们根据SRE团队的参与度定义参与模型。对于全职参与，我们更愿意将SRE嵌入产品开发团队，这样有助于提供时间和精力来减轻产品开发团队的负担。随着开发人员SRE技能和能力提高的同时，SRE和产品团队有更多的时间来了解彼此。对于长期合作，我们优先考虑最适合我们公司战略的应用

在定义参与范围时，我们尝试衡量团队或应用与SRE实践相关的成熟度。我们发现，在考虑SRE实践和原则时，每个团队处于不同的水平。我们正努力使用应用成熟度模型来提供帮助。

设定共同的目标和期望

对于任务的最后期限和完成度而言设定正确的目标十分重要。为此，我们按照以下原则工作：

我们强调，应用所有者（非SRE）直接负责对应用进行更改。

SRE参与是为了公司范围的利益。任何新的自动化或工具都应该同时改进整个公司使用的常用工具和自动化，避免一次性的脚本开发。

SRE应该让开发人员团队提前了解可能会引入的新流程（例如，负载测试）。

参与应用准备评审（ARR）和生产就绪程度评审（PRR），如《Google SRE运维解密》第32章所述。ARR和PRR的拟议变更必须优先由开发人员和SRE共同考虑。

SRE不是传统的运维工程师。他们不支持手动工作，例如运行部署作业。

我们会与开发团队一起明确目标，并将目标划分为一个个里程碑。如果你是一家基于敏捷开发的公司，你可以撰写描述或综述。SRE团队可以将这些目标映射到他们的待办事项中。

设定目标时我们的共同模式是：

确定参与范围。
示例1：在下一季度，我希望团队的所有成员都能够处理GKE/GAE部署，熟悉生产环境，并能够处理生产故障。
示例2：在下一季度，我希望SRE与开发团队合作，在扩展和监控方面保证应用稳定性，针对故障有运行手册和自动化任务。

确定并明确标出最终结果成功案例。
示例：参与后，产品开发团队可以在不升级的情况下处理Google Kubernetes Engine的服务故障。

冲刺和沟通

任何与产品开发团队的合作都始于发布和计划会议。在发布之前，我们的SRE团队会审核应用架构和我们的共同目标，验证在给定时间范围内预期结果是否切合实际。相互参与可以从创建描述和综述的联合计划会议开始。

这种参与的流程可能是：

查看应用架构。

定义共享目标。

举行启动和计划会议。

进入开发周期以达到里程碑。

进行回顾来获得参与方的反馈。

进行生产就绪程度评审。

进入开发周期以达到里程碑。

计划、执行发布。

我们要求团队定义反馈方法并就反馈频率达成一致。SRE和开发团队都需要有关工作和非工作的反馈。为了让这一举措获得成功，我们发现通过协商提供持续的循环反馈是有效的——例如，每两周一次进行审查或与团队经理确认。如果相互参与不起作用，我们也不希望团队回避并减少接触。

衡量影响力

为了确保SRE从事高价值的工作，对SRE参与工作的影响力进行衡量十分重要。为了方便SRE确定最有效的方法，我们还衡量每个合作团队的成熟度级别。我们与Google客户可靠性团队（CRE）团队合作，并在开始参与之前与产品工程团队的负责人进行时间点评估。

时间点评估包括遍历成熟度矩阵，衡量服务的成熟度，依据SRE关注的各个方面开展（如《Google SRE运维解密》第32章所述），并就功能区域的各个方面达成一致，如可观察性、容量规划、变更管理和事件响应处理。在进一步了解团队的优劣和盲点之后，有助于更好的确定SRE参与度。

在SRE完成工作且开发团队可以自行发布之后，我们会再次评估衡量SRE参与的价值。如果我们有一个成熟度模型，我们会根据模型进行衡量，看看参与度是否会带来更高的成熟度。

设定基本规则

在Google，每个SRE团队都有两个主要目标：

短期
通过提供可用、可按需扩展、操作稳定的系统来满足产品的业务需求，立足于系统的可维护性。 长期
将服务的运维操作优化到不需要持续人工投入的水平，这样SRE团队可以继续开展下一个高价值的工作。

为此，各小组就某些合作原则达成一致，例如：

业务工作的定义（和硬性限制）。
通过商定和衡量服务SLO来明确开发人员和SRE团队工程工作的优先级。你可以在没有SLO的情况下工作，但我们的经验，项目开始时还未确定SLO及工作优先级意味着在后面的工作中将回溯到此步骤。有关如何在没有SLO的情况下理想地进行工程工作，请参阅第427页的“案例研究1：将Waze从AdHoc扩展到计划变更”。
商定季度错误预算，确定发布速度和其他安全系数，例如处理意外使用增长的超额服务容量。
为确保持续存在的问题得到关注并确定修复根本原因的优先级，开发人员需要参与日常运维中。

计划与执行

为确保SRE团队在优化和降低运维成本的同时达到预期和产品目标，需要主动规划和协调执行。我们建议在两个（相邻）阶段进行规划：

在开发人员的领导下，确定产品和服务的优先级，并发布年度企划图。
定期审查和更新路线图，并得出与路线图一致的目标（季度或其他）。

路线图确保每个团队拥有清晰、高效工作的长期时间线。可能会有充分的理由（例如，开发组织变化太快）来放弃路线图。但在稳定的环境下，缺乏路线图可能是SRE团队与其他团队合并，将服务管理工作移交回开发团队，甚至是解散的信号。

与开发领导层保持持续的战略对话有助于快速确定工作重点，讨论SRE为业务增加价值的新机会，或停止对产品而言没有成本效益的工作。

路线图可以专注于改进产品，还可以解决如何应用和改进常见的SRE技术和流程以降低运维成本。

保持持续有效的关系

健康有效的关系需要不断的努力，本节简述了对我们而言效果非常好的策略。

投入时间共同努力

投入时间相互协作这种简单的行为有助于SRE和开发人员更有效的协作。我们建议SRE定期与开发人员当面沟通确保其运维的服务稳定性。SRE还可以定期与其他SRE团队沟通，这些团队运维的服务可以向本团队负责的服务提供流量或提供服务使用的通用基础架构。因为团队已经彼此了解并且设定了如何启动和管理升级的期望目标，这样，在故障或意见分歧期间，SRE团队可以自信且迅速的升级事件。

保持开放的沟通渠道

除了之前提到的团队日常沟通之外，我们还发现了一些更加正式的信息交换方法，这些方法在参与过程中十分有效。

SRE可以与产品领导进行季度“生产状态”谈话，帮助他们了解应该在何处投入资源以及SRE如何帮助他的产品或服务。类似的，开发人员可以定期向SRE团队提供“产品状态”，或者让SRE参与开发团队的执行演示。向SRE团队概述了开发团队在上季度所取得的成就（并让SRE了解他们自己的工作要如何实现）。还提供了产品未来几个季度的最新信息，以及让产品负责人了解SRE在哪些方面发挥了作用。

定期执行服务评估

作为服务的未来决策者，SRE和负责该服务的开发团队每年至少应该见面一次。也许很难更频繁的开会-例如，可能涉及洲际旅行。在会议期间，我们通常会分享未来12-18个月的路线图，并讨论新项目和发布会。 SRE团队有时会进行回顾讨论团队想要停止做什么，继续做什么以及开始做什么。项目可以出现在多个区域且这些意见都是有效的。最好的结果通常是全团队都参与的，所以需要积极促进这些会议。这些会议产生的细节可以推动重大的服务变更，因而被评为服务会议中最有用的会议。

当规则开始变化时要重新评估

如果之前协商的部分（参见379页的“设置基本规则”）开始回滚，开发人员和SRE都需要更改优先级以使服务恢复正常。我们发现，根据紧急程度，意味着可能发生以下任何一种情况：

团队指定的工程师必须放弃低优先级任务，专注于回滚。
两个团队都号称“可靠性黑客马拉松”，但通常团队的优先级是在黑客马拉松之上的。
停止功能开发，两个团队的多数成员都专注于解决回滚问题。
技术领导层确定产品的可靠性存在严重风险，团队要“全力以赴”的响应。

根据你的SLO和错误预算调整优先级

指定明确的SLO有助于团队安排工作优先级。如果服务存在丢失SLO或存在用完错误预算的风险，那么两个团队的高优先级工作应该是使服务恢复安全。他们可以通过战术措施（例如，超额配置以解决与流量相关的性能回滚）和更具战略性的软件修复（例如优化，缓存和优雅降级）来降级此类情况。如果服务在SLO内且剩余错误预算充足，我们建议使用备用错误预算来提高功能迭代速度，而不是在服务改进上花费过多的精力。

妥善处理错误

人总会犯错。和我们的事后文化一致，我们不会责怪某个人，而是专注于系统行为。你的情况可能和我们不一样，但以下策略也可以作为参考。

三思而后行

如果可能，请勿在疲惫或情绪高涨时进行后续对话。在高压力时，人们很容易误解书面交流如电子邮件中的语气。读者会记住这些词语让他们产生何种感受的，当你在异地进行通信时，通常应该进行视频聊天，这样你可以看面部表情，听到的词语语调也可以帮忙消除原本可能产生的歧义。

当面（或尽可能近的）解决问题

仅通过代码审查或文档交互很难让人集中注意力。当另一个团队的行为或决定与我们预期的不一致时，我们会和他们讨论并询问为何没有达到预期。

要乐观

要感谢别人积极主动的行为。做起来可能很简单-例如，在代码审查，设计审查和故障场景培训期间，我们要求工程师介绍出彩的内容。你可能注意到优秀的代码注释或感谢人们愿意花时间投入设计审核。

了解沟通的差异

不同的团队对如何传播信息有不同的预期，了解这些差异有助于加强团队的关系。

将SRE扩展到更大的环境

目前为止，我们讨论的场景涉及一个SRE团队，一个开发团队和一个服务。较大的公司，甚至是使用微服务模型的小公司，可能需要扩展部分或全部团队规模。

单个SRE团队支持多项服务

由于SRE需要专业技能并且是稀缺资源，因此Google通常将SRE与开发人员的比率保持在<10%。因此，一个SRE团队通常与其产品领域（PA）中的多个开发团队合作。

如果SRE的数量不足以支持需要面对的服务数，是，那么SRE团队可以将精力集中到一项服务，或者集中在开发人员较少的一些服务上。

根据我们的经验，如果这些服务具有以下特征，你可以将有限的SRE资源应用到多个服务中：

服务是单一产品的一部分。提供了用户体验的端到端所有权以及与用户的一致性。
服务建立在相似的技术栈上。可以最大限度的减少认知负担，有效的重用技术技能。
服务由同一开发团队或少数相关开发团队构建。这样可以最大限度的减少关联数量，便于商定优先级。

构建多个SRE团队环境

如果你的公司足够大，拥有多个SRE团队，或许还有多个产品，那么你需要选择SRE和产品组相关联的合适的架构。

在Google，我们支持复杂的开发人员组织。如图18-2所示，每个PA由多个产品组组成，每个产品组包含多个产品。SRE组织以层次结构的方式影响开发人员组织，每个级别都有共享的优先级和最佳实践。当一个组中的所有团队或PA中的所有组都共享相同或相似的特定业务目标，且每个产品组都有产品领导和SRE领导时，这个模型都是有效的。

图18-2. 大规模的开发者与SRE团队关系图（每个产品领域）

如果你的组织有多个SRE团队，你需要以某种方式对其进行分组。我们发现有两种主要的分组方式：

将团队分组到产品中，这样他们就不必与太多不同的开发团队协调。
将团队分组到技术栈中（例如，“存储”或“网络”）。

为了防止在开发人员重新开发的期间SRE团队的流失，我们建议根据技术而不是开发人员PA报告架构来组织SRE团队。例如，许多支持存储系统的团队都以相同的方式构建和运行。即使是来自开发组织的不同部分，将技术型产品组中的存储系统分组可能会更有意义。

使SRE团队结构适应不断变化的环境

如果你需要调整SRE团队的结构来响应不断变化的PA需求，那么我们建议你根据服务需求以及工程和运维负载来创建，拆分（切分），合并和解散SRE团队。每个SRE团队都应该有一个清晰的章程来反映他们的服务，技术和运维。当一个SRE团队拥有太多服务时，我们宁愿将现有团队分成多个团队来传递企业文化并发展现有领导层，而不是从头开始建立新的团队。类似这种的变化不可避免会对现有团队造成破坏，因此我们建议你仅在必要时对团队进行重组。

运行有凝聚力的分布式SRE团队

如果你需要确保全天候保持业务连续性，并且拥有全球性的服务，那么可以通过在全球范围内建立你的SRE团队来提供均匀覆盖。如果你拥有多个全球分布的团队，我们建议根据邻接以及服务和共享技术的相似性来协调团队。独立的团队通常效率较低，且容易受到团队外部重组的影响-我们只有在业务明确需要他们并且考虑了其他所有选项后才会建立这样的团队。

许多公司没有足够的全球覆盖资源，但即使你只是在建筑物之间分布（不考虑洲际），创建和维护两个地方的团队也是有必要的。

通过创建、维护组织标准来推动规划和执行以及培养和维护共享的团队文化十分重要。为此，可以定期让整个团队聚在一起-例如，每12-18个月举办一次全员参与的峰会。

有时，对团队的个人而言，拥有某些特定职责是没有意义的-例如，从备份中执行定期测试还原或实施跨公司技术任务。在团队分布式站点间平衡这些责任时，请记住以下策略：

将个人职责分配给单个站点，但要定期轮换（例如，每年）。
分担各站点之间的责任，积极努力的平衡参与度和工作量。
不要常年将责任锁定在某个站点。我们发现这种配置的成本最终会超过收益。虽然这个站点可以很好的履行职责，但会培养“我们与他们”的心态，有碍知识的分享，并给业务带来连续性的风险。

所有这些策略都需要站点之间维持战术和策略沟通。

关系结束

SRE参与不一定是无限期的。SRE通过有影响力的工程工作提供价值，如果工作不再具有影响力（即，SRE参与的价值消失），或者大部分工作不再在工程（或运维）层面，你可能需要重新审视当前参与的SRE。一般而言，独立的SRE团队倾向从过度辛劳的团队转变成更有趣的工程工作团队。

在团队级别，如果SRE不再提供足够的业务价值来抵偿成本的话，你可能会归还服务。例如：

如果服务已经优化到不再需要SRE持续参与的水平
服务的重要性或相关性已经降低
如果服务已达到使用寿命

以下案例研究展示了两个Google SRE参与模式的结束方式。第一个结果基本上是积极的结果，而另一个的结果则比较微妙。

案例研究1：Ares

Google的Abuse SRE和CommonAbuse Tool（CAT）团队为大多数Google产品提供了反滥用保护，并与面向客户的产品合作以确保用户安全。Abuse SRE团队应用工程工作来降低CAT的运维负担，以便开发人员能够直接支持其用户。这些用户是Google运维CAT所捍卫的资源，他们对CAT的功效及其对问题或新威胁的响应时间有着很高的预期。

有效的反滥用战斗需要保持持续的关注，能快速的适应变化，面对新的威胁和攻击时具有灵活性。通常SRE的目标是可靠性和有计划的功能开发，这些要求是与之冲突的。CAT团队通常需要快速开发并为受到攻击的资源部署新的保护措施。但是，Abuse SRE推迟了所要求的的变更，针对每个变更都要求对整个生产系统的影响进行更深入的分析。团队和审查之间协商的时间限制加剧了这种紧张局势。

为了改善这种状况，Abuse SRE和CAT领导层开展了一个持续全年度的项目，在CAT内部建立了一个专门的基础设施团队。新成立的“Ares”团队有权统一Google资源的反滥用基础设施。该团队由CAT工程师组成，他们拥有生产基础知识和构建运行大型服务的经验。团队启动了一项交换计划，将生产管理知识从Abuse SRE转移到CAT基础设施团队成员。

Abuse SRE团队告诉Ares团队，在生产中启动新服务最简单的方法（当你已经运行大型分布式服务时）是最小化服务所带来的额外认知负荷。为减少这种认知负荷，系统应尽可能是同构的。一起部署和管理生产服务集合意味着可以共享相同的发布结构，容量规划，访问存储的子服务等。根据这一建议，Ares重新设计了整个反滥用堆栈，应用模块化概念转向了微服务模型。他们还构建了一个新层，为开发人员提供抽象化，这样就不必担心监控，日志记录和存储等较低级别的生产细节。

现在，Ares团队开始管理新的反滥用基础设施，看上去更像是CAT的SRE团队。同时，Abuse SRE专注于整个反滥用基础设施的生产部署和高效的日常运维。 Ares工程师和AbuseSRE之间的协作带来了以下改进：

现在，Ares团队开始管理新的防滥用基础设施，看上去更像是CAT的SRE团队。同时，Abuse SRE专注于整个防滥用基础设施的生产部署和高效的日常运维。 Ares工程师和Abuse SRE之间的协作带来了以下改进：

由于CAT团队现在拥有“内部”生产专家，他们本身也是反滥用战斗的专家，Abuse SRE不再需要审查新的功能变更。大大缩短了新功能的开发时间。与此同时，由于新的基础设施抽象了生产管理细节，CAT团队的开发人员的开发速度也有了提高。
由于大多数请求不需要更改基础架构，因此Abuse SRE团队对CAT团队提出的新需求也少了很多。又因为基础设施很少需要更改，该团队对新功能影响的评估也比之前简单。当需要更改基础架构时，Abuse SRE只需要清楚对基础架构的影响，而不用了解具体的功能。
由于现在产品集成相当于功能发布，所以需要与反滥用基础架构集成的产品有更快更加可预测的转变时间。

在该项目结束时，Abuse SRE不再直接支持CAT，而是专注于底层基础设施。这并没有影响CAT的可靠性，也没有使CAT团队承担额外的运维工作；相反，这加快了CAT的整体发展速度。

目前，Ares通过大量Google资源来保护用户。自团队成立以来，SRE和产品开发合作一起就基础设施如何在生产中发挥作用进行决策。正是由于Ares的努力才使得这样的伙伴关系成为可能，Ares创造了一种共同的使命感。

案例研究2：数据分析通道

有时维持SRE运维关系的成本高于SRE提供的价值。这种情况下，通过解散SRE团队来结束这种关系是可行的。

注1：Google HR在这类转换中为员工提供新机会

随着时间的推移这种关系的价值在减小，但很难确定终止合作的时间点。Google的两个支持重点收入数据分析通道的团队就面临这一挑战。在经过十年的合作之后，确定分离的方法是十分重要的。回想起来，我们能够确定团队互动的几种模式，这些模式是我们需要重新考虑SRE团队和产品团队间关系的重要指标。

数据挖掘

在衰退的前三年，所有相关方都认识到他们的主要数据分析通道正在遇到扩展的限制。当时，开发团队决定规划新系统，并让少数工程师专门投入此项工作。随着此项工作的融合合并，有必要为现有系统开发大型，复杂或有风险的特性来支持新系统的工作。随着时间的推移，产生了两个重要的影响：

对新项目采用了非正式规则：如果项目的复杂度或修改现有系统以适应项目涉及到的风险太高，那么最好在新系统中进行规划。
随着资源转向开发新系统，即使对现有系统进行相对保守的变更也变得十分困难。但此时对现有系统的使用量仍在快速增加。

沟通失败

在保持现有系统正常运行的同时设计，构建，启动替换系统对任何工程团队而言都是一项挑战。压力自然的落在同时关注着新、旧系统的人，以及需要做出优先级决策的团队身上。当团队在组织结构上是分离的，这些困难可能更加复杂-例如，一个专注于维护和运维现有系统的SRE团队和一个致力于下一代系统的开发团队。

在整个周期中，为了维护和保持团队间良好的工作关系，定期，开放和合作的沟通十分重要。在这个例子中，沟通不畅导致了团队间工作关系的不和谐。

解散

花费了一段时间才意识到SRE和开发团队完全脱节是不可取的。最终，最简单的解决方案是消除组织障碍，让开发团队完全把控新旧系统的优先级工作。在旧系统完全淘汰之前，预计两个系统将同时存在18-24个月。

将SRE和产品开发功能整合到一个团队中可以使高层管理人员最大限度的响应他们的问责领域。同时，团队可以决定如何平衡运维需求和速度。虽然解散两个SRE团队并不是件愉快的事，但这样做解决了在何处投入精力的问题。

尽管开发团队不可避免会有额外的运维负担，但是重新调整旧系统的所有权给对服务更了解的人员有助于更快的解决运维问题。该团队可以更深入的了解故障的潜在原因，能更高效的排查故障和解决问题。但是，开发团队在短期内接手所支持服务的运维工作时，不可避免会产生一些负面影响。SRE团队的最后工作是尽可能的分享运维知识，帮助开发团队顺利承担这项工作。

如果工作关系更健康-团队合作可以有效的解决问题-SRE能在短期内将生产工作交付给开发团队。在系统重新稳定并强健能够满足预期的增长需求后，SRE通常会重新承担系统运维的责任。SRE和开发团队要主动直接解决问题并找出需要重置的工作内容。SRE的一部分工作是在面对不断变化的业务需求时帮助开发进行优化开发，寻找解决挑战性问题的解决方案。

结论

SRE团队参与的模式会改变服务生命周期的各个阶段。本章对每个阶段都提供了具体建议。Google和纽约时报SRE团队的例子表明，有效管理参与度和指定出色的技术设计决策同样重要。有时SRE的参与应该达到一个自然的终止点。Ares和数据分析通道团队的案例研究提供了如何实现这点的示例，以及如何很好的结束参与关系。

在谈及SRE和产品开发团队之间建立有效关系的最佳实践时，关键在于定期和开放式沟通共享目标和方向。你可以通过多种方式扩展SRE团队，但这些关系管理原则应该始终如一。为了保持SRE参与的长期成功，协调团队目标，理解彼此的目标与捍卫SLO同样重要。