概述
凌晨三点，核心交易系统挂了。值班同学手忙脚乱地翻 Runbook，DBA 说不是数据库的问题，网络组说链路正常，开发说代码没改。三个团队互相甩锅，故障恢复时间拖了 47 分钟。
这是很多公司运维现状的缩影。问题不在于人不努力，而在于没有一个工程化的可靠性团队来拆解问题。
SRE（Site Reliability Engineering）这个概念是 Google 在 2003 年提出来的。Ben Treynor Sloss 带着一帮软件工程师，用写代码的方式解决运维问题，而不是靠堆人力。(Google SRE 书 里把这个故事讲得很清楚)
但"建一个 SRE 团队"这件事，远比"招几个 SRE 工程师"复杂。这篇笔记记录的是从零搭建 SRE 团队的实战经验——岗位怎么设、人怎么招、能力怎么评、团队怎么带。不讲理论框架，讲踩过的坑和跑通的做法。
为什么要建 SRE 团队，而不是继续用传统运维
先说清楚一个根本问题：SRE 和传统运维到底有什么不同？
传统运维团队的核心模式是"人肉运维"——出了问题靠经验排查，日常操作靠手动执行，知识靠师傅带徒弟口口相传。人越多，能覆盖的系统越多，但效率不会提升。真正的问题在于，这种模式下，运维工作量随系统规模线性增长，而人不可能无限招。
Google 的做法是用软件工程的方法替代重复性操作。SRE 团队里，每个人花在纯运维操作上的时间不超过 50%，剩下时间必须用来做工程化改进——写自动化工具、设计监控系统、优化部署流程。Google 在《SRE: Google 运维解密》中明确要求 SRE 团队的琐事（Toil）占比不得超过 50%，这叫"50% 规则"。(Google SRE Book - Eliminating Toil)
对比如下：
| 维度 | 传统运维团队 | SRE 团队 |
|---|---|---|
| 核心能力 | 操作执行、经验排查 | 编码、系统设计、自动化 |
| 工作模式 | 被动响应 | 主动工程化 |
| 知识传承 | 口口相传 | Runbook、文档、代码 |
| 团队规模与系统规模 | 线性增长 | 边际递减 |
| 考核导向 | 处理工单数量 | 可靠性指标 + 自动化覆盖率 |
| 故障处理 | 救火为主 | 事后复盘 + 系统性改进 |
一句话总结：传统运维是"用人力扛系统"，SRE 是"用代码养系统"。
SRE 团队的组织架构设计
三种常见模式
团队怎么组织，取决于公司规模和业务复杂度。我见过三种主流模式，各有适用场景：
模式一：集中式 SRE 团队
一个独立的 SRE 部门，服务所有业务线。适合中小型公司（50-500 人技术团队）。
CTO
└── SRE 部门
├── 基础设施组（机房、网络、存储）
├── 平台工具组（CI/CD、监控、日志）
├── 可靠性组（SLO、故障演练、容量规划）
└──值班轮岗组（On-Call）
好处是技术栈统一、工具链复用、标准一致。坏处是离业务远，有时候不理解业务为什么需要这么搞。
模式二：嵌入式 SRE
SRE 工程师分散到各业务线，向业务线汇报，同时虚线向 SRE 部门汇报。适合大公司（500+ 技术团队，多条业务线）。
CTO
├── 交易业务线
│ ├── 开发团队
│ └── SRE（业务线归属，虚线向 SRE 部门汇报）
├── 风控业务线
│ ├── 开发团队
│ └── SRE
└── SRE 平台部门（提供共享工具和标准）
好处是 SRE 深度理解业务，响应快。坏处是标准难统一，各业务线各搞各的。
模式三：平台 + 嵌入式混合
这是 Google 等大厂采用的模式。有一个 SRE 平台团队做基础设施和工具，各业务线有自己的嵌入式 SRE。平台团队负责"造武器"，嵌入式 SRE 负责"打仗"。
CTO
├── SRE 平台部门
│ ├── 监控告警平台组
│ ├── 容器与编排组
│ ├── 变更管理组
│ └── 可靠性工程组
├── 业务线 A
│ └── 嵌入式 SRE（使用平台工具，深耕业务）
└── 业务线 B
└── 嵌入式 SRE
我推荐的做法
公司技术团队 100 人以下，用集中式。100-500 人，集中式 + 按业务线分组。500 人以上，考虑平台 + 嵌入式。
别上来就抄 Google 的模式。Google 有几千个 SRE，他们能搞嵌入式是因为平台基础设施足够成熟。你连监控都没搞明白就搞嵌入式，最后就是每个业务线各搞一套，比传统运维还乱。
岗位设计与职责划分
核心 SRE 岗位
一个 SRE 团队需要以下几类角色，不一定每类一个人，小团队可以一人多岗：
1. SRE 工程师（核心岗）
SRE 团队的绝对主力。要求同时具备系统运维能力和编码能力。日常工作包括：
- 参与系统架构评审，提可靠性建议
- 编写自动化工具（部署、巡检、故障自愈）
- 设计和实现监控告警
- 参与值班和故障处理
- 编写和维护 Runbook
这个岗位最核心的要求是：能写代码。不是"会写 Shell 脚本"那种，而是能写 Go/Python 服务、能维护基础设施代码（Terraform/Ansible）。
2. 平台工程师
负责构建内部开发者平台——让开发团队能自助完成部署、监控、扩缩容等操作。这个岗位偏架构设计，需要理解开发团队的需求和痛点。
3. 可靠性工程师
专注于 SLO 设计、错误预算管理、故障演练、容量规划。这个岗位不一定需要编码能力很强，但必须对可靠性理论有深入理解，能驱动业务团队做可靠性决策。
4. On-Call 工程师
值班岗位，负责一线故障响应。在小团队中，这个角色由 SRE 工程师轮岗承担。大团队可以设专职。
岗位配比建议
| 团队规模 | SRE 工程师 | 平台工程师 | 可靠性工程师 | 开发:SRE 比 |
|---|---|---|---|---|
| 10-50 人开发 | 1-2 | 0（SRE 兼） | 0（SRE 兼） | 1:15 |
| 50-100 人开发 | 2-3 | 1 | 0（SRE 兼） | 1:12 |
| 100-300 人开发 | 4-6 | 2 | 1 | 1:10 |
| 300+ 人开发 | 8+ | 3+ | 2+ | 1:8 |
开发:SRE 比这个数字是经验值。Google 大约 1:7 到 1:10（取决于业务复杂度），但 Google 的 SRE 门槛极高。对国内大部分公司，1:10 到 1:15 是合理的起步比例。
SRE 能力模型
能力矩阵
下面这套能力矩阵是我从实际团队管理中总结出来的，分四个维度、三个等级。
四个维度：
- 系统工程——Linux 内核、网络、存储、数据库
- 编码与自动化——至少一门编程语言、IaC 工具、CI/CD
- 可观测性——监控、日志、链路追踪、告警设计
- 可靠性工程——SLO、错误预算、故障分析、容量规划
三个等级：
| 等级 | 定义 | 典型能力 |
|---|---|---|
| L1 初级 | 能执行、能排查常见问题 | 会用基本 Linux 命令排障；能写 Shell/Python 脚本；能维护已有监控系统 |
| L2 中级 | 能设计、能优化、能独立负责 | 能设计监控体系；能写 Go/Python 服务；能用 Terraform/Ansible 管理基础设施；能定义 SLO |
| L3 高级 | 能规划、能驱动变革 | 能设计团队级可靠性策略；能主导架构演进；能培养 L1/L2 人才；能影响产品决策 |
完整能力矩阵如下：
| 能力维度 | L1 初级 | L2 中级 | L3 高级 |
|---|---|---|---|
| 系统工程 | 熟悉 Linux 基础；会排查 CPU/内存/磁盘/网络常见问题 | 理解内核调度/内存管理/网络栈；能调优系统参数 | 能设计多地域多活架构；能做深度性能分析 |
| 编码与自动化 | 能写 Shell 脚本和简单 Python；会使用 Ansible playbook | 能用 Go/Python 开发运维工具；能用 Terraform 管理 IaC | 能设计内部开发者平台；能驱动全公司自动化标准 |
| 可观测性 | 能维护 Prometheus/Grafana；能配置告警规则 | 能设计全链路监控方案；能用 OpenTelemetry 统一可观测性 | 能设计可观测性平台架构；能用数据驱动可靠性决策 |
| 可靠性工程 | 理解 SLI/SLO 概念；能参与值班 | 能独立定义和实施 SLO；能做容量规划 | 能设计错误预算策略；能驱动故障复盘改进落地 |
招人时的能力评估
招 SRE 最头疼的问题：怎么判断一个人是真 SRE 还是包装过的传统运维？
我的方法是：面试分四轮，每轮重点不同。
第一轮：线上编码（30 分钟）
不是 LeetCode 算法题。给一个实际运维场景，让候选人写代码。比如：
“写一个 Python 脚本，检查 Kubernetes 集群中所有 Pod 的资源使用情况，找出 CPU 使用率超过 80% 且 Request 配置不足的 Pod，输出到 CSV。”
这道题考察的是：Python 编码能力、Kubernetes API 使用、对 Request/Limit 的理解。传统运维大概率写不出来。
第二轮：系统排障（45 分钟）
给一个真实故障场景，让候选人描述排查思路。比如：
“线上服务延迟从 50ms 涨到 500ms，CPU 使用率正常，内存使用率 60%，网络带宽正常。怎么排查？”
好答案：从应用层开始看 GC 日志、看数据库慢查询、看锁竞争。差答案：重启试试。
第三轮：系统设计（45 分钟）
让候选人设计一个监控系统。比如：
“公司有 50 个微服务，300 台服务器。设计一套监控方案，要求覆盖基础设施、中间件、应用层，能实现分钟级故障发现。”
考察的是监控分层思维、工具选型能力、告警策略设计。
第四轮：文化与价值观（30 分钟）
聊对值班、故障复盘、自动化的看法。判断候选人的工程文化认知。
“你觉得 SRE 最该做的事情是什么？” “故障复盘时，如果发现是某个人操作失误导致的，你会怎么处理？”
第二个问题的答案很重要。如果候选人说"处罚这个人"，那他还不理解 SRE 文化。正确方向是：分析为什么这个操作会出错（是不是缺少防呆设计？是不是自动化程度不够？），推动系统性改进。
团队梯队建设
从 0 到 1 的建队路径
阶段一：核心 1-2 人（0-3 个月）
找 1-2 个 L2/L3 级别的 SRE，先搭起来监控和告警基础。这个阶段不要招 L1，因为没有 L2/L3 带，L1 会迷茫。
这个阶段的目标：让团队知道系统在干什么。监控覆盖率从 0 到 60%，核心服务有告警。
阶段二：扩展到 3-5 人（3-6 个月）
加入 1-2 个 L1 和 1 个 L2。L1 负责日常值班和运维操作，L2 负责平台工具建设。
目标：监控覆盖率 80%，CI/CD 基础流水线跑通，核心服务有 Runbook。
阶段三：成型团队 5-10 人（6-12 个月）
加入平台工程师和可靠性工程师角色。开始做 SLO 设计、故障演练、容量规划。
目标：核心服务有 SLO，完成第一次混沌工程演练，On-Call 轮值制度建立。
阶段四：成熟团队 10+ 人（12 个月+）
拆分平台团队和业务 SRE 团队。平台团队做工具，业务 SRE 深耕业务线。
目标：自动化覆盖率 70%+，Toil 占比控制在 50% 以下，有完整的可靠性度量体系。
人才培养机制
师徒制
每个 L1 配一个 L2/L3 做 mentor。mentor 的职责包括：Code Review、技术方案评审、职业发展建议。这比扔一堆文档给新人有效得多。
轮岗制
让 SRE 工程师在不同业务线之间轮岗。好处是避免知识孤岛，坏处是有短期效率下降。建议每 6-12 个月轮一次。
故障复盘驱动学习
每次故障复盘都是一次团队学习机会。复盘会议要求全员参加（值班人员不在时另补），复盘产出改进项分配到个人，改进结果在下次复盘时回顾。
Google SRE 团队有一个原则叫"Blameless Postmortem"——无指责复盘。复盘的目的是"理解发生了什么"而不是"找出谁该罚"。(Google SRE Book - Postmortem Culture) 这个理念必须贯彻，否则团队会开始隐瞒问题，那才是最大的隐患。
考核与激励
SRE 的 OKR 设计
SRE 团队的考核不能用"处理了多少工单"来衡量——这会鼓励制造工单。应该用可靠性指标和工程化指标。
O1：提升系统可靠性
| KR | 目标 | 衡量方式 |
|---|---|---|
| 核心服务 SLO 达标率 | > 99.9% | 月度 SLO 报告 |
| MTTR（平均恢复时间） | < 15 分钟 | 故障工单统计 |
| 故障数量（P0/P1） | 同比下降 30% | 故障工单统计 |
O2：提升自动化覆盖率
| KR | 目标 | 衡量方式 |
|---|---|---|
| Toil 占比 | < 50% | 工时统计 |
| 自动化巡检覆盖率 | > 80% | 脚本/平台统计 |
| CI/CD 流水线覆盖率 | > 90% | 流水线统计 |
O3：知识沉淀
| KR | 目标 | 衡量方式 |
|---|---|---|
| Runbook 覆盖率 | 核心服务 100% | 文档统计 |
| 故障复盘改进项关闭率 | > 90% | 复盘跟踪 |
On-Call 激励
On-Call 是 SRE 团队最辛苦的活。不能让值班的人既辛苦又没回报，否则没人愿意值班。
我的做法是：
- 值班补贴——工作日 200 元/天，周末 500 元/天，节假日 800 元/天
- 值班后的调休——夜间被叫醒处理故障，第二天可调休半天
- 季度 On-Call 之星——由团队投票选出，额外奖金
值班轮换周期建议 1-2 周一轮，太短交接成本高，太长疲劳积累严重。
避坑指南
坑一：招了传统运维贴 SRE 标签
这是最常见的坑。招了一堆"会写 Shell 脚本的运维"，挂上 SRE 的 title，但实际上干的还是传统运维的活。
怎么避免：面试必须考编码。不是考算法，是考实际工程问题。如果候选人连 Kubernetes API 都不会调用，那他离 SRE 还有距离。
坑二：SRE 变成背锅侠
“系统挂了是 SRE 的责任”——这个认知要趁早纠正。SRE 的职责是"保障可靠性"，但可靠性是设计出来的，不全是运维出来的。如果开发团队上线不经过测试、不做灰度、不设限流，SRE 再强也兜不住。
解决方法：建立变更管理流程。任何上线必须经过 SRE 评审（至少核心服务），CI/CD 流水线里卡质量门禁。SRE 有权拒绝不达标的上线。
坑三：工具越多越乱
SRE 团队容易陷入"造轮子"的怪圈。监控系统用 Prometheus，又搞了一套 Zabbix；CI/CD 用了 Jenkins，又搞了一套 GitLab CI；告警有 Alertmanager，又搞了一套自研告警平台。
工具不是越多越好。每多一个工具，就多一份维护成本。我的原则是：能用开源的不自研，能用一套的不搞两套。如果现有工具确实满足不了需求，先评估是否有替代方案，实在没有再自研。
坑四：过度追求 SLO 精度
有些团队上来就想把 SLO 设计得特别精确——四个九、五个九、6 个 Sigma。精度越高，工程成本越高。
Google 的经验是：大部分服务 99.9% 就够了。用户感知不到 99.9% 和 99.95% 的区别。与其追求 0.05% 的提升，不如先把 MTTR 从 30 分钟降到 10 分钟。(Google SRE Book - Service Level Objectives)
坑五：团队文化不是喊口号
“无指责复盘"“自动化一切"这些文化不是贴在墙上的。需要团队 leader 在每次复盘、每次评审中身体力行。如果 leader 自己复盘时就在找人追责，那团队的信任基础很快就塌了。
坑六：把 AI 当万能药
2026 年 AIOps 很火，很多公司觉得上了 AI 就能解决一切运维问题。实际上，如果监控数据质量差、告警策略不合理，AI 只会让你更快地收到更多垃圾告警。先打好基础设施——标准化监控数据、优化告警策略、积累高质量历史数据，然后再谈 AI。
SRE 与开发团队的协作边界
这个问题不解决，团队建起来也是内耗。
SRE 负责：基础设施、平台工具、监控告警、值班响应、可靠性策略
开发负责：业务代码、单元测试、性能优化、业务监控埋点
共同负责：SLO 定义、容量规划、故障复盘
关键原则：SRE 不是开发的保姆，开发也不是 SRE 的甲方。两者是协作关系。SRE 提供平台和标准，开发在平台上自助操作。如果开发团队连部署都需要 SRE 手把手帮，说明平台做得不够好——这是 SRE 的问题，不是开发的问题。
总结
建一个 SRE 团队，核心就三件事：
选对人。SRE 的核心能力是编码 + 系统理解 + 可靠性思维。面试时务必考实际工程问题，别被简历上的证书忽悠。
搭好结构。组织架构要匹配公司规模，集中式适合小团队，混合式适合大团队。别照搬大厂模式，先解决自己的问题。
养好文化。无指责复盘、50% 规则、自动化优先。这些不是口号，需要在日常工作中一点一点落实。
团队建设是长期工程，别指望半年就能见效。我见过最快的团队也要 12 个月才能形成战斗力。但一旦跑起来，SRE 团队带来的收益远超成本——系统更稳定、故障恢复更快、开发效率更高、技术债可控。
最后说一句：SRE 团队的价值不是"不出故障”，而是"出了故障能快速恢复，并且同样的故障不犯第二次”。这才是可靠性工程的本质。
参考资料与致谢
本文在撰写过程中参考了以下资料，感谢原作者的贡献：
- Google SRE Book - Introduction — Google SRE 团队，SRE 概念的起源与核心理念
- Google SRE Book - Eliminating Toil — Google SRE 团队，50% 规则与琐事治理
- Google SRE Book - Postmortem Culture — Google SRE 团队，无指责复盘文化
- Google SRE Book - Service Level Objectives — Google SRE 团队，SLO 设计方法与实践
- What Does a Site Reliability Engineer Do? — Coursera，SRE 岗位职责与技能要求
- Building your digital transformation team: 4 essential roles — Red Hat，团队角色设计与职责划分