SRE 团队搭建：从招第一个人到建 10 人团队 原创

本文是 SRE 实战系列第 15 篇，也是这个系列第一次把镜头从"系统"转向"人"。全文约 9000 字，讲的是一个人力从 1 到 10 的真实过程：第一年招谁、第二年怎么分工、团队怎么不被 toil 淹掉、怎么向老板证明价值、招错人怎么止损。所有表格、JD、面试题、会议议程都可以直接改改就用。

这一篇回答的是第 9 篇（思维方式转变）留下的那个问题：思维方式可以一个人转变，但团队要从哪里长出来？

---

一、先说一个真实处境

老板把你叫进会议室，说：我们要做 SRE，你先牵头，先招一个人。

这时你手上通常有三样东西：

• 一堆没人接的告警
• 一个没人看过容量规划的集群
• 一份写了三个季度没动的"稳定性建设规划"

以及两样没有的东西：

• 没有编制说明——这个"SRE"到底干什么，老板心里是模糊的
• 没有验收标准——半年后怎么算干得好，没人说得清

绝大多数 SRE 团队最后变成"高级运维二组"，不是因为技术不行，而是因为这两个空白在第一周没被填上。第一周填不上，第一年就会一直被动救火；第一年被动救火，第二年就没有预算扩到 10 人。

所以本文不按"招聘、培训、管理"这种通用框架写，而按人数的真实节奏写：1 人 → 3 人 → 5 人 → 10 人，每个阶段解决一个特定问题，解决不了就不要进入下一阶段。

---

二、阶段零：招人之前，先定义这个岗位

2.1 一句话职责，而不是一页 JD

关于 SRE 的定义，Google 的书里有权威版本。但对团队搭建而言，那些定义都不够用——因为它们描述的是"成熟的 SRE 做什么"，而你面对的问题是"我们公司现在只有一个人，他能干什么"。

我建议在招第一个人之前，由你（和老板一起）写下一句话，贴在团队文档首页：

我们的 SRE 负责用工程手段让核心服务的可靠性变成可度量、可承诺、可改进的东西。我们不为具体的故障背锅，我们为故障的发现速度、恢复速度和重复发生率负责。

这句话有三个刻意的限定，每一个都很重要：

限定	排除了什么	为什么必须排除
用工程手段	排除了"帮我们手动发个版""帮我清一下日志"	不然第一个月就会被当共享运维用，第三个月 toil 占比 90%
核心服务	排除了全公司所有系统	1 个人撑不住 200 个服务，必须圈定战场
发现/恢复/重复发生	排除了"不能出故障"这个无法完成的目标	见第 9 篇的 MTTR/MTTD/MTBF 框架

这句话最大的作用不是对外宣传，而是对内划界。 以后任何需求进来，先问一句：它属于这三件事吗？不属于就不该排进你的队列。

2.2 招第一个人：三个必须项和三个陷阱

第一个人的画像，和第五个人的画像完全不同。第一个人要的不是最懂 SRE 的人，而是最能在一片荒地里自己开出路的人。

必须项（缺一不可）：

1. 能写生产级代码：不是"会写脚本"，而是能维护一个有测试、有 CI、有 review 的工具仓库。SRE 的产出物是系统，不是操作记录。
2. 有 Linux + 网络的硬底子：能独立定位"这条链路为什么慢"——从应用指标下钻到 TCP 重传、从 DNS 下钻到 conntrack（这一层的能力可以看第 14 篇）。
3. 能读得懂业务：知道这个服务的 QPS 从哪来、这 5 分钟不可用折算成多少钱。没有这个能力，SLO 就只能抄别人的数字。

加分项（有则更好，没有可培养）： Kubernetes 生产经验、Prometheus/Grafana 体系搭建经验、写过 Go/Python 工具、做过容量规划。

三个常见陷阱：

陷阱	现场表现	后果
招一个"经验丰富但只在大厂螺丝钉岗位待过"的人	张口 Prometheus 联邦、闭口百万级 QPS，但没独立从零搭过一套监控	第一个人需要的是"能独自把一件事从头做完"，不是"能在一个已有体系里维护一块"
招一个很听话的执行者	让干啥干啥，从不反驳	第一个人必须能替你顶住不合理的需求。你需要的是一起定义规则的合伙人，不是助手
招一个"运维老法师"	Linux 底层极强、故障处理极快，但拒绝写代码	他会变成单点、变成瓶颈，而且他会用"我十分钟就搞定"来合理化所有手工操作

2.3 面试怎么问：四道能筛出真本事的题

SRE 面试最大的失效点，是问了太多"你懂不懂"（知识题），太少"你怎么办"（判断题）。下面四道题，每一道都在测一种不可速成的能力。

题一（工程能力）：

描述一个你自己写过的、现在还在跑的工具。它的输入、输出、失败模式分别是什么？如果它挂了，你怎么知道？

• 好回答：能说清错误处理、告警方式、谁在用。
• 坏回答：只说功能，说不清失败后会怎样。说明他写的工具从没上过生产。

题二（故障判断）：

用户反馈"页面很慢"。你手上有应用指标、日志、链路追踪和 eBPF 三样工具。你的第一条命令是什么，为什么是这一条。

• 好回答：先确认范围（是所有用户还是部分、是所有接口还是某个接口），再选工具。说明他能快速收缩搜索空间。
• 坏回答：立刻开始翻某个具体仪表盘。说明他靠惯性排障，不靠推理。

题三（业务理解）：

你们线上支付服务 P99 从 200ms 涨到 350ms，SLO 目标是 99.9% 可用 + P99 200ms。现在要不要发版冻结？说出你的判断依据。

• 好回答：先看错误预算的剩余和消耗速率，再区分是持续劣化还是单点抖动，最后给出"冻结还是不冻结"的明确结论。
• 坏回答：只说"再看看"或"和产品商量"。说明他没有量化的决策习惯。

题四（边界感——最关键的一题）：

产品经理要求你"每天手工帮他导一份日报"。你怎么处理？

• 好回答：问清这份报表的使用者和使用频率 → 如果能自动化就给个定时任务 + 自助页面；如果是临时需求，就写进 toil 台账，累计到一定频次再处理。
• 坏回答："好的。"——这一声"好的"，就是未来 toil 占比 90% 的起点。

这四道题里，第四道的权重应该最高。 它测的不是代码能力，是这个人的时间观念和工程自尊。

---

三、阶段一（1-3 人）：先建立"一个人能赢"的战场

3.1 前 90 天：只做三件事

第一个人到岗后的前 90 天，不要碰架构、不要碰流程、不要写规划。只做三件能被别人看见、能被度量的事：

第 1 件事：给最重要的 3 个服务做一份"可观测性体检表"。

产出物是一张表，不是一套平台。表长这样：

服务	有 RED 指标	有健康检查	有资源 request/limit	告警有 Runbook	最近一次故障能定位到根因
order-service	✅	✅	❌	❌	❌
payment-api	✅	✅	✅	✅	✅
user-center	❌	✅	❌	❌	❌

这张表的价值：它是你第一次能用证据说话。 你不需要说"我们的可观测性不行"，你只需要把表发出去，缺口自己会说话。

第 2 件事：修掉表里"最便宜的那 30%。"

别从上到下全修。挑那些改一行配置就能补上的（补 resources、加探针、给现有告警补 Runbook URL），90 天内把体检表的绿灯率从 20% 拉到 60%。

第 3 件事：建立 toil 台账，从第一天开始。

用一个共享表格，每个人每天上班第一件事是往里面加一行：

日期	操作	耗时	触发原因	能否自动化	自动化收益估算
03-04	手工扩容 order-service	20 min	大促前预估不足	✅ HPA	每月省 6h
03-05	帮业务查日志找订单号	15 min	无自助查询	✅ 日志检索页	每月省 10h

为什么这件事从第一天就要做： 因为 toil 是隐性成本，不记账就等于不存在。一年后你要向老板申请第五个人时，唯一有说服力的材料就是这张表（第 9 篇里 50% 那条红线的数据来源，也是它）。

3.2 前 90 天的验收标准

给自己定三条可被检验的标准，90 天后主动向老板汇报：

• 全公司核心服务的数量、负责人、SLO 目标，有一张统一的清单（哪怕只有 10 行）
• 3 个核心服务的绿灯率从基线提升 40 个百分点以上
• toil 台账连续 8 周有记录，能算出当前 toil 占比

如果 90 天做不到这三件事，不要急着招第二个人。 因为这说明问题不是人力不足，而是方向不清——加人只会让混乱的规模变大。

---

四、阶段二（3-5 人）：从"我干"到"分工"

4.1 第一次分工：按责任域切，不按系统切

3 个人最容易犯的错是"你负责 A 业务、你负责 B 业务"。这种切法在 3 人时看似公平，到 5 人时就会撞车：同一个 K8s 集群三个人都在改，同一个 Prometheus 三个人都在加规则。

正确的切法是按责任域（capability）切，每个域有唯一 owner：

责任域	干什么	产出物	衡量指标
可观测性	指标/日志/链路采集、看板规范、存储成本	采集标准、看板模板	覆盖率、单指标月成本
稳定性治理	SLO 体系、告警治理、错误预算流转	SLO 清单、告警分级规范	告警有效率、SLO 覆盖率
平台与自动化	K8s 平台、GitOps、自助工具、CI/CD	自助平台、发布门禁	toil 占比、人均发布次数
容量与成本	容量规划、压测、成本优化	容量模型、成本报表	单位请求成本

注意：3 人时，一个人要带 1.5 个域（比如"可观测性 + 稳定性治理"）。

这没问题——重要的是每个域有唯一的人对结果负责，而不是每件事有三个人参与。

4.2 一个关键机制：域 owner 有决策权

分工能不能生效，取决于一个细节：owner 对自己域内的技术选型有没有最终决定权。

如果每件事都要"大家一起讨论"，那你得到的不是分工，是三个实习生向一个主管汇报。会开不完，决策还慢。

我的建议是明确写下来：

• 域 owner 在自己域内可以直接决定工具选型和实现方案，不需要开会
• 需要跨域协调的（比如采集标准的变更会影响 SLO 计算），走 RFC，一周内必须给出结论
• 涉及生产风险的变更（比如换采集器），走变更评审，但评审的重点是"如何回滚"，不是"要不要做"

4.3 5 人时的年度节奏：把工作排进日历

到 5 个人，团队必须有一份能被遵守的年度节奏，否则永远在响应别人的需求。

Q1：可观测性补全 —— 核心服务覆盖率 100%，告警有效率 > 60%
Q2：SLO 落地     —— Tier1/2 服务全部有 SLO，错误预算进 CI 门禁
Q3：自动化       —— 高频 toil 消除 Top 10，toil 占比降到 40% 以下
Q4：韧性验证     —— 混沌实验常态化，复盘改进完成率 > 80%

这份节奏的用法：任何不属于当季主题的需求，都被明确推迟到下一季，并记录在案。 记录在案这一步很重要——它让"被推迟"变成一次公开决策，而不是一次遗忘。

---

五、阶段三（5-10 人）：规模化带来的四个新问题

人数翻倍不是线性的。5 人到 10 人，会出现四个在小团队里根本不存在的病。

5.1 病一：on-call 变成轮盘赌

5 人时，一个人一周值一次班还能扛；10 人时如果还是"全员大轮",就会出现：每个人都在被叫醒，但没人真正熟悉被叫醒的那个服务。

解法：把 on-call 分成两层。

层级	职责	归属	响应时间
一线（L1）	按 Runbook 处置已知故障模式，判断升级	SRE 团队轮值	5 分钟应答
二线（L2）	处置未知故障，跨服务定位	服务 owner（含开发）	30 分钟应答

关键在第二条：让开发进 L2。 这不是把责任推给开发，而是把"你最懂自己的服务"这件事变成制度。实施时配套两件事：L2 只接 L1 升级过来的问题（不做初筛）、L2 的响应必须能在远程完成（不要求到公司）。

5.2 病二：知识只存在人脑里

10 个人里一定有两个"什么都知道"的人。他们不在的时候，团队就等于停摆。这不是他们的错，是团队的知识管理出了问题。

**检验方法（每季度做一次）：**随机抽 5 条 P1 告警，问一个跟这条告警无关的团队成员：这条告警意味着什么、第一步做什么、做完找谁。能答对 4 条以上算及格。

不合格就从两条抓手补：

1. Runbook 必须由告警创建者写、由域 owner 审核（第 6 篇里有告警强制带 Runbook 的 CI 门禁，可以直接用）
2. 每次故障复盘产出的改进措施里，至少有一条是"知识固化"——补文档、补看板、补自动化，三选一

5.3 病三：审批成了瓶颈

10 人团队常常会沉淀出一堆"需要 SRE 审批"的事项：改配置要审批、加告警要审批、上监控要审批。审批的初衷是控制风险，结果是把 SRE 变成了流程收费站。

解法：把审批拆成两半——能自动化的检查交给机器，剩下的人才审。

# 发布就绪检查：把"需要人审"变成"机器先查"
readiness_gate:
  auto_check:               # 机器判定，失败直接阻止
    - "deployment 有 resources.requests/limits"
    - "deployment 有 livenessProbe/readinessProbe"
    - "存在对应的 ServiceMonitor"
    - "告警规则包含 runbook 注解"
  human_review_only:        # 只有这些才需要人看
    - "影响 Tier1 服务的架构变更"
    - "SLO 目标值的调整"
    - "跨集群的网络策略变更"

判断标准很简单：如果一个检查项可以写成代码，就不该消耗一个人的一次点击。 第 9 篇里那份发布就绪清单，在这里的角色是"减少审批而不是增加审批"。

5.4 病四：招聘标准悄悄下降

这是最隐蔽的一种。团队 5 人时，你有精力认真面每个人；10 人时，招聘往往被交给最忙的人草草处理，"先来了再说"。

解法：维护一份"团队能力地图"，按季度更新。

能力项	现有覆盖人数	目标人数	缺口处理
K8s 平台	4	3	已满足
网络/内核排障	1	2	下个 HC 优先
SLO 体系与告警治理	2	2	已满足
工具开发（Go/Python）	3	3	已满足
成本与容量	0	1	培养内部人选

这张表的用法是：招聘不是"补人数"，是"补格子"。 每次开 HC，先看哪个格子的覆盖人数低于目标，再决定 JD 怎么写。

---

六、怎么招到第 5 到第 10 个人

6.1 三种来源，优先级从高到低

来源	优点	风险	适合补的格子
内部转岗（开发/运维/DBA）	懂业务、懂系统、信任成本低	需要 3-6 个月培养期	平台自动化、稳定性治理
社区/开源贡献者	有真实代码可看，能力可验证	数量稀少，需要长期运营	工具开发、可观测性
外部招聘有 SRE 经验者	上手快，能带来成熟做法	容易水土不服，也可能把大厂流程硬套过来	补关键缺口

一个容易被忽视的事实：前 5 个人里，至少 2 个应该来自内部转岗。 因为前 5 个人需要深度理解你们的系统，而这个知识在外面买不到。

6.2 JD 怎么写才有用

反面教材（99% 的 SRE JD 都长这样）：

熟悉 Linux、熟悉 Kubernetes、熟悉 Prometheus、有 SRE 经验、有良好的沟通能力、有责任心……

这段话里没有一个字能筛掉人。有效的 JD 应该写"你会做什么"和"我们怎么判断你做得好"，而不是"你需要会什么"。

一个可用的模板（可直接改）：

岗位：SRE 工程师（可观测性与稳定性方向）

你入职后前 6 个月会做的事：
1. 接管 3 个 Tier1 服务的可观测性与 SLO，产出可用的错误预算看板
2. 把当前每周约 8 小时的手工操作自动化掉（我们会给你 toil 台账）
3. 参与告警治理：把 P1 告警从每周 40 条降到 10 条以内，且不遗漏真实故障

我们怎么判断你做得好：
- 你负责的服务，平均发现时间（MTTD）在你的任期内下降
- 你写的工具有人在用，并且你知道它挂了会怎样
- 你提出的改进措施，有一半以上在 3 个月内落地了

我们不看：
- 你原来在多大的公司
- 你考过什么证书

"我们不看"这一段是这份 JD 里最有价值的部分。 它把不合适的人提前挡掉了，也把合适的人吸引过来了。

6.3 面试流程：4 轮，不超过 6 小时

轮次	内容	时长	谁来面	判定什么
1	简历与项目深挖	45 min	你	他做过的项目里，哪些是他真正做的
2	故障判断 + 编码	90 min	团队 2 人	现场给一个故障场景和一道小工具题
3	系统设计	60 min	跨团队（开发）	让他设计一个可观测性/发布体系
4	价值观与边界	30 min	你 + HR	toil 观念、会不会说"不"

第 3 轮让开发来面，是有意设计的。 它同时测两件事：候选人的协作姿态，以及开发团队对 SRE 角色的真实期待。很多团队忽略这一轮，结果招进来的人和开发团队互相看不上，半年就散了。

---

七、怎么让团队不被 toil 淹掉

7.1 toil 预算是团队级 KPI，不是个人觉悟

第 9 篇讲的是个人的 toil 治理，这里要讲团队版——因为在团队层面，toil 会自我强化：

toil 多 → 没时间做自动化 → toil 更多 → 人累 → 招人 → 新人先接 toil → 新人也在 toil 里出不来

打断这个循环的唯一办法，是把 toil 变成一个有预算、有看板、有月度清算的东西。

具体做法（每月 1 小时，团队一起做）：

1. 从 toil 台账里汇总上月的总耗时和占比
2. 按"周耗时 × 可自动化程度"排序
3. 投票选出下月要消灭的 Top 3 项，每项指定 owner 和截止日期
4. 上月没做完的项，继续留在表里——但不允许累积超过 5 项

一条硬规则：如果连续两个月 toil 占比超过 50%，当季不再接受任何新需求，全部精力用于还债。 这条规则要提前和老板谈好并写进团队文档——不然真到那天，你没有立场拒绝需求。

7.2 一个反直觉的做法：留出 20% 的"不排期时间"

10 人团队里，建议每周留半天（约 20% 时间）不做任何排期任务，由每个人自己决定干什么——看源码、修小工具、读论文、写文档都行。

这不是福利，是投资。因为：

• 团队里最有价值的工具，往往诞生于没有明确目标的时间
• 没有留白时间，人的注意力会一直停在"响应模式"，永远无法进入"设计模式"
• 这是留住工程师最便宜的方式——比加薪便宜，比调岗有效

衡量这 20% 有没有白花的办法：每季度问一次"这三个月你在这段时间里做出来的东西"，并把有价值的产出记进团队知识库。 如果连续两个季度没有任何有价值的产出，说明留白变成了摸鱼，此时再收紧也不迟。

---

八、怎么向老板证明这个团队值这个钱

8.1 别报"我们做了多少事"

技术团队汇报最常见的方式是"我们上线了监控平台、做了告警治理、落地了 SLO"。这三句话对老板来说约等于零信息，因为他无法判断这些事值多少钱。

要换算成他能感知的量纲。 下面这三个公式，比任何 PPT 都好用：

公式一：可用性损失折算成金额

月度稳定性收益 = 上月不可用时长减少量（分钟） × 每分钟业务损失

例：MTTR 从 45 分钟降到 20 分钟，月均 3 次 P1
   每月少损失 75 分钟 × 每分钟 2 万元 = 150 万元/月

这个数字要保守算，并且一定要和业务方对过一次。 对过一次的意义在于：以后这个数字就是双方共同认可的，不是 SRE 自说自话。

公式二：toil 消除折算成人月

月度效率收益 = 上月 toil 节省时长（小时） × 人均时薪 
             ≈ 节省时长 / 160 小时（人月）

例：月消除 240 小时手工操作 ≈ 1.5 个人月

公式三：成本优化折算成云账单

成本收益 = 上月云账单减少量（注意标注基线月份）

8.2 一份能过关的月度可靠性报告

每月一页，四个板块，用数据开头，不用文字开头：

板块	内容	数据来源
稳定性	本月 SLO 达成率、错误预算消耗、P1 故障数与 MTTR	SLO 看板
效率	toil 占比趋势、本月消除的 toil 项、发布次数	toil 台账、CI
成本	单位请求成本、上月环比	云账单、容量报表
下月	3 件事，每件都有可验收的完成标志	——

注意板块四的写法：只写 3 件事，每件事都要能被检验。 "推进告警治理"不是一个可验收的项；"把 P1 告警从每周 40 条降到 20 条以内，且真实故障召回率不低于 95%"才是。

8.3 用什么指标衡量团队本身

如果老板问"你们团队自己怎么衡量好坏"，不要回答"故障少"。用这四个：

指标	含义	参考目标
SLO 覆盖率	多少核心服务有可用的 SLO	> 80%
toil 占比	手工重复工作占团队总时间	< 40%（10 人团队可放宽到 50%）
MTTD / MTTR	发现与恢复速度	逐季度下降
复盘改进闭环率	复盘产出的措施按时完成的比例	> 80%

---

九、招错了怎么办：三个月的止损机制

这一节大多数团队搭建文章不会写，但它比招聘技巧更重要。招错人的成本不是工资，是团队里其他 9 个人的时间。

9.1 先区分"没长成"和"不合适"

这两件事的处理方式完全相反：

类型	表现	处理
没长成	能力缺口明确、愿意学、交付质量在提升但慢	换岗位/换域、给 3 个月明确目标和带教
不合适	价值观不匹配——比如反复把手工操作当成能力、拒绝写代码、把责任外推	尽早止损

核心判别标准是：这个人愿不愿意改变自己的工作方式。能力可以补，工作方式的改变意愿不能强求。

9.2 一个具体的止损流程

• 第 1 个月末：明确告诉他"你当前离这个岗位的要求差在哪一项"，落到书面
• 第 2 个月末：给一个具体的、和他能力缺口直接对齐的小项目，看交付
• 第 3 个月末：如果项目交付依然不达标，进入绩效流程，而不是无限延长试用

关键点：第一次沟通要在有具体证据的时候发生，不要等到"感觉不行"才开口。 证据是：某个工具交付延期了多少天、多少次需要别人重写、多少次把 toil 当成了正当工作。

9.3 这一节最重要的建议

在 3 人之前，宁缺毋滥。 因为早期招进来的人会定义团队的文化：如果他习惯手工操作，后面招来的人也会学着手工操作；如果他把深夜救火当成英雄主义，团队就会系统性低估自动化的价值。文化一旦成型，比技术债更难还。

---

十、一张路线图：四年把 1 个人带到 10 个人

阶段	人数	核心命题	关键动作	毕业标准
阶段零	0 → 1	定义岗位，划清边界	写一句话职责、定 90 天目标、建 toil 台账	老板能复述你的职责边界
阶段一	1 → 3	建立能赢的战场	可观测性体检表、补最便宜的 30%、toil 记账	3 件事可被验证
阶段二	3 → 5	分工与节奏	按责任域分工、域 owner 有决策权、年度节奏	toil 占比 < 50%
阶段三	5 → 8	规模化治理	on-call 分层、知识固化、审批自动化、能力地图	关键知识不再只存在人脑
阶段四	8 → 10	组织化运作	月度报告、季度能力盘点、梯队（每个域至少两人）	你休假一个月，团队照常运转

最后一格是整张表的终点，也是唯一的终极验收标准：如果团队离开你就运转不下去，那你建的不是团队，是你自己的延长线。

---

十一、六个常见误区

误区一：先把人招满，再想怎么做

错。 人多了但方向不清，只会把混乱放大 10 倍。正确的顺序是：先定义职责 → 招第一个人验证 → 再复制。

误区二：招人时优先看"有大厂 SRE 经验"

不一定对。 大厂经验里有大量"只有在大厂规模才成立"的做法。对 1-5 人的初始团队，能不能独立从零建起一套东西，比在成熟体系里维护过一块更重要。

误区三：分工就是分业务

错。 按业务分工，3 人之后必然撞车。按责任域分工、每域唯一 owner、owner 有决策权，是唯一能扛住人数增长的切法。

误区四：团队扩大后，toil 问题会自动缓解

错，会加剧。 新人进来先接 toil，是默认路径。如果不主动打断，人数翻倍 toil 也翻倍，加人变成了加负债。

误区五：向老板汇报要讲技术成果

错。 老板能感知的量纲只有三个：钱、时间、风险。技术成果必须换算成这三者之一，否则再大的工作量在他那里也是"你们很忙"。

误区六：招错人是运气问题

不完全是。 招错人的成本可以控制——只要你在第一个月就把差距讲清楚、第三个月就敢做决定。真正把招错人拖成灾难的，是"再看看"。

---

写在最后

从 1 个人到 10 个人，本质上和从运维到 SRE 是同一种转变，只是对象不同：

• 对系统，你要做的是把"人肉响应"换成"自动化系统"
• 对团队，你要做的是把"个人英雄"换成"可复制的组织能力"

前者写成了这个系列的前 14 篇。后者，落地时其实只要问一个问题：

如果明天我离开这个团队一个月，会发生什么？

如果答案是"照常运转"，你就成功了。如果答案是"乱成一团"，那你现在还只是一个人的 SRE，不是一个团队的 SRE。

这件事和你的技术水平无关，和你的组织能力有关。 而组织能力，只能靠一次次真实决策攒出来。

---

本文是 SRE 实战系列第 15 篇。前 14 篇把系统和流程铺开了：SLO 体系（3-5、10 篇）、告警治理与分级（6、8、13 篇）、可观测性（7、12、14 篇）、工程效能（11 篇）、文化与思维（9 篇）。本文把这些实践落到了"谁来干、怎么分工、怎么证明价值"这个最实际的问题上——因为再好的方法论，也需要一个能持续运转的团队来承载。

系列回顾：第 9 篇讲的是一个人的思维方式怎么变，本文讲的是一个团队的能力怎么长出来；第 10 篇讲错误预算怎么用，本文讲的是怎么让老板认可错误预算背后那笔投入。

下一篇预告：SRE 成熟度模型——你的团队在第几级，以及每一级怎么往上跳。