一句话区分
- DevOps：一种文化与实践——开发与运维不再分家，目标是"快、稳、可学习"
- SRE（Site Reliability Engineering）：Google 提出的一套具体方法，用软件工程方式做运维。Google 内部 2003 年起由 Ben Treynor 团队实践，2016 年 O'Reilly 出版的《Site Reliability Engineering》一书把方法论向业界系统化
- Platform Engineering：给开发团队建内部平台作为产品（Internal Developer Platform / IDP），让自助、可重复
三者不是替代关系——很多组织三者并存。
历史脉络（粗略）
2009 Patrick Debois 组织首届 DevOpsDays，DevOps 一词流行
↓
2016 《Site Reliability Engineering》出版，SRE 概念外溢
↓
2020 前后 Spotify 开源 Backstage、CNCF 启动 TAG App Delivery
"Internal Developer Platform" 概念被广泛讨论
↓
2022+ Gartner 把 Platform Engineering 列入趋势报告，进入主流视野
↓
今天 三者并存，叫法看公司文化
实操层面的差别
| 维度 | DevOps（文化） | SRE（实践） | Platform Eng（组织） |
|---|---|---|---|
| 起源 | 社区运动 | Google 内部 | Team Topologies / Spotify 等 |
| 核心方法 | CI/CD、自动化、协作 | SLO/Error Budget、Toil 控制 | 内部开发者平台（IDP） |
| 角色 | 每个工程师都是 DevOps | 专门的 SRE 团队 | 平台团队 + 业务团队 |
| 衡量 | 部署频率、MTTR | SLO 达成、Toil 占比 | 开发者满意度、平台 NPS |
| 适合公司规模 | 任何 | 中大型有可靠性诉求 | 几百人以上多团队 |
SRE 的 SLO / Error Budget 概念见 ops-corp/23-sli-slo / 24-error-budget。
头衔 ≠ 工作内容
- 一家叫"DevOps Engineer"的公司可能在做经典运维 + 一点 CI
- 一家叫"SRE"的公司可能 90% 时间在写 K8s yaml
- 一家叫"Platform Engineer"的可能在维护一个 Backstage 内部门户
看 JD 的实际工作描述比看 title 准。
组织演进的常见路径
小公司：1 个全栈工程师兼运维
↓
团队长大
↓
指定一个人主管发布与监控（兼职 SRE）
↓
独立 DevOps / SRE 团队（专人）
↓
多个业务团队 + 1 个 Platform 团队
每一步不是非走不可——很多 100 人公司不需要专门的 Platform 团队。
反模式：DevOps 团队 ≠ DevOps
"我们成立了一个 DevOps 团队" — 这往往是反模式：又把 dev 和 ops 切开了，只是换了个名。
DevOps 的初衷是消除墙，不是换一面墙。Platform Engineering 部分回应了这个矛盾：平台团队的客户是开发者，不是替开发者运维。
推荐阅读
- Google SRE Book — 三本（SRE / SRE Workbook / SRE Practical）都免费
- Team Topologies — Stream-aligned / Platform / Enabling / Complicated-subsystem 四种团队
- Platform Engineering Maturity Model (CNCF) — 平台工程成熟度模型
- State of DevOps Report (DORA) — 年度报告，业内公认参照
下一篇：怎么判断自己团队的运维处在哪一阶。