AI 时代：从 DevOps 到平台工程
Source: Dev.to
我最近和很多 DevOps 工程师交谈，大家一直在问同一个问题：“平台工程只是又一次炒作，还是我真的需要在意它？”
我了解到：平台工程师的薪酬比 DevOps 角色高出最高约 27 %。但这并不是关键所在。
有哪些变化
六个月前，所有公司都在争先恐后地加入 AI 工具。给开发者配上 Copilot，加入一些 AI 代理，问题就解决了，对吧？
错。
Thoughtworks 的 Rickey Zachary 在 2025 年的路上奔波了 200 天，他不断看到同样的模式：AI 并不能修复破碎的系统——它只会让系统更快地崩溃。
- 你的文档分散在 Confluence、Notion 和某人的 Google Drive 中？AI 帮不上忙。
- 你的部署流程有七个手动审批步骤？AI 代理只会在第三步出错，而不是第七步。
- 多年来你一直在规避的技术债务？AI 会立刻绊倒它。
不舒服的事实是，AI 会放大你已有的状况。好的系统会变得更好，混乱的系统会变得更混乱。
为什么平台工程
这就是平台工程出现的地方，也说明它并非只是换了个名字的 DevOps。
DevOps 教会我们自动化和协作。平台工程提出了不同的问题：如果我们把基础设施打造为开发者真正想使用的产品，会怎样？
想想最近一次有开发者请求你提供某些资源时的情形。你可能会：
- 收到一条 Slack 消息或工单
- 手动完成（或运行你的脚本）
- 可能在某处记录了它
- 下周又为另一位开发者重复同样的操作
平台工程意味着构建一个自助服务门户，让开发者自行完成。你只需一次性构建产品，而不是反复执行相同的任务。思维方式的转变是巨大的——你不再仅仅是自动化任务，而是在设计体验。
AI 连接
时机很重要：人工智能需要平台来运行。
组织正意识到，在未解决底层基础设施的情况下向开发者提供 AI 工具是毫无意义的。研究表明，86 % 的组织现在认为平台工程对于从 AI 中获得真实价值至关重要。
有两个互补的机会：
- 构建 AI 驱动的平台 – 使用 AI 让平台更智能（例如，能够回答问题的文档、在问题发生前进行预测的系统，或真正有帮助的故障排除）。
- 为 AI 构建平台 – 创建机器学习团队所需的基础设施（模型部署流水线、GPU 管理、数据流水线）。解决这些问题会让你极具价值。
实际改变的内容
您需要的技能并非完全不同。您已经了解：
- 基础设施即代码
- CI/CD 流水线
- Kubernetes 与容器
- 云平台
- 监控与安全
另外还包括：
- 考虑用户（是的，开发者也是用户）
- 设计人们愿意使用的 API
- 编写不烂的文档
- 衡量开发者体验，而不仅仅是正常运行时间
- 构建人们主动选择使用的东西，而不是被迫使用
那最后一点至关重要。当平台工程构建了某些东西并强迫人们使用时会失败；当开发者因为它让他们的工作更轻松而主动选择你的平台时，它就会成功。
如何开始
你不需要任何许可就可以开始像平台工程师一样思考。
- 挑选你收到的最令人烦恼的重复请求。 为其构建自助服务解决方案。做到足够好，让人们不再向你提出该请求。
- 像向朋友解释一样记录它， 而不是写技术手册。
- 衡量影响。 你节省了多少时间？有多少工单消失了？
然后用更大的项目重复上述过程。
成功转型的案例
- 构建内部门户，将资源供应时间从 3 天缩短到 10 分钟。
- 为部署创建黄金路径，使事故率降低了 60 %。
- 在公司启动 AI 项目时，专注于 MLOps 基础设施。
这些团队没有等到平台工程职位的招聘信息。他们在 DevOps 角色中创建了平台工程，证明了价值，随后职业自然随之而来。
真正的问题
AI 并没有取代平台工程师；它让这个角色变得更加关键。
一个只是一味重复过去做法的 DevOps 工程师，可能在两年后发现自己的岗位难以立足。
区别不在于学习所有新技术，而在于从 “I automate things” 转变为 “I build products that enable people.” ——这就是转变所在，也正是它重要的原因。
我会从这里开始
如果这与你产生共鸣并且你想进一步探索：
- 本周： 与三位开发者交谈。询问他们对你的基础设施有哪些不满。认真倾听。
- 本月： 用自助方式解决其中一个问题。做好文档。衡量影响。
- 本季度： 找到平台工程社区。加入他们的Slack并看看其他人在构建什么。
职业路径并不神秘。构建能让开发者生活更好的东西。衡量影响。分享你的学习。循环往复。
平台工程并不被认证或特殊知识所垄断。这是一种可以从今天起就采纳的思维方式。问题是你是否会这么做。
感谢阅读。期待再见！