撰稿丨千山

近年来，部分国外的开发者公开发声：DevOps就是扯淡，开发根本不想做运维。

更有甚者，直言“DevOps已死，平台工程才是未来”。

之后不久，Gartner发布2023年十大战略技术趋势，“平台工程”赫然在列。Gartner预测，到2026年，80%的软件工程组织将建立平台团队，其中75%将包含开发者自助服务门户。

平台工程，即platform engineering，作为流行概念，在开发领域迅速成为一颗冉冉升起的新星。但出于某种营销策略，总会有人将平台工程宣告为DevOps的终结。甚至一些从业者也在向大众描述这样一幅图景：DevOps走向末路，平台工程未来可期。

但事实上，DevOps和平台工程并非这种“你死我活”的关系，两者并不矛盾，甚至在某种程度上可以说，平台工程有可能为DevOps带来新生。

1、DevOps进化“三难题”

DevOps是一种文化，作为敏捷软件文化的一部分，它诞生的土壤根植于两点：以敏捷开发为代表的持续开发方式的出现以及持续开发带来的运维问题。

从团队角度看，DevOps往往涵盖包容、协作、自主和共同责任等要义，弥补了开发与运维间的矛盾；从流程角度看，DevOps旨在构建能满足持续改进目标的敏捷开发实践；从工具角度看，DevOps通过拥抱自动化来创建快速反馈循环从而提升质量和敏捷性。

早在2006年，亚马逊CTO沃纳·沃格斯（Werner Vogels）就首次提到了“你建立，你运行（You build it, you run it.）”的理念，确立了开发人员应该在整个生命周期中“拥有”他们的应用程序。但是等DevOps文化开始盛行，各大公司纷纷进行实践时，各色挑战又不断浮出水面。

第一，当DevOps实践需要支持许多开发和产品团队时，扩展问题就会出现，每个团队都在技术栈、工具、流程、云服务提供商及其特性和功能上做出自己的决定。这不仅会导致效率低下，还会让管理愈加繁重。

第二，随着云原生技术的推广与普及，无论从数量还是复杂性来看，工具环境都在快速增长。过去数年中，开发人员对软件交付过程中越来越多的部分负责。这种复杂性给开发人员带来了极大的认知负担，还增加了新功能开发的启动时间。

正如初创公司Humanitec的首席执行官Kaspar Von Grünberg在公开讲话中提到的，在一个微服务和多个分布式部署环境迅速扩散的时代，运营规模与既往不同，应用也要复杂得多，对开发人员要求过多是不现实的。他如是描述，端到端的所有权是“一个崇高的梦想，但对个人贡献者不公平。我们要求开发者一次性完成这么多工作。然后我们总是抱怨没有输出或者交付速度不够快。但事实却是我们没有让他们轻易兑现承诺。”

第三，文化障碍。Puppet发布的2021年度DevOps状况调查报告指出，83%的IT决策者表明他们的组织正在实施DevOps实践。但与此同时，绝大多数组织仍然停留在DevOps演变的中期阶段。其中，文化问题是DevOps取得成功的主要障碍，错位的激励措施和问责结构都会成为成熟度的制约因素。

可以看到，DevOps的兴起源于企业有意弥合运维与开发之间的裂隙，但在实施过程中有部分企业简单粗暴地将其理解为“让开发人员去负责运维的工作”，甚至让高级开发人员接管了运维角色，导致了开发渐渐不堪重负。

2、平台工程因何而生

这一现实也引出了DevOps停滞背后的核心矛盾：开发者不想跟基础设施打交道，但企业在发展过程中又需要专人管控自己的基础设施。在此背景下，平台工程应运而生。

Luca Galante将平台工程定义为“设计和构建工具链和工作流的学科，为云原生时代的软件工程组织提供自助服务功能。平台工程师提供的集成产品通常被称为‘内部开发人员平台（IDP）’，涵盖了应用程序整个生命周期的运营需求。”

当然，目前来说，平台工程并无公认的概念。而且由于每个企业的堆栈、文化、代码库和工具集的不同，也很难设定标准化的建设方式。

正如ThoughtWorks工程主管Evan Bottcher所说，“很难用语言表示。‘平台’其实是一个非常模糊的术语，我们用来形容对提高大规模交付速度和效率非常重要的方法。”他更愿意将这一“平台”形容为：“自助服务API、工具、服务、知识和支持的基础，被配置为备受关注的内部产品。”

简单来说，平台工程面向的是开发人员，作为一套自助式内部开发者平台的机制和架构，用于构建和运营支持软件交付和生命周期管理，主要目标是优化开发者体验，并加快产品团队为客户创造价值的速度。

通过建设这样一个企业内部开发平台，可以让开发者以“自助式”实现应用的端到端流程。Grünberg表示，成功的平台团队会创建一条“黄金路径”，将开发人员从不必要的认知负荷中解放出来，同时保留开发人员在需要时偏离路径的自由。而且对Ops工程师来说，采用平台工程还可以帮助他们摆脱反复做同样的任务。

理想状态下，一个功能完备的内部开发平台能够降低系统的复杂性，加快软件部署周期，提高开发人员的工作效率，同时降低运营负担。从这一角度看，平台工程与DevOps并不矛盾。

平台工程将很多运维操作抽象化，提供简单易用的操作界面，让运维这件事情不再需要高级的专业知识，从而让DevOps的理念有了喘息之机。

以Kubernetes为例。在一些DevOps设置中，开发人员在每次接触Kubernetes相关的交付设置时往往都会有所顾虑。如果想提高效率，就需要为Kubernetes设置实现真正的自助服务。

开发者自助服务意味着工程师可以自行调配和使用测试、保护和部署应用程序和服务所需的技术，而无需等待Ops提供资源或启动环境。平台工程的主要作用就在于此：通过内部开发人员平台进行抽象，提供了易于使用的构建块，降低了开发人员完成工作所需的Kubernetes专业知识水平，从而可以花更少的时间摆弄基础设施，更多的时间专注客户功能。

此外，在涉及重复性任务时，这种自助服务会减少大量的瓶颈和关键人员依赖，进而节省团队时间和资源，加快交付周期和创新周期。

曾在谷歌从事过内部开发平台建设的Chris Stephenson曾在博客中提到：“一个有效的内部开发者平台的关键点在于能够把复杂的问题划分好。每个人都有自己擅长处理的一部分复杂问题，而其他人完全可以忽略这些问题。”

因此，忽略那些让DevOps 消亡的杂音，专注于采用有助于企业在DevOps旅程中更快成熟的方法论，或许会成为更多人了解和进行平台工程实践的初衷。

3、开发和运维，可以快乐“玩耍”

DevOps的核心理念是缩短流程长度，实现敏捷化运营。但矛盾的点在于开发和运维本身是有各自专业门槛的角色，即使是在一些真正实践DevOps的大公司，开发能做的或许也就是部署和监控，更高阶的运维操，诸如容器替换等，还是要交给云平台或架构部来负责。

更重要的是，企图让一人承担两角的结果就是，不但会减少开发本职的投入，而且也会因技能点和时间所限而无法保障交付质量。而平台工程的出现提供了新解，它并不试图解决开发与运维的分工问题，也不会试图介入干预运维流程，而是用平台工程去抽象专业化能力，提供更易用的工具，来帮助完成运维这件事。

当然也要遵循一些基本的分工边界。因为开发在DevOps上的痛点不光是技能门槛，还有时间的分配问题。在运维领域，可以将和开发密切相关的工作（比如部署、发布），通过平台工程将能力开放给开发。但一些耗时较长的周期性工作，监控、巡检之类，还是交给专业的运维团队为宜。

总体而言，平台工程对于弥合开发和运维之间的沟壑是有助益的。内部开发平台和DevOps团队的工作会有一定的交集，DevOps工程师也会有一定机会过渡到平台工程师的角色，在整个组织中产生更广泛的影响，并将他们的专业知识应用于为开发人员提供更好的体验。开发人员不必在基础设施和其他Ops任务上陷入泥沼，运维可以更聚焦向上游转移到更关键的任务。内部开发人员平台使开发人员和运维人员能够专注于各自工作的核心职责和优势，真正实现“术业有专攻”“专人做专事”。

参考链接：

https://baijiahao.baidu.com/s?id=1754504889810005642

https://thenewstack.io/kubernetes-pains-platform-engineering-can-help/

https://baijiahao.baidu.com/s?id=1699154279421899478

来源： 51CTO技术栈