bittern.cn
2SRE 工作手册

SRE 参与模式的演进

从框架到生产

生产就绪评审简单化框架框架即服务SRE 参与模式

🎯 AI 时代的学习建议：不要只读理论。理解这一章的设计动机（为什么需要这个概念？）和边界条件（什么情况下会失效？）。当 AI 生成的代码涉及这些概念时，你能判断它是否用对了场景。AI 能帮你总结内容，但无法替代你亲手阅读、思考、建立直觉的过程。

第2章 SRE 参与模式的演进

从框架到生产

章节导读

在 Google 内部，一个产品团队想要获得 SRE 的支持，并不是一件理所当然的事。恰恰相反，SRE 团队对「接管」一个新服务持谨慎态度，因为接管意味着承担生产责任——从此这个服务的半夜告警、事故响应、容量规划都成了 SRE 的事。如果服务本身设计糟糕、文档缺失、负责人不明，SRE 的接管只会让双方都陷入泥潭。因此，Google 在多年实践中演化出了一套完整的「SRE 参与模式」：从最初的简单咨询，到深度嵌入式接管，再到把可靠性能力沉淀为框架和平台。本章讨论的就是这套模式的演进逻辑，它是蓝皮书的第 2 章，也是组织层面落地 SRE 的路线图。要理解 SRE 参与模式，先要理解一个核心问题：SRE 为什么不能「来者不拒」？答案藏在 SRE 的规模约束里。一个 SRE 团队能支撑的服务数量受人力限制，如果每个服务都要求 7×24 值班支持，团队很快会被摊薄到无法为任何服务提供高质量支持。Google 的经验是，SRE 团队必须对介入的服务设置门槛，这个门槛就是「生产责任的前提条件」：服务必须有明确的负责人（owner），必须愿意把生产环境的操作权交给 SRE，必须有足够的资源支持改造，团队之间必须就 SLO 达成一致。没有这些前提，SRE 的介入就是无源之水。蓝皮书把 SRE 的参与模式描述为一个演进光谱。最轻量的一端是「简单化框架」（Simplification Framework）：SRE 不接管任何生产责任，而是帮助产品团队审视系统复杂度，找出可以删除和简化的部分。这个模式的洞察在于：很多可靠性问题的根源不是缺少运维支持，而是系统本身过于复杂。一个 SRE 以外部视角审视系统，往往能发现产品团队习以为常的冗余。往上一级是「框架 SRE」（Framework SRE）：SRE 团队构建通用的可靠性基础设施——监控模板、告警框架、发布流水线、容量规划工具——让产品团队自助使用。再往上是「咨询式 SRE」：SRE 作为顾问参与设计评审和生产就绪评审，给出专业意见但不直接操作。最重的一端是「嵌入式 SRE」：SRE 工程师深度加入产品团队，承担完整的生产责任，包括值班。参与模式的选择不是一劳永逸的，而是随服务的成熟度和重要性动态调整。一个服务可能先接受框架支持，通过生产就绪评审后升级为咨询式合作，最终对最关键的服务实施嵌入式接管。这个演进过程本身就是一种筛选机制：只有真正重视可靠性的团队才会走完全程。本章还会详细讨论两个关键工具。第一个是「生产就绪评审」（Production Readiness Review，PRR）：一套结构化的检查清单和流程，在服务上线或 SRE 接管之前，系统性地评估其可靠性状态——监控是否完备？告警是否合理？容量是否规划？故障模式是否明确？回滚是否可行？PRR 不是走过场的审批，而是 SRE 与产品团队共同发现和改进问题的协作过程。Google 的 PRR 通常持续数周，产出一份详尽的评估报告和一系列改进项。第二个是「框架即服务」的理念：把 SRE 的最佳实践编码为平台和工具，而不是靠人肉传播。当可靠性能力被平台化之后，SRE 的影响力就不再受团队人数限制——一个框架团队构建的监控平台可以服务几百个产品团队。这正是 Google SRE 组织能够支撑整个公司生产环境的关键。对于正在组建或转型 SRE 团队的组织，本章的内容尤其重要。常见的失败模式有几种：一是「大跃进」，SRE 团队成立第一天就宣布接管所有核心服务，结果被淹没在没准备好的系统的故障里；二是「空心化」，SRE 沦为高级工单处理团队，只做被动响应不做工程改进；三是「孤岛化」，SRE 与开发团队形成新的对立墙，重复了 DevOps 之前的老路。避免这些陷阱的方法，就是按照本章描述的演进路径，循序渐进地建立信任、明确边界、沉淀工具。接下来的内容将详细展开：SRE 参与的前提条件、简单化框架的具体方法、PRR 的完整流程、框架团队的建设路径、SRE 团队规模的计算方法，以及 Google 内部服务接管的真实案例。无论你的组织处于 SRE 之旅的哪个阶段，这些模式都能为你提供参照坐标。

核心概念

  • 生产就绪评审
  • 简单化框架
  • 框架即服务
  • SRE 参与模式

要点精析

SRE 参与的前提条件：生产责任、明确负责人与足够资源。Google SRE 在接管任何服务之前，都会确认三个前提条件是否满足。第一是生产责任的转移：产品团队必须愿意把生产环境的操作权真正交给 SRE，而不是「出了事叫 SRE 来救火，平时 SRE 说不上话」。半吊子的责任转移是最糟糕的状态——SRE 承担了值班的辛苦，却没有权限推动架构改进。第二是明确的负责人：服务必须有清晰的 owner，当 SRE 在半夜发现需要业务决策的问题时（比如「要不要丢弃这批数据」），必须有一个有权限、有能力拍板的人可以升级。没有 owner 的服务就像没有监护人的孩子，SRE 无法对其长期健康负责。第三是足够的资源：接管一个不达标的服务意味着大量的改造工作——补监控、写值班手册、做容量规划、修复架构缺陷。这些工作需要产品团队投入开发资源配合，如果产品团队只想要「免费的可靠性」而不愿投入，接管注定失败。这三个条件的本质是「对等承诺」：SRE 承诺承担生产责任，产品团队承诺给予权限、明确责任人和投入资源。蓝皮书强调，SRE 团队应该有勇气对不满足前提条件的服务说「不」，或者提出「先满足条件再接管」的分阶段方案。这种纪律短期看会得罪人，长期看保护了 SRE 团队的有效性，也倒逼产品团队重视可靠性。

从框架到生产：SRE 接管的完整流程。Google 的 SRE 接管不是一次事件，而是一个持续数月的流程，大致分为五个阶段。阶段一：初步评估。SRE 与产品团队会面，了解服务的业务重要性、架构概况、当前运维状态，判断是否值得接管以及需要哪种参与模式。阶段二：生产就绪评审（PRR）。SRE 对服务进行系统性体检，产出评分卡和风险清单，双方就改进项达成一致。阶段三：改进实施。产品团队（有时加上 SRE 协助）完成 PRR 发现的改进项：补齐监控告警、编写值班手册、消除单点、建立容量基线。这个阶段可能持续数周到数月。阶段四：影子值班（Shadowing）。SRE 开始跟随产品团队的值班轮换，先观察不操作，逐步过渡到 SRE 主值班、产品团队备份。影子期是知识转移的关键窗口，SRE 在真实故障中学习系统的行为模式。阶段五：正式接管与持续维护。SRE 承担完整值班责任，同时持续进行容量规划、性能优化和可靠性改进。接管后 PRR 不是一次性的——重大架构变更后应该重新评审。整个流程的精髓在于「渐进的信任建立」：每个阶段都是双方的磨合期，任何阶段发现严重问题都可以暂停或退出。这种设计避免了「闪婚式接管」的常见悲剧：SRE 接了一个自己不了解的系统，第一次大故障就处理得一塌糊涂，双方信任彻底破裂。

简单化框架：降低系统复杂度的工程方法。简单化框架是 SRE 参与模式中最轻量的一种：SRE 不承担生产责任，而是以外部专家视角帮助产品团队降低系统复杂度。这个模式的出发点是一个观察：许多团队找 SRE 帮忙，真正的问题不是「缺少运维」，而是「系统太复杂以至于没人能可靠地运维它」。简单化框架的工作方法包括几个步骤。第一步：绘制真实的依赖图。不是设计文档里理想化的架构图，而是通过流量分析、调用链追踪得到的实际依赖关系。团队常常惊讶地发现，自己的服务依赖着早已忘记的组件。第二步：分类每个依赖。问三个问题：这个依赖挂了服务还能工作吗（强依赖 vs 弱依赖）？这个依赖的使用率有多高？有没有更简单的替代方案？第三步：识别删除候选。从未被调用的接口、只有一个消费者的「通用」抽象、为想象中的未来需求预留的扩展点、重复实现相同功能的组件。第四步：评估简化的风险与收益，制定分阶段的简化计划。Google 的一个典型案例是某服务经过简单化审视后，删除了 30% 的代码和一半的依赖组件，故障率显著下降，值班负担大幅减轻。简单化框架的另一个价值是「建立关系的敲门砖」：它让产品团队以低风险的方式体验 SRE 的价值，为后续更深入的参与模式打下信任基础。

生产就绪评审（PRR）：上线前的可靠性检查清单。PRR 是 Google SRE 最结构化的工具之一，其本质是在服务上线或接管前，系统性地回答「这个服务准备好面对生产环境了吗」。一份完整的 PRR 覆盖以下维度：监控与告警（是否有基于症状的 SLI、告警是否可操作、是否有仪表盘）；容量规划（单实例容量、当前负载水位、增长预测、扩容流程）；故障处理（值班手册、常见故障处置步骤、升级路径）；变更管理（发布自动化程度、金丝雀能力、回滚速度、配置审计）；韧性设计（超时与重试策略、过载保护、依赖故障时的降级行为、单点故障）；数据安全（备份策略、备份恢复验证、数据一致性保障）；文档与知识（架构图、运行手册、onboarding 材料）。PRR 的执行方式同样重要：它不是 SRE 单方面打分，而是 SRE 与产品团队一起逐项走查，每个结论都要有证据支撑（给我看监控截图、给我演示回滚流程）。「演示而非描述」是 PRR 的黄金法则——声称有备份不算数，现场恢复一次才算数。PRR 的产出是一份报告和一个改进计划，改进项按风险排序，明确负责人和时间点。评审结论通常分三档：就绪（可以接管）、有条件就绪（完成指定改进后接管）、未就绪（需要重大改造）。Google 的经验是，PRR 平均会发现几十个改进项，其中总有两三个是「没人意识到的重大风险」，仅凭这一点，PRR 的投入就物有所值。

框架即服务：将可靠性能力平台化。当 SRE 组织成熟到一定阶段，会发现一个瓶颈：嵌入式 SRE 的模式无法规模化——公司有几万个服务，SRE 只有几百人，靠人肉接管永远追不上服务增长的速度。解法是「框架即服务」：把 SRE 的知识和最佳实践编码为平台和工具，让产品团队自助获得可靠性能力。Google 的框架 SRE 团队构建的典型平台包括：统一的监控系统（Borgmon，Prometheus 的前身），任何服务接入后自动获得标准指标采集和告警能力；标准化的发布流水线，内置金丝雀、自动回滚、变更审计；容量规划平台，自动分析负载趋势并给出扩容建议；标准化的值班和告警路由系统，自动处理升级和交接。框架的价值在于「默认可靠」：产品团队不需要成为可靠性专家，只要使用平台提供的标准组件，就自动继承了 Google 十几年沉淀的最佳实践。框架 SRE 的工作方式与嵌入式 SRE 截然不同：他们的「客户」是其他 SRE 团队和开发人员，他们的产出是 API 和工具而不是运维操作，他们的成功指标是平台的采用率和通过平台避免的人工工作。建设框架团队的常见误区是「闭门造车」：框架团队脱离一线，构建出没人用的「理想平台」。Google 的对策是框架 SRE 定期轮岗到嵌入式团队，保持对真实痛点的手感；同时平台的路线图由用户需求驱动，而不是技术兴趣驱动。

SRE 团队的规模与结构：如何计算需要多少 SRE。这是每个组建 SRE 团队的组织都会问的问题，Google 给出的答案出人意料地量化。计算 SRE 人力需求的核心变量是「操作负载」（operational load）：值班响应、工单处理、事故处置消耗的人力。Google 的经验法则是：SRE 团队花在操作负载上的时间不应超过 50%，否则没有余力做工程改进。由此可以反推团队规模：假设一个服务每周产生 X 小时的值班负载、Y 小时的工单负载，加上必要的会议和协调开销，就可以估算需要多少全职人力。值班轮换还有一个硬约束：为了保证值班质量，一个人值班的频率不能太高。Google 的标准是值班团队至少 8 人，这样每人每月值班不超过一周，两次值班之间有足够恢复期。如果凑不齐 8 人，可以考虑与其他团队合并值班轮换，或者采用「工作时间值班 + 非工作时间仅响应紧急告警」的降级模式。团队结构方面，成熟的 SRE 组织通常呈金字塔形：底部是框架和平台团队（人数最多，杠杆最大），中部是各产品线的嵌入式 SRE，顶部是少量的咨询专家和架构师。一个实用的自检指标是「SRE 与开发的比例」：Google 大约是 1:5 到 1:10，如果你的组织远低于这个比例，说明 SRE 要么在做不该做的事，要么服务的支持质量在悄悄劣化。规模计算不是一次性的——服务增长、自动化程度提升、架构简化都会改变操作负载，应该每季度重新评估。

案例：Google 内部服务的 SRE 接管过程。蓝皮书第 2 章提供了几个真实的接管案例，其中最有代表性的是一个大型存储服务的接管过程。初始状态：该服务由开发团队自己运维，没有正式值班制度，告警混乱（每天数百条，大部分无人处理），架构文档严重过时，团队对「SRE 接管」既期待又抵触。接管过程分三步走。第一步是简单化审视：SRE 团队花了两周分析系统，发现服务有 12 个直接依赖，其中 4 个实际上从未在关键路径上使用；有 3 套功能重叠的监控；配置管理系统有两代并存。删除冗余后，系统复杂度显著下降。第二步是 PRR 与改进：评审发现了 40 多个改进项，最严重的包括：主从切换没有自动化且从未演练、备份存在但从未验证恢复、一个关键的限流配置实际上没有生效。产品团队用了三个月完成高优先级改进。第三步是影子值班到正式接管：SRE 先跟随开发团队值班六周，期间处理了两次真实故障，暴露出值班手册的多个缺失环节并逐一补齐。正式接管后六个月的效果数据：告警数量下降 90%，平均故障恢复时间从 45 分钟降到 12 分钟，开发团队用于运维的时间减少 60%，这些时间被重新投入到功能开发。这个案例的关键启示是：接管的价值不在于「SRE 比开发更会运维」，而在于接管流程强制性地清偿了可靠性债务，并把运维从「业余兼职」变成了「专业全职」。

当 SRE 说「不」：拒绝的艺术与机制。SRE 团队必须经常说「不」：拒绝接管未就绪的服务、拒绝没有回滚方案的发布、拒绝超出容量的流量承诺。但「说不」如果处理不好，会把 SRE 变成组织里的「阻碍部门」。Google 的做法是把拒绝机制化、透明化。第一，用标准说话：拒绝的依据是事先公开的 PRR 标准和 SLO 要求，而不是 SRE 的主观判断。「你的服务监控覆盖率只有 40%，低于接管标准的 80%」比「我们觉得你的服务不行」有说服力得多。第二，拒绝的同时给出路径：每次说「不」都附带一份改进清单——「完成这五项，我们就接管」。这把对抗关系转化为了合作关系。第三，提供降级选项：如果产品团队等不及完整接管，可以先接受框架支持或咨询式参与，让服务先跑起来，同时推进改进。第四，建立升级机制：如果产品团队认为 SRE 的拒绝不合理，有明确的升级路径（双方管理层共同评审），避免 SRE 变成不可挑战的官僚机构。一个反面案例值得警惕：某公司的 SRE 团队以「可靠性守门人」自居，对所有发布一票否决，结果开发团队绕过 SRE 建立了自己的发布通道，SRE 被彻底边缘化。守门人的正确姿势是「教练 + 裁判」：既指出问题，也帮助解决；既执行标准，也保持标准的合理演进。

参与模式的动态演进：没有一劳永逸的选择。SRE 参与模式不是静态标签，而是随服务生命周期和组织成熟度不断调整的状态。几种典型的演进场景：场景一，初创期公司只有一两个 SRE，此时唯一可行的模式是框架 + 咨询——构建基础监控告警平台，帮助各团队建立基本实践，切忌承诺嵌入式接管。场景二，某服务从边缘业务成长为营收核心，原本的平台支持不够了，需要升级为嵌入式接管，走完整的 PRR 流程。场景三，某服务进入维护期，功能基本冻结，SRE 可以从嵌入式退出，转为平台支持，把人力释放给更需要的新服务——退出和进入同样重要，SRE 团队的可持续性依赖于定期「卸载」低价值承诺。场景四，公司被收购或业务合并，两套 SRE 体系需要融合，此时应该先统一监控和告警平台（框架层融合），再逐步对齐流程和标准。判断是否需要调整参与模式的信号包括：操作负载持续超出团队 50% 红线（需要减负或加人）；服务的业务重要性发生数量级变化（需要升级支持等级）；产品团队的工程能力显著提升（可以降级支持）；平台能力成熟到可以替代人工支持（框架化机会）。建议每半年做一次正式的参与模式评审，把所有支持的服务列出来，逐一确认当前模式是否仍然合适。这种定期审视避免了两种慢性病：SRE 悄悄积累了过多承诺导致全面过载，或者 SRE 守着过时的接管关系浪费人力。

中小组织的 SRE 落地路径：不要照搬 Google。蓝皮书的案例大多来自 Google 这样的超大规模组织，但绝大多数读者所在的公司只有几十到几百名工程师。直接照搬 Google 模式会遭遇严重的水土不服：没有 8 个人可以组成值班轮换、没有资源建独立的框架团队、没有统一的基础设施平台。中小组织的务实路径是这样的。第一阶段（0 到 3 个月）：不设立专职 SRE，而是指定 1 到 2 名「可靠性冠军」（可以是资深开发兼职），完成三件事：为核心服务定义 SLI/SLO、建立统一的监控告警（用 Prometheus + Grafana 这类开源方案）、编写第一版值班手册。第二阶段（3 到 12 个月）：建立轻量值班制度，工程师团队轮流值班（开发也参与值班，这是 Google「谁构建谁运维」理念的变体）；引入无指责事后分析；把重复出现的故障做成自动化修复。第三阶段（1 年以上）：如果业务规模证明需要，再设立专职 SRE 岗位，此时已经有成熟的实践基础，专职 SRE 可以专注于平台建设和最复杂的服务。关键原则有三条：值班轮换凑不够人时，用「降低值班强度」代替「取消值班」——比如只响应 P1 告警、非工作时间允许延迟响应；工具选型优先开源和托管服务，不要自研平台；SRE 实践的价值要用数据证明（MTTR 下降、告警数量减少、发布频率提升），这些数据是争取更多资源的唯一语言。记住：Google 的 SRE 体系是二十年演化的结果，你的目标是找到适合当前规模的最小可行实践，然后随业务一起成长。

代码示例

/* 示例 1：生产就绪评审（PRR）评分卡模板（TypeScript） */
interface PRRDimension {
  name: string;
  score: 0 | 1 | 2;  /* 0=缺失 1=部分 2=完备 */
  evidence: string;
  gaps: string[];
}
const prrTemplate: PRRDimension[] = [
  { name: "监控与SLI", score: 0, evidence: "", gaps: [] },
  { name: "告警可操作性", score: 0, evidence: "", gaps: [] },
  { name: "容量规划", score: 0, evidence: "", gaps: [] },
  { name: "值班手册", score: 0, evidence: "", gaps: [] },
  { name: "变更与回滚", score: 0, evidence: "", gaps: [] },
  { name: "韧性设计", score: 0, evidence: "", gaps: [] },
  { name: "备份与恢复", score: 0, evidence: "", gaps: [] },
];
function prrVerdict(dims: PRRDimension[]) {
  const total = dims.reduce((s, d) => s + d.score, 0);
  const max = dims.length * 2;
  if (total >= max * 0.7) return "READY";
  if (total >= max * 0.4) return "CONDITIONAL";
  return "NOT_READY";
}
这个评分卡把 PRR 的七个核心维度编码为可计算的结构。三个设计要点：第一，每个维度必须附「证据」——监控截图、演练记录、文档链接，杜绝口头保证；第二，gaps 数组记录具体差距，直接转化为改进计划的任务项；第三，verdict 函数用 70% 和 40% 两条线把结论分为三档，「CONDITIONAL」档意味着可以接管但必须附带限期改进承诺。实际使用时建议把模板放进代码仓库，每次评审提交一个填好的 JSON 文件，这样评审历史可追溯、可对比。Google 的 PRR 远比这个模板细致（每个维度下有十几个子项），但小团队从这个粒度开始已经足够，重要的是养成「用证据说话」的评审文化。
/* 示例 2：SRE 团队规模估算模型 */
function estimateSREHeadcount(params: {
  services: number;            /* 接管的服务数量 */
  oncallHoursPerWeek: number;  /* 每服务每周值班负载(小时) */
  ticketHoursPerWeek: number;  /* 每服务每周工单负载(小时) */
  toilCapRatio: number;        /* 操作负载上限，Google 标准为 0.5 */
}) {
  const weeklyOpsHours =
    params.services * (params.oncallHoursPerWeek + params.ticketHoursPerWeek);
  /* 值班轮换最小 8 人才能保持健康频率 */
  const oncallMin = 8;
  const opsHeadcount = weeklyOpsHours / (40 * params.toilCapRatio);
  return {
    weeklyOpsHours,
    opsHeadcount: Math.ceil(opsHeadcount),
    recommended: Math.max(Math.ceil(opsHeadcount), oncallMin),
  };
}
/* 例：3 个服务，每个每周 10 小时值班 + 5 小时工单 */
/* weeklyOpsHours = 45, opsHeadcount = ceil(45/20) = 3,
   但值班轮换约束要求至少 8 人 => recommended = 8 */
这个模型揭示了 SRE 人力规划中常被忽视的一点：操作负载计算和值班轮换约束是两个独立的下限，最终规模取两者最大值。例子里按负载只需要 3 人，但健康的值班轮换需要 8 人——每人每月最多值一周班，否则疲劳累积会导致响应质量下降和人员流失。如果凑不齐 8 人，选项有：与其他团队合并值班池、降低值班强度（只响应紧急告警）、或者用自动化削减负载后重新评估。toilCapRatio 参数对应 Google 的「50% 规则」：操作负载超过一半时间，团队就失去了做工程改进的能力，负载会随规模增长而失控。这个模型应该每季度重跑一次，输入数据来自真实的值班系统和工单系统统计，而不是拍脑袋估计。
/* 示例 3：依赖分类与简化候选识别（伪代码） */
const dependencies = analyzeTraffic(service, "30d");
for (const dep of dependencies) {
  dep.criticality = isStrongDependency(dep) ? "STRONG" : "WEAK";
  dep.usageQPS = dep.requestCount / (30 * 86400);
  dep.simplifyCandidate =
    dep.usageQPS < 0.01 ||          /* 几乎无流量 */
    dep.consumers.length === 1 ||   /* 只有一个调用方 */
    dep.overlapsWith.length > 0;    /* 与其他依赖功能重叠 */
}
const candidates = dependencies.filter((d) => d.simplifyCandidate);
/* 输出简化候选清单，附流量证据，供架构评审讨论 */
这段代码实现了简单化框架的核心步骤：用真实流量数据（而非文档和记忆）识别简化候选。三个判断条件分别对应三类常见冗余：僵尸依赖（曾经用过、早已废弃，但没人敢删）、过度通用化（为多个消费者设计的抽象实际只剩一个消费者，可以内联简化）、功能重叠（两代系统并存，如新旧两套配置管理）。关键实践细节：流量窗口要足够长（30 天甚至 90 天），因为有些依赖是月度批处理任务，短窗口会漏判；识别出候选后不能直接删除，要先「静默降级」——把依赖调用改为记录日志但不生效，观察一个周期确认无影响后再物理删除。Google 的经验是，一次认真的依赖审视平均能发现 20% 到 30% 的可删除组件，这是降低操作负载最便宜的方式。
/* 示例 4：参与模式决策树（配置化表达） */
const engagementDecisionTree = {
  question: "服务的业务关键度？",
  branches: [
    {
      when: "营收核心 / 用户直接感知",
      next: {
        question: "PRR 评分是否达到 READY？",
        branches: [
          { when: "是", action: "嵌入式接管（Embedded SRE）" },
          { when: "否", action: "限期改进 + 咨询式支持，达标后接管" },
        ],
      },
    },
    {
      when: "重要但非核心",
      action: "框架支持 + 咨询式评审（Framework + Consulting）",
    },
    {
      when: "边缘 / 维护期",
      action: "仅平台自助支持，不投入 SRE 人力",
    },
  ],
};
把参与模式的选择编码为决策树有两个好处：决策一致性（不同服务、不同时间用同一标准判断，避免「谁会哭谁有奶」）和可沟通性（产品团队能清楚看到自己该走哪条路径、需要满足什么条件）。这棵树的两个关键判断点：业务关键度决定投入上限——SRE 人力永远稀缺，必须优先保障核心服务；PRR 评分决定介入方式——未就绪的服务即使再重要也不能直接嵌入式接管，否则 SRE 会被拖入无底洞。「限期改进 + 咨询式支持」这个中间态是实践中最常用的分支，它既给了产品团队明确的达标路径，也让 SRE 保持了介入的杠杆。建议每个组织根据自己的情况定制这棵树（比如加入「团队工程成熟度」维度），并把它作为 SRE 服务目录的一部分公开。
/* 示例 5：接管进度追踪（阶段门模型） */
const takeoverStages = [
  { stage: 1, name: "初步评估", exitCriteria: "双方签署参与意向，确定模式" },
  { stage: 2, name: "生产就绪评审", exitCriteria: "PRR 报告完成，改进计划确认" },
  { stage: 3, name: "改进实施", exitCriteria: "高危项 100% 关闭，中危项 >80% 关闭" },
  { stage: 4, name: "影子值班", exitCriteria: "SRE 独立处理 >=3 次真实事件，手册补齐" },
  { stage: 5, name: "正式接管", exitCriteria: "SLO 协议生效，告警路由切换完成" },
];
/* 每个阶段有明确的退出准则，未达标不进入下一阶段 */
function canAdvance(current: number, progress: Record<string, boolean>) {
  return takeoverStages[current].exitCriteriaMet(progress);
}
阶段门（stage-gate）模型把接管流程变成可管理的项目：每个阶段有明确的退出准则，达标才能推进，未达标就停下来补齐。最值得强调的是阶段 4「影子值班」的退出准则——「SRE 独立处理至少 3 次真实事件」。这个数字不是随意的：一次事件可能是运气，三次才能验证知识转移的真实性。影子期常见的失败是「假影子」：告警还是发给开发团队，SRE 只是抄送旁观，从未真正动手。正确的做法是从影子期第一周起，非紧急事件就由 SRE 主处理、开发团队在旁指导。阶段 5 的「告警路由切换」是接管的物理标志——当半夜的电话开始打给 SRE 而不是开发时，责任转移才真正完成。整个模型建议配合项目管理工具追踪，每周同步进度，让双方管理层对时间表有共同预期。

实验笔记

本实验的目标是让你完整体验一次「生产就绪评审」（PRR）的核心流程，并练习用简单化框架审视一个真实系统。实验分四个部分，预计 4 到 5 小时。第一部分：选择评审对象并收集信息（约 1 小时）。选择你团队负责的一个服务，或一个你熟悉的开源系统（如 Redis 集群部署、Kafka 消息管道）。收集以下信息：架构图、依赖清单、部署拓扑、监控仪表盘截图、最近三个月的事故记录、值班安排。如果信息缺失，把「缺失本身」记录下来——信息不可得往往是 PRR 的第一个红色信号。第二部分：执行简化版 PRR 检查清单（约 1.5 小时）。逐项检查以下维度并打分（0 分=完全缺失，1 分=部分具备，2 分=完备）：【监控】是否有基于症状的 SLI？是否有覆盖所有强依赖的监控？【告警】告警是否可操作？是否存在告警风暴历史？告警是否分级路由？【容量】是否知道单实例的容量上限？是否有容量预测和扩容流程？【故障处理】是否有值班手册？常见故障的处置步骤是否文档化？是否演练过回滚？【变更管理】发布是否自动化？是否支持金丝雀？配置变更是否有审计？【韧性】服务是否有过载保护？依赖故障时行为是否明确（超时、重试、熔断）？是否有单点故障？【数据】数据是否有备份？备份是否验证过可恢复？计算总分并对照：满分 28 分，20 分以上为「基本就绪」，12 到 19 分为「需要改进」，12 分以下为「未就绪」。第三部分：简单化审视（约 1 小时）。用四个问题审视系统：哪些组件如果删除，用户不会察觉？哪些依赖可以用更简单的方案替代（比如自建缓存换成托管服务）？哪些接口从未被调用或只有一个调用方？哪些「为了将来扩展」的抽象至今只用了一种实现？为每个发现写出简化建议和风险评估。第四部分：撰写 PRR 报告与改进计划（约 1 小时）。报告结构：服务概述、评分卡（各维度得分与证据）、Top 5 风险项（按「影响 × 概率」排序）、简化机会清单、分阶段改进计划（30 天内 / 90 天内 / 长期）。每个改进项必须写明负责人和验收标准。决策树练习：假设评审总分是 14 分，且「告警」和「故障处理」两个维度都是 0 分，而产品团队要求 SRE 下个月接管值班——你会同意吗？写出你的决策逻辑：先补齐告警和值班手册（否则接管等于让 SRE 盲飞），设定复查时间点，明确接管的前提条件清单，与产品团队达成书面协议。通过本实验你将体会到：PRR 的本质不是「把关」，而是把隐性的可靠性债务显性化，让接管决策基于事实而非人情。

延伸阅读

  • The Site Reliability Workbook 第 2 章 "The Evolving SRE Engagement Model"——本章的原始出处，详细描述了 Google 的 SRE 参与模式演进，包括简单化框架、生产就绪评审的完整流程，以及多个内部服务的接管案例研究。原文包含 PRR 检查清单的更多细节和 Google 团队的实际对话记录，值得精读。
  • SRE 黑皮书第 2 章 "The Production Environment at Google, from the Viewpoint of an SRE Team Member"——从一名 SRE 工程师的视角描述 Google 的生产环境全貌，包括 Borg 集群管理、Chubby 锁服务、监控体系等基础设施。读完这章你会理解为什么 Google 的 SRE 模式高度依赖其统一的基础设施，以及普通公司借鉴时需要做哪些适配。
  • Team Topologies（Matthew Skelton 与 Manuel Pais 著）——讨论技术团队的组织拓扑：流对齐团队、平台团队、赋能团队、复杂子系统团队四种类型。书中「平台团队」与「赋能团队」的概念与 Google 的框架 SRE 和咨询式 SRE 高度对应，为 SRE 组织设计提供了更通用的理论框架和大量行业案例。
  • Production Readiness Checklist（开源社区版本）——GitHub 上有多个受 Google PRR 启发的开源检查清单项目，如 dastergon/awesome-sre 中收录的各类生产就绪清单。它们把 Google 的方法简化为可直接使用的模板，适合中小团队快速起步，建议下载两三个版本对比后裁剪出自己的清单。`, 《Google SRE 课程：SRE 组织与参与模式》——Coursera 上 Google SRE 课程的相关章节，视频形式讲解了 SRE 团队的组建、参与模式选择和与产品团队的协作，配有 Google 工程师的访谈。适合团队集体观看讨论，作为启动 SRE 转型的 kickoff 材料。
  • Accelerate 第 9 章与第 12 章——讨论组织文化、团队边界与软件交付绩效的关系，用数据证明了松耦合架构和清晰团队边界对交付效率的影响。这些研究为「SRE 应该以什么模式介入产品团队」提供了组织行为学层面的证据支持。
  • The Phoenix Project 中关于「技术债与交接」的章节——小说中主人公接手混乱数据中心的桥段，生动展示了没有生产就绪评审的接管是什么样子：未知的依赖、缺失的文档、隐藏的故障模式。用这个故事向管理层解释为什么 PRR 值得投入时间，往往比技术论证更有效。
2/12SRE
0%