当前位置：

文章详情

SRE 参与模式如何演进：从生产就绪评审 PRR 到 SRE 平台

SRE 参与：做什么、怎么做，以及为什么做

在现代软件工程和服务可靠性建设中，SRE 参与模式决定了一个服务能否更早、更系统地满足生产环境要求。本文将围绕 SRE 参与、生产就绪评审（Production Readiness Review，PRR）、早期参与模型以及 SRE 平台化实践，讨论服务可靠性如何从后期补救逐步走向前期设计。

本书其余部分主要讨论的是：当 SRE 团队已经负责某项服务时，会发生什么。然而，很少有服务在生命周期一开始就能获得 SRE 支持。因此，我们需要一套流程来评估服务，判断它是否值得由 SRE 支持；协商如何改进那些会妨碍 SRE 支持的问题；并最终完成 SRE 支持的引入。我们将这一流程称为“接入”。

如果你所在的环境中已有大量服务，而且这些服务的成熟度参差不齐，那么 SRE 团队很可能需要花费相当长的时间，按照优先级逐一推进接入工作，直到所有高价值目标都完成接入。

这种做法很常见，也是处理既有系统的一种合理方式。但在实践中，至少还有两种更好的方式，可以将生产经验和 SRE 支持引入新旧服务之中。

第一种方式与软件工程中的经验类似：缺陷发现得越早，修复成本就越低。同样，SRE 团队介入得越早，服务质量通常越高，收益也越早显现。如果在设计初期就引入 SRE，往往可以缩短上线时间，并让服务从一开始就更加可靠，因为团队不必再花大量时间纠正设计或实现上的缺陷。

另一种方式，也许是最佳方式，是缩短那些高度定制、差异巨大的系统最终抵达 SRE 团队面前的路径。具体而言，可以为产品开发团队提供一个经过 SRE 验证的基础设施平台，让他们基于该平台构建系统。这样的平台兼具可靠性和可扩展性，因而能带来双重收益：一方面，它可以从根本上降低某些认知负担；另一方面，它通过规范常见的基础设施实践，使产品开发团队能够专注于应用层创新——而那里才是真正创造业务价值的地方。

接下来的章节将依次讨论这些 SRE 参与模型。我们先从“经典”的、由 PRR 驱动的模型开始。

PRR 模型：SRE 参与服务的典型起点

SRE 参与服务的最典型起点，是生产就绪评审（Production Readiness Review，PRR）。这一流程旨在根据服务的具体情况识别其可靠性需求。通过 PRR，SRE 会运用自身积累的知识和经验，帮助确保运行在生产环境中的服务具备足够的可靠性。通常，PRR 被视为 SRE 团队承担服务生产管理责任的前置条件。

图 32-1 展示了一个典型服务的生命周期。生产就绪评审可以在服务生命周期的任何阶段启动，但随着时间推移，SRE 的参与方式也在不断扩展。本章首先介绍简单 PRR 模型，随后讨论如何对其加以改进，形成更扩展的参与模式；最后介绍框架和 SRE 平台架构如何帮助 SRE 扩展参与流程，并扩大影响范围。

SRE 参与模式如何演进：从生产就绪评审 PRR 到 SRE 平台

图 32-1.典型的服务生命周期

SRE 参与模型的核心关注点

SRE 致力于承担关键服务的生产责任，并切实提升这些服务的可靠性。SRE 关注服务的多个方面，这些方面合称为“生产”。它们包括：

系统架构和服务间依赖关系
埋点、指标和监控
应急响应
容量规划
变更管理
性能：可用性、延迟和效率

当 SRE 参与某项服务时，目标是在所有这些方面改进服务，使其生产管理变得更加容易。

替代性支持：文档与咨询如何提升服务可靠性

并非所有海外某大型科技公司的服务都能获得 SRE 的深度参与。这背后有几个原因：

许多服务并不需要极高的可靠性和可用性，因此可以通过其他方式获得支持。
从组织设计上看，请求 SRE 支持的开发团队数量通常超过 SRE 团队可承载的带宽（参见“简介”）。

当 SRE 无法提供全面支持时，仍会提供其他改善生产环境的方式，例如文档和咨询。

文档

针对内部技术和广泛使用的系统客户端，海外某些公司通常会提供开发指南。某些公司的《生产指南》记录了服务生产最佳实践，这些最佳实践来自 SRE 团队和开发团队共同积累的经验。开发人员可以参考这些文档中的解决方案和建议，改进自己的服务。

咨询

开发人员也可能寻求 SRE 咨询，以讨论特定服务或特定问题领域。某些负责发布协调工程的团队（参见“大规模可靠产品发布”）会将大量时间用于为开发团队提供咨询。即便并非专门负责发布咨询的 SRE 团队，也会经常为开发团队提供咨询支持。

当一项新服务或新功能即将上线时，开发人员通常会咨询 SRE，以获得有关上线准备工作的建议。一次上线咨询通常由一到两名 SRE 花费几个小时，从宏观层面审视设计和实现方案。随后，SRE 顾问会与开发团队会面，就需要关注的风险领域提出建议，并讨论可用于提升服务生产质量的成熟模式或解决方案。其中一些建议可能来自前文提到的《生产指南》。

咨询会议的范围必然较宽，因为在有限时间内不可能深入理解某个具体系统。对某些开发团队而言，咨询并不足够：

这些服务自发布以来已经呈指数级增长，现在需要投入远超文档和咨询所能覆盖的时间才能充分理解。
许多其他服务后来开始依赖这些服务，使其承载了来自大量不同客户的流量。

这类服务可能在发展到一定规模后，开始在生产环境中遭遇重大挑战，同时也变得对用户至关重要。在这种情况下，就需要长期的 SRE 支持，以确保这些服务在发展过程中得到妥善维护。

生产就绪评审：简单 PRR 模型

当开发团队请求 SRE 接管某项服务的生产管理时，SRE 会评估该服务的重要性以及 SRE 团队自身的可用性。如果该服务确实需要 SRE 支持，并且 SRE 团队与开发团队就支持所需的人力达成一致，SRE 就会与开发团队启动生产就绪评审。

生产就绪评审的目标包括：

确认服务符合公认的生产配置和运行准备标准，并确认服务所有者已准备好与 SRE 合作、利用 SRE 的专业能力。
提升服务在生产环境中的可靠性，并尽可能减少事故发生的数量和严重程度。PRR 覆盖 SRE 关注的所有生产环节。
在完成足够改进，并确认服务已准备好接受 SRE 支持之后，由 SRE 团队承担其生产责任。

这就引出了生产就绪评审流程本身。该流程包含三种不同但相互关联的参与模式：简单生产就绪评审模型、早期参与模型，以及框架和 SRE 平台模型。我们将依次讨论它们。

我们先从简单 PRR 模型开始。该模型通常适用于已经上线、并即将由 SRE 团队接管的服务。PRR 流程包含多个阶段，类似于开发生命周期，尽管它也可以与开发生命周期并行、独立地推进。

参与启动

SRE 管理层首先会决定哪个 SRE 团队最适合接管该服务。通常会选择一到三名 SRE，或由他们主动承担 PRR 流程。随后，这个小组会与开发团队展开讨论。讨论内容包括：

为服务制定服务级别目标/服务级别协议（SLO/SLA）。
规划为提升可靠性所需的设计变更，其中一些变更可能具有较大影响。
制定计划和培训安排。

这一阶段的目标，是就 SRE 团队如何与开发团队及其服务协作、最终要达成什么目标、预期产出是什么，形成共识。对研发团队而言，这类流程往往涉及团队目标、客户反馈、需求清理、评审排期、开发、测试、发布上线以及经验沉淀等多个环节；如果借助 PingCode 这类智能化研发管理工具，可以更好地打通研发全生命周期数据，让 PRR 相关任务、知识和改进项在同一流程中持续流转。

分析

分析是第一个重要工作阶段。在这一阶段，SRE 评审人员会理解服务，并开始分析其生产环境中的缺陷。他们的目标，是从 SRE 关注的各个方面评估服务成熟度。同时，他们还会检查服务的设计和实现，确认其是否符合生产最佳实践。

通常，SRE 团队会专门为分析阶段建立并维护一份生产就绪评审清单。该清单面向特定服务，通常基于领域专业知识、相关或类似系统的经验，以及《生产指南》中的最佳实践。SRE 团队也可能咨询其他团队，尤其是那些对服务某些组件或依赖项更有经验的团队。

以下是一些清单项目示例：

服务更新是否会一次性影响系统中过大比例的资源？
该服务是否连接到了其依赖项的适当服务实例？例如，面向最终用户的服务请求，不应依赖专为批处理场景设计的系统。
该服务在与关键远程服务通信时，是否请求了足够高的网络服务质量？
该服务是否会将错误上报到中央日志系统进行分析？对于所有会导致响应变慢或最终用户服务中断的异常情况，是否都会被记录并暴露出来？
是否对所有用户可见的请求失败进行了充分埋点和监控，并配置了合适的告警机制？

这份清单还可能包含特定 SRE 团队遵循的运维标准和最佳实践。例如，一个功能正常但不符合 SRE 团队“黄金标准”的服务配置，可能会被重构，以便更好地配合 SRE 工具使用，从而支持可扩展的配置管理。

SRE 还会查看该服务近期发生的事故、事后复盘以及事故后续任务。这项评估旨在衡量服务的应急响应需求，以及成熟运维控制手段的可用性。

改进和重构

分析阶段会产出服务改进建议。下一阶段通常按以下步骤推进：

根据改进项对服务可靠性的影响确定优先级。
与开发团队讨论并协商优先事项，制定执行计划。
SRE 团队和产品开发团队共同参与、相互协作，重构服务的部分内容，或实现其他必要功能。

这一阶段的持续时间和工作量通常差异最大。具体需要投入多少时间和精力，取决于可用于重构的工程时间、评审开始时服务的成熟度和复杂度，以及许多其他因素。

培训

生产环境中的服务管理通常由整个 SRE 团队负责。为确保团队准备充分，负责 PRR 的 SRE 评审人员会组织团队培训，并提供支持服务所需的文档。通常情况下，这些工程师会在开发团队的协助和参与下，组织一系列培训课程和演练。培训内容可能包括：

设计概览
系统中各类请求路径的深入分析
生产部署和运行环境说明
针对系统各项操作的实践演练

培训结束后，SRE 团队应当已经准备好管理该服务。

接入

培训阶段旨在帮助 SRE 团队顺利完成服务接入。该阶段涉及服务生产各个方面的职责和所有权逐步移交，包括部分运维工作、变更管理流程、访问权限等。

SRE 团队将继续关注前文提到的各个生产领域。为完成过渡，开发团队必须在一段时间内持续提供支持和建议，帮助 SRE 团队逐步适应服务的生产管理。这种合作关系也将成为两个团队未来协作的基础。

持续改进

活跃服务会不断变化，以响应新的需求和状况，包括用户对新功能的请求、不断演变的系统依赖关系、技术升级，以及其他因素。面对这些变化，SRE 团队必须通过持续改进来维护服务的可靠性标准。

负责该服务的 SRE 团队会在服务运行过程中，通过审查新的变更、响应事故，尤其是在开展事后复盘和根因分析时，自然而然地加深对服务的理解。每当服务新增功能、组件或依赖项时，这些专业知识都会以建议和提案的形式分享给开发团队。此外，服务管理中积累的经验也会被纳入最佳实践，并记录在《生产指南》和其他文档中。

SRE 参与示例：某项服务的接入过程

最初，某项示例服务由开发人员负责，包括紧急响应的值班呼叫。然而，随着服务使用量和收入增长，SRE 支持变得至关重要。

由于产品已经上线，SRE 对其进行了生产就绪评审。他们发现的一个问题是，仪表盘未能完整覆盖 SLO 中定义的一些指标，因此需要修复。在所有已提交的问题都得到解决后，SRE 接管了该服务的值班呼叫，但两名开发人员也加入了轮值。

开发人员会参加每周的值班会议，讨论上一周出现的问题，以及如何应对即将发生的大规模维护或集群停机。此外，他们现在也会与 SRE 讨论服务的未来规划，以确保新版本能够顺利发布——尽管意外情况总会伺机扰乱计划。

演进简单 PRR 模型：早期参与

到目前为止，我们讨论的都是简单生产就绪评审模型中的 PRR。该模型主要适用于已经进入发布阶段的服务。这种模型存在一些局限和成本：

团队之间额外的沟通可能会增加开发团队的流程开销，也会增加 SRE 评审人员的认知负担。
合适的 SRE 评审人员必须有空，并且能够在既有工作安排下管理时间和优先级。
SRE 的工作必须高度透明，并经过开发团队充分审阅，以确保有效的知识共享。SRE 应当像开发团队的一部分一样开展工作，而不是作为一个外部团队独立推进。

然而，PRR 模型的主要局限在于：服务往往已经上线并大规模运行，而 SRE 的介入却发生在开发生命周期较晚阶段。由此产生的缺陷，可能对 SRE 参与的成功以及服务本身未来的发展构成重大挑战。

如果 PRR 能够在服务生命周期的更早阶段进行，SRE 修复服务潜在问题的机会将显著增加。这样一来，SRE 参与成功的可能性以及服务未来成功的可能性都会提升。

早期参与的候选服务

早期参与模型将 SRE 引入开发生命周期的早期阶段，从而获得显著的额外收益。应用早期参与模型，需要在开发生命周期早期识别服务的重要性和/或业务价值，并判断该服务的规模或复杂度是否足以从 SRE 专业能力中受益。适用的服务通常具备以下特征：

该服务实现了重要的新功能，并将成为现有 SRE 管理系统的一部分。
该服务是对现有系统的重大重写或替代，面向相同的目标用例。
开发团队在产品发布时寻求 SRE 建议，或联系 SRE 进行接管。

早期参与模型本质上是将 SRE 深度融入开发流程。SRE 的职责并未改变，但实现更高生产质量服务的路径有所不同。SRE 会参与设计及后续阶段，并最终在构建阶段期间或之后的某个时间点接管服务。该模型建立在开发团队和 SRE 团队积极协作的基础之上。

早期参与模型的收益

尽管早期参与模型确实存在前文讨论过的一些风险和挑战，但与在服务生命周期后期才启动的参与相比，SRE 在整个产品生命周期中提供额外专业能力和协作，能够带来显著收益。

设计阶段

在设计阶段引入 SRE 协作，可以预防生产环境中的多类问题或事故。虽然设计决策可以在开发生命周期后期撤销或修正，但这类变更通常会带来高昂的工作量和复杂度成本。最好的生产事故，就是那些根本没有发生的事故。

有时，艰难的权衡会导致最终选择并非最佳设计方案。参与设计阶段，意味着 SRE 能够提前了解各种权衡，并参与决定是否接受某个非最优方案。SRE 的早期介入旨在最大限度减少服务上线后围绕设计选择产生的争议。

构建和实现阶段

构建阶段主要关注生产相关因素，例如埋点和指标、运行与应急控制、资源利用率以及效率。在这一阶段，SRE 可以通过推荐特定的现有库和组件，或帮助在系统中构建某些控制机制，来影响和改进实现方案。

SRE 在这一阶段的参与有助于简化未来运维工作，并让 SRE 在正式上线前积累运维经验。

发布阶段

SRE 还可以帮助实现广泛使用的发布模式和控制机制。例如，SRE 可以帮助实施“暗发布”：在现有用户流量继续发送到旧服务的同时，也将其中一部分复制到新服务。新服务的响应之所以称为“暗”的，是因为这些响应会被丢弃，并不会实际展示给用户。

暗发布等实践可以帮助团队获得运营洞察，在不影响现有用户的情况下解决问题，并降低发布后出现故障的风险。平稳发布对于降低运维负担、保持发布后的开发势头至关重要。发布前后的任何中断，都可能引发源代码和生产环境的紧急变更，并打断开发团队对未来功能的开发工作。

发布后阶段

在系统上线初期拥有稳定系统，通常能够减少开发团队在提升服务可靠性和添加新功能之间的优先级冲突。在服务生命周期的后续阶段，早期阶段获得的经验教训也能更好地指导重构或重新设计。

通过更深入的参与，SRE 团队可以比采用简单 PRR 模型更快接管新服务。SRE 团队与开发团队之间更长时间、更紧密的合作，也能建立起可长期维系的协作关系。积极的跨团队关系能够增强共同责任感，并帮助 SRE 团队确立对生产环境的责任。

退出服务：并非所有服务都需要完整 SRE 接管

有时，某项服务并不需要完整的 SRE 团队管理。这个判断可能是在服务上线后做出的，也可能是 SRE 团队曾参与服务维护，但从未正式接管。这样的结果并不是坏事，因为这说明该服务的设计目标是可靠且易于维护，因此可以继续由开发团队负责。

SRE 团队也可能较早介入某项服务，但该服务最终未能达到预期使用量。在这种情况下，SRE 投入的精力只是新项目整体业务风险的一部分；相比那些真正达到预期规模的项目而言，这项成本通常并不高。SRE 团队可以重新分配工作，并将获得的经验教训应用到后续项目中。

演进型服务开发：框架和 SRE 平台

早期参与模型在推动 SRE 参与方面，相比只适用于已上线服务的简单 PRR 模型，已经向前迈出了一大步。然而，如果我们希望通过设计实现可靠性，把 SRE 参与提升到更高层次，仍然还有改进空间。

SRE 参与模式演进中的经验教训

随着时间推移，前文描述的 SRE 参与模式呈现出几种不同规律：

每项服务的接入通常需要两到三名 SRE，持续两到三个季度。PRR 的提前期相对较长，往往需要几个季度。所需工作量与待评审服务数量成正比，但又受限于可执行 PRR 的 SRE 人数不足。这些因素导致服务接管被串行化，并且必须对服务进行严格优先级排序。
由于不同服务的软件实践各不相同，每项生产功能都以不同方式实现。为了符合 PRR 驱动的标准，通常需要为每项服务重新实现功能；或者最多只是在共享代码的一小部分服务子集中实现一次。这种重复实现浪费了大量工程资源。一个典型例子是，由于不同服务没有采用相同的代码结构，功能类似的日志框架不得不在同一种语言中反复实现。
对常见服务问题和故障的分析揭示了一些模式，但修复和改进措施很难轻松复制到其他服务中。典型例子包括服务过载和数据热点问题。
SRE 在软件工程方面的贡献通常局限于特定服务。因此，构建可复用的通用解决方案十分困难。结果是，各个 SRE 团队积累的新经验和最佳实践，很难应用到已经上线的其他服务中。

影响 SRE 参与模式的外部因素

历史上，外部因素从多个方面给 SRE 组织及其资源带来了压力。

某些海外大型科技公司正日益顺应行业趋势，转向微服务架构。151 因此，请求 SRE 支持的数量以及需要支持的服务数量都在增加。由于每项服务都有固定的基础运维成本，即使是简单服务也需要更多人员支持。微服务还意味着更短的部署周期，而这在此前由 PRR 驱动的模型下难以实现，因为该模型中的部署周期可能长达数月。

招聘经验丰富、资质合格的 SRE 工程师既困难又成本高昂。尽管招聘部门投入了大量精力，SRE 工程师的数量仍然不足以支持所有需要其专业能力的服务。此外，SRE 工程师入职后的培训周期也比普通开发工程师更长。

最后，SRE 组织还需要满足大量且不断增长的开发团队需求，而这些团队目前并未获得直接的 SRE 支持。这一职责要求 SRE 支持模式必须远远超出最初的概念和参与方式。

迈向结构化解决方案：框架

为了有效应对这些情况，我们需要建立一种遵循以下原则的模型：

成文化的最佳实践

将生产环境中行之有效的方法转化为代码，使服务能够直接使用这些代码，并从设计上具备“生产就绪”能力。

可复用的解决方案

为缓解可扩展性和可靠性问题，提供通用且易于共享的技术实现。

具有通用控制界面的通用生产平台

提供统一的生产设施接口、统一的运维控制，以及统一的监控、日志记录和配置能力。

更便捷的自动化和更智能的系统

通用控制界面能够以前所未有的方式支持自动化和智能系统。例如，SRE 可以轻松获得与故障相关的单一信息视图，而不必手动收集和分析来自不同来源的原始数据，例如日志、监控数据等。

基于这些原则，某些海外大型科技公司创建了一组由 SRE 支持的平台和服务框架，每个框架对应一种受支持的开发环境，例如 Java、C++ 和 Go。使用这些框架构建的服务，会共享一些专门设计用于与 SRE 支持平台兼容的实现，并由 SRE 团队和开发团队共同维护。

框架带来的主要变化在于：产品开发团队可以使用由 SRE 构建并验证过的框架解决方案来设计应用程序，而不必在事后改造应用程序以符合 SRE 标准，也不必额外增加 SRE 人员来支持那些与其他服务显著不同的定制化服务。

应用程序通常包含业务逻辑，而业务逻辑又依赖各种基础设施组件。SRE 对生产环境的关注，主要集中在服务中与基础设施相关的部分。服务框架以标准化方式实现基础设施代码，并解决各类生产问题。每个问题都会封装在一个或多个框架模块中，每个模块都针对特定问题领域或基础设施依赖项提供统一解决方案。

框架模块可以解决前文列举的多类 SRE 问题，例如：

埋点和指标
请求日志记录
涉及流量和负载管理的控制系统

SRE 会构建框架模块，为相关生产领域提供规范化解决方案。因此，开发团队可以专注于业务逻辑，因为框架已经负责正确使用基础设施。

框架本质上是对一组软件组件的使用方式，以及这些组件如何组合进行规范化实现。框架还可以以统一方式暴露控制各种组件的能力。例如，一个框架可以提供以下功能：

将业务逻辑组织成语义明确的组件，并用标准术语引用这些组件。
为监控埋点提供标准维度。
为请求调试日志提供标准格式。
为管理负载削减提供标准配置格式。
用语义一致的度量方法表示单台服务器容量以及“过载”的判定，并将其反馈给各种控制系统。

框架在一致性和效率方面提供了多项前置收益。它们使开发人员不必再以临时方式、针对特定服务，用略有不兼容的方式拼接和配置各个组件，也不必再由 SRE 手动审查这些实现。框架为跨服务的生产问题提供单一、可复用的解决方案。这意味着框架用户最终会获得相同的通用实现，并将配置差异降至最低。

某些海外大型科技公司支持多种主流应用开发语言，并为这些语言都实现了相应框架。虽然不同语言的框架实现，例如 C++ 和 Java，无法共享代码，但它们的目标是为相同功能提供一致的 API、行为、配置和控制能力。因此，开发团队可以选择符合自身需求和经验的语言平台，而 SRE 团队仍然可以在生产环境中获得熟悉且一致的体验，并使用标准工具管理服务。

SRE 平台带来的新服务和管理优势

这种基于服务框架、通用生产平台和控制界面的结构化方法，带来了一系列新的好处。

运营成本显著降低

基于更强规范框架构建的生产平台，可以显著降低运营开销，原因包括：

它支持对代码结构、依赖关系、测试、编码风格指南等进行严格的一致性测试。这一能力也有助于提升用户数据隐私、测试和安全方面的一致性。
它具备适用于所有服务的内置服务部署、监控和自动化能力。
它使大量服务，尤其是不断增长的微服务，更容易被管理。
它能够实现更快部署：一个想法可以在几天内发展为完全上线、达到 SRE 水准生产质量的服务。

面向通用支持而设计

随着服务数量持续增长，其中大多数服务既不需要 SRE 团队深度参与，也无法由 SRE 团队直接维护。尽管如此，那些无法获得完整 SRE 支持的服务，仍然可以通过构建方式使用由 SRE 开发和维护的生产级功能。

这种做法有效突破了 SRE 人员配置瓶颈。让所有团队都能使用由 SRE 支持的生产级标准和工具，可以提升组织整体的服务质量。此外，所有使用框架实现的服务，都能自动受益于框架模块的持续改进。

更快、成本更低的协作

框架方法能够加快 PRR 执行速度，因为我们可以依赖：

作为框架实现一部分的内置服务功能。
更快的服务接入速度，通常可由一名 SRE 在一个季度内完成。
使用框架构建的服务，会降低 SRE 团队的认知负担。

这些特性使 SRE 团队能够减少服务接入所需的评估和资质确认工作量，同时保持较高的服务生产质量标准。

基于共同责任的新型 SRE 参与模式

最初的 SRE 参与模式只提供两种选择：要么提供全面 SRE 支持，要么几乎不提供 SRE 支持。152

拥有通用服务架构、规范和软件基础设施的生产平台，使 SRE 团队能够支持“平台”基础设施，而开发团队则负责服务功能性问题的值班支持，也就是应用程序代码中的错误。在这种模式下，SRE 团队承担服务软件基础设施大部分的开发和维护工作，尤其是负载均衡、过载保护、自动化、流量管理、日志记录和监控等控制系统。

这种共同责任模式不仅需要技术边界清晰，也需要协作边界清晰。对于跨团队任务、文档、会议、日历、工时、审批等协作事项较多的组织，可以通过 Worktile 这类通用项目协作系统统一承载，降低 SRE 团队、开发团队和管理团队之间的信息割裂。

该模型在两个主要方面不同于最初的服务管理设想：它引入了一种新的 SRE 与开发团队交互关系模型，也引入了一种新的 SRE 支持服务管理人员配置模型。153