在 Google，站点可靠性工程（SRE）是我们不断定义可靠性目标，衡量这些目标，并根据需要努力改善我们的服务的做法。我们最近指导您浏览了 SRE 工作手册。您可以将这些指导视为 SRE 团队通常会做的事情，并结合团队的成熟度，确定何时团队倾向于执行这些任务。我们相信，许多公司都可以按照该指导来启动和发展新的 SRE 团队。

从那时起，我们听说人们了解 SRE 在 Google 上通常会做什么，并了解应该在 SRE 成熟度的各个级别上实施哪些最佳实践。我们也从很多人那里听到了您如何定义自己的团队成熟度水平。但是，对于接下来的“SRE 团队的实际组织方式”，直到现在为止，基本上尚未记录在案！

在这篇文章中，我们将介绍 SRE 团队的不同实现，是如何为实现目标建立界限的。我们描述了我们经历的六个不同的实现，以及我们观察到的最重要的优缺点。请记住，您对 SRE 的实现可以有所不同，这不是详尽的清单。近年来，我们在 Google SRE 组织中看到了所有这些类型的团队（即一组 SRE 团队），除了“Kitchen Sink”类型的团队。随着 SRE 团队积累经验，此处的实现顺序是相当普遍的发展路径。

在开始实施 SRE 之前

在选择此处讨论的任何实现之前，请与您的团队做一些准备工作。我们建议分配一些人的工程时间，并在公司内找到至少一名兼职的 SRE 相关实践的倡导者。这种类型的初始，非正式形式的组织方式有一些优点和缺点：

优点

○无需组织更改即可轻松开始 SRE 旅程。

○  使您能够低成本地测试和适应您的环境的 SRE 实践。

缺点

○  日常工作需求与采用 SRE 实践之间的时间管理。

推荐给：没有规模来采用 SRE 团队专门人员的组织，和/或在广泛采用之前尝试 SRE 实践的组织。

SRE 团队实施的类型

01

KITCHEN SINK，又名“EVERYTHING SRE”

这描述了一个 SRE 团队，其中所涵盖的服务或工作流的范围通常是不受限制的。它通常是现有的第一个（或唯一的）SRE 团队，并且可能会像 Google SRE 刚开始时那样自然发展。此后，我们采用了混合模型，包括下面列出的实现。

优点

○ 假设只有一个团队，SRE 团队之间没有覆盖差距。

○ 易于发现的模式，并在服务和项目之间有相似之处。

○ SRE 倾向于充当不同开发团队之间的粘合剂，利用不同的软件来创建

缺点

○  通常缺乏 SRE 团队章程，或章程规定公司中的一切都可能在范围之内，冒着使团队超负荷的风险。

○  随着公司和系统复杂性的增长，这样的团队倾向于从能够对所有事物产生深远的积极影响，转向做出更多浅薄的贡献。有一些方法可以缓解这种现象，而无需完全更改实施，或启动另一个团队（请参阅下面的服务层）。

○  涉及此类团队的问题可能会对您的整个业务产生负面影响。

推荐给：一家只有几个应用程序和用户流程的公司，在没有专门的 SRE 团队的情况下，采用 SRE 做法和对角色的需求已经超出了可以配备的人员，但是范围很小，以至于无法拥有多个 SRE 团队。

02

基础设施

这些团队倾向于专注于幕后工作，这些工作有助于使其他团队的工作更快，更轻松。常见的实现包括维护共享服务（例如 Kubernetes 集群），或维护在“公共云”的提供商，例如，Google Cloud Platform（GCP），之上构建的公共组件（例如，CI/CD，监控，IAM 或 VPC 配置）。这不同于从事与产品相关的服务的 SREs，即内部编写的面向客户的代码。

优点

○  允许产品开发人员使用 DevOps 实践来维护面向用户的产品，而在整个企业中的实践上没有分歧。

○  SRE 可以专注于提供高度可靠的基础架构。他们通常将生产标准定义为代码，并努力消除任何尖锐的边缘，以大大简化产品开发人员运行自己的服务的过程。

缺点

○  根据基础架构的范围，涉及此类团队的问题可能会对您的整个业务产生负面影响，类似于 Kitchen Sink 实施。

○  缺乏与公司客户的直接联系，可能导致人们将重点放在不一定与客户体验相关的基础架构改进上。

○  随着公司和系统复杂性的增加，可能需要拆分基础架构团队，因此适用与产品/应用程序团队相关的弊端（请参见下文）。

推荐给：具有多个开发团队的任何公司，因为您可能必须配备基础架构团队（或考虑配备基础架构团队）来定义通用标准和实践。对于大型公司来说，同时拥有基础架构DevOps 团队和 SRE 团队是很常见的。DevOps 团队将专注于客户化 FLOSS，并为应用程序团队编写自己的软件（功能），而 SRE 团队则专注于可靠性。

03

工具

仅有工具的 SRE 团队倾向于专注于构建软件，以帮助开发人员评估，维护和提高系统可靠性或SRE工作的任何其他方面，例如，容量规划。

可以认为工具是基础架构的一部分，因此 SRE 团队的实现是相同的。的确，这两种类型的团队相当相似。实际上，通常与基础架构团队相关联的服务路径上的共享后端相反，工具团队倾向于将更多的精力放在具有面向可靠性功能集的支持和计划系统上。

副作用是，通常会有更多直接反馈给基础架构 SRE 团队。工具 SRE 团队冒着为业务解决错误问题的风险，因此需要努力始终了解团队解决前线可靠性的实际问题。基础架构和工具团队的利弊往往相似。此外，对于工具团队：

缺点

○  您需要确保工具团队不会无意间变成基础架构团队，反之亦然。

○  长期辛劳和整体工作量增加的风险很高。这通常包含在由您的业务主管批准建立的团队章程中。

推荐用于：任何需要高度专业化的和可靠性相关的工具公司，而这些工具目前尚无可用的FLOSS或SaaS。

04

产品/应用程序

在这种情况下，SRE 团队将努力提高关键应用程序或业务领域的可靠性，但是诸如批处理程序之类的辅助服务的可靠性，是另一个团队的责任，通常情况下，开发人员同时涵盖 dev 和 ops 功能。

优点

○  为团队的工作提供明确的重点，并允许从业务优先级到团队努力的地方之间，明确联系起来。

缺点

○  随着公司和系统复杂性的增长，将需要新的产品/应用程序团队。每个团队的产品重点，可能导致基础架构的重复，或团队之间实践的差异，这样效率低下，并限制了知识共享和流动。

推荐用于：对于这样的公司，作为第二个或第n个团队，以 Kitchen Sink，基础设施或工具团队为起点，并且具有关键的面向用户的应用程序，并且具有很高的可靠性需求，这证明专用的 SREs 的费用相对较高。

05

嵌入式

这些 SRE 团队，让 SREs 嵌入了他们的对应的开发团队，通常是每个开发团队一个。嵌入的 SREs 通常与开发人员共享一个办公室，但是嵌入式安排可以是远程的。

嵌入式 SRE 与开发人员之间的工作关系，往往受到项目或时间的限制。在嵌入式安排期间，SREs 通常是非常操作性的，执行诸如更改代码和服务配置之类的工作。

优点

○  使专注的 SRE 专业知识可以导向特定的问题或团队。

○  可以同步演示 SRE 实践，这可以是一种非常有效的教学方法。

缺点

○  这可能导致团队之间缺乏标准化，和/或实践中的分歧。

○  SRE 可能没有机会与同伴花费很多时间来指导他们。

推荐用于：此实现可以很好地启动 SRE 功能，或进一步扩展另一个实现。当您的项目或团队需要一段时间的 SRE 时，这可能是一个很好的模型。这种类型的团队，还可以通过推动采用本方式，来增强工具或基础架构团队的影响力。

06

咨询

该实现与上述嵌入式实现非常相似。不同之处在于，咨询 SRE 团队倾向于避免更改客户代码和服务配置。

咨询 SRE 团队可能会编写代码和配置，以便为自己或开发人员构建和维护工具。如果他们执行后者，则可以说他们是咨询和工具实现的混合体。

优点

○  通过与直接更改代码和配置解耦，它可以帮助进一步扩展现有 SRE 组织的积极影响（另请参见下面对可靠性标准和实践的影响）。

缺点

○  顾问可能缺乏足够的背景来提供有用的建议。

○  鉴于他们通常不会更改代码和配置，即使他们能够间接产生技术影响，咨询 SRE 团队的常见风险被认为是非操作性的（即几乎不会产生风险）。

推荐给：直到您的公司或复杂性被认为很大，并且当需求超出了其他各种实现的现有 SRE 团队所能提供的支持时，我们才建议您配备一个专门的 SRE 顾问团队。请记住，在您为第一个 SRE 团队配备人员之前，我们建议配备一个或几个兼职顾问（请参见上文）。

SRE 团队实施的常见修改

我们已经看到了对于上述大多数实现的两个常见修改。

可靠性标准和实践

01

SRE 团队还可以充当整个公司的“可靠性标准和实践”小组。

标准和实践的范围可能有所不同，但是通常涵盖更改生产系统、事件管理、错误预算等的可接受方式和时间。换句话说，尽管这样的 SRE 团队可能不会直接与每个服务或开发团队进行互动，通常是团队在其专业领域内的其他地方，确定可接受的条件。

我们已经看到以两种不同的方式采用这些标准和实践：

○  影响力主要依靠有机采用，并向团队展示这些标准和实践如何帮助他们实现目标。

○  任务依赖于组织结构、流程和层次结构来推动可靠性标准和实践的采用。

任务的有效性取决于组织文化，以及 SRE 团队的经验、资历和声誉。任务的方法在其他领域中普遍地采用严格流程的组织中可能是有效的，但是在个人具有高度自治权的组织中，成功的可能性很小。在这两种情况下，即使由经验丰富的人员组成的新团队，也可能比具有通过良好实践获得高可靠性的历史和声誉的团队，更难以建立公司范围的标准。

我们还观察到软件开发是平衡这些方法的有效工具。在这种情况下，SRE 团队开发一种零配置方法，如果服务或目标团队恰巧使用预先确定的系统，则可以采用一种或多种可靠性标准和实践，并增加零设置成本。一旦他们看到使用该系统可以实现的好处（通常可以节省时间），就会影响开发团队通过提供的工具来采用这些实践。随着采用这样的系统的增加，该方法可以转向针对 SREs 的目标改进，并通过与可靠性相关的一致性测试来设定任务。

服务层级

02

无论哪种 SRE 团队模型定义了团队的范围，任何 SRE 团队都有权决定他们与所在区域内的软件和服务的互动深度。当开发团队、应用程序或基础架构的数量超过 SRE 团队能完全支持的能力时，尤其如此。解决这个挑战的常用方法是提供 SRE 参与的层次。这样做通过在这两个选项之间添加至少一层以上的内容，扩展了“对我们而言尚不存在或尚未被 SRE 看到”和“由 SRE 完全支持”的二元方法。

二元方法的一个共同特征是，“由 SRE 完全支持”通常是指在一些上线流程后，给定的服务或工作流程由 SRE 和开发人员共同拥有，包括及时响应的职责。

不幸的是，SRE 团队或任何其他团队，在他们可以完全上线多少服务的方面，往往达到极限。随着架构的多样性和服务复杂性的增加，认知负荷和记忆回忆会很痛苦。

这是 SRE 分层方法的示例：

○  第0层：零散的咨询工作，没有专门的 SRE 人员。

○  第1层：项目工作，需要一些专用的 SRE 时间。

○ 第2层：该服务已上线（或上线中）以及时响应，并获得更多的专用 SRE 时间。

这些层的实现细节根据实际的 SRE 实现本身而有所不同。例如，通常不希望咨询和嵌入式 SRE 团队在第2层上提供服务（如及时响应），但可能在第1层提供专门的人员（而不是共享人员）。我们建议定义经 SRE 和开发人员领导批准的服务层级文档。此签署与记录您的团队章程（如上所述）有关但不相同。

曾经有一个 SRE 团队采用多种实现方式的特征，而不是采用服务层的例子。例如，一个单独的 Kitchen Sink 的 SRE 团队，也可以由两名 SRE 顾问扮演双重角色。

常见的 SRE 路径

您的 SRE 组织可以按照上面的顺序实施。另一个常见的途径是实施在“开始之前”中所述的内容，然后为一个 Kitchen Sink 的 SRE 团队配备人员，但是在需要成立第二个 SRE 团队时，将基础结构的顺序按产品/应用程序交换。在这种情况下，结果是两个专门的产品/应用程序 SRE 团队。当托管的解决方案，例如，Google Cloud 提供的解决方案，以外的产品/应用程序具有足够的广度，但两个团队之间几乎没有共享基础架构时，这才有意义。

第三种常见的方法是从“开始之前”过渡到基础架构（或甚至工具）团队，跳过“Kitchen Sink”和产品/应用程序阶段。当应用程序团队有能力并且愿意定义和维护SLO时，这种方法最有意义。

我们强烈建议您尽早在SRE流程中同时评估“可靠性标准和实践”和“服务层级”，但这只有在您建立了第一个 SRE 团队之后才可行。

接下来我该怎么办？

如果您只是开始进行 SRE 练习，我们建议您阅读您有 SRE 团队吗？如何开始和评估您的旅程，然后根据我们上面共享的信息，评估最适合您需求的 SRE 实施。

如果您领导一个或多个 SRE 团队，建议您以通用的术语描述它们的实现（类似于我们上面讨论团队实现的方式），根据您自己的经验评估优缺点，并确保 SRE 团队的目标和范围是通过团队章程文档定义的。此练习可以帮助您避免过载和过早的重组。

在 Google，站点可靠性工程（SRE）是我们不断定义可靠性目标，衡量这些目标，并根据需要努力改善我们的服务的做法。我们最近指导您浏览了 SRE 工作手册。您可以将这些指导视为 SRE 团队通常会做的事情，并结合团队的成熟度，确定何时团队倾向于执行这些任务。我们相信，许多公司都可以按照该指导来启动和发展新的 SRE 团队。

从那时起，我们听说人们了解 SRE 在 Google 上通常会做什么，并了解应该在 SRE 成熟度的各个级别上实施哪些最佳实践。我们也从很多人那里听到了您如何定义自己的团队成熟度水平。但是，对于接下来的“SRE 团队的实际组织方式”，直到现在为止，基本上尚未记录在案！

在这篇文章中，我们将介绍 SRE 团队的不同实现，是如何为实现目标建立界限的。我们描述了我们经历的六个不同的实现，以及我们观察到的最重要的优缺点。请记住，您对 SRE 的实现可以有所不同，这不是详尽的清单。近年来，我们在 Google SRE 组织中看到了所有这些类型的团队（即一组 SRE 团队），除了“Kitchen Sink”类型的团队。随着 SRE 团队积累经验，此处的实现顺序是相当普遍的发展路径。

在开始实施 SRE 之前

在选择此处讨论的任何实现之前，请与您的团队做一些准备工作。我们建议分配一些人的工程时间，并在公司内找到至少一名兼职的 SRE 相关实践的倡导者。这种类型的初始，非正式形式的组织方式有一些优点和缺点：

优点

○无需组织更改即可轻松开始 SRE 旅程。

○  使您能够低成本地测试和适应您的环境的 SRE 实践。

缺点

○  日常工作需求与采用 SRE 实践之间的时间管理。

推荐给：没有规模来采用 SRE 团队专门人员的组织，和/或在广泛采用之前尝试 SRE 实践的组织。

SRE 团队实施的类型

01

KITCHEN SINK，又名“EVERYTHING SRE”

这描述了一个 SRE 团队，其中所涵盖的服务或工作流的范围通常是不受限制的。它通常是现有的第一个（或唯一的）SRE 团队，并且可能会像 Google SRE 刚开始时那样自然发展。此后，我们采用了混合模型，包括下面列出的实现。

优点

○ 假设只有一个团队，SRE 团队之间没有覆盖差距。

○ 易于发现的模式，并在服务和项目之间有相似之处。

○ SRE 倾向于充当不同开发团队之间的粘合剂，利用不同的软件来创建

缺点

○  通常缺乏 SRE 团队章程，或章程规定公司中的一切都可能在范围之内，冒着使团队超负荷的风险。

○  随着公司和系统复杂性的增长，这样的团队倾向于从能够对所有事物产生深远的积极影响，转向做出更多浅薄的贡献。有一些方法可以缓解这种现象，而无需完全更改实施，或启动另一个团队（请参阅下面的服务层）。

○  涉及此类团队的问题可能会对您的整个业务产生负面影响。

推荐给：一家只有几个应用程序和用户流程的公司，在没有专门的 SRE 团队的情况下，采用 SRE 做法和对角色的需求已经超出了可以配备的人员，但是范围很小，以至于无法拥有多个 SRE 团队。

02

基础设施

这些团队倾向于专注于幕后工作，这些工作有助于使其他团队的工作更快，更轻松。常见的实现包括维护共享服务（例如 Kubernetes 集群），或维护在“公共云”的提供商，例如，Google Cloud Platform（GCP），之上构建的公共组件（例如，CI/CD，监控，IAM 或 VPC 配置）。这不同于从事与产品相关的服务的 SREs，即内部编写的面向客户的代码。

优点

○  允许产品开发人员使用 DevOps 实践来维护面向用户的产品，而在整个企业中的实践上没有分歧。

○  SRE 可以专注于提供高度可靠的基础架构。他们通常将生产标准定义为代码，并努力消除任何尖锐的边缘，以大大简化产品开发人员运行自己的服务的过程。

缺点

○  根据基础架构的范围，涉及此类团队的问题可能会对您的整个业务产生负面影响，类似于 Kitchen Sink 实施。

○  缺乏与公司客户的直接联系，可能导致人们将重点放在不一定与客户体验相关的基础架构改进上。

○  随着公司和系统复杂性的增加，可能需要拆分基础架构团队，因此适用与产品/应用程序团队相关的弊端（请参见下文）。

推荐给：具有多个开发团队的任何公司，因为您可能必须配备基础架构团队（或考虑配备基础架构团队）来定义通用标准和实践。对于大型公司来说，同时拥有基础架构DevOps 团队和 SRE 团队是很常见的。DevOps 团队将专注于客户化 FLOSS，并为应用程序团队编写自己的软件（功能），而 SRE 团队则专注于可靠性。

03

工具

仅有工具的 SRE 团队倾向于专注于构建软件，以帮助开发人员评估，维护和提高系统可靠性或SRE工作的任何其他方面，例如，容量规划。

可以认为工具是基础架构的一部分，因此 SRE 团队的实现是相同的。的确，这两种类型的团队相当相似。实际上，通常与基础架构团队相关联的服务路径上的共享后端相反，工具团队倾向于将更多的精力放在具有面向可靠性功能集的支持和计划系统上。

副作用是，通常会有更多直接反馈给基础架构 SRE 团队。工具 SRE 团队冒着为业务解决错误问题的风险，因此需要努力始终了解团队解决前线可靠性的实际问题。基础架构和工具团队的利弊往往相似。此外，对于工具团队：

缺点

○  您需要确保工具团队不会无意间变成基础架构团队，反之亦然。

○  长期辛劳和整体工作量增加的风险很高。这通常包含在由您的业务主管批准建立的团队章程中。

推荐用于：任何需要高度专业化的和可靠性相关的工具公司，而这些工具目前尚无可用的FLOSS或SaaS。

04

产品/应用程序

在这种情况下，SRE 团队将努力提高关键应用程序或业务领域的可靠性，但是诸如批处理程序之类的辅助服务的可靠性，是另一个团队的责任，通常情况下，开发人员同时涵盖 dev 和 ops 功能。

优点

○  为团队的工作提供明确的重点，并允许从业务优先级到团队努力的地方之间，明确联系起来。

缺点

○  随着公司和系统复杂性的增长，将需要新的产品/应用程序团队。每个团队的产品重点，可能导致基础架构的重复，或团队之间实践的差异，这样效率低下，并限制了知识共享和流动。

推荐用于：对于这样的公司，作为第二个或第n个团队，以 Kitchen Sink，基础设施或工具团队为起点，并且具有关键的面向用户的应用程序，并且具有很高的可靠性需求，这证明专用的 SREs 的费用相对较高。

05

嵌入式

这些 SRE 团队，让 SREs 嵌入了他们的对应的开发团队，通常是每个开发团队一个。嵌入的 SREs 通常与开发人员共享一个办公室，但是嵌入式安排可以是远程的。

嵌入式 SRE 与开发人员之间的工作关系，往往受到项目或时间的限制。在嵌入式安排期间，SREs 通常是非常操作性的，执行诸如更改代码和服务配置之类的工作。

优点

○  使专注的 SRE 专业知识可以导向特定的问题或团队。

○  可以同步演示 SRE 实践，这可以是一种非常有效的教学方法。

缺点

○  这可能导致团队之间缺乏标准化，和/或实践中的分歧。

○  SRE 可能没有机会与同伴花费很多时间来指导他们。

推荐用于：此实现可以很好地启动 SRE 功能，或进一步扩展另一个实现。当您的项目或团队需要一段时间的 SRE 时，这可能是一个很好的模型。这种类型的团队，还可以通过推动采用本方式，来增强工具或基础架构团队的影响力。

06

咨询

该实现与上述嵌入式实现非常相似。不同之处在于，咨询 SRE 团队倾向于避免更改客户代码和服务配置。

咨询 SRE 团队可能会编写代码和配置，以便为自己或开发人员构建和维护工具。如果他们执行后者，则可以说他们是咨询和工具实现的混合体。

优点

○  通过与直接更改代码和配置解耦，它可以帮助进一步扩展现有 SRE 组织的积极影响（另请参见下面对可靠性标准和实践的影响）。

缺点

○  顾问可能缺乏足够的背景来提供有用的建议。

○  鉴于他们通常不会更改代码和配置，即使他们能够间接产生技术影响，咨询 SRE 团队的常见风险被认为是非操作性的（即几乎不会产生风险）。

推荐给：直到您的公司或复杂性被认为很大，并且当需求超出了其他各种实现的现有 SRE 团队所能提供的支持时，我们才建议您配备一个专门的 SRE 顾问团队。请记住，在您为第一个 SRE 团队配备人员之前，我们建议配备一个或几个兼职顾问（请参见上文）。

SRE 团队实施的常见修改

我们已经看到了对于上述大多数实现的两个常见修改。

可靠性标准和实践

01

SRE 团队还可以充当整个公司的“可靠性标准和实践”小组。

标准和实践的范围可能有所不同，但是通常涵盖更改生产系统、事件管理、错误预算等的可接受方式和时间。换句话说，尽管这样的 SRE 团队可能不会直接与每个服务或开发团队进行互动，通常是团队在其专业领域内的其他地方，确定可接受的条件。

我们已经看到以两种不同的方式采用这些标准和实践：

○  影响力主要依靠有机采用，并向团队展示这些标准和实践如何帮助他们实现目标。

○  任务依赖于组织结构、流程和层次结构来推动可靠性标准和实践的采用。

任务的有效性取决于组织文化，以及 SRE 团队的经验、资历和声誉。任务的方法在其他领域中普遍地采用严格流程的组织中可能是有效的，但是在个人具有高度自治权的组织中，成功的可能性很小。在这两种情况下，即使由经验丰富的人员组成的新团队，也可能比具有通过良好实践获得高可靠性的历史和声誉的团队，更难以建立公司范围的标准。

我们还观察到软件开发是平衡这些方法的有效工具。在这种情况下，SRE 团队开发一种零配置方法，如果服务或目标团队恰巧使用预先确定的系统，则可以采用一种或多种可靠性标准和实践，并增加零设置成本。一旦他们看到使用该系统可以实现的好处（通常可以节省时间），就会影响开发团队通过提供的工具来采用这些实践。随着采用这样的系统的增加，该方法可以转向针对 SREs 的目标改进，并通过与可靠性相关的一致性测试来设定任务。

服务层级

02

无论哪种 SRE 团队模型定义了团队的范围，任何 SRE 团队都有权决定他们与所在区域内的软件和服务的互动深度。当开发团队、应用程序或基础架构的数量超过 SRE 团队能完全支持的能力时，尤其如此。解决这个挑战的常用方法是提供 SRE 参与的层次。这样做通过在这两个选项之间添加至少一层以上的内容，扩展了“对我们而言尚不存在或尚未被 SRE 看到”和“由 SRE 完全支持”的二元方法。

二元方法的一个共同特征是，“由 SRE 完全支持”通常是指在一些上线流程后，给定的服务或工作流程由 SRE 和开发人员共同拥有，包括及时响应的职责。

不幸的是，SRE 团队或任何其他团队，在他们可以完全上线多少服务的方面，往往达到极限。随着架构的多样性和服务复杂性的增加，认知负荷和记忆回忆会很痛苦。

这是 SRE 分层方法的示例：

○  第0层：零散的咨询工作，没有专门的 SRE 人员。

○  第1层：项目工作，需要一些专用的 SRE 时间。

○ 第2层：该服务已上线（或上线中）以及时响应，并获得更多的专用 SRE 时间。

这些层的实现细节根据实际的 SRE 实现本身而有所不同。例如，通常不希望咨询和嵌入式 SRE 团队在第2层上提供服务（如及时响应），但可能在第1层提供专门的人员（而不是共享人员）。我们建议定义经 SRE 和开发人员领导批准的服务层级文档。此签署与记录您的团队章程（如上所述）有关但不相同。

曾经有一个 SRE 团队采用多种实现方式的特征，而不是采用服务层的例子。例如，一个单独的 Kitchen Sink 的 SRE 团队，也可以由两名 SRE 顾问扮演双重角色。

常见的 SRE 路径

您的 SRE 组织可以按照上面的顺序实施。另一个常见的途径是实施在“开始之前”中所述的内容，然后为一个 Kitchen Sink 的 SRE 团队配备人员，但是在需要成立第二个 SRE 团队时，将基础结构的顺序按产品/应用程序交换。在这种情况下，结果是两个专门的产品/应用程序 SRE 团队。当托管的解决方案，例如，Google Cloud 提供的解决方案，以外的产品/应用程序具有足够的广度，但两个团队之间几乎没有共享基础架构时，这才有意义。

第三种常见的方法是从“开始之前”过渡到基础架构（或甚至工具）团队，跳过“Kitchen Sink”和产品/应用程序阶段。当应用程序团队有能力并且愿意定义和维护SLO时，这种方法最有意义。

我们强烈建议您尽早在SRE流程中同时评估“可靠性标准和实践”和“服务层级”，但这只有在您建立了第一个 SRE 团队之后才可行。

接下来我该怎么办？

如果您只是开始进行 SRE 练习，我们建议您阅读您有 SRE 团队吗？如何开始和评估您的旅程，然后根据我们上面共享的信息，评估最适合您需求的 SRE 实施。

如果您领导一个或多个 SRE 团队，建议您以通用的术语描述它们的实现（类似于我们上面讨论团队实现的方式），根据您自己的经验评估优缺点，并确保 SRE 团队的目标和范围是通过团队章程文档定义的。此练习可以帮助您避免过载和过早的重组。