最近， Scott Carey 发表了一篇调查文章，喊出了一些开发者的心声：“扯淡的DevOps，我们开发者根本不想做运维！”除此之外，软件工程师兼DevOps评论员Sid Palas也在推特上写道，“DevOps已死，平台工程才是未来。”

平台工程火了，DevOps真的走向末路了？服务了国内各个行业的Dev和Ops，我也想来说说自己的一点看法。

一、什么是DevOps？

说DevOps已死，我们得首先明确DevOps是什么？连是什么都不清楚，何来死了的说法。

这里的Dev，是广泛意义的资源的使用方，在不同的场景下有不同的角色，比如金融机构大多是软开团队，集团企业是子公司的技术人员，政务云是委办局的用户，行业云是被服务的企业，校园云是学校师生等。这里的Ops，也就是基础设施的建设方和资源的运维方。

DevOps是一个概念，是为解决Dev和Ops中间的鸿沟，加快应用开发和上线过程而提出的概念。传统的软件开发，Dev和Ops是隔离的，简单如下图：

那具体什么是DevOps？DevOps是希望Dev和Ops能够合作的更紧密，从而加速应用系统的开发、测试和发布过程。DevOps概念图如下：

DevOps发展这么多年，其实已经构建了非常强大的生态体系，“DevOps已死”难道是说，下图中的DevOps工具链的公司都死了？显然不是，这些DevOps工具链对软件研发上线效率提升起到很大作用。

那具体问题是什么呢？Scott Carey和Sid Palas为何会发出如此呼声？对于这块，我们骞云还是有很深刻的理解的，因为我们的平台，就是帮广义上的Dev用户更好的使用Ops提供的基础设施云资源。

二、国内Dev和Ops协作现状

为帮助大家理解，下面先介绍一下我们看到的绝大部分国内中大型企事业单位的Dev和Ops的情况。

过去几年，各家企业、组织都在投入大量时间和精力去建设云、上云以及采用更多的云。国内的云，包括了私有化的公有云，也包括容器云、超融合，还有安全云等等。

随着云的发展，应用架构也在不断的云化，分布式架构、微服务、无服务、多云应用架构更加普及。数字化让应用系统数量持续变多，单个应用系统需要的云资源类型和数量越来越多，上线和变更更加频繁。

可以看到，数字化让系统数量更多、数据更大、迭代速度更快，必然会推动IT复杂度的提升，整体IT系统的熵会越来越大。在数量和复杂度都不可避免增加的情况下，如何让系统更加有序成为企业眼下关注的焦点。

接下来我们看看整体的云的建设情况。近几年各家企业事业单位投入大量的时间精力金钱建设的大量的云，包括虚拟化、私有云、容器云、公有云，还包括大量的行业云，比如金融云、政务云、国资云、超算云，绝大部分的云都是由Ops团队来进行规划建设和运维，很多云的日常运维甚至交给了第三方外包团队或者MSP厂商。

让我们从广义的Dev视角来看看云是如何被使用的，以及Dev和Ops是否紧密合作了呢？广义的Dev人员包括了企业内Dev、应用系统的架构师、技术负责人、政务云的委办局、集团云的分子公司的技术人员。在我们接触过的上千家企事业单位中，大部门企事业的云服务，大概率在以下三个阶段之中：

1. 云资源是通过电话或电子邮件获取；

2. 云资源是通过工单（OA）申请，电话讨论来获取；

3. 云资源是通过标准化服务目录，电话讨论来获取。

可以看到，电话、微信、邮件是大部分Dev和Ops沟通的主要途径，人肉执行运维是主要手段。资源申请，提工单；资源变更，尽量不变，必须变化，则继续工单加电话。

这个方式在物理机，甚至虚拟化时期，尚能勉强维持运转。想象大部分项目就是在启动阶段，批量申请服务器，开通一下网络资源；项目启动申请，结束关闭，停止使用所有资源。一次申请几十台上百台的服务器，配置相同，大家对服务器理解相同，工单系统还能满足需求。如果后台人员还懂点Shell、Powershell、Ansible，甚至Terraform，其实这个过程还是可以挺快的。

在我们服务的几百个客户里，就有一个证券客户，前端ITSM、Ops团队自己开发了Powershell脚本，人工执行实现虚拟机的批量创建。这样通过OA、邮件、科管系统来申请资源的过程，会出现资源浪费严重，需要提前几天申请，需要外包团队加班开通资源等问题。但当Dev有了一堆的服务器，很多情况和Ops就没什么交集了。Dev拿到一堆的IP地址和访问信息，剩下的事情都是自己能搞定的。变更配置，打快照备份？Dev都自己想办法搞定吧。

随着应用架构的云化，资源的使用从以单一云服务器，变成采用更多的云产品。随着大云（类似AWS这样有着数百种云服务的云平台）的深入采用，直接使用云产品而不是自己去构建各种基础服务，成为持续提升研发和运维人效，增强系统可扩展性、可运维性的关键。最普遍的，虚拟机里面安装MySQL变成了云平台的RDS MySQL；NAS变成了对象存储等。

我们有一客户，上百个自研的系统，用到云平台提供数据库、中间件、安全、大数据等数十种服务。大家可以脑补一下，每个不同的应用的部署架构都不一样，相同的应用，在开发、测试、UAT、生产、部署架构、底层资源方面也可能不一样。于是Dev和Ops之间如何协作变成了云化应用架构转型过程中的一个关键问题。

遇到这样的问题，大部分企业Ops的想法是，云不是提供了多租户能力，自服务能力吗？我给每个Dev都创建账号，让他们自己想怎么用就怎么用，Ops只要确保底层资源够多，够稳定就行。这其实也是大部分人的原始想法，甚至是不少专业运维人员的想法。

这个就是让每个Dev尽量变成云运维人员，了解企业内部的网络规划，了解企业的IT规范，更深入地了解众多云产品的运维底层逻辑，使用资源时都按照企业的规范来用，其实这些都需要Dev承担更多的运维责任。

考虑到绝大部分企业都不止一朵云（一种类型，部署几套，其实是几朵云），少的三四朵，多的七八朵，不仅责任重大，还非常低效，易出错，因此有人喊出了“Dev不想变成Ops”的口号。

于是，我们也有客户，觉得基础设施即代码挺好的，Dev不是会写代码吗，让每个人都自己写Terraform，Ops只要审批就够了。理想很丰满，现实很骨感，能写好Terraform的人，对云的Ops的理解，比在云平台界面上直接操作要求还高。要会用IaC，不但得知道Terraform，还得知道云，但现实是大部分Dev，两个都不懂，所以Dev也做不了Ops。

三、ITIL框架支持的DevOps

DevOps发展这么多年，其实一直都是要加强Dev和Ops的协作，提升协作效率，减少人肉响应。从来没有Dev变成Ops，或者Ops变Dev，因为两个领域需要完全不同的技能、知识。

了解ITIL的朋友们会发现，其实更好地服务资源的使用方（Dev）也是ITIL的目的。Dev是IT的使用部门，云是IT部门管理的资源，ITIL是让IT更好地服务使用部门的。因此当我们看到ITILv4在拥抱Agile，支持DevOps时，我们不禁会惊叹，这个发展了超过40年的概念，也在积极寻求如何让Ops更好地服务Dev。

如果用CMMI成熟度体系来度量Dev和Ops的合作，我们可以清晰地看到，完全依靠电话或邮件的交互方式，IT管理成熟度仅处于初始级别，工单系统的出现，IT管理进阶至Level 2级别，有了最基本的记录和管理。但Dev和Ops合作下的IT服务管理水平仍存在着巨大的上升空间。

四、平台工程是DevOps的替代还是新瓶装旧酒？

2023年，Garter年在其发布的十大战略技术趋势中提出了一个新的概念——平台工程。具体来说，平台工程是用来构建和运营支持软件交付，和生命周期管理的自助式开发者平台的机制和架构。平台工程的目标是优化开发者体验并加快产品团队为客户创造价值的速度。

如此描述，似乎说了很多，但又感觉什么也没说。但凡熟悉HP OpenView（知道这名字的都暴露年龄了）、VMware vRealize的行业人士都会觉得平台工程就是新瓶装旧酒。

为什么这样说呢？回顾前两年Gartner提出的概念——CMP，CMP的核心能力如下图所示，简单来说就是一个平台，通过服务目录，提供资源的自服务、监控告警的自服务等能力，并且这些能力都是通过部署和编排来实现的。听上去是不是和平台工程很相近？

那CMP是前几年才出现的全新的形态吗？也不是，CMP是围绕云如何使用的完整场景提出来的总结概念，虽然大部分人肤浅地认为多个云需要一个界面所以需要CMP。

可以比较一下，VMware的vRealize产品线，完整的目标也是构建DevOps-Ready的IT，vRealize产品线最初的产品远早于CMP概念的提出。（偷偷吐槽一下，vRealize在VMware是云管理产品线，但Gartner不认为vRealize是CMP，后来又提出了云管理工具的MQ，囊括了vRealize、Datadog、Terraform等更多的产品形态）

说到ITIL，就不能不提ServiceNow。ServiceNow成立20年，是世界第二大SaaS公司，其旗舰产品NowPlatform，不断的从传统IT基础设施过渡到云基础设施，从传统的ITSM发展为具备新型的DevOps能力，面向Dev构建更加强大的云基础设施的自服务能力。

从下图可以看到，ServiceNow也有对云资源的自服务和自动化的能力，这也是平台工程的核心。

如果将平台工程比作成一座冰山，那么其提供的自服务能力则是Dev感受到的能力的水上部分，为了支持自服务，平台工程需要具备类似ServiceNow平台的服务设计、治理、自动化、监控自服务、资源发现等一系列能力。

五、DevOps没死，平台工程是为了更好的DevOps而生

既然类似平台都出现那么多年了，为何Gartner却将平台工程列为2023年十大战略技术趋势之一呢？

个人认为有以下几方面原因：VMware的用户，采用vRealize （主要是vRealize Automation的能力）的还是少数，更何况在多云环境（国外的云，主要是公有云）下，大部分用户都还没有用。而大部分ServiceNow的用户，使用的还是其ITSM和CMDB的能力。国内的情况，更是大部分企业Ops团队还在建设传统的CMDB、ITSM、面向运维的监控告警等基础能力的阶段。

在应用不断上云的过程中，Dev和Ops的协作出现了更加明显的瓶颈，于是Gartner就老生常谈了这个问题，并指出我们需要平台工程来串联Dev和Ops。

无论是VMware vRealize、ServiceNow Now Platform, 还是骞云的运维服务平台，都是帮助我们的用户，打通资源的使用方和资源运维方，确保在安全、合理、合规的情况下，让Dev更加快速地获取所需要的资源，或者更进一步，专注应用层，减少管理资源层的负担。

现在，我们可以回答文章开头的疑问了，DevOps其实没死，平台工程也不是新的，两者并不存在矛盾关系，甚至在某种程度上我们可以说，平台工程是为实现更好的Dev和Ops的协作而生。

这次给大家介绍了DevOps的状况，以及为什么会出现平台工程。下一期我们会讨论平台工程是如何建设的，具体需要哪些能力。敬请期待！