谷歌的 SRE 和开发是如何合作的?
本文是一篇比较有价值的、介绍 SRE 的文章。国内的所谓 SRE 职责其实并不明确，大部分其实还是干普通运维的事。但文中介绍的谷歌的运作方式起点还是相对比较高的，无论对 SRE、对开发，甚至对公司都有很高的要求。正如本文所述，谷歌的方式并不一定适合其他公司，但其 SRE 的建设经验仍然能够带来一定的启发。在阅读本文的时候，我是比较好奇谷歌是如何解决 SRE 和开发相互推诿的问题的。
译自：How Google SRE And Developers Collaborate(https://itrevolution.com/how-google-sre-and-developers-collaborate/)
谷歌的 SRE 是一个专业的工程师组织，致力于设计、构建和维护大型产品服务。SRE 可以是软件工程师或系统工程师，但通常会同时具备这两种技能。
谷歌的 SRE 的任务是：
保证谷歌的产品和基础设施能够满足可用性目标 根据(1)，最大化长期特征速度 feature velocity，用于评估新特性的发布速度使用软件而非人力来完成(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 的真正作用。
我个人认为理想的业务应该是一个个可以正反馈的闭环，相关成员都能够在保证交付的前提下，提升业务的可靠性，并从中得到技能提升和成就感。作为项目管理人员，应该细化项目的迭代周期，考虑项目可能存在的风险点，避免因为操之过急，导致开发进度和可靠性都无法满足。
原文链接：https://www.cnblogs.com/charlieroro/p/16501260.html