本文是一篇比较有价值的、介绍SRE的文章。国内的所谓SRE职责其实并不明确，大部分其实还是干普通运维的事。但文中介绍的谷歌的运作方式起点还是相对比较高的，无论对SRE、对开发，甚至对公司都有很高的要求。正如本文所述，谷歌的方式并不一定适合其他公司，但其SRE的建设经验仍然能够带来一定的启发。在阅读本文的时候，我是比较好奇谷歌是如何解决SRE和开发相互推诿的问题的。

译自：How Google SRE And Developers Collaborate

谷歌的SRE是一个专业的工程师组织，致力于设计、构建和维护大型产品服务。SRE可以是软件工程师或系统工程师，但通常会同时具备这两种技能。

谷歌的SRE的任务是：

• 保证谷歌的产品和基础设施能够满足可用性目标
• 根据(1)，最大化长期特征速度(feature velocity，用于评估新特性的发布速度，参见Feature velocity and Serverless)
• 使用软件而非人力来完成(1)和(2)
• 当SRE处理(1)和(3)的效率高于开发时，SRE才会参与其中

可靠性和速度并不是互斥的，通常速度可以受益于可靠性的提升，反之亦然。然而，在产品或服务未达到期望的SLO前，(当需要在可靠性和速度之间进行权衡时)SRE会优先考虑稳定性，而非速度。如果没有达到SLO，此时产品的可靠性要比特征速度更加重要。当产品满足SLO后，以牺牲特征速度为代价来换取额外的可靠性则会适得其反。相比采用粗暴的方式来满足目标，SRE会采用工程和自动化方式(而非人力)来优化运维流程。

SLO是一个很好的判定何时该关注可靠性，何时改关注发布速度的标准。的确，如果产品服务已经达到SLO，那么继续提升像性能、可靠性等标准可能会对产品的发布造成很大影响。

作为一个专家团队，(产品开发团队，以下简称Dev对)谷歌SRE有着很高的需求量；SRE能够带来额外的价值的机会很多。在很多场景下，SRE可能会被放大。但如何某个问题可以被Dev组织解决，那么雇佣一个Dev而非SRE反而是一种更灵活的方式，可以减少跨组织带来的开销。引入SRE的最终的目标是使用足够的SRE来最大化影响和开销的比率(即提高性价比)。谷歌的SRE不应该作为其他公司实现SRE的蓝图，但可以作为研究案例。每个组织都是独特的，其需求和目标可能与谷歌不尽相同。但谷歌过去20年的实践经验提供了许多教训，可以帮助其他公司加速其SRE进程。

谷歌的SRE并不是静态的，它是持续演进的，谷歌的不同部门会根据需要采用不同的模型。与很多组织不同，谷歌的SRE是一个中心化的团队。SRE从最初的寥寥数人，目前已经发展为拥有近千人的团队。如下图所示，SRE团队专于特定产品领域(PA)，并与该PA中的开发人员密切合作。SRE PAs的数目是可变的，可能会包含近百个SRE。SRE PAs由Dev伙伴组织提供资助，并在每个组织层面与之合作。一个SRE PA通常要比Dev伙伴组织小一个数量级，但比率可能相差很大。大多数SRE团队都有两个工作点，每个点有6到8个SRE，时区差为5到9个小时，以实on-call轮换。

可以看到谷歌的SRE是一个中心化的独立组织，更像是一个项目人力资源池。SRE和Dev会签订合作条约，规定合作范围和内容，以及合作目标，并由Dev提供资金支持。

这种组织架构看起来更有点像甲乙方的关系。对于大多数公司来说其实并不适合，主要有以下几个方面的考量：

• SRE进入Dev其实也是有成本的，需要学习了解Dev的产品和服务功能。
• 跨团队运作存在沟通成本、职责明确等问题
• 如果公司没有足够的业务资助SRE团队，有可能SRE团队优先会成为某些情况下的成本优化对象。

当然好处也是有的，就是更灵活，也让SRE更加纯粹，避免在项目结束之后变为业务运维之类的角色。

合作原则

SRE的工作是基于合作(engatement)的，与Dev同步展开。一个合作会同时涉及到两方，通常会围绕特定的服务或产品。大多数情况下，SRE和Dev之间的合作就是为了提升稳定性、基础设施以及针对特定产品系统的运维而建立的伙伴关系。其他合作可则能会关注产品的端到端用户体验或某个水平架构主题。任何一种合作都可能会跨多个产品系统。一个典型的SRE团队会与系统开发范围内的Dev团队保持一系列合作。

合作模型是谷歌SRE的基本观念。它描述了合作和一系列最佳实践(高效分配资源、沟通、协调以及SRE和Dev之间的协作)原则。它不是一个基于规则的静态模型，但为相关方提供了清晰的界限并设定了相互预期，并且可以轻松识别异常或降低合作度。

本章描述了合作模型的原则，下面将讨论合作类型以及如何在实践中使用它们。

合作原则是这种组织架构核心。它规定了SRE的工作范畴，避免SRE沦为测试+运维角色。

对齐SRE的使命

如前所述，SRE的使命是提高可靠性、效率以及提高谷歌产品的发布速度，保持团队的健康。这种使命应该贯穿每个合作，且每次合作都应该对这些目标产生可衡量的积极影响。

倡导用户

SRE是用户和用户体验的倡导者--无论是外部用户还是内部用户。事实上，可以由系统(或系统组)罗列出SRE的合作内容，但这不应该削弱SRE对用户如何感知可靠性(或缺乏可靠性)的关注。这种关注反映了强调端到端或以客户为中心、SLOs以及SRE的职责重点是关注开发合作伙伴的可靠性差距和风险，即使这些不在SRE团队的直接责任范围内。建议首先在产品层面对齐，然后再让SRE团队关注关键用户的历程(critical user journeys (CUJs))或端到端体验(即使SRE直接负责的特定领域被划定在一组(可能比较宽泛的)服务下)。

这其实是对SRE的一个高要求，总体目标是做出一个好的产品。

清晰的价值定位

SRE只应承担能够比其他任何人更有效执行的工作。将一个特定的团队添加到Dev团队中会引入额外的组织复杂度并增加孤岛风险。如果所有工作都能保证跟在Dev团队内部一样的质量和效率，那么这种方案是可行的，但在需求变更时，让所有团队更加灵活地转变工作并不是一件容易的事情。

SRE是技术娴熟的专业工程师，他们是备受追捧的人才，薪酬与开发同行相当。为了判定是否添加SRE的headcount ，一个合作应该包括具有持久价值的大量可靠性工作，而不是以on-call内容为主。否则，添加Dev的headcount则更有意义。为了深入了解哪些工程流提供了最高的价值，可以引入一定量的on-call工作。但是，给训练有素的工程师团队提供大量on-call工作可能会导致SRE团队内部的不满。由于Dev团队太小或由于Dev团队在某个单独的位置而无法覆盖其on-call的工作内容而引入SRE是错误的，这并不是证明SRE参与的充分理由。

明确范围

SRE团队的工作范围应该局限于某些服务(或CUJs)，并且有明确的相关性和界限。SRE不会对特定的服务负责，通常会对Dev团队的所有服务提供基础的支持。Dev和SRE领导层需要定期协商合作范围。

这一点至关重要，如果没有明确的工作范围和界限，SRE就可能被放大处理很多边界模糊的内容，沦为集多种职责于一身的角色。

由开发资助

SRE PAs接受Dev组织授予的headcount 。SRE不通过其自身的管理链接受headcount ，也不能携带未分配的headcount 。虽然Dev资助了SRE团队，但一旦转移了headcount，则由SRE负责该headcount。SRE PA负责人有义务与资助的Dev伙伴进行协商，以便能高效、有效地使用该headcount。如果无法通过SRE工作提供比Dev伙伴更有价值的工作，则需要将该headcount返回给Dev组织。

资助应该是长期的。因为过程中会花费比较长的时间来招聘SREs，并让其在SREs岗位上就职。出于这种原因，谷歌SRE计划在两年或两年以上的时间范围内为headcount 提供资金，并且不将资金与短期、有时间限制的活动挂钩。员工人数的波动将导致效率低下，并且无法让SRE团队深度参与到产品中。

SRE和Dev领导会审视合作的资助程度，例如按年度进行资助。过程中应该考虑合作类型是否正确以及是否降低或增加资金(如通过授予或返还headcount ，或在SRE内重新分配)，最终双方达成一致。然而，SRE领导层拥有在现有headcount的限制下分配项目优先级的权利。否则，可能无法充分考虑到安排足够的合作人员等因素。

战略伙伴关系

卓越的产品是一项长期投资。合作不应该仅限于SRE PA层面。SRE PA作为一个整体，应该具有与Dev 组织相同并与之互补的战略愿景，不能仅仅进行一系列毫无联系的合作。SRE PA领导需要有SRE PA愿景，并负责与Dev组织领导优先协商任务。

每个单独的合作都是根据多年的规划建立起来的。合作有望在Dev和SRE之间建立一个共同的路线图，所开展的工作应该在SRE和Dev之间双向移动。SRE不应仅仅执行Dev交过来的任务。

应该在安排出现问题之前设定预期值。否则在胁迫下，很难达成书面协议。系统及其组件会发生变化、合并和偏差。SRE需要小心地使用产品，如果没有足够的启动时间，就不能立即支持新系统。

Dev所有权

不考虑合作的类型，服务本身以及服务的可靠性隶属于Dev团队(即便在某些形式的合作下日常生产权限属于SRE)。这意味着保障服务可靠性的责任并没有下发到SRE团队中，SRE团队的成员是专业的可靠性工程师，他们通过某种类型的合作与Dev团队建立伙伴关系，并帮助Dev团队达到可靠性目标(这反过来规定了SRE对Dev的责任)。

积极、稳健的开发人员参与是服务健康的一部分。由于SRE并不会控制headcount的分派，因此不能单独负责某个服务，历史上，当Dev合作结束之后，这些服务仍然由SRE提供服务，但通常结局都比较糟糕。因此，如果Dev团队打算减少人员配置，则还需要减少服务本身，并将剩余用户迁移到其他服务。一旦Dev不再资助，SRE的服务合作将立即结束，分配的headcount将在Dev合作结束之后返回给Dev团队。

这也是谷歌PA的一种好处，合作是有期限的，因此开发团队不会无限制地将一些事情交给SRE。一旦合作结束，SRE将不再管理该Dev团队的事务。这反过来也对Dev团队本身提出了一定要求。

联合合作伙伴关系

开始并继续与SRE进行合作是Dev和SRE双方共同协商的结果。不能强制SRE接受某个合作，Dev也不能强制资助某一方，Dev和SRE任一方都可以结束合作。

如果Dev或SRE某一方想要结束合作，那么就应该结束本次合作，并以符合上述资助原则的方式重新审查(重新部署或返回)headcount 职位。以非协商一致的方式结束合作是双方应该避免的事情。

共同的努力

SRE和Dev可以带来不同的专长：SRE注重可靠性原则、系统架构和生产最佳实践，而Dev组织通常更加擅长其业务领域。服务的成功是一种共同努力的结果。除了不同的团队担任不同的角色外，双方都有一个共同的目标。包括联合OKRs(目标和关键结果)，并遵守错误预算策略(即当服务/CUJ达不到SLO时冻结特性发布)。Dev和SRE的共同目标是使用更有效的方式保证服务的SLO，因此违反SLO，对Dev和SRE 双方都是一个严重的问题。

SLOs和错误预算提升了对可靠性目标的理解，并可以以此衡量合作是否成功。这也使得SRE和Dev需要联合起来考虑如何在可靠性和特性速度之间进行权衡。冻结策略提供了一种简单的方法，可以在客户/用户信任有被破坏的危险时，调整这种平衡，使其达到可靠性。

运维和on-call责任也是一项共同努力，随着服务变得更加成熟，大部分(但不是100%)的维护责任通常由SRE承担。

SLOs是一个很好的团队粘合剂，可以让双方为同一目标而共同努力。但由于是不同的团队，SRE领导也需要对项目的SLO进行评估，避免因为不合理的SLOs或不成熟的团队导致无法达成目标。

SRE不是一个"运维团队"

SRE的使命不是处理运维工作，而是提升系统的可靠性。on-call是结束SRE的一种手段，通常这种方式提供了其他方面无法提供的宝贵见解，但on-call工作本身并没有长期价值。on-call不应该是SRE的核心工作，且单凭这一点并不能证明成立SRE团队是合理的。应该严格限制SRE的运维工作，SRE团队的苦力工作(中断，生产清理等)不应该超过50%的时间。如果超过该阈值，Dev必须负责处理额外的运维工作。这种机制保障了SRE有足够的时间来改善项目，进而降低运维压力。

Dev应该至少承担一部分运维职责。典型示例包括升级下的次级on-call轮换、非生产环境的所有权、和/或处理非关键运维工作。接触运维对于维持和培养Dev团队的生产知识至关重要。应以书面形式跟踪责任划分，以避免误解。

谷歌能够保证SRE的核心职责的一个原因也有组织架构的一部分因素在起作用。由于合作期限的约束，使得Dev团队不能将所有运维和on-call职责都交给SRE。

运维并不是零和游戏

SRE合作应该关注降低整体的运维压力，而不是将运维职责从一处转移到另一处。一个成功的合作会将运维压力降低到理想程度。Dev应该保证24/7 on-call升级路线。

授人以渔

SRE不应该作为生产的人类抽象层。这种方法不可扩展，加强了孤岛，破坏了关键反馈回路，并将生产复杂性转化为证明SRE存在的理由。相反，SRE应该帮助Dev更深刻地理解服务的生产特性

提升生产标准

SRE应促进使用通用生产平台和标准化基础设施。这种平台有几个优点：

• 提供了一致的服务管理基础设置，降低了实现跨服务需求的实现成本
• 降低生产中运营个人服务的持续成本(例如，入职时间、工程师培训时间、劳动)。
• 总体降低支持生产中所有服务的成本；通过使传授技能，工程师可以更轻松地处理不同的服务
• 降低开发人员和SRE之间以及不同SRE团队之间转移服务的成本。
• 提高工程师在团队之间的流动性。
• 简化并降低生产风险
• 提高工程师的速度
• 提高整体的生产服务资源利用率

SRE应发布SRE PA级别的生产平台标准---该原则适用于服务，与SRE的支持级别无关。

有意义的工作

必须考虑工作质量。谷歌的SRE与Dev有着相同的流动机会，因此需要一个新颖、富有挑战性、有趣的环境来实现个人发展。SRE在OKR规划方面与Dev密切合作，但最终拥有自己的OKR。

进度追踪

与SRE的合作是一项重大投资，需要结构化规划和进度追踪。SRE和Dev共享一个的路线图，并跟踪目标进展，定期审查服务的健康状况、关键性、业务合理性和优先级。 这可以通过业务审查、季度报告和生产健康审查等方式实现。

左移(shift left)

SRE合作可能发生在服务生命周期的任意阶段--不局限于生产启动阶段。通常在服务生命周期的早期(即"左移"，如，在设计和实现阶段)引入SRE是最具影响力和效率的。在设计阶段，可以很容易地更改基本架构和基础设施决策，但对于一个完全产品化的系统来说，修改这些决策通常非常困难或代价高昂。早期与SRE建立合作关系可以防止以后出现严重的问题。

总结

谷歌SRE的成功带有特定的企业基因：

• 公司体量：保证了SRE的"就业市场"
• 公司人员素质：保证了Dev和SRE团队的人员能够遵守相关流程约定，并能够保证绝大部分人员的技能水平和职业素养。

因此谷歌的SRE并不一定适用于其他企业，但其所提倡的SRE中心化也有其存在的意义，除了灵活地支持各个业务线，也可以让SRE避免沦为业务运维工具人。让SRE和Dev以SLOs作为决定提高可靠性还是特征速度的分界线，以此可以让各个团队有一个共同的目标。另外一个至关重要的是合作约定，该约定类似合同，除了保证SLOs的完成，也是可以避免SRE放大化的一个重要条约。

除了对SRE和Dev的硬性要求外，文中还提出了一些建议性的意见。但这需要各个团队成员具有一定程度的职业素养，且能够形成正反馈才能真正实现。文中所描述的SRE更像是个战斗旅和专家顾问的角色，不应该将其作为传统运维或on-call轮岗人员，这样会降低SRE的工作热情，无法发挥SRE的真正作用。

我个人认为理想的业务应该是一个个可以正反馈的闭环，相关成员都能够在保证交付的前提下，提升业务的可靠性，并从中得到技能提升和成就感。作为项目管理人员，应该细化项目的迭代周期，考虑项目可能存在的风险点，避免因为操之过急，导致开发进度和可靠性都无法满足。