DevOps、SRE 和平台工程：差别到底在哪儿。
三个词出现在同一份招聘启事、同一份方案、同一页幻灯片里。它们解决的是不同的问题，而把其中一个当成另一个的代价，是一整支团队非常专业地做错事。
一句话的答案。
DevOps 是一种工作方式。SRE 是一门中间放了个数字的工程学科。平台工程是一个内部产品。一个说团队怎么交付，一个说多少故障可以接受，第三个说团队不必再自己造什么。
混淆有个很具体的原因：这三件事用的是同一批工具。流水线、容器、基础设施即代码和监控，在三者里都出现。但工具一样不代表问题一样，而分开它们的问题不是「用什么工具」，是「这个人被要求改善的是什么」。
三个，一个一个来。
团队怎么交付
AWS 把 DevOps 定义为文化理念、实践和工具的组合，用来提升一个组织高速交付应用和服务的能力。核心是拆掉开发和运维之间那堵墙。
它点名的实践：持续集成、持续交付、微服务、基础设施即代码、监控与日志，以及团队之间的沟通。
被考核的是：从写完代码到它跑在生产环境要多久，以及这中间有多少是自动的。
多少故障可以接受
Google 那本书用一句话概括了它的由来：SRE 就是你让一名软件工程师去设计一个运维团队时发生的事。它不是换了名字的运维 —— 它是被写成软件的运维。
两条具体规则：Google 把 SRE 的整体运维工作量上限定在 50%，并且把 100% 视为几乎所有系统的错误可靠性目标。
被考核的是：系统守住了约定的可用性目标，而且错误预算是被有意识地花掉的。
谁都不必再造一遍的那些东西
CNCF 把云原生计算平台定义为一组集成起来的能力，按使用者的需求来定义和呈现。CNCF 自己采用的那句引述描述了结果：一套由自助 API、工具、服务、知识和支持构成的基座，像一个内部产品那样组织起来。
它点名的属性包括：把平台当产品、自助服务、文档与新人上手、更低的认知负担、可选且可组合的能力，以及默认安全。
被考核的是：内部采用率。一个被各团队绕开的平台，是成本，不是产品。
并排看。
| 问题 | DevOps | SRE | 平台工程 |
|---|---|---|---|
| 它是什么 | 文化、实践和工具 | 一门工程学科 | 一个内部产品 |
| 度量单位 | 交付频率和交付时长 | 可用性目标和错误预算 | 内部团队的采用率 |
| 什么时候进场 | 从第一次部署起 | 当宕机开始花钱的时候 | 当多个团队在重复同一件事的时候 |
| 做歪了的信号 | 变成管流水线那个团队的名字 | 变成没有书面目标的值班 | 各团队都在绕开这个平台 |
你公司现在需要的是哪一个。
三个问题，按顺序问。你第一个回答「不」的地方，就是你的问题所在。
改一行代码，当天能上生产环境吗？
不能的话，问题在 DevOps，招多少 SRE 都解决不了。流水线、自动化测试和基础设施即代码，排在任何关于可靠性的讨论前面。
你能用一个数字说出系统每月可以停多久吗？
不能的话，问题在 SRE —— 而且第一步是把这个目标写下来，不是先招人。没有目标就没有错误预算，没有错误预算，「发版和稳住谁优先」就变成一场谁嗓门大的讨论。
不同团队在用不同方式解决同一个基础设施问题吗？
是，而且团队不止两三支，那平台工程就说得通了。只有一支团队时，内部平台是一个只有一个用户的产品 —— 只有维护成本，没有规模收益。
我们见得最多的那个错。
公司在还没有 DevOps 的时候就上平台。结果永远一样：一个漂亮的内部门户，盖在一套手工交付流程上面。各团队照旧提工单，只是中间多了一个界面，而这个平台变成了又一件要维护的东西。
第二常见的：把原来就有的值班岗改叫 SRE。名片换了，活没换 —— 因为没有写下来的可用性目标，没有人从里面推出过任何错误预算，Google 那条「运维工作不超过一半时间」的限制也从来没有落地。这个人只是带着一个更好听的头衔在救火。
真正管用的顺序是最枯燥的那个：先把交付自动化，再把可用性目标写下来，然后开始度量，最后才为那些已经在重复的事铺好路。这里每一步都能自己回本 —— 这恰恰是不该跳过任何一步的理由。
关于 DevOps、SRE 和平台工程的问题。
DevOps 和 SRE 有什么区别？
DevOps 是文化、实践和工具的组合，目的是把软件交付得更快，拆掉开发和运维之间那堵墙。SRE 是一门工程学科，它在这件事上放了一个数字：定一个可用性目标，从中推出一份错误预算，再用这份预算决定什么时候发版、什么时候停下来。DevOps 说的是怎么工作；SRE 说的是多少故障可以接受，以及超了之后做什么。
错误预算是什么？
它是可用性目标的补数。Google 的 SRE 书把错误预算定义为「1 减去可用性目标」：99.99% 的目标，在统计周期里留下 0.01% 的不可用额度可以花。预算还有剩，团队就继续发版。预算花完了，优先级就转向可靠性，直到它重新攒回来。
为什么 100% 可用性是个错误的目标？
因为 Google 自己就是这么写的：对几乎所有系统来说，100% 都是错误的可靠性目标。每多一个 9，成本比上一个高得多，而且过了某个点用户根本感觉不到差别 —— 他的网络、他的手机和他的运营商，出问题的频率已经比你的系统高了。
平台工程是什么？
就是把内部基础设施当成产品来做。CNCF 把云原生计算平台定义为一组集成起来的能力，按使用者的需求来定义和呈现。落到实处就是：自助服务、文档、铺好的路，以及更低的认知负担。
我的公司三个都需要吗？
几乎不会同时需要。DevOps 排第一，因为它是工作方式，不需要新建团队。SRE 在你有东西跑在生产环境、而且它一挂就要花钱、并且得有人用数字来负责的时候进场。平台工程要等到有足够多的团队在重复做同一件基础设施的事，把那条路一次性铺好才划得来。
没有定义可用性目标，能招 SRE 吗？
人能招进来，但他会变成一个换了名字的值班岗。没有可用性目标就没有错误预算，没有错误预算就没有「可靠性和新功能谁优先」的判断依据，整门学科就退化成救火。目标要排在招聘前面。
资料来源
文中的定义，以及引用的那两个数字 —— 50% 的上限和错误预算 —— 都出自下面这三份一手资料，在 2026 年 8 月 9 日打开核对过。