为什么传统 DevOps 停止扩展

Source: Dev.to

传统 DevOps 运行良好……直到组织规模扩大。
在小规模时，一个中心化的 DevOps 团队负责部署、修复和处理所有故障，感觉很高效。
在大规模时，它却成为瓶颈。并不是因为 DevOps 本身不好——人类的扩展方式与系统不同。

扩展传统 DevOps 的挑战

1. 人员成为瓶颈

高级 DevOps 工程师成本高且难以招聘。

2. 工具链变成意大利面

每个工具解决一个问题，但维护脆弱的集成比帮助团队快速前进更耗时。

3. 手动步骤重新出现

手动工作会导致：

• 不一致
• 错误
• 深夜宕机

手动流程无法扩展，会放大风险。

4. 开发者承担过多运维负担

缺乏合适的抽象时，开发者会变成：

• 偶然的基础设施专家
• 兼职 SRE
• 更慢的功能构建者

认知负荷上升，交付速度下降。

5. 没有自助服务 = 没有速度

开发者要与以下内容搏斗：

• Kubernetes YAML
• Terraform 内部细节
• 云原语

他们花时间在基础设施上，而不是交付功能。

6. 孤岛悄然回归

• 运维因稳定性获奖
• 开发因速度获奖

不同的激励导致旧有摩擦。

7. 监控仍然是被动的

团队在故障发生后才响应。规模化时他们需要：

• 主动可观测性
• 快速根因分析
• 上下文信息，而不仅仅是警报

向平台工程的演进

这些挑战并没有让 DevOps 死亡，而是迫使它进化。平台工程应运而生，以：

• 编码最佳实践
• 提供黄金路径
• 抽象复杂性
• 安全地实现自助服务

内部开发者平台并不取代 DevOps 原则——它们让这些原则在企业规模下发挥作用。DevOps 并未失败；它成功得需要一种新形态。

从： 为所有人做 DevOps 的人
到： 为所有人提供 DevOps 能力的平台

这就是转变的本质，也是平台工程存在的原因。

大问题

如果 DevOps 不能永远部署所有东西……会有什么取代它？

在第 2 部分，我们将看看领先公司如何通过平台工程来解决这个问题。