互联网裁中台、合并 Dev+Ops，这事没那么简单

中台被砍、开发运维合并、一个人顶三个人用——听起来是行业共识，但真做起来，很多公司踩了坑。

先说结论：把开发和运维合并到一个人身上，短期省钱，长期可能更贵。

三种模型，不是只有合并这一条路

全球大厂在这个问题上走了三条完全不同的路。

模型一：亚马逊「你写的代码，你自己跑」

Amazon 内部有一句著名的话：You build it, you run it.

开发团队对自己的服务全权负责。写了代码，自己部署、自己监控、凌晨三点报警自己爬起来修。没有单独的运维团队来接盘。

听起来就是你现在看到的趋势——Dev 和 Ops 合并到一个人身上。

但亚马逊有一个前提条件：内部工具做到了极致。 每个团队都有标准化的 CI/CD 流水线、自动扩缩容、一键回滚。开发的精力不是花在「怎么运维 Kubernetes」，而是花在「怎么让自己的业务代码不出问题」上。

没有这套工具，让开发去搞运维就是让外科医生去修手术灯——能修，但浪费。

模型二：Google SRE「运维是工程问题，不是体力活」

Google 没有合并 Dev 和 Ops，而是创造了一个全新的角色——SRE（Site Reliability Engineer）。

SRE 是专门做运维的工程师，但他们不是传统运维。Google 的规则是：SRE 最多花 50% 时间处理日常运维，剩下 50% 必须用来写自动化工具，减少未来的运维负担。

如果某个服务故障太多、超过了「错误预算」，SRE 有权要求开发团队暂停新功能，先把稳定性修好。

这个模型的精髓不是「谁干运维」，而是把运维变成可量化的工程指标。不是「感觉系统挺稳定」，而是「99.95% 可用性，还剩 0.05% 的犯错额度」。

国内大部分公司裁中台、合并岗位的时候，只抄了「让人多干活」，没抄「拿一半时间写自动化」。

模型三：Spotify / Netflix 的平台工程「让开发不需要懂运维」

2026 年，Gartner 预测 80% 的大型组织会建立平台工程团队。

核心思路不是「让开发学运维」，而是建一个内部平台，让开发不用学运维。

Spotify 开源了 Backstage——一个内部开发者门户。开发要部署一个新服务，不用懂 Docker、K8s、CI/CD 配置，打开 Backstage，点几下，自动生成全套基础设施。平台团队在背后把运维复杂性吸收掉了。

Netflix 的做法更激进：他们有专门的平台团队做「铺路」——金色路径（Golden Path）。开发只需要专注业务代码，平台自动处理部署、监控、扩容、安全合规。开发甚至不需要知道底层是 K8s 还是 Serverless。

这才是真正的解法：不是让每个人什么都会，是让会的人把通行路径铺好，让其他人踩着走就行。

国内为什么走偏了？

阿里的中台故事是最好的反面教材。

2015 年阿里提出「大中台、小前台」，轰动整个中国互联网。字节、京东、美团全部跟进。但到了 2020 年，张勇自己说「要把中台变薄」。

为什么？因为中台变慢了。一个新业务要从零起步，找中台要一个能力，排队一两个月。淘宝特价版（淘特）团队干脆搬出西溪园区，自己另起炉灶。

2023 年阿里「1+6+N」改革，本质是把中台拆回各业务线。字节 2021 年 BU 化，把中台分拆到抖音、飞书等六大事业群。

但问题在于：拆中台不等于消灭中台的能力。 阿里拆完之后，留下的不是「每个人都得自己搞运维」，而是把通用的基础设施能力下沉到了更贴近业务的层面。字节拆完之后，抖音自己建了相机中台、直播中台——不是不做中台了，是让中台更小、更专属、更快。

国内很多公司只学了前半句「裁中台」，没学后半句「建平台」。结果是：中台没了，但平台也没建。运维经验散落在几个人脑子里，前人走了后人重踩一遍坑。

合并 Dev+Ops 的隐性代价

AWS 自己在一份分析报告里写得很直白：

「去中心化的 DevOps 模式有最高的不一致性、错误和安全漏洞风险，可能让开发者望而却步，尤其是他们不熟悉云基础设施的时候。」

三个实际问题：

1. 认知过载。 一个全栈工程师要懂前端、后端、数据库、网络、K8s、CI/CD、安全合规、成本优化。每层都在变，一个人的带宽根本追不上。
2. 运维经验的不可替代性。 你在凌晨三点被叫起来修过一次 ES 集群的脑裂，和你读过一篇博客说「脑裂是因为网络分区」，是两个完全不同的理解层级。运维经验不是能速成的——合并岗位意味着要么招有经验的人（贵），要么让没经验的人试错（贵）。
3. 紧急情况下的决策质量。 线上出了 P0 故障，一个人同时要判断是代码 bug 还是基础设施问题。两个领域的排查思路完全不同。一个专职 SRE 五分钟能定位的问题，全栈工程师可能要半小时——半小时对于 P0 故障意味着几十万用户受影响。

什么才是真正有效的做法？

不是「合并岗位」或「不合并」的二元选择，而是根据公司规模和组织成熟度选策略：

小公司（< 50 人）： Dev+Ops 合并是现实，没得选。但至少要有一个人的 30% 时间专用于建自动化——CI/CD、基础设施即代码、监控告警。不建自动化，人走了系统就崩。

中型公司（50-200 人）： 建一个 2-3 人的平台团队。不帮业务团队搞定运维细节，而是提供自服务平台：标准化的部署流水线、基础设施模板、监控面板。让业务开发 自助 而不是 自学。

大型公司（200+ 人）： 平台工程团队 + SRE 嵌入式模型。平台团队建内部开发者平台（类似 Backstage），SRE 嵌入核心业务团队，但 SRE 花至少 40% 时间写自动化而不是救火。不要让 SRE 沦为「高级运维外包」。

2026 年的变量：AI 正在改写运维规则

这一年最大的变化不是组织架构，是 AI 运维工具开始真正落地。

AI 驱动的可观测性系统能预测故障、自动检测配置漂移、自愈——2026 年的趋势是运维从「救火」转向「调教」。工程师不再半夜爬起来改配置，而是训练 AI 模型识别异常模式、优化告警阈值。

这意味着：运维经验的价值在迁移。你不需要知道「这个报错怎么修」，你需要知道「什么数据喂给 AI 能让它更快发现问题」。

这对「合并 Dev+Ops」策略的影响是双面的：一方面 AI 降低了运维门槛，开发更容易上手运维；另一方面 AI 运维本身成了新的专业领域，需要专门的人来调教——又回去了。

最后一句

裁中台、合并岗位不是战略，是财务动作。真正的战略是：你建了什么让剩下的人能更少干活、更多交付。

亚马逊、Google、Netflix 走的都是后一条路。国内大多数公司走的还是前一条。