阮一峰的网络日志：运维的未来是平台工程

转载自阮一峰的网络日志。我印象中阮一峰是个前端大咖，竟然也开始探讨运维话题了，看来这个话题最近确实热度不减。老规矩，兼听则明，偏信则暗，听百家之言，自我决策。原文地址：《运维的未来是平台工程》

运维的未来是不是平台工程？这篇文章给出的判断很直接：传统 Ops 作为单独工种会被压缩，但“让软件稳定运行”的专业能力不会消失，它会转向平台工程、DevOps 或云基础设施服务等形态。

核心观点可以先概括成四点：

• 传统运维的核心职责是管理服务器和运行环境，但云服务和 DevOps 正在改变职责边界。
• DevOps 让开发者承担更多运行责任，却无法完全替代专业运维能力。
• 平台工程负责评估、采购、整合云服务，并把基础设施能力产品化给开发团队使用。
• 运维工程师的转型方向主要是业务 DevOps、平台工程，或进入 IaaS 云厂商继续深耕底层基础设施。

互联网公司有一个重要工种，叫做"运维"。

“运维"的英文是 Operations，简写为 Ops，直译就是"操作”，指的是各种服务器操作。

简单说，运维工程师就是管理服务器、保障代码运行环境的人。

这是很重要的工作，公司理应非常重视。但是实际上这几年，运维岗位一直在缩减，Ops 工程师被要求转型 DevOps 工程师。据我知道，很多运维工程师其实很苦恼。

应该怎么看待这种变化？运维有没有前途？将来会怎么发展？

最近，我读到一篇老外的文章，标题就叫《运维的未来是平台工程》。

“The future of Ops is platform engineering.”

作者系统地回答了上面这些问题，认为运维最终将会消失，演变成一种新的工种—-“平台工程”（platform engineering）。

我觉得他的文章很有启发，让我对运维的看法清晰了很多，分享给大家。

一、运维的由来

最早的时候，并没有运维，程序员同时负责编写和运行软件。

但是，编写软件和运行软件，其实是两种不同的技能：前者需要熟悉代码，后者需要熟悉服务器。

互联网软件发展起来以后，这两种技能就逐渐分家了。

开发工程师负责编写代码，运维工程师负责运行代码（即保障服务器运行环境）。

从职责拆分的角度看，运维最初解决的是“谁来保证代码跑在稳定环境里”的问题。只要企业还需要服务器、网络、数据库、部署系统和故障处理，这类能力就不会消失；变化的是它由哪个团队、用什么工具和流程来承担。

二、运维的衰落

事实证明，开发和运维分家是一个巨大的错误。

写代码的人不了解服务器环境，管理服务器的人不了解代码在干什么，这样不利于做出优秀的产品，也不利于排查问题。

因此，有些公司就推动，开发与运维重新合在一起：编写软件的人也要负责运行软件。

这就是 DevOps 的由来，它等于 Dev（开发）+ Ops（运维）。

另一方面，互联网公司的核心资产和竞争力，更多的是代码，而不是运维。所以，公司也有意愿，把更多的力量投入在开发上，逐步压缩专门的运维团队，积极外包尽可能多的基础设施。

这两方面因素决定了，运维作为一个单独的工种，正在逐渐消失。

这里的“消失”不是说运行保障不再重要，而是说传统意义上只负责机器、机房和脚本的岗位会减少。企业更希望把基础设施能力沉淀为云服务、平台能力和自动化流程，让业务开发可以更快、更安全地交付代码。

三、DevOps 的问题

但是，DevOps 实际上没有办法取代运维。

越来越复杂的业务，注定了系统和基础设施也越来越复杂，同时还必须稳定可靠。

普通的开发工程师，根本不可能做到这一点。他既不了解所有基础设施，也达不到专业运维的系统管理水平。

这种情况下，公司就会选择外包，采购外部的云服务，把基础设施外包给专业的云服务商， 最大化压缩自身成本。

所以，DevOps 的真正问题不是理念不对，而是边界不能无限扩大。开发者可以对自己服务的运行负责，但企业仍然需要有人设计交付平台、治理权限、封装部署流程、统一监控告警、管理云资源和处理跨团队基础设施问题。

四、运维的职责

虽然总体上，运维是管理服务器，但是可以细分成两方面的职责：构建基础架构 + 管理运行环境。

“构建基础架构"指的是硬件的采购、安装、上架、联网这些工作。

“管理运行环境"指的是保障业务软件的运行。

DevOps 出现后，“构建基础架构"这一职责逐渐消失，变成了采购云服务，“管理运行环境"这一职责则是转给了 DevOps 工程师。

于是，新的问题出现了：谁负责采购和整合云服务？

这个问题正是平台工程出现的入口。云服务越多，团队越需要一个中间层来屏蔽复杂性：开发者不应该每次发布服务都重新学习云厂商 API、网络策略、权限模型和监控接入方式。

五、平台工程是什么

采购合适的云服务，并不是一件简单的事情。

云服务纷繁复杂，各种 API、SDK 和配套工具令人眼花缭乱，即使经验丰富的运维工程师也不容易说清楚。

因此，需要有专职人员来做出正确决策，选择一套满足需要的云服务，并且负责编写工具，整合所有采购来的云服务，供业务开发使用。

这种角色就叫做平台工程，他负责评估、采购、整合各种云服务，作为自身的基础设施，并在外部云服务基础上构建自己的平台，让开发工程师能够在其上自助服务，将自己的代码投入生产。

上面的定义有几个要点。

（1）基础设施是外包的，以求成本和开发周期最小化。

（2）平台工程师负责整合外包的基础设施，构建成一个平台。

（3）开发工程师在该平台上，自主搭建和管理运行环境，自己运行代码。

换句话说，平台工程的产出不是一台机器或一份脚本，而是一套内部开发者平台。这个平台要把部署、配置、日志、监控、告警、权限、成本和合规等能力封装成可复用的服务，让业务团队以自助方式完成日常交付。

六、平台工程与运维的区别

平台工程与运维，存在几个显著区别。

（1）平台工程需要开发软件，包括编写测试和代码审核，团队的运作方式很像开发团队，有产品经理、甚至设计师和前端工程师。

运维一般不开发应用软件，最多就是写一些自动化脚本。

以前，有的工程师写代码，有的工程师跑代码。今后，所有工程师都编写代码，并且运行自己的代码，不管你是开发工程师、DevOps 工程师或者平台工程师，不同之处只在于按层或功能划分的职责范围不同。

（2）平台工程是云原生的，所有工作都存在于云上。

运维不是云原生的，需要自己管理硬件，只能说是支持云的。

（3）平台工程采购云服务，运维采购的是硬件。

可以把二者的差异理解为：

这也是为什么平台工程团队的工作方式更像产品研发团队：它需要理解内部用户需求，维护长期路线图，并用工程化方式持续交付平台能力。

七、运维工程师的出路

随着传统的运维角色的消失，现有的运维工程师必然面临着转型，不外乎有三种出路可以选择。

（1）如果喜欢开发业务软件，可以选择成为 DevOps 工程师。

（2）如果喜欢开发平台软件，可以选择做平台工程，专注于基础设施的整合。

（3）如果更喜欢硬件和底层，可以选择加入"基础设施即服务”（IaaS）的云公司，深入研究基础设施。

FAQ：运维、DevOps 与平台工程怎么理解？

Q1：平台工程是不是运维的新名字？

不是。平台工程继承了一部分运行保障职责，但它的重点是把基础设施能力产品化，让开发团队自助使用，而不是继续依赖人工运维操作。

Q2：DevOps 会不会取代所有运维岗位？

不会。DevOps 能让开发者承担更多运行责任，但复杂基础设施、跨团队治理、统一平台和底层能力仍然需要专门团队建设。

Q3：传统运维工程师转平台工程，最需要补什么能力？

最关键的是软件工程能力和产品化思维，包括代码开发、测试、代码审核、API 设计、自动化、云服务整合，以及面向内部用户设计平台体验。

结论

运维的未来不是简单消失，而是职责重组。基础设施建设越来越多交给云服务商，业务运行责任越来越多回到开发团队，中间剩下的复杂整合和自助平台能力，就构成了平台工程的空间。对运维工程师来说，真正要判断的是自己更愿意靠近业务交付、平台研发，还是底层基础设施。