第8章 SRE 与其他团队协作

框架团队与产品团队

章节导读

如果说前面几章讨论的是 SRE 与机器系统的关系——如何设定 SLO、如何设计告警、如何防止过载、如何保障数据管道——那么从本章开始，蓝皮书转向了一个同样关键却常被技术团队低估的维度：SRE 与人的系统。可靠性从来不是 SRE 一个团队能独立交付的产品，它诞生于 SRE 与开发团队、产品团队、其他 SRE 团队之间无数次具体的协作：一次设计评审上的争论、一份接管协议的签署、一场事故中的并肩作战、一个「这个服务我们暂时不能接」的艰难决定。协作机制设计得好，SRE 是组织的可靠性放大器；设计得不好，SRE 会沦为高级救火队，或者更糟——成为与开发团队互相指责的新「墙」。Google 用二十年时间打磨出的协作模式，正是本章要拆解的内容。先从一个真实困境说起。某公司的 SRE 团队成立半年，接手了三个核心服务，团队成员疲惫不堪：半夜告警不断，但每次深入排查都发现根因在代码里，需要开发团队修复；开发团队的态度是「生产环境归你们管，我们只管写功能」；SRE 想推动架构改进，却发现自己对这个服务既没有代码权限也没有决策权。这是典型的「责任与权力错配」：SRE 承担了生产责任，却没有获得相应的权限和开发团队的实质性投入。蓝皮书第 8 章的核心命题就是解决这个错配——SRE 与其他团队的合作必须建立在明确的契约之上，而不是模糊的善意。契约的第一块基石是责任边界。SRE 与开发团队之间需要回答一系列具体问题：谁负责值班？谁负责修复代码级 bug？谁负责容量规划？谁有权决定「牺牲可靠性换功能速度」？Google 的答案不是「一刀切」，而是按参与模式分层：嵌入式 SRE 承担完整生产责任但深度参与设计决策；咨询式 SRE 提供专业意见但生产责任仍在开发团队；框架 SRE 提供工具平台让各团队自助。每种模式对应不同的责任矩阵，而选择哪种模式取决于服务的业务关键度、团队的工程成熟度和 SRE 的人力预算。契约的第二块基石是共同的度量语言——SLO 和错误预算。第 3 章讲过错误预算如何把「可靠性 vs 速度」的立场之争转化为数据驱动的决策，本章要讨论的是它在跨团队协作中的制度角色：当产品团队想在错误预算耗尽时强行发布，仲裁机制是什么？当开发团队认为 SLO 定得太保守，调整流程是什么？Google 的实践是把这些规则写成书面的错误预算政策，由 SRE 与产品负责人共同签署——事先约定好游戏规则，事中就不需要靠嗓门和职级解决问题。契约的第三块基石是结构化的协作仪式：设计评审（Design Review）让 SRE 在架构定型之前注入可靠性视角——事后改造的成本是事前设计的十倍；生产就绪评审（PRR）在服务上线或接管前系统性排查可靠性债务；简单化框架（Simplification Framework）帮助团队识别并删除不必要的复杂度。这些仪式的共同点是「把协作流程化」：不依赖某个 SRE 恰好被邀请参加会议，而是让可靠性评审成为服务生命周期的标准关卡。本章还会深入讨论几个高难度的协作场景。第一个是「当 SRE 说不」：拒绝接管一个服务是 SRE 团队最重要也最容易得罪人的能力。Google 的 SRE 团队有明确的拒绝标准——没有明确的 owner、不愿转移生产权限、不愿投入资源改进、PRR 严重不达标——以及标准的拒绝话术：不是「不接」，而是「满足这些条件后我们再接」。拒绝的纪律保护的不只是 SRE 团队自己，更是整个 SRE 职能的公信力：如果什么服务都接，接了就垮，最终所有团队都不会再信任 SRE。第二个场景是框架团队（Framework SRE）的运作：当组织里有几十个 SRE 团队时，如何避免每个团队重复造轮子？Google 的答案是设立专门的框架 SRE 团队，把监控模板、发布流水线、容量规划工具、值班系统做成内部平台产品，用「产品思维」服务其他 SRE——框架团队的成功标准不是自己做了多少事，而是其他团队因此少做了多少事。第三个场景是嵌入式与咨询式的动态切换：一个服务可能起步时用咨询模式培养开发团队的可靠性能力，成熟后升级为嵌入式接管，也可能因为业务边缘化而降级为纯平台自助支持。参与模式不是身份标签，而是随服务生命周期调整的协作档位。理解本章内容有一个贯穿性的类比：SRE 与其他团队的关系，就像专科医生与全科医生的关系。专科医生（SRE）拥有深厚的专业知识，但不能替全科医生（开发团队）管理病人的日常健康；全科医生负责日常诊疗，但遇到复杂病症需要专科会诊（设计评审）、转诊标准（PRR）和明确的分工协议（责任矩阵）。最糟糕的医疗体系是专科医生变成「万能急诊室」——什么都接、什么都治不好；最糟糕的 SRE 组织也是如此。健康的协作体系让每个角色在自己的能力圈内发挥最大价值，用清晰的接口连接彼此。接下来的内容将具体展开：责任边界的划分方法与 RACI 矩阵、与产品团队的错误预算谈判、框架团队的建设路径、嵌入式与咨询式的选择决策树、设计评审与 PRR 的操作细节、拒绝接管的标准与流程、以及跨团队事故协作的无指责文化。无论你正在组建 SRE 团队、已经身处其中、还是与 SRE 合作的开发或产品人员，这些协作模式都能帮你把「可靠性」从一句口号变成一套可持续运转的组织机制。

核心概念

框架 SRE
嵌入式 SRE
责任边界
设计评审

要点精析

责任边界：SRE 与开发团队的契约设计。SRE 与开发团队协作失败的根源，几乎总是责任边界模糊——出了事互相推诿，平时互相观望。健康的边界设计需要回答一组具体问题：谁承担值班响应（on-call）？谁负责修复代码级缺陷？谁负责容量规划与扩容执行？谁负责监控告警的维护？谁有权批准 SLO 变更？Google 的经验是用 RACI 矩阵（Responsible 执行者、Accountable 负责者、Consulted 被咨询者、Informed 被告知者）把每个运维职责显式分配到角色，而不是留给「默契」。嵌入式模式下，SRE 是生产环境的 R 和 A，开发团队是代码修复的 R、架构决策的 C；咨询式模式下则相反，开发团队承担生产责任，SRE 只是 C。边界设计有三个常见误区。误区一：「共同负责」——RACI 里每个格子都填两个团队，等于没人负责，Accountable 必须唯一。误区二：责任与权限分离——让 SRE 值班却不给生产变更权限，等于让人赤手空拳上战场；权限必须随责任一起转移。误区三：边界一成不变——服务成熟度在变、团队人员在变，责任矩阵应该每半年复审一次，重大架构变更后立即复审。检验边界是否清晰的实用方法是「半夜测试」：凌晨三点某类故障发生，值班的人不需要思考就知道自己该做什么、什么情况下升级给谁。如果答案模糊，边界就有洞。另一个关键实践是把边界写成文档并双方签署——仪式感不是官僚主义，它迫使双方认真讨论那些平时回避的尴尬问题（比如「你们的代码 bug 导致我半夜起床，修复的 SLA 是什么」），并把共识固化下来。

与产品团队的协作：可靠性与功能的权衡谈判。SRE 与产品团队的张力是结构性的：产品团队的成功指标是功能上线速度和用户增长，SRE 的成功指标是稳定性和错误预算健康度，两者天然存在拉扯。蓝皮书的核心洞见是：不要试图消灭这种张力，而要给它一个公平的竞技场——错误预算。谈判的制度设计包含几个要素。第一，SLO 的共同制定：SLO 不能由 SRE 单方面强加，也不能由产品单方面拍板，正确流程是 SRE 提供工程视角（当前系统实际能达到的可靠性、每提升一个 9 的成本），产品提供用户视角（用户能感知什么、竞品水平、合同承诺），双方基于事实协商。第二，错误预算政策的书面化：预算充足时产品团队有完全的发布自由，SRE 不得以「风险」为由阻拦；预算耗尽时发布冻结，产品团队不得以「业务紧急」为由绕过——除非走明确的豁免流程（安全修复、可靠性修复、双方负责人共同签字的紧急业务变更）。第三，仲裁机制：当双方对豁免有分歧，升级到更高层级（如工程 VP）裁决，但升级应该是例外而非常态，频繁升级说明政策本身有漏洞。Google 的真实案例：某产品团队在预算耗尽后要求发布一个重要功能，SRE 拒绝，双方升级到 VP；VP 没有直接拍板，而是要求产品团队量化「延迟两周发布的损失」与 SRE 量化「带病发布的事故概率与影响」，数据摆出来后双方自己达成了「先修复最大风险项、两周后发布」的折中方案。这个案例的精髓是：错误预算机制把「权力博弈」转化为「数据对话」，而管理层的角色是维护机制而非代替机制做决定。

框架 SRE：为其他 SRE 团队提供杠杆。当组织的 SRE 团队从 1 个变成 10 个、50 个，一个新问题浮现：每个团队都在重复解决相同的问题——搭监控、写发布脚本、做容量模型、建值班轮换。框架 SRE（Framework SRE）就是为解决这种重复而生：一个专门构建可靠性基础设施的内部平台团队，它的「客户」是其他 SRE 团队和产品团队。Google 的框架 SRE 产出包括：标准化的监控模板（新服务接入即获得 SLI 仪表盘和告警基线）、统一的生产就绪评审工具、容量规划框架、发布流水线平台、事故管理工具。框架团队的成功标准与业务 SRE 截然不同：不是「我们处理了多少事故」，而是「其他团队因为我们的工具少花了多少时间、少犯了多少错误」。衡量指标例如：新服务达到生产就绪的平均时间、PRR 一次通过率、告警模板的采用率、每服务的平均值班负载。运营框架团队有三个关键实践。第一，产品思维：框架团队要把自己的工具当产品运营——做用户调研（其他 SRE 的痛点是什么）、写使用文档、收集反馈、发布版本说明，而不是「扔一个内部工具出来爱用不用」。第二，采用靠拉力不靠推力：强制推广会激起抵触，好的框架工具应该让早期采用者明显受益（接入监控模板后值班告警噪音下降 60%），口碑自然传播。第三，警惕象牙塔化：框架团队成员必须定期参与一线值班和事故响应，否则构建的工具会脱离实战——Google 的框架 SRE 通常保留一定比例的一线支持工作。框架 SRE 与业务 SRE 的关系是「杠杆与支点」：一个优秀的框架团队能让整个组织的可靠性水位系统性抬升，这是任何单个嵌入式团队都无法做到的规模效应。

嵌入式 SRE vs 咨询式 SRE：参与模式的选择。这是 SRE 组织设计的核心决策之一，两种模式各有明确的适用场景。嵌入式 SRE（Embedded）：SRE 工程师全职加入产品团队，与开发人员坐在一起（或至少在同一个汇报线），承担完整生产责任包括值班。优势是深度上下文——嵌入式 SRE 了解代码、了解业务、了解团队，能做出最贴合的可靠性决策；劣势是成本高（一个团队至少需要 2-3 名 SRE 才能维持健康轮换）和视野局限（深陷单一产品，容易失去跨团队的最佳实践视角）。咨询式 SRE（Consulting）：SRE 团队作为顾问服务多个产品团队，参与设计评审和 PRR，提供专业建议，但生产责任仍在开发团队。优势是杠杆率高（一个咨询 SRE 可以支持 5-10 个团队）和视野广阔（见过各种系统的坑，能横向移植经验）；劣势是建议缺乏强制力（「说了他们不听」）和上下文浅（每次介入都要重新了解系统）。选择的决策框架基于三个维度：业务关键度（营收核心、用户直接感知的服务值得嵌入式投入）、团队成熟度（开发团队工程能力强、有可靠性意识的，咨询式即可；反之需要嵌入式手把手带）、SRE 人力预算（嵌入式的人均服务覆盖数远低于咨询式，人力紧张时只能好钢用在刀刃上）。Google 的典型配比是少数核心服务嵌入式、大多数服务咨询式加框架支持。一个重要的动态视角：模式可以演进——新服务起步用咨询式帮助建立基础，业务变关键后升级嵌入式；或者嵌入式 SRE 服务团队两年后，把日常生产责任移交给已经成熟的开发团队，自己转向咨询角色。蓝皮书特别提醒：最糟糕的状态是「半嵌入式」——SRE 人在产品团队但生产责任不清，既没有嵌入式的权限也没有咨询式的独立性，两头不讨好。

设计评审：把可靠性注入架构定型之前。修复一个架构级可靠性缺陷的成本，在设计阶段是 1，在开发阶段是 10，在上线后是 100——这个粗略的数量级关系解释了为什么 SRE 必须参与设计评审（Design Review）。设计评审是 SRE 影响力杠杆最高的协作场景：一次两小时的评审提出的意见，可能避免未来两年的值班噩梦。SRE 在设计评审中应该问的核心问题清单：这个服务的 SLO 是什么，架构能否支撑？所有外部依赖列出来了吗，每个依赖故障时行为是什么（超时多久、重试几次、降级到什么状态）？有没有单点故障？容量模型是什么，单实例能扛多少 QPS，如何扩容？发布方式是什么，能否金丝雀，回滚要多久？状态存在哪里，备份策略是什么，恢复演练过吗？监控怎么做，SLI 从哪里采集？过载时会发生什么，有保护机制吗？评审的时机同样重要：太早（只有模糊想法）SRE 无从评起，太晚（架构已定型、代码写了一半）修改成本已经很高。最佳窗口是「架构草图完成、详细设计开始前」。Google 的实践是重大项目的评审分两轮：第一轮概念评审（判断方向性风险），第二轮详细评审（逐项过检查清单）。评审的输出不是「通过/不通过」的二元判决，而是风险清单加改进建议——SRE 的角色是「专业顾问」而非「审批官僚」，最终决策权在项目负责人，但 SRE 的意见和项目的回应都应该记录在案。常见的失败模式是评审流于形式：SRE 被拉进会议但没有提前材料、只能即兴提问，会后意见无人跟进。对策是制度化：评审材料提前 48 小时分发、检查清单作为标准模板、每条意见有明确的处理状态（采纳/拒绝及理由）、上线前的 PRR 回查设计评审遗留项。

生产就绪评审（PRR）：接管与上线的标准关卡。PRR 在第 2 章已有详述，本章从协作视角补充它的组织意义：PRR 本质上是 SRE 与开发团队之间的「验收仪式」，它把「服务是否可靠」从主观印象变成结构化证据。协作视角下 PRR 的三个关键设计。第一，PRR 是共同工作而非单方审计：Google 的 PRR 由 SRE 和开发团队一起完成，开发团队先自评，SRE 复核并补充——这个过程本身就是知识转移，SRE 通过追问了解系统，开发团队通过自评发现自己从未想过的问题（「等等，我们的备份好像从来没验证过能恢复」）。第二，PRR 结果与接管决定显式挂钩：READY 才接管，CONDITIONAL 附带限期改进承诺接管，NOT_READY 明确拒绝并给出达标路径。这种透明规则让「拒绝」不再是人际冲突，而是标准的执行。第三，PRR 是活文档：服务重大变更后触发增量评审，每次事故复盘检查「PRR 为什么没拦住这个问题」并更新清单——PRR 检查清单的演进史就是组织可靠性认知的成长史。PRR 与其他协作机制的关系：设计评审关注「未来的架构」，PRR 关注「当下的状态」，事故复盘关注「过去的教训」，三者形成闭环——设计评审的意见在 PRR 验证落地，事故的教训反哺两者的清单更新。一个值得强调的细节是 PRR 的「证据文化」：每个检查项不接受口头保证，必须提供可验证的证据——监控项要给出仪表盘链接和最近一个月的数据，备份要给出最近一次恢复演练的记录，容量要给出压测报告。证据要求看似苛刻，实则保护双方：它让开发团队的投入被看见（有证据的完备监控是实打实的工程成果），也让 SRE 的接管决定经得起事后检验。

当 SRE 说不：拒绝接管的标准与艺术。拒绝接管不可靠的服务，是 SRE 团队最重要也最反直觉的能力。直觉上，SRE 存在的意义就是接管生产责任，拒绝似乎违背使命；但 Google 二十年经验得出的结论恰恰相反：无原则的接管会摧毁 SRE 团队和 SRE 职能本身。逻辑链条是这样的：接管一个不达标的服务，意味着 SRE 立即陷入告警海洋和事故泥潭；团队时间被救火占满，无法做工程改进；服务质量没有改善，开发团队认为「SRE 接了也没什么用」；SRE 士气崩溃、人员流失；最终组织对 SRE 职能失去信心。因此，拒绝不是消极防御，而是保护 SRE 长期有效性的积极策略。拒绝的标准应该事先公开、对事不对人：服务没有明确的 owner（半夜需要业务决策时找不到人拍板）；开发团队不愿转移生产权限（只想要 SRE 值班却不让 SRE 操作生产）；PRR 评分严重不达标且团队不愿投入资源改进；服务的重要性不足以支撑 SRE 的人力成本（边缘服务应该走平台自助而非人工接管）。拒绝的艺术在于话术和替代方案：永远不说「我们不接」，而说「满足这些条件后我们接管，这是条件清单和我们的评估依据，我们可以先用咨询模式帮你们达标」。这种「有条件的 yes」把对抗转化为合作路线图。升级压力是必然的——被拒绝的团队往往会找管理层施压，此时事先公开的拒绝标准就是 SRE 的护身符：管理层可以基于标准讨论「这个服务是否值得特批资源」，但不能要求 SRE 无标准地接盘。Google 还有一个精妙的机制：拒绝接管的同时提供「轻量级支持包」（标准监控模板、值班手册模板、培训名额），让被拒绝的团队感受到 SRE 是助力而非障碍。拒绝的终极目标不是把服务挡在门外，而是倒逼服务变得值得接管。

内部 SLO 契约：团队间服务质量的书面承诺。当组织内服务之间形成依赖网络，一个隐蔽的可靠性问题出现了：你的服务依赖的内部服务没有承诺任何质量水平，它挂了你的 SLO 陪葬，而你无从追责也无从规划。内部 SLO 契约（Internal SLO Contract）就是解决这个问题的机制：服务提供方对自己的消费者做出书面的质量承诺，包括可用性目标（如 99.95%）、延迟目标（如 P99 < 200ms）、变更通知义务（如破坏性变更提前 14 天通知）、支持承诺（如工作时间 4 小时响应）。契约的价值在三方面。第一，依赖治理：有了契约，消费方可以计算「依赖链的可靠性预算」——如果我的 SLO 是 99.9%，而强依赖的内部服务只承诺 99.5%，这在数学上就不可行，必须推动提供方提升或改造架构（加缓存、降级、多供应商）。第二，事故问责的非情绪化：依赖服务故障导致你的 SLO 违约时，契约让「这是谁的错误预算消耗」有据可查，避免事故复盘变成扯皮大会。第三，变更协调：契约中的变更通知条款是防止「上游悄悄改 schema 打挂下游」这类经典事故的第一道防线。制定契约的实践要点：承诺要基于历史数据而非美好愿望（先看过去 90 天实际达到的水平，契约定在略高于现状的位置）；契约要有版本和复审周期（每半年对照实际表现修订）；违约的后果要事先约定（通常是提供方错误预算冻结——违约期间暂停自己的功能发布，优先修复可靠性）。Google 内部基础设施团队（Borg、Spanner、Chubby 的运维团队）对上层服务都有明确的 SLO 承诺，这是整个生产体系可组合可靠性的基础。对中小组织的建议：不必给所有服务建契约，从「被依赖最多的 5 个核心服务」开始，契约模板一页纸即可，重要的是养成「依赖必须有承诺」的文化。

跨团队事故协作：指挥体系与无指责文化。重大事故几乎必然跨越团队边界：故障在 A 团队的服务显现，根因在 B 团队的变更，修复需要 C 团队的基础设施配合。跨团队事故协作的效率，取决于两个平时就要建设的东西：指挥体系和信任文化。指挥体系方面，Google 采用类似消防部门 ICS（Incident Command System）的结构：事故指挥官（Incident Commander）统一协调，不亲自排查；操作团队（Ops）执行具体修复动作；沟通负责人（Communications）对外同步信息、对内隔离噪音；规划负责人（Planning）记录时间线、跟踪待办。跨团队事故的关键规则是「指挥官唯一」——无论涉及多少团队，指挥权必须集中在一人，多头指挥是事故延长的头号人祸。指挥官不一定来自责任团队，事实上由第三方团队（如 SRE）担任往往更客观。信任文化方面，无指责事后分析（Blameless Postmortem）是跨团队协作的粘合剂。原理很简单：如果事故复盘变成追责大会，各团队在事故中就会倾向于隐瞒信息、推卸责任、自我保护——而这些行为恰恰延长事故、掩盖根因。无指责的核心不是「不追究责任」，而是「假设每个人在当时掌握的信息下做出了合理决策」，复盘聚焦于「什么样的系统和流程让这个错误得以发生」而非「谁犯了错」。跨团队复盘的实操要点：复盘会议由中立方（SRE 或专门的可靠性团队）主持；时间线还原基于客观数据（日志、监控、聊天记录）而非各方记忆；行动项分配到团队而非个人，且每个行动项有负责人和截止日期；行动项完成情况定期跟踪——「写了复盘不改问题」比不复盘更伤士气。Google 的复盘报告有标准模板和触发标准（用户可见宕机、数据丢失、响应时间超过阈值等自动触发），高严重度事故的复盘会由更高层级评审。无指责文化的检验标准：团队成员是否愿意在事故发生后第一时间公开说「是我干的」——如果敢，说明文化健康；如果都在等别人先开口，说明追责恐惧仍在。

协作反模式图鉴：识别与矫正。蓝皮书和 Google 的多年实践中反复出现一些协作反模式，识别它们是改善的第一步。反模式一：「救火队 SRE」——SRE 团队只做事故响应不做工程改进，琐事占比远超 50%，团队沦为高级运维。矫正：强制执行琐事上限，把自动化和可靠性工程列为团队 OKR，管理层考核工程产出而非救火次数。反模式二：「影子开发团队」——SRE 为了快速解决问题开始替开发团队写功能代码、修业务 bug，边界逐渐溶解，最终开发团队把 SRE 当成免费外包。矫正：明确 SRE 的代码贡献范围（可靠性工具、监控、自动化），业务代码修复的责任始终在开发团队，SRE 可以 pair 但不代劳。反模式三：「审批官僚 SRE」——SRE 把自己定位为关卡审批者，评审只挑毛病不给方案，开发团队视 SRE 为阻力并设法绕过。矫正：评审输出必须包含可执行的改进建议和替代方案，SRE 的 KPI 加入「帮助多少服务达标」而非「拦截多少上线」。反模式四：「隐形 SRE」——咨询式 SRE 给完建议就消失，不跟踪落地，建议质量逐渐脱离实际。矫正：咨询 engagements 有明确的跟进周期，SRE 参与建议实施的关键节点。反模式五：「团队私有化」——嵌入式 SRE 在产品团队待久了完全「本土化」，失去 SRE 专业社区的连接，最佳实践不再流动。矫正：嵌入式 SRE 保留在 SRE 大团队的汇报线或虚拟组织，定期轮岗，参加跨团队的 SRE 例会和复盘。反模式六：「工具强推」——框架团队闭门造车，用行政命令推广没人想用的工具。矫正：框架团队建立用户反馈渠道，用采用率和满意度而非行政覆盖率衡量成功。这些反模式的共同根源是把 SRE 与其他团队的关系理解为「职能划分」而非「协作设计」——组织结构图上画一条线很容易，让线两侧的团队真正高效协作，需要契约、仪式、文化和持续的刻意维护。

协作机制的度量与持续改进。SRE 与其他团队的协作质量本身需要度量，否则改进无从谈起。Google 和业界实践中常用的协作健康度指标包括以下几类。效率类：新服务从立项到通过 PRR 的平均时长（衡量协作流程是否顺畅）；设计评审意见的平均关闭时长；跨团队事故的 MTTA（平均确认时间）和 MTTR（平均恢复时间）中「等待其他团队响应」的时间占比（衡量事故协作的摩擦）。质量类：PRR 一次通过率（太低说明前期辅导不足，太高可能说明标准放水）；接管后 90 天内的事故率（衡量接管质量和 PRR 有效性）；内部 SLO 契约的达标率；复盘行动项的按时完成率（低于 70% 通常意味着复盘文化形式化）。满意度类：开发团队对 SRE 支持的满意度调查（Google 定期做，问题包括「SRE 的意见是否专业」「协作是否顺畅」「SRE 是否理解你的业务」）；SRE 团队自身的健康度调查（琐事占比、值班负担、士气）。这些度量的使用有三个原则。第一，度量用于诊断而非考核个人：把 PRR 通过率变成某个 SRE 的 KPI，会立刻诱发标准放水；度量的正确用法是发现系统性瓶颈（「为什么 60% 的 PRR 卡在监控项？是不是监控模板太难用了？」）。第二，趋势重于绝对值：协作机制的改进是慢变量，看季度趋势而非单点数字。第三，度量要配对话机制：数字只能提示问题，理解问题需要 SRE 与开发团队的定期对话——Google 的 SRE 团队与合作团队有季度业务回顾（Quarterly Business Review），过一遍协作数据、吐槽痛点、约定改进项。协作机制本身也遵循「演进」哲学：没有一劳永逸的组织设计，只有持续观察、持续调整的动态平衡。当你的组织引入 SRE 时，请把本章的协作契约、评审仪式、拒绝标准、度量体系一起引入——只引入技术实践而不引入协作机制的 SRE 转型，大概率会退化为换了名字的运维团队。

代码示例

/* 示例 1：生产就绪评审（PRR）检查清单模板（YAML） */
prr_checklist:
  service: payment-gateway
  version: "2.3"
  reviewers: ["sre-alice", "dev-bob"]
  date: 2024-03-15
  dimensions:
    - name: monitoring
      items:
        - check: "基于症状的 SLI 已定义（可用性/延迟/质量）"
          status: pass
          evidence: "grafana.com/d/payment-sli"
        - check: "所有强依赖有监控覆盖"
          status: gap
          evidence: "风控服务调用无延迟指标"
          action: "补充 risk_service_latency 指标，负责人 dev-bob，期限 2 周"
    - name: capacity
      items:
        - check: "单实例容量已知且有压测报告"
          status: pass
          evidence: "压测报告 2024-02：单实例 800 QPS @ P99<200ms"
        - check: "容量预测覆盖未来两个季度"
          status: gap
          action: "接入容量规划框架，期限 4 周"
    - name: incident_readiness
      items:
        - check: "值班手册覆盖 Top 10 故障场景"
          status: partial
          evidence: "手册覆盖 6 个场景"
          action: "补齐剩余 4 个场景，影子值班期间完成"
  verdict: CONDITIONAL  /* READY | CONDITIONAL | NOT_READY */
  conditions:
    - "所有 gap 项在接管前关闭或给出双方认可的期限"
    - "影子值班至少 4 周且独立处理 3 次以上真实事件"

这份 YAML 把 PRR 从「会议讨论」变成「结构化数据」，三个设计点值得学习。第一，每个检查项三要素：status（pass/gap/partial）、evidence（可验证的证据链接）、action（差距对应的具体行动，含负责人和期限）——没有证据的 pass 不算 pass，没有行动项的 gap 等于没发现。第二，verdict 三档制避免了二元判决的僵硬：CONDITIONAL 是实践中最常见的结果，它把「接管」和「改进」解耦——服务可以带着明确的改进承诺进入接管流程，而不是无限期等待完美。conditions 数组写清附加条件，影子值班要求（独立处理 3 次真实事件）是知识转移的硬指标。第三，清单进代码仓库、按版本管理：每次评审提交一个 YAML 文件，历史可追溯、可对比（「上次评审的 gap 都关了吗」），还能横向聚合分析（「全组织 PRR 最常挂的维度是什么」——这个统计直接指导框架团队的工具建设优先级）。Google 的 PRR 清单远比这份细致（每个维度十几个子项），但结构相同。起步建议：先用这份骨架跑三个服务，根据实际发现的遗漏逐步扩充清单——清单本身也应该是演进的活文档，每次事故复盘都问一句「PRR 清单需要加什么才能拦住这次事故」。

/* 示例 2：SRE 接管协议（YAML 契约模板） */
sre_engagement_agreement:
  service: payment-gateway
  engagement_model: embedded  /* embedded | consulting | framework_only */
  effective_date: 2024-05-01
  review_cadence: quarterly
  responsibilities:
    sre_team:
      - "7x24 值班响应，P1 事故 15 分钟内确认"
      - "监控告警体系的维护与优化"
      - "容量规划与扩缩容执行"
      - "发布流水线的可靠性把关（金丝雀策略、回滚预案）"
      - "主导事故复盘与行动项跟踪"
    dev_team:
      - "代码级缺陷修复：P1 缺陷 24 小时内出修复或缓解方案"
      - "值班手册的业务逻辑部分维护"
      - "PRR 改进项的按期交付"
      - "重大架构变更提前发起设计评审"
  authorities:
    sre_team:
      - "生产环境变更执行权（回滚、扩容、切流、降级）"
      - "错误预算耗尽时的发布冻结权（豁免需双方负责人联签）"
    dev_team:
      - "功能发布决策权（错误预算充足时 SRE 不得阻拦）"
      - "架构方案最终决定权（SRE 意见记录在案）"
  slo_commitment:
    availability: 0.999
    latency_p99_ms: 300
    error_budget_window_days: 28
  escalation_path:
    - level: 1
      when: "值班层面无法解决的技术问题"
      to: "开发团队 on-call"
    - level: 2
      when: "需要业务决策（如丢弃数据、接受降级）"
      to: "服务 owner + SRE tech lead"
    - level: 3
      when: "责任或资源争议"
      to: "双方总监，48 小时内裁决"
  exit_criteria:
    - "任一方提前 60 天书面通知可启动移交"
    - "移交期不少于 8 周，含反向影子值班"
  signatures: ["sre-director", "dev-director", "product-owner"]

接管协议是 SRE 与开发团队之间最重要的契约文档，这份模板覆盖了五个关键部分。responsibilities 与 authorities 的对应关系是精髓：SRE 承担值班责任的同时获得生产变更权（责任与权限对等），开发团队保留功能发布权的同时承担代码缺陷修复的 SLA（P1 缺陷 24 小时响应）——没有这个修复 SLA，SRE 值班会沦为「只能重启不能根治」的无限循环。slo_commitment 把第 3 章的 SLO 机制写进契约，错误预算的冻结权和豁免规则显式化，避免事中扯皮。escalation_path 的三级设计对应三类不同性质的问题：技术问题、业务决策、组织争议——混为一谈是事故指挥混乱的常见根源（技术升级路径被业务争论堵塞）。最容易被忽视但最能体现成熟度的是 exit_criteria：好的契约不仅规定如何开始，还规定如何体面地结束。服务可能因为业务边缘化不再值得嵌入式支持，也可能因为开发团队成熟度提升而「毕业」为自主运维——8 周移交期加反向影子值班（开发团队主值班、SRE 观察）确保知识回流。签署人包含双方总监和产品负责人，仪式感强化了契约的严肃性。实践建议：协议每季度的 review 不是走过场，重点检查三件事——责任矩阵与实际执行是否一致（有没有 SRE 在默默干开发的活）、升级路径是否被真实使用过、SLO 是否需要随业务变化调整。

/* 示例 3：RACI 责任矩阵（TypeScript 配置） */
type RACI = "R" | "A" | "C" | "I";
interface MatrixRow {
  activity: string;
  sre: RACI;
  dev: RACI;
  product: RACI;
  security: RACI;
}
const raciMatrix: MatrixRow[] = [
  { activity: "值班响应与事故处置",   sre: "A", dev: "C", product: "I", security: "I" },
  { activity: "代码缺陷修复",         sre: "C", dev: "A", product: "I", security: "I" },
  { activity: "SLO 设定与调整",       sre: "R", dev: "C", product: "A", security: "I" },
  { activity: "错误预算政策执行",     sre: "A", dev: "R", product: "C", security: "I" },
  { activity: "容量规划",             sre: "A", dev: "C", product: "C", security: "I" },
  { activity: "架构设计决策",         sre: "C", dev: "A", product: "C", security: "C" },
  { activity: "发布执行",             sre: "R", dev: "A", product: "I", security: "I" },
  { activity: "安全漏洞修复",         sre: "C", dev: "R", product: "I", security: "A" },
  { activity: "事故复盘主持",         sre: "A", dev: "R", product: "I", security: "I" },
  { activity: "监控告警维护",         sre: "A", dev: "C", product: "I", security: "I" },
];
/* 校验规则：每行有且仅有一个 A */
function validateRACI(rows: MatrixRow[]) {
  return rows.filter((r) =>
    [r.sre, r.dev, r.product, r.security].filter((x) => x === "A").length !== 1
  );
}

RACI 矩阵把模糊的「协作」翻译成精确的责任分配，这份配置展示了几个典型活动的标准答案和一条铁律。先读几个关键行：「SLO 设定」的 A 是产品而非 SRE——这是反直觉但正确的设计，SLO 本质是业务承诺（用户能期待什么质量），SRE 是 R（执行测算和工程实现），产品是 A（对承诺负责）；把 A 给 SRE 会导致 SLO 变成纯工程指标而失去业务对齐。「代码缺陷修复」的 A 必须是开发团队，SRE 只是 C——这条守住了「SRE 不是免费修 bug 劳力」的边界。「发布执行」SRE 是 R、开发是 A：SRE 操作发布流水线，但发布内容和时机的责任在开发。铁律是 validateRACI 函数检查的：每行有且仅有一个 A（Accountable）。两个 A 等于没有 A（出事时互相观望），零个 A 更是灾难（没人对结果负责）。R（Responsible，干活的人）可以有多个，C（Consulted，事前咨询）和 I（Informed，事后知会）用于信息流设计——很多协作摩擦源于「我居然是从事故报告里才知道这个变更」，那就是 I 缺失。使用建议：矩阵按服务粒度定制（核心服务和边缘服务的分配不同），放进接管协议一起签署，每半年复审。复审时最有价值的问题是「过去半年有哪些活动实际执行者和矩阵不符」——不符处要么改矩阵要么改行为，不允许长期名实分离。

/* 示例 4：框架团队标准监控模板（Prometheus 规则 YAML） */
/* 新服务接入监控平台时自动生成的基线告警 */
groups:
  - name: service-baseline-availability
    rules:
      /* 多窗口多燃烧率：快烧 page，慢烧 ticket */
      - alert: HighErrorBurnRate_Fast
        expr: |
          (
            slo:sli_error:ratio_rate5m{service="$SERVICE"} > 14.4 * (1 - $SLO)
            and
            slo:sli_error:ratio_rate1h{service="$SERVICE"} > 14.4 * (1 - $SLO)
          )
        for: 2m
        labels: { severity: page, team: "$OWNER_TEAM" }
        annotations:
          summary: "$SERVICE 错误预算快速消耗（2% 预算/小时）"
          runbook: "https://runbooks.internal/$SERVICE/high-error-rate"
      - alert: HighErrorBurnRate_Slow
        expr: |
          (
            slo:sli_error:ratio_rate30m{service="$SERVICE"} > 6 * (1 - $SLO)
            and
            slo:sli_error:ratio_rate6h{service="$SERVICE"} > 6 * (1 - $SLO)
          )
        for: 15m
        labels: { severity: ticket, team: "$OWNER_TEAM" }
        annotations:
          summary: "$SERVICE 错误预算持续消耗（5% 预算/6小时）"
  - name: service-baseline-saturation
    rules:
      - alert: HighCpuSaturation
        expr: |
          avg(rate(container_cpu_usage_seconds_total{service="$SERVICE"}[5m]))
          /
          avg(kube_pod_container_resource_limits{service="$SERVICE",resource="cpu"})
          > 0.85
        for: 15m
        labels: { severity: ticket, team: "$OWNER_TEAM" }
        annotations:
          summary: "$SERVICE CPU 达到限额 85%，评估扩容"

这是框架 SRE 团队提供给全组织的标准监控模板，体现了「可靠性能力平台化」的核心思路。模板的设计哲学有三层。第一层是标准化：所有接入服务自动获得同一套基线告警——可用性用多窗口多燃烧率（第 4 章的方法论直接编码进模板：14.4 倍燃烧率对应每小时烧 2% 预算，快烧 page 级；6 倍燃烧率对应慢烧 ticket 级），饱和度用资源使用率与限额的比值。新团队不需要懂燃烧率数学就能获得 Google 级别的告警质量，这就是框架的杠杆。第二层是参数化：模板中 SERVICE、SLO、OWNER_TEAM 是占位变量，服务注册到平台时自动填充——服务 owner 在注册表单里填 SLO 和值班团队，告警规则、仪表盘、值班路由一次性生成。第三层是可操作性：每条告警强制携带 runbook 链接和 team 标签，没有 runbook 的告警不允许上线（平台在规则校验阶段拦截）——这是把「告警必须可操作」的原则用工具强制执行。框架团队运营这类模板的关键指标：模板覆盖率（多少服务在用）、告警精确率（page 级告警中真实需要行动的比例，目标 > 90%）、误报反馈闭环（值班一键标记误报，框架团队每周消化）。模板演进机制同样重要：每次重大事故复盘若发现「基线模板本可以更早发现」，就把新规则加入模板——全组织一次性获得免疫力，这是单个团队复盘无法比拟的规模效应。

/* 示例 5：内部 SLO 契约（服务间质量承诺，YAML） */
internal_slo_contract:
  contract_id: ISC-2024-017
  provider:
    service: user-profile-api
    team: identity-sre
  consumers:
    - service: checkout-api
      team: commerce-dev
    - service: recommendation-engine
      team: recsys-dev
  commitments:
    availability:
      slo: 0.9995
      window_days: 28
      measurement: "提供方边缘 SLI（非消费方本地测量）"
    latency:
      p50_ms: 15
      p99_ms: 80
      note: "P99 超过 150ms 视为可用性事件计入错误预算"
    change_management:
      breaking_change_notice_days: 14
      deprecation_notice_days: 90
      schema_registry: "schemaregistry.internal/user-profile"
    support:
      business_hours_response: 4h
      p1_incident_response: 15m
  consumer_obligations:
    - "消费方必须设置合理超时（建议 100ms）与重试预算"
    - "消费方 QPS 超过 5000 需提前 30 天报备容量"
    - "消费方不得缓存超过契约允许的 TTL（60s）"
  breach_policy:
    - "月度违约：提供方在复盘中说明根因与改进计划"
    - "连续两月违约：提供方功能发布冻结，优先修复可靠性"
    - "消费方违规使用（如重试风暴）：消费方承担对应错误预算消耗"
  review:
    cadence: semi-annual
    data_source: "过去 180 天实际 SLI 数据 vs 承诺值"
  signed: ["identity-sre-lead", "commerce-dev-lead", "recsys-dev-lead"]

内部 SLO 契约把「团队间依赖」从口头默契变成可执行的质量承诺，这份模板有几个精妙的设计。第一，测量点的选择显式化：契约规定用提供方边缘的 SLI 而非消费方本地测量——两者可能因网络、消费方自身问题产生分歧，事先约定测量口径避免了事故复盘时「你的监控说正常，我的监控说超时」的扯皮。第二，延迟承诺与可用性预算打通：「P99 超过 150ms 视为可用性事件」意味着慢也是违约，防止提供方用「请求都成功了」为劣质性能辩护。第三，consumer_obligations 是常被遗漏的半边契约：可靠性是双向的，消费方必须设置合理超时和重试预算（防止重试风暴打垮提供方）、超量使用要提前报备（提供方的容量规划依赖这个信息）、遵守缓存 TTL（防止数据一致性事故）。只约束提供方的契约是不完整的。第四，breach_policy 的对称性：提供方连续违约要冻结自己的功能发布（用自己的错误预算买单），消费方违规使用也要承担对应的预算消耗——违约后果落在错误预算机制上，与第 3 章的理论完美衔接。契约的半年复审基于 180 天真实数据：承诺长期轻松达标说明定低了（消费方可能在为不必要的可靠性付出成本），频繁违约说明定高了或系统需要投资。内部契约网络成熟后，组织可以计算「依赖链可靠性预算」——checkout-api 的 99.9% 依赖 user-profile-api 的 99.95%，数学上可行；如果提供方只承诺 99.5%，消费方的 SLO 就是空中楼阁，这正是契约让「依赖治理」可计算的价值。

/* 示例 6：升级路径与协作流程配置（YAML） */
escalation_and_collaboration:
  incident_escalation:
    - level: L1
      responder: "SRE 值班工程师"
      triggers: ["基线告警", "SLI 异常"]
      actions: ["按 runbook 处置", "执行标准缓解（回滚/扩容/切流）"]
      escalate_when: "30 分钟未缓解，或需要业务决策"
    - level: L2
      responder: "开发团队 on-call + SRE tech lead"
      triggers: ["L1 升级", "P1 事故自动拉入"]
      actions: ["深入排查", "代码级修复或热修"]
      escalate_when: "2 小时未缓解，或影响扩大"
    - level: L3
      responder: "事故指挥官（双方总监指定）"
      triggers: ["L2 升级", "跨 3 个以上团队", "重大用户影响"]
      actions: ["启动 ICS 指挥体系", "对外沟通", "资源调度"]
  design_review_trigger:
    required_when:
      - "新服务立项"
      - "引入新的强依赖"
      - "存储 schema 破坏性变更"
      - "预计 QPS 增长超过 3 倍"
    sla: "材料提交后 5 个工作日内完成评审"
  takeover_decision_tree:
    - question: "服务是否营收核心或用户直接感知？"
      no: "framework_only（平台自助支持）"
      yes: next
    - question: "是否有明确 owner 且愿意转移生产权限？"
      no: "拒绝，提供轻量支持包与达标路径"
      yes: next
    - question: "PRR 评分是否 READY？"
      yes: "embedded 接管"
      no: "consulting 辅导 + 限期改进，达标后升级 embedded"

这份配置把本章讨论的协作机制统一编码为可执行的流程规则，三个部分各解决一类协作摩擦。incident_escalation 的关键设计是每级都有明确的 escalate_when 条件（30 分钟未缓解、需要业务决策、影响扩大）——升级不靠值班工程师的主观判断（「再等等看」是事故延长的常见原因），而靠客观触发器。L1 的 actions 限定为标准缓解动作（回滚、扩容、切流），这体现了「先恢复后排查」的原则：值班工程师不需要理解根因就能行动。design_review_trigger 用白名单定义什么情况必须发起设计评审——「引入新的强依赖」和「QPS 增长超 3 倍」这两条尤其重要，它们分别对应架构风险变化和容量风险变化，是事故复盘中最常见的「当初评审一下就好了」场景。5 个工作日的评审 SLA 防止评审变成开发进度的瓶颈（SRE 团队响应慢是开发团队绕过评审的头号借口）。takeover_decision_tree 是第 2 章参与模式决策的浓缩版：三个问题依次过滤——业务关键度决定值不值得投入人力，owner 与权限决定能不能接管，PRR 决定以什么方式接管。注意「no owner」分支的输出不是简单拒绝，而是「轻量支持包 + 达标路径」，把拒绝转化为改进的起点。建议把这份配置放进组织的 SRE 服务目录公开维护，所有合作团队都能查到规则——透明性是协作信任的基础，规则公开后，「找关系走后门」的空间消失，协作回归专业主义。

实验笔记

本实验的目标是完整演练 SRE 与其他团队的协作机制设计：绘制责任矩阵、起草接管协议、模拟设计评审与拒绝接管决策。实验分五个部分，预计 4 到 5 小时，最好由 3 到 5 人小组完成并分别扮演 SRE、开发团队和产品团队角色——角色扮演的价值在于亲身体验立场差异。第一部分：协作现状诊断（约 45 分钟）。选择你所在组织的真实 SRE 与开发团队协作现状（没有 SRE 团队则假想一个），回答诊断问题清单：值班责任归谁？代码缺陷修复的响应时间有没有约定？SRE（或运维）有没有生产变更权限？发布决策谁说了算？上一次跨团队事故的指挥权在谁手里？升级路径是否文档化？把答案与本章的契约标准对比，列出「模糊地带清单」——每一个模糊地带都是一次未来事故的种子。检查清单：是否发现了至少 3 个「责任与权限不对等」的实例？是否有活动处于「两个团队都以为对方负责」的状态？第二部分：RACI 矩阵工作坊（约 1 小时）。针对所选服务，用本章示例 3 的结构绘制 RACI 矩阵：列出至少 12 项运维相关活动（值班、缺陷修复、SLO 设定、容量规划、发布执行、监控维护、事故复盘、安全修复、架构决策、文档维护、扩容执行、变更审批），为每项分配 SRE/开发/产品/安全四个角色的 RACI。规则：每项活动有且仅有一个 A；分配后运行「半夜测试」——随机抽三项活动，问「凌晨三点这件事出问题，谁第一个行动、谁最终负责」，答案必须能从矩阵直接读出。角色扮演环节：开发团队角色有权挑战任何把自己团队 A 太多的分配，SRE 角色有权拒绝承担没有配套权限的责任——通过三轮谈判达成双方签字的矩阵。记录谈判中最激烈的分歧点，这通常暴露了组织真实的权责矛盾。第三部分：接管协议起草（约 1 小时）。基于 RACI 矩阵，起草一份完整的接管协议，必须包含：双方责任清单（对应矩阵）、双方权限清单（重点：SRE 的生产变更权边界、发布冻结权的触发条件与豁免流程）、SLO 承诺与错误预算政策、三级升级路径（技术/业务/组织争议分开）、退出条款（移交期长度、反向影子值班安排）。起草后交换评审：开发团队角色检查「SRE 权限是否过大会侵犯开发自主权」，SRE 角色检查「责任是否都有配套权限和资源」。修订至双方可签署。第四部分：设计评审与拒绝接管模拟（约 1 小时）。场景 A 设计评审：开发团队角色准备一个新服务的架构草图（15 分钟即兴设计：一个订单处理服务，依赖数据库、消息队列、第三方支付网关），SRE 角色用本章的评审问题清单执行 30 分钟评审，输出风险清单和改进建议（每条建议必须附替代方案，练习「不只挑毛病」）。场景 B 拒绝接管：产品团队角色要求 SRE 下周接管一个 PRR 评分 NOT_READY、没有明确 owner 的遗留服务，并以「管理层很重视」施压。SRE 角色练习标准拒绝流程：引用公开的拒绝标准、给出达标路径和轻量支持包、提出分阶段方案（先咨询辅导、达标后接管）。复盘两个场景：评审意见的质量如何？拒绝是否既守住了原则又维护了关系？第五部分：协作健康度指标设计（约 30 分钟）。为你的组织设计一套协作度量仪表盘：从效率类（PRR 平均时长、跨团队事故中等待响应的时间占比）、质量类（接管后 90 天事故率、复盘行动项按时完成率）、满意度类（双向满意度调查问题）各选至少 2 个指标，写明数据来源和采集方式。决策树练习：嵌入式 SRE 团队发现自己 70% 时间在替开发团队修业务 bug，团队士气低落——作为 SRE 负责人你的行动路径是什么？（预期路径：用 RACI 矩阵对照实际工作找出边界溶解点 → 与开发负责人重签协议明确缺陷修复 SLA → 设置过渡期逐步移交 → 若开发团队无力承接，升级到双方总监讨论资源投入 → 同时评估是否降级为咨询模式。）通过本实验你将体会到：协作机制不是软性的「沟通技巧」，而是可以像系统架构一样被设计、被文档化、被度量、被持续改进的工程对象。