16 SRE 与研发协作

概述#

SRE 不是一个孤立的团队——如果 SRE 和研发之间是"互相甩锅"的关系，前面 15 章讲的所有方法论都会失效。可靠性是研发和 SRE 的共同责任，不是 SRE 的单方面承诺。

本章讲清楚三种协作模型、可靠性准入机制、以及怎么在组织里建立责任共担的文化。

SRE 与研发协作是整本书的落地点——前面 15 章讲的所有方法论（SLO、Error Budget、告警工程、事件管理、混沌工程），都需要研发团队的参与和认可才能真正生效。

一、三种协作模型#

模型 1：嵌入式 SRE（Embedded SRE）#

SRE 工程师嵌入到研发团队中，和研发一起做架构设计、Code Review、发布决策。

适用：大型业务线、独立产品。

Google 的实践：每个产品线配 1-2 名嵌入式 SRE，参与日常开发活动，但绩效考核在 SRE 组织（避免被同化）。嵌入式 SRE 每 12-18 个月轮换，防止知识过度集中。

模型 2：平台 SRE（Platform SRE）#

SRE 团队建设共享的可靠性平台（可观测性、发布系统、容量平台），研发自助使用。

适用：中大型组织，多条业务线。

风险：平台 SRE 容易变成"工具团队"——只管建平台不管业务是否用好。需要配合"可靠性准入"机制强制研发使用平台。

模型 3：混合模型（Hybrid）#

平台 SRE 建基础设施 + 部分 SRE 嵌入核心业务。这是中大型公司的常见选择：

SRE 组织
├── 平台组（Platform SRE）：可观测性、发布、SLO 框架
│   ├── 可观测性团队
│   ├── 发布工程团队
│   └── 容量与成本团队
└── 嵌入组（Embedded SRE）：分配到核心业务线
    ├── 交易业务 SRE
    ├── 支付业务 SRE
    └── AI 业务 SRE

优势：平台组建标准化的工具和流程，嵌入组保证业务得到定制化支持。两者互相反馈——平台组从嵌入组了解真实需求，嵌入组从平台组获得工具支持。

模型选择的考量#

二、可靠性准入机制#

服务从开发到上线的可靠性检查点#

"可靠性准入清单"（示例）#

新服务上线前必须通过：

• SLI 已定义（至少成功率和 P99 延迟）
• SLO 目标已和业务方商定
• Prometheus Recording Rules 和告警规则已部署
• 告警全链路已验证（firing + resolved 都能到达目标群）
• Runbook 已编写（至少包含如何判断真问题和回滚步骤）
• Dashboard 已创建（至少 RED 面板）
• PodDisruptionBudget 已配置
• 健康检查（liveness/readiness）已配置
• 压测基准已建立
• 日志已结构化（JSON 格式）
• 链路追踪已接入（OpenTelemetry）
• 容量规划文档已编写
• 回滚流程已预演

这份清单是硬门槛——不是建议，是新服务上线必须满足的条件。SRE 有"一票否决权"：清单没通过的服务不能上线。

服务成熟度分级#

组织应该制定一个时间表：

• 新建服务必须在 1 个月内达到 L1
• 核心服务 3 个月内达到 L2
• 支付等关键服务 6 个月内达到 L3
• 所有核心服务 12 个月内达到 L4

可靠性准入的执行#

准入清单不是"写在 wiki 里的建议"，需要强制执行：

• CI/CD 流水线集成检查（如告警规则没提交则不能发布）
• SRE review 环节作为发布流程的必经节点
• 服务等级评估每月 review，未达标的限期整改
• 新服务 owner 必须参加"SRE 入门培训"

三、责任共担模型#

传统模型 vs SRE 模型#

三条责任边界#

On-call 分层#

最关键的分层：基础设施 on-call vs 应用 on-call。

On-call 升级路径：
  应用告警 → 应用研发 on-call（5 min ack）
    → 应用研发处理不了 → 升级到 SRE
  基础设施告警 → SRE on-call（5 min ack）
    → SRE 处理不了 → 升级到 IMOC

核心原则：应用研发必须 on-call 自己的服务。不 on-call 自己代码的工程师不是完整的工程师——只有 on-call 过才会真正理解"运维体验"，写出更易维护的代码。

研发参与 On-call 的好处#

1. 理解运维痛苦：亲身体验过告警的工程师，下次写代码会更注意可观测性
2. 快速修复 bug：应用告警最懂代码的是写代码的人
3. 分担 SRE 压力：SRE 不必所有告警都响应
4. 建立可靠性意识：on-call 是最好的"可靠性教育"

研发参与 On-call 的挑战#

1. "我不是运维"：需要文化引导——on-call 是工程师职责的一部分
2. 不熟悉基础设施：需要培训——SRE 给研发做 on-call 培训
3. 担心影响开发进度：需要管理支持——on-call 时间算工作时长，不是额外负担
4. 夜间告警恐惧：需要告警治理——研发只接应用层告警，不接基础设施告警

四、典型反模式#

反模式 1：SRE 当高级运维#

组织给 SRE 配了团队，但不给工程时间，全用在救火上。半年后核心成员离职。

修正：50% toil 上限是硬指标。SRE 团队的工程时间必须被保护，管理层要 review toil 占比。

反模式 2：SLO 形式化#

定了一堆 SLO 但不参与发布决策，错误预算耗尽也没人管，SLO 变成 dashboard 装饰。

修正：SLO 必须和发布决策绑定。Error Budget 耗尽 = 冻结发布，这条规则必须管理层签字。

反模式 3：Postmortem 走过场#

开了复盘会但 Action Items 没人跟进，同样的故障反复发生。

修正：Action Items 进 OKR，完成率作为团队 KPI。

反模式 4：SRE 和开发对立#

SRE 变成"拦着不让发版"的角色，开发绕着走，组织政治消耗巨大。

修正：用 Error Budget 数据决策。SRE 不拦发布，数据拦发布——Budget 不足就冻结，Budget 充足就放行。

反模式 5：没有 blameless 文化#

复盘开成追责会，工程师不敢说真话，根因永远是"操作失误"。

修正：领导层明确支持 blameless。复盘文档不写人名，用角色。

反模式 6：责任推诿#

"你的服务你 on-call，但这个数据库问题不归我管"

修正：明确各层的 on-call 归属。应用层 = 研发，基础设施层 = SRE，数据库 = DBA（或 SRE 兼）。

反模式 7：把 SRE 当运维外包#

"SRE 就是帮我们做运维的"——开发不参与 on-call、不写告警、不写 Runbook。

修正：强调 SRE 是工程角色。开发必须参与自己服务的可靠性工作。

五、如何推动 SRE 文化落地#

从技术到组织的推进路径#

Phase 1: 选一个痛点最大的服务 → 建 SLO 体系 → 看到效果 → 研发开始信任
Phase 2: 推广到核心服务线 → 建标准 → 建平台 → 提高效率
Phase 3: Error Budget 政策生效 → 发布决策数据化 → 文化形成

关键洞察：SRE 文化不是"推行"出来的，是"做出效果后自然形成的"。第一个服务做出来后，其他团队会主动要求加入——因为他们看到了效果。

与开发的沟通策略#

阻力 1："99.9% 太严格了，我们根本达不到"

解法：把 SLO 目标和 Error Budget 一起讲。"我们允许每月有 43 分钟不可用，目前还有 30 分钟余量"——数字比百分比更有说服力。

阻力 2："告警太多了，都是误报"

解法：让开发参与调整告警阈值和 for 时间。记录每次告警是否有效，3 个月回顾。

阻力 3："我的功能很重要，必须按时发布"

解法：把 Error Budget 放在公共 Dashboard 上。"当前还剩 X% 的 Budget，这次发布风险评估是 Y，是否继续由团队共同决定。"

阻力 4："SLO 体系太复杂，我们团队没时间搞"

解法：SRE 提供"开箱即用"的 SLO 模板和工具。研发只需填 SLI 定义，其他自动生成。

阻力 5："混沌工程太危险，不能在 prod 做"

解法：从 dev 开始，逐步推到 staging，最后 prod。每一步都展示效果——"演练发现的 7 个问题，修复后系统韧性显著提升"。

SLO 推进的三阶段（从 SLO 实战文章提取）#

阶段 1（1-2 月）：只观察，不告警
  → 建 Dashboard，让团队熟悉指标
  → 修正 SLI 计算逻辑
  → 让业务方先看到数字，建立共识

阶段 2（3-4 月）：引入告警
  → 只配 P1 告警（快速消耗）
  → 每月 Error Budget 回顾
  → 建 SLO 违规复盘流程

阶段 3（5 月+）：SLO 影响决策
  → Error Budget 冻结策略生效
  → SLO 指标影响发布决策
  → 每季度回顾并调整 SLO 目标

管理层的角色#

SRE 文化落地需要管理层支持：

• CTO/VP 明确表态：可靠性是工程目标，不是运维负担
• 资源支持：给 SRE 团队足够的工程时间，不被 toil 淹没
• 决策支持：Error Budget 冻结发布时，管理层不"开后门"
• 文化支持：blameless 复盘，管理层不追责个人
• 考核支持：SLO 达标率进团队 OKR，不只是 SRE 的 KPI

没有管理层支持，SRE 文化只能停留在"工具层面"，无法形成真正的组织能力。

六、SRE 与研发的日常协作#

架构评审#

新服务或重大架构变更时，SRE 参与 review：

• 是否有单点故障
• 是否有熔断/降级/重试设计
• 是否考虑了容量规划
• SLO 目标是否合理
• 可观测性是否到位
• 故障恢复路径是否清晰

Code Review#

SRE review 可靠性相关代码：

• 错误处理是否完整
• 重试逻辑是否正确（幂等、Jitter、最大次数）
• 资源释放是否到位（连接池、文件句柄）
• 日志是否结构化
• 埋点是否完整

联合演练#

SRE 和研发一起做混沌工程演练：

• SRE 设计演练方案
• 研发参与执行（了解系统在故障下的行为）
• 共同复盘，共同修复

知识共享#

• SRE 给研发做可靠性培训
• 研发给 SRE 做业务逻辑培训
• 共同维护 Runbook
• 联合 Postmortem

实战要点#

1. SRE 不是研发的运维外包。如果 SRE 工作变成纯操作（toil > 50%），组织没有真正实施 SRE。
2. 可靠性准入清单是"硬门槛"。不是建议，是新服务上线必须满足的条件。
3. On-call 责任必须分层：基础设施 SRE on-call 管集群/网络/存储，应用研发 on-call 管自己的服务。
4. 用数据替代争论。不吵"能不能发版"，看 Error Budget；不吵"告警是不是太多"，看真阳率和 MTTA。
5. 第一个成功案例最关键。选一个痛点最大的服务做 SLO 试点，做出效果后其他团队会主动跟进。
6. 管理层支持是前提。没有 CTO/VP 的明确支持，SRE 文化无法落地。
7. 研发必须 on-call 自己的服务。不 on-call 自己代码的工程师不是完整的工程师。
8. 责任边界必须清晰。SRE 建平台，研发用平台；SRE 定标准，研发执行标准。边界不清就会互相推诿。
9. 持续培训。SRE 给研发做可靠性培训，研发给 SRE 做业务培训——互相学习才能协作。
10. 庆祝成功。每次 SLO 达标、每次演练通过、每次事故成功恢复——都要公开认可。正向反馈强化文化。

小结#

SRE 与研发的协作是整本书的落地点——前面 15 章讲的所有方法论（SLO、Error Budget、告警工程、事件管理、混沌工程），都需要研发团队的参与和认可才能真正生效。核心原则就一条：可靠性是团队运动，不是 SRE 的单人赛。

判断一个组织的 SRE 文化是否成熟，看三件事：

1. 研发 on-call 自己的服务（不是 SRE 全包）
2. 发布决策基于 Error Budget（不是 SRE 拦发布）
3. 复盘是 blameless 的（不是追责会）

三件事都做到是成熟文化；只做到一两件是"在建立中"；一件都没做，SRE 就是"换了名字的运维"。

SRE 文化的最高境界是"消失"——当所有研发都具备可靠性意识、都参与 on-call、都写 SLO 时，SRE 团队可以专注做更前瞻的工程（如混沌工程、自愈系统、容量规划）。SRE 不是"帮研发做运维"的团队，而是"让研发能自己做运维"的团队。

这就是 SRE 路线的终点：让可靠性成为每个工程师的肌肉记忆，而不是某个团队的专属责任。