DevOps / SRE 总览:开发 vs 运维 vs SRE / 这个系列要解决什么
工程师对「DevOps / SRE」最大的误解是把它当成「升级版的运维」——以为加个监控、装个 Prometheus、上一套 K8s 就是 SRE 了。这是行业被工具厂商和招聘 JD 联手洗脑的结果。真相是:SRE 是一种用软件工程方法管理可靠性的工程范式,跟"运维"是两套技能树。运维问"怎么把这台机器修好",SRE 问"怎么让这台机器即使挂了业务也不掉"——前者是修工(handyman),后者是工程师(engineer)。这种范式区别决定了:你不能靠"招个高级运维"做到 SRE,就像你不能靠"招个高级前端"做到产品经理——技能树压根没重叠。
一句话先记住:DevOps 是一种文化主张(Dev 和 Ops 一体化),SRE 是这种主张的一个具体落地范式(用软件工程的方法学做可靠性)。Google 在 2003 年起把 SRE 做成内部职能,2016 年出了 SRE Book,从此整个行业有了一份"可靠性工程"的可参考蓝图——但这份蓝图建立在 Google 的规模、文化、薪资水平之上,中型团队照抄会出事。这个系列就是教你哪部分抄、哪部分改、哪部分别学。
一、为什么应用工程师必须懂 SRE
1.1 三个让工程师破防的真实场景
场景 1:你上线了一个"小改动",凌晨被叫醒,发现"小改动"动了某个全局配置
周五下午 17:30,你把一个 PR 合进 main 分支:
把日志级别从 INFO 改成 DEBUG,方便下周排查一个偶发问题
CI 绿,review 也过了,没人多想
周六凌晨 02:30,告警炸了:
- 磁盘 99% 满
- 应用因日志写入失败开始 5xx
- DEBUG 日志把交易流水的明文打了出来(合规告警)这个场景的核心不是"代码写错了"——代码完全合规,review 也过了。核心是没有人对"上线之后"负责:没有 SLO(磁盘满到 80% 该不该告警没人定)、没有发布门禁(日志级别变更没标识为"高风险变更")、没有 On-call 体系(凌晨告警没人接)、没有可观测性(磁盘从 50% 飙到 99% 的过程没有人看)。所有"开发完了就完了"的团队,都在等这种事故发生。
场景 2:你给客户承诺 "99.9% 可用",签合同时没人算这意味着什么
销售给客户写了"系统可用性 SLA: 99.9%"
工程师签字:"应该没问题吧,我们 prod 看起来很稳"
三个月后客户来对账:
"你们这个季度有 3 次故障,每次 1 小时,合计 3 小时"
"按 SLA,这季度允许 3*30*24*60*0.001 = 130 分钟下线"
"你们超了 50 分钟,按合同要赔 ¥20 万"
工程师才想起来:
- SLA 是合同概念,SLO 是工程目标,SLI 是测量指标
- 这三个字母组合从来没在工程团队定义过
- 客户的"故障"定义和你的不一样(客户算"打不开",你算"5xx")
- 你连"过去 90 天累计可用时间"都没度量这个场景的根因是 SLI / SLO / SLA 三件套从未在工程团队建立。SRE 工程的一半工作是把"业务承诺"和"工程现实"通过这三个字母对齐——没有这套语言,商务上的承诺就是空头支票。
场景 3:你的告警群每天 200 条消息,没人看了,真出事时埋在噪声里
团队群 #alerts 看起来很专业:
- 每天 200+ 条告警刷屏
- "CPU > 80%" —— 一天来 30 次,大家都不看了
- "P99 > 500ms" —— 一天 50 次,新人以为是日志
- "节点 NotReady 1min 后恢复" —— 一天 10 次
某天凌晨,真的核心 DB 连接池打满:
- 告警在 02:11 准时发出
- 03:45 客服群炸了,工程师才意识到告警群里有一条
- 中间 90 分钟,P0 在 200 条噪声里被忽略这个场景的核心是"告警工程"没做:静态阈值告警必然爆炸、多燃烧率没用、告警没有分级、误报没有反馈机制。告警系统不是"装上 Prometheus 就完事",是一套需要持续运营的工程产品。
1.2 这三个场景的共同点
不是"代码不够好" —— 代码 review 都过了
不是"工程师不努力" —— 都是合理工作
不是"工具不够多" —— Prometheus / 告警群都有
是"代码合上去之后的事没人系统化做"
—— 没人定 SLO / 没人配告警分级 / 没人写 Runbook
—— 没人排 On-call / 没人做复盘 / 没人跟踪根因修复
—— 没人把"业务承诺"翻译成"工程指标"
—— 没人在告警风暴里识别真信号这就是 SRE 工程要解决的问题:让"代码上线"和"系统可靠"成为两件被独立、可量化、可改进的工程。你写代码再好,这一半工作不做,生产系统就是一颗等待引爆的雷。
二、DevOps 和 SRE 是什么,以及它们的关系
讲这两个词最大的混乱来自:业界对它们的定义从来没统一过。我下面给的是"对中型团队最有用的"版本,不是"最学术正确"的版本——后者你去问 ChatGPT 能问出 10 种答案。
2.1 DevOps:一种文化主张
DevOps 的本意:打破"开发(Dev)"和"运维(Ops)"之间的墙——让写代码的人对"代码上线后跑得好不好"负责,让做运维的人参与到"代码怎么设计才好维护"的早期讨论。
传统组织(2010 年前主流):
┌───────────┐ ─────扔过墙─────▶ ┌───────────┐
│ 开发 │ "代码我写完了" │ 运维 │
│ │ ◀──────抗议────── │ │
│ "为什么 │ │ "你这代码 │
│ 上线慢?"│ │ 没法部署"│
└───────────┘ └───────────┘
开发追求"快"(新功能),运维追求"稳"(不变更)
两者的 KPI 直接冲突DevOps 主张这堵墙不该存在——开发也要懂部署,运维也要参与设计,两边共享 KPI(发布速度 + 系统稳定)。
但 DevOps 只是文化主张,不是具体方法论——它没告诉你:
- 怎么具体度量"稳定"?
- 谁来负责"出事时谁先看告警"?
- 发布失败该怎么定义"失败"?
- 运维工作和开发工作的边界在哪?
这些问题留给了"具体落地方"——SRE 是其中一个落地方。
2.2 SRE:Google 给出的具体范式
SRE(Site Reliability Engineering)是 Google 在 2003 年起内部职能,2016 年出了 SRE Book,把这套范式公开化。SRE 的核心主张:
SRE = 用软件工程的方法做可靠性
把"运维"重新拆解:
- 哪些是机械重复的(Toil) → 自动化掉
- 哪些是可工程化的(SLO/告警) → 做成可量化的产品
- 哪些是需要判断的(事故响应) → 用流程和角色来规范
- 哪些是必须人在场的(决策) → 留给人,但用工具放大
然后,招"会写代码"的人来做这套事
——这就是 SRE,不是高级运维SRE Book 里给了 Google 内部的 4 条铁律(详见下一篇):
- 错误预算(Error Budget)——把"100% 可用"翻译成"允许 X 分钟不可用",这 X 分钟是创新的预算
- Toil 上限——SRE 不得超过 50% 时间在机械重复工作上,否则任务退回开发
- 黄金信号(Golden Signals)——一个服务该看的 4 个核心指标:Latency / Traffic / Errors / Saturation
- Blameless Postmortem——事故复盘只追流程不追个人
这 4 条加在一起,构成了"可靠性工程"的最小可行范式。后续的所有工具(Prometheus / Grafana / ArgoCD / PagerDuty)都是这套范式的某个环节的工具化。
2.3 DevOps 和 SRE 的关系
最简洁的描述(也是 Google 自己的说法):
┌──────────────────────────────────────────────────────────┐
│ │
│ DevOps:一种文化主张("Dev 和 Ops 应该一体化") │
│ │ │
│ ├── 实践 A:全栈工程师承担运维(小团队常见) │
│ │ │
│ ├── 实践 B:平台工程(Platform Engineering) │
│ │ 平台团队建工具,业务团队自助使用 │
│ │ │
│ └── 实践 C:SRE(Google 范式) │
│ 专职 SRE 团队,用工程方法做可靠性 │
│ │
└──────────────────────────────────────────────────────────┘
class SRE implements DevOpsSRE 是 DevOps 的一个具体子类,不是 DevOps 的替代品也不是升级版。一个团队可以做 DevOps 但没有 SRE 编制(用全栈做),也可以有 SRE 编制但 DevOps 文化烂(SRE 和开发互相甩锅)。
2.4 SRE ≠ 高级运维
国内招聘市场最大的坑:「SRE 工程师」JD 写成了「高级运维」JD——
典型的"假 SRE"JD:
- 负责 Linux 系统维护和故障排查
- 熟悉 K8s / Docker / Nginx 部署
- 7x24 On-call 应急响应
- 能写 Shell / Python 脚本
- 加分:有 Ansible / Terraform 经验
真正的 SRE JD 应该长这样:
- 设计和实施 SLI / SLO,推动可靠性目标量化
- 用软件工程方法降低 Toil(自动化、平台化)
- 主导事故响应流程,组织 Blameless Postmortem
- 设计告警策略(多燃烧率、SLO-based)
- 用代码而不是工单解决重复问题
- 加分:会 Go / Rust 写工具,会 PromQL,理解分布式系统理论两份 JD 的差别本质上是:运维是"修工",SRE 是"工程师"。运维处理"现在出的问题",SRE 设计"以后不会出这个问题"的系统。前者用工单,后者用 PR。
国内为什么会有这个错位:
- 传统运维团队转型 SRE,但只换了名字没换技能
- 招聘市场上"会写代码的运维"贵,公司想找便宜的
- 业务团队不想自己 On-call,把 SRE 当替罪羊
这三条加在一起,造成了"SRE 工程师"在国内 80% 的实际工作就是高级运维。这个系列不接受这种定义——本系列讲的 SRE 是 Google 那种 SRE,即使你的 title 是"高级运维",看完这套你做的就是 SRE 的事。
三、Google SRE 在中国小团队为什么跑不通
SRE Book 是好书,但中型团队照抄会出事——因为这本书建立在 Google 的若干前提之上,这些前提在中型团队都不成立。
3.1 Google 的前提条件
SRE Book 隐含的前提:
1. 你有专职 SRE 编制(不是兼职,不是甩锅给运维)
2. SRE 和开发是平等谈判方(不是 SRE 给开发打杂)
3. 业务方接受"错误预算用完就停发版"(不是销售压一切)
4. 工程师工资足够高,不能 burnout(Google 工程师起薪 30 万美元)
5. 系统规模够大,自动化 ROI 足够(每个工具花一个月开发,值)
6. 公司业务多样化,某条线挂一会儿不影响整体(不是 to B 单产品)这 6 条前提任何一条不满足,SRE Book 的某些建议就跑不通——这是这一节的核心论点。
3.2 中型团队的真实约束
┌─────────────────────────────────────────────────────────┐
│ 中型团队的真实约束(10 人 / 100 微服务 / 5000 QPS) │
├─────────────────────────────────────────────────────────┤
│ 约束 1:没有专职 SRE │
│ 最多 1-2 个"DevOps 工程师",还兼着 CI/CD │
│ → 50% 工程时间没法切割,人都不够分 │
│ │
│ 约束 2:开发兼 On-call │
│ SRE 和开发不是平等谈判方,SRE 是被领导的角色 │
│ → 错误预算的"政治"没有谈判台 │
│ │
│ 约束 3:销售导向,业务方刹不住车 │
│ "下周必须上"是常态,"停发版"是奢侈品 │
│ → 错误预算政策只能软执行 │
│ │
│ 约束 4:工程师产能稀缺 │
│ 自动化一个 Toil 要 1 周,Toil 本身一周才出 5 次 │
│ → 不是所有 Toil 都值得自动化 │
│ │
│ 约束 5:业务集中,挂一会儿就是事故 │
│ 一个核心 API 挂 10 分钟,客户就在打投诉电话 │
│ → 错误预算的"积累"机制不适用 │
│ │
│ 约束 6:工资压力下,On-call 加班费不一定能配齐 │
│ 深夜被叫醒一次 ¥100,但实际生理代价 ¥500 │
│ → On-call 制度的"激励"很难拉齐到 Google 水平 │
└─────────────────────────────────────────────────────────┘3.3 直接抄 SRE Book 的典型翻车
我见过的真实事故:
翻车 1:招了个"SRE",其实是高级运维
团队招了一个"SRE 工程师"
JD 写得很 SRE,实际工作:
- 每周接 50 个工单(扩容 / 续费 / 报错排查)
- 写了 3 个月没写超过 100 行代码
- 业务团队继续把他当"运维",有需求就提单
- 半年后辞职:"这不是我想做的工作"
教训:招 SRE 之前,业务团队的 mindset 没改,
SRE 进来只会被消耗成高级运维翻车 2:照搬"错误预算用完停发版"
团队读完 SRE Book,定 SLO 99.9%
某月错误预算超支,SRE 宣布"停发版一周"
业务方:"客户等着这个功能,你们停发版客户跑了"
拉了一个会,业务方赢了,继续发
SRE 此后不再敢提"停发版",错误预算政策名存实亡
教训:错误预算是一种"权力工具",
你没有让业务方接受的政治资本,这工具就是摆设翻车 3:盲目追求 50% 工程时间
团队 5 个开发 + 1 个 SRE
SRE Lead 看完 SRE Book,定"SRE 不超过 50% Toil"
实际情况:每周告警 80 条,Toil 全部由 SRE 一人承担
SRE 加班到 60% 都打不住,新工程一行没做
6 个月后 SRE 辞职,告警群没人值
教训:50% 时间是组织设计,不是个人努力
你只有 1 个 SRE,这条线本来就是单点失败3.4 那这本书还要不要读
要读,但要"批判性地读"——把 SRE Book 当成"参考架构",不是"实施指南":
读 SRE Book 的正确姿势:
1. 学概念:错误预算 / Toil / 黄金信号 / Postmortem 都是真理
2. 学方法学:SLO 怎么定、告警怎么配、复盘怎么开
3. 学组织设计:理解 Google 为什么这么做,而不是照抄
4. 学反面教材:Google 自己也讲了哪些"我们试过不行的"
不要直接照抄的:
1. 50% 时间(改成"每人每周 1 天非告警时间")
2. SRE 和开发的"权力平衡"(在中国得靠 CTO 兜底)
3. 错误预算的"停发版"硬约束(改成"软警告 + 升级")
4. 大规模自动化(只自动化 ROI 正的)这个系列就是 SRE Book 的"中型团队改造版"——把那些值钱的概念落地到 10 人团队 / 5000 QPS 的真实约束下,把那些跑不通的直接砍掉或重写。
四、本系列的定位和读者画像
4.1 读者画像
你应该长这样:
- 写 Java / Go / Node,代码量 3+ 年
- 知道 K8s / Docker 基础,做过几次部署
- 团队 5-30 人,业务流量 100-10000 QPS
- 见过几次生产事故,但还没系统化处理过
- 已经在用 Prometheus / Grafana,但不知道有没有用对
- 想把"代码合到 main"和"系统可靠"两件事都做好这个系列不服务:
✗ 完全没生产经验的学生
→ 先去 backendLearning 把基础打牢,33/34 篇足够入门
✗ 大厂的全职 SRE
→ 你们的规模问题(全球流量 / 万级服务)本系列不讲
✗ 纯运维 / DBA / 网络工程师
→ 这里的视角是"应用工程师视角",DBA 视角的可靠性请另找
✗ AI / Agent 系统的 SRE
→ AI 系统的可观测性 / 评估 / 安全有专门体系,在 aiLearning4.2 这个系列的写作主线
每一篇都回答同一个问题:
"这件事不做会怎样,做了能多扛多少事故"
不讲:
✗ "业界最佳实践"这种空话
✗ "Google 是怎么做的"原话搬运
✗ Datadog / New Relic 的市场白皮书
讲:
✓ "我们团队 10 人 / 100 微服务 / 5000 QPS,这件事该不该做"
✓ "做到什么程度,什么时候停"
✓ "做错了会出什么事,怎么救"4.3 一条贯穿全系列的暗线:三个数字
MTTR(Mean Time To Recovery,故障恢复时间)
→ 故障发生到恢复的平均时间
→ 第二层(可观测性)让你能更快定位故障
→ 第六层(On-call / 事故响应)让你能更快协调修复
MTBF(Mean Time Between Failures,故障间隔时间)
→ 两次故障之间的平均时间
→ 第三层(SLO / 告警)让你提前发现 MTBF 在变短
→ 第四层(渐进发布)让发布不直接拉短 MTBF
Change Failure Rate(发布失败率)
→ 多少比例的发布导致事故
→ 第四层(CI/CD / GitOps)让发布失败概率降低
→ 第五层(IaC)让"配置发布失败"也可控
复盘(Postmortem)
→ 把这三个数字闭环——出事后哪个变差了,怎么改进
→ 第六层(33 篇)讲清楚怎么开复盘不变扯皮每读完一层,回头看一眼:我把这三个数字往哪个方向推了?如果你不能说出一篇文章怎么影响这三个数字之一,那篇文章对你团队就没价值。
五、34 篇地图:六层结构
┌─────────────────────────────────────────────────────────────┐
│ 第六层:生产实战(28-34) │
│ On-call / Runbook / 容量 / 混沌 / 事故 / 复盘 / FinOps │
│ 面试和真实工作的硬通货,7 篇 │
├─────────────────────────────────────────────────────────────┤
│ 第五层:IaC 与配置管理(24-27) │
│ IaC 心智 / Terraform / Pulumi / 配置管理 │
│ 最容易半途而废的一层,4 篇 │
├─────────────────────────────────────────────────────────────┤
│ 第四层:CI/CD 与发布工程(18-23) │
│ CI/CD 心智 / 制品仓库 / GitOps / 渐进发布 / FF / DB 变更 │
│ 最贴日常,80% 团队不及格,6 篇 │
├─────────────────────────────────────────────────────────────┤
│ 第三层:SLO 与告警工程(13-17) │
│ SLI/SLO/SLA / RED&USE / 告警分级 / 仪表盘 / 错误预算政治 │
│ 最反直觉,讲完你才知道告警为什么一直爆炸,5 篇 │
├─────────────────────────────────────────────────────────────┤
│ 第二层:可观测性三件套(05-12) │
│ Metrics / Prometheus / PromQL / VM-Thanos / Logs / │
│ 日志采集 / OTel / Profiling │
│ 最值钱的一层,90% 事故先在这里发现,8 篇 │
├─────────────────────────────────────────────────────────────┤
│ 第一层:DevOps / SRE 心智(01-04) │
│ 总览(本篇) / Google SRE 精华 / 可观测性是什么 / 四真相 │
│ 地基,看完知道"SRE 不是高级运维",4 篇 │
└─────────────────────────────────────────────────────────────┘5.1 每层学完能解决什么
第一层(01-04):
学完能在白板上回答:
- "SRE 和 DevOps 是什么关系"
- "为什么 99.9% 一个月只有 43 分钟错误预算"
- "Monitoring 和 Observability 的区别"
- "失败是常态,你的代码假设过这点吗"
解决:团队 mindset 对齐,不再把 SRE 当运维
第二层(05-12):
学完能在 PR 评审里指出:
- "这个 metric 用 user_id 当 label 会让 Prometheus 挂掉"
- "这条 PromQL 用 increase 算 QPS 是错的"
- "OpenTelemetry 的 traceparent 没透传"
- "持续 profiling 没接上 GO_PPROF 端口"
解决:观测到故障的能力,从"事后捞日志"到"实时定位"
第三层(13-17):
学完能给团队定:
- 一份 SLO 文档(SLI 选择 + 错误预算政策)
- 一份多窗口多燃烧率的告警规则
- 一份"哪些 dashboard 必须保留,哪些是垃圾"的清单
解决:告警噪音 90% 削减,真信号不被淹
第四层(18-23):
学完能给团队做:
- 一份 GitOps 工作流(ArgoCD + 多环境 promote)
- 一份金丝雀发布门禁(自动 rollback 条件)
- 一份 Feature Flag 设计模板
解决:Change Failure Rate 从 30% 降到 5% 以下
第五层(24-27):
学完能给团队建:
- 一份 IaC 仓库结构(三层分层 + Module 设计)
- 一份 State 管理规范(远程后端 + 锁 + 加密)
- 一份 Drift 治理流程(定期 detect + 紧急修复)
解决:基础设施"漂移"从"半年差 40%"到"每周差 1%"
第六层(28-34):
学完能给团队建:
- 一份 On-call 制度(轮值 + Pager + 升级路径)
- 一份 Runbook 库(任何值班人能跑)
- 一份事故响应手册(IC/Ops/Comms 角色 + 战时频道模板)
- 一份成本可观测性的 dashboard
解决:MTTR 从"2 小时"到"30 分钟",团队从"靠英雄"到"靠流程"5.2 不同角色的最小阅读路径
┌────────────────────────────────────────────────────────────┐
│ 角色 │ 必读 │ 选读 │
├─────────────────┼────────────────┼──────────────────────────┤
│ 应用开发 │ 01-04, 13-17, │ 24-27(改基础设施) │
│ │ 18-23, 28-29 │ │
├─────────────────┼────────────────┼──────────────────────────┤
│ 高级开发 / Lead │ 01-17, 28-34 │ 18-27(具体落地) │
├─────────────────┼────────────────┼──────────────────────────┤
│ SRE / DevOps │ 全部 │ │
├─────────────────┼────────────────┼──────────────────────────┤
│ 架构师 / 技术 │ 01-04, 13-17, │ 05-12(具体可观测性栈) │
│ CTO │ 28-34 │ │
├─────────────────┼────────────────┼──────────────────────────┤
│ 平台工程 │ 01-04, 18-27, │ 13-17(SLO 工程) │
│ │ 34 │ │
└────────────────────────────────────────────────────────────┘应用开发的核心阅读 = 第一层 + 第三层 + 第四层 + 第六层前两篇——加起来 14 篇,涵盖"代码上线之后该懂的最少东西"。SRE / DevOps 必须全读,这是岗位职责。架构师不必深入到 PromQL 细节,但 SLO / Postmortem / 容量规划必须懂。
六、与其他系列的边界
我有 7 个技术系列,这一个是"上线之后"的视角。怎么跟其他 6 个区分,看下表:
| 内容 | 已有系列 | 本系列 |
|---|---|---|
| Docker / K8s 部署 | backendLearning/24-30 ✅ | 不重复,只在 IaC / GitOps 里讲 K8s 上的发布 |
| 微服务 / 服务网格 | backendLearning/32 / 60 ✅ | 不重复,只讲服务网格出的指标怎么读 |
| 监控基础 / 日志基础 | backendLearning/33-34 ✅ | 升级,讲选型 / PromQL / OTel / 长存储 |
| CICD 基础 | backendLearning/40 ✅ | 升级,讲 GitOps / 渐进发布 / 制品安全 |
| SRE 入门 | backendLearning/59 ✅ | 升级,讲 SLO 算术 / On-call / 复盘工程 |
| IaC 基础 | backendLearning/58 ✅ | 升级,讲 state / drift / module 设计 |
| 限流熔断 / 任务调度 | backendLearning/43-44 ✅ | 不重复,只在容量规划一篇引用 |
| 压测 | backendLearning/36 ✅ | 不重复,本系列把压测结果接到容量模型 |
| 反向代理 / WAF / 排障 | networkLearning ✅ | 不重复,只在链路追踪一篇引用 |
| 性能工具 / eBPF | osLearning/26-27 ✅ | 不重复,只讲"持续性能剖析"工程化 |
| 抗压 / 容灾 / 多机房 / 灰度 | systemDesign ✅ | 不重复,只讲容量规划落地与混沌演练 |
| 安全监控 / 应急响应(安全侧) | securityLearning/29 ✅ | 互补,本系列讲可用性视角的事故响应 |
| 供应链安全 | securityLearning/26 ✅ | 不重复,只在镜像签名一篇引用 |
| AI Infra / LLM Ops | aiLearning ✅ | 不重复,只在 FinOps 提 GPU 成本 |
简单粗暴的判断:
"我代码本身有问题" → backendLearning / networkLearning
"我系统挂了不知道为什么" → 本系列(可观测性 / 事故响应)
"我系统总是挂" → 本系列(SLO / 容量 / 混沌)
"我发布老出事" → 本系列(CI/CD / GitOps / 渐进发布)
"我基础设施改不动" → 本系列(IaC)
"我团队出事没人响应" → 本系列(On-call / 复盘)
"我被攻击了" → securityLearning
"我成本失控了" → 本系列 34 篇(FinOps)七、读完整套你应该有的本能
看到任何一个新服务上线,你下意识地问:
□ 它的 SLI 是什么(用户视角的"可用"长什么样)
□ 错误预算给多少(SLO 99.5% 还是 99.9%)
□ 黄金 4 信号的 dashboard 在哪
□ 关键告警有 Runbook 吗
□ 出事谁 On-call(轮值表在哪)
□ 灰度怎么发(蓝绿 / 金丝雀 / FF)
□ 自动回滚条件是什么
□ 上次类似故障的 Postmortem 在哪
□ 容量上限测过吗(单实例 / 整体)
□ 跨可用区还是单可用区
□ 依赖的下游 SLO 是多少
□ 这次发布会燃烧多少错误预算
这套问题就是这个系列要教会你的"反射"这套反射不是知识,是肌肉记忆——看到一个新服务,这 12 个问题在 30 秒内全部过一遍。问完一遍,要么这个服务是健壮的,要么你已经识别了 5 个风险。这就是"对生产系统负责的人"和"只写代码的人"的差别。
7.1 第二个硬指标:四份文档
看完整套之后,你应该能独立写出团队的:
1. 一份 SLO 文档
- SLI 选择(用户视角)
- 错误预算(月度 / 季度)
- 政策(超支怎么办)
- 燃烧率告警规则
2. 一份事故响应手册
- IC / Ops / Comms / Scribe 角色
- 升级路径(5/15/30 分钟)
- 战时频道模板
- 时间线记录模板
3. 一份发布门禁清单
- CI 必过的检查项
- 灰度策略(金丝雀比例 / 持续时间)
- 自动 rollback 条件
- 跨环境 promote 流程
4. 一份 On-call 手册
- 轮值表(Primary / Secondary)
- 告警分级(P0/P1/P2)
- 升级规则
- 补偿政策(调休 / 加班费)这四份文档不是模板填空——是你对自己团队的工程承诺。文档质量决定团队稳定性的上限。
八、立场声明
这个系列的写作立场:
✓ 服务于"对生产系统负责"的工程师视角
不是替开发背锅的运维,而是用软件工程方法把可靠性做成
可度量、可管理、可改进的产品属性
✓ 中型团队优先
10 人 / 100 微服务 / 5000 QPS,大厂全球流量调度不讲
Google / 字节级硬件运维不讲,小厂兼职 SRE 不讲
✓ K8s + Prometheus + Loki + OTel + ArgoCD + Terraform 默认栈
每篇标注"换成 VM / 其他工具"哪些结论还成立
✗ 不讲"DevOps 是文化"这种口号
文化要落到流程和工具上,不落地的文化是 PPT 文化
✗ 不抄 Google SRE Book
那两本书在那儿,这里只补它们对中型团队没讲透的工程细节
✗ 不写"装 Prometheus 三步走"
不是工具教程,是工程视角
✗ 不堆 yaml
只贴关键 20-50 行,讲清取舍理由
✗ 不一刀切建议
任何"必须 / 一定 / 永远不要"都给适用条件九、踩坑提醒(总览版,后面每篇细讲)
- 把 SRE 当高级运维——这是国内最大的误解,SRE 是工程师,不是修工
- 照搬 Google SRE Book——前提条件不一样,50% 时间 / 停发版 / 大规模自动化都会翻车
- 以为"上了 K8s 就 DevOps"——K8s 只是底座,可观测性 / SLO / 发布 / On-call 一样都不能少
- 不定 SLO 喊 99.99%——商务承诺空头支票,出事就是违约
- 告警按静态阈值配——必然爆炸,真信号被噪声淹
- 没有 On-call 制度——靠"老张随时在线",老张离职日就是断手日
- 盲目自动化——自动化没价值的 Toil,反而造新的 Toil
- 复盘变扯皮——blameless 不是空话,是工程纪律
- 不做容量规划——以为云能弹无限,某天遇到限额秒挂
- IaC 当文档用——Terraform 仓库挂在那儿,实际所有变更走控制台
- CI/CD 只追快——发布 10 分钟一次但失败率 30%,稳定性反而下降
- 复盘没 follow-up——同样的事故 6 周后重演
这 12 条每条对应这个系列的一篇文章——下面 33 篇就是这 12 条坑的逐个填补。
十、节奏建议
建议阅读节奏:
第 1 周:第一层 4 篇(本篇 + 02 + 03 + 04)
全是"心智文章",看完心里有底了再往下走
第 2-3 周:第二层 8 篇(05-12)
可观测性最值钱,建议跟着自己团队的 Prometheus 实操
第 4 周:第三层 5 篇(13-17)
SLO 工程,**这一周读完后立刻给自己服务定一份 SLO**
第 5-6 周:第四层 6 篇(18-23)
CI/CD,跟着自己团队的发布流程对照
第 7 周:第五层 4 篇(24-27)
IaC,**这一周用 Terraform 写一个 minimal 项目**
第 8 周以后:第六层 7 篇(28-34)
生产实战,每篇都对应"你这周可能要做的事"
总耗时:8-12 周,大致两到三个月不要一口气读完——这套东西消化需要时间,每读完一篇试着应用到自己团队 1-2 个动作,比连续读 34 篇但什么都不改"读得快"得多。
十一、小结:你为什么读这个系列
回到开篇:
"你不再只是把代码合到 main 上的工程师"
读完这个系列之后,你会:
- 知道"代码上线"只是工作的 30%,剩下 70% 是看不见的工程
- 知道 SLO / 告警 / On-call / 复盘 不是运维的事,是工程师的事
- 知道任何"100% 可用"承诺都是空头支票
- 知道失败是常态,系统设计要为失败准备
- 知道"自动化"不是答案,是工具
- 知道复盘不是甩锅会,是工程改进会
最终,你成为团队里"对生产系统负责"的那个人
不是头衔,是能力——
出事时大家自然会看向你,因为你能拍板、能定位、能修复SRE 这门手艺,在国内被严重低估——很多公司还在用招"高级运维"的薪资招"SRE 工程师"。但这种错配不会一直持续——任何业务到了规模就一定会撞上可靠性问题,撞上了才会发现这个能力的稀缺。你提前练这套手艺,就是给自己积复利。
下一篇:02-Google-SRE精华.md——这一篇讲 SRE 的"概念图",下一篇讲 Google 给的"具体范式"。不会翻译整本 SRE Book(那本书自己读才有用),只挑 4 个对中型团队最有用的概念:
- 错误预算(99.9% = 一个月 43 分钟,这 43 分钟该花在哪)
- Toil(机械可重复无长期价值,怎么识别怎么消灭)
- 50% 工程时间(Google 怎么落地,中型团队怎么改造)
- 黄金信号(Latency / Traffic / Errors / Saturation,为什么是 4 个不是 7 个)
结尾给一段"哪些直接抄,哪些必须改,哪些千万别学"——把 Google 范式翻译成中型团队能用的版本。读完这两篇,你对 SRE 这门手艺的整体框架就建立了。