DevOps 真死了？平台工程真有用？

最近，平台工程（Platform Engineering）这个概念非常火爆。起源是 Scott Carey 的一篇调查文章《扯淡的 DevOps，我们开发者根本不想做运维！》（https://mp.weixin.qq.com/s/ZLIdcZOAAKHRl2KvRsxkGA）。然后平台工程就这么从 DevOps 的灰烬中诞生了（https://platformengineering.org/talks-library/devops-is-dead-long-live-platform-engineering）。包括 Gartner 上，平台工程也处于 blooming 阶段，看起来像一汪的新贵。

但是，平台工程（Platform Engineering）是什么？平台工程和 DevOps 关系是什么？平台工程真的能取代 DevOps 并给我们带来有益的提升么？

首先，我们先回看一下 DevOps。2000 年代后期，DevOps 与敏捷方法随着云计算的兴起而大行其道。作为将开发与运维合并起来的新理念，DevOps 希望打通这两支以往长期孤立的软件构建与部署力量，实现“1+1>2”的积极效应。与此同时，当时的软件工程师也恰好需要缩短用户反馈循环、提升生产环境下的更新推送频率，这也在无形中推进了开发与运维间的融合。

这玩意和测试左移一样，其实说白了就是把各种工作转嫁给开发，把开发塑造成一个全能的万事通。既然在 BOSS 们的眼中，开发能完成一切，那么其他的角色就可以消失了，一个开发干了三个人的活，还只用发一份工资，这个成本缩减大法简直完美。

但是，开发、测试、运维是三种完全不一样性质的工作。开发如果需要的是创造，那运维是重复和维稳，测试是细致和全面。让开发一人分饰三角的企图，不但会减少开发的本职工作投入，而且会让其他两项工作由于没有匹配的能力投入而无法保证质量。

所以，在 Google，有专门的 SRE 团队，并没有完全走向 DevOps。即使真正践行 DevOps 的公司，开发可能能做的也就是部署和监控。一些高阶的运维操作，比如容器替换、网络运维等，不是交给云平台就是让架构部来负责。

DevOps 的理念是缩减流程长度，敏捷化运营。从上面的分析我们看出 DevOps 是一个「理想很丰满，现实很骨感」的乌托邦。接下来我们再看一下平台工程的理念又是什么呢？平台功能不是 DevOps 这样的理论派，平台工程是一个实用主义。平台工程不试图解决开发和运维的职责分工问题，也不试图解决运维流程的问题，平台工程的理念是提供通俗易用的工具，帮助运维这件事情能成。

平台工程将运维操作抽象化为运维平台的能力，提供开发简单易用的运维操作界面。让运维这件事情不在需要高级的专业知识，从而让 DevOps 的理念能够苟延馋喘。

但是，如果不解决分工边界问题，平台工程也不可能成功。开发在 DevOps 上的痛点不光是专业技能问题，还有时间分配问题。大家都清楚，运维是需要时间投入的，监控、应急、部署、发布、巡检，每一项都是需要放时间进去的工作。即使有了平台工程，只是降低了工作准入的门槛，也没有降低工作需要占用的时间。

所以，和测试分工一样（可以参见我上一篇文章https://xie.infoq.cn/article/8ec79e9224fdad8ea5c5b38da，开发做白盒，测试做黑盒），在运维领域，可以将一些和开发密切相关的一次性工作，比如部署、发布，通过平台工程的方式将能力开放给开发，由开发在开发过程中顺带完成。但是一些耗时的周期性工作，比如监控、应急、巡检等，还是应该由专业的用运维团队承担。具体是否需要用平台功能降低工作门槛，用更便宜的资源来做，这个当然能有对老板更有好 ^_^。

总之，不管是开发、测试还是运维，需要的技能和人员要求是有差异的，还是需要遵循社会大分工的原则，专业的人做专业的事。用平台功能去抽象专业化能力，降低准入门槛，这个是有用的，但是是战术层面的，不应替代战略层面的人工原则。