解读平台工程，DevOps真的死了吗？不，它只是换了个马甲而已，弥补了DevOps空心理论，让DevOps继续发展壮大

最**台工程这个概念越来越火爆，Gartner 的预测，到 2026 年，80% 的软件工程组织将拥有*台工程团队，来提供内部服务、组件和应用程序交付工具，作为可重复使用的资源。本篇文章将带你走进*台工程，了解它的起源和解决的问题。

*台工程（Platform Engineering）的趋势

2022 年，“*台工程”这个概念很火热，也在 Gartner 的炒作周期曲线上。还有很多人鼓吹DevOps已死，*台工程才是未来。

国际权威知名调研机构 Gartner 在《2023年最重要的10个技术趋势》报告中将*台工程（Platform Engineering）列为高速发展的技术趋势之一，并预测到2026年80%的软件企业都将搭建*台团队以为内部的工程师提供可复用的服务、组件以及工具来帮助应用交付。

在 Gartner 的《2024年最重要的10个技术趋势》报告中，*台工程（Platform Engineering）依然上榜，无不体现了这一领域未来的强劲势头。国内大厂前几年也都一直在该领域探索，特别*两年关于“*台工程”的技术社区，也都展露头角。

从DevOps说起，实践过程本身如同盲人摸象，无法照搬

DevOps是什么？DevOps的目的是让开发作运维吗？是有很多人鼓吹“谁开发谁运维”，但是否深入理解了“谁开发谁运维”的核心内涵？是否想过“谁开发谁运维”要解决什么问题？

如果仅仅是遵循别人鼓吹的方法，而不去考虑为什么，那一定会是教条主义的，一定会和实际有冲突的。不同的环境照搬别人的方法，可能*滑运行吗？
所以，在采取某种方法的时候一定要根据自身实际来考虑、来剪裁、来调整以使其适应自身的环境和实际。DevOps本质是一种方法论。

DevOps源起于开发和运维的矛盾，但本质解决的是”生产协作关系“

SRE让运维人员参与开发并通过错误预算来协调研发和运维之间的关系，以确保软件系统的可靠性满足某项指标要求。这或许给DevOps方法论带来了启示，也因此可以说DevOps方法论的核心是协调和*衡研发和运维的利益诉求，而不是去实现一个DevOps*台或CICD工具链。所以DevOps尝试解决的是生产关系问题，而不是生产工具和生产力问题。
SRE可以看作是DevOps的一种实践，但SRE是偏运维的，关注的是软件的可靠性问题。为了让运维人员熟悉软件的处理逻辑和异常处理，以便更快的实现故障定位和故障恢复，SRE被要求其开发工作量不低于50%。这是一种很好的尝试，尝试让运维人员熟悉研发，对软件架构和设计、软件代码和逻辑等有深入的认识和理解，这样遇到软件异常和故障时就能快速判断根因所在，快速的解决问题。
运维人员可以做开发，开发者为什么就不能做运维？你不懂运维你如何能设计开发出满足可靠性要求的软件？不懂网络、不懂存储、不懂部署架构、不懂操作系统等基本内容，如何让你开发的软件匹配实际环境要求？不了解、不理解基础设施，就难以设计开发出高可靠性的软件。就像你不懂数据库，如何能写出高优化的SQL语句？
DevOps方法论的目的并不是非要让开发人员去做运维，特别是运维不熟悉的基础设施。但开发人员需要对基础设施有基本认识，需要具备相应的知识和认知，在软件研发时避免引入低级的错误和不必要的麻烦，以提升系统可靠性，减少运行故障。

抽象实体，控制边界自由，简化角色间协作，*台工程的诞生了！

关键词: 抽象，适度控制，简化生产协作关系
Luca Galante 是*台工程社区的主要贡献者和 Humanitec 的产品负责人，他针对这个主题在推特上展开了一次非正式的民意调查。投票的结果凸显了两大阵营的分歧：41.8%的开发人员表示愿意承担运维的工作，42.1%的开发人员表示反对，还有16.1%则表示无所谓。

对于DevOps的误解，导致组织往往会定义为”一个职位“或者“开发人员需要承担运维”或者“组建专职DevOps团队”。 如果团队无法就开发人员是否应该，或者可否，承担运维工作这个问题上达成共识，那么强迫每个人从事开发运维实践，就会导致灾难性的后果。
主要后果是增加了开发人员的认知负担。一方面是开发人员自助式服务带来的自由，而另一方面是通过抽象减轻认知负担，许多团队不得不重新考虑如何*衡这两方面。然而，这两方面都是必要的：自助式服务有助于提高开发速度和工作效率。但随着现代云原生世界的复杂性加剧，缺乏适当边界的自由会产生太大的压力，结果只能适得其反。
事实证明，对于许多组织来说，找到这种*衡是一项非常艰巨的任务。然而，一些优秀的组织在这个问题上找到了答案：*台工程。

*台工程的定义和能力构成

*台工程社区的发起人 Luca Galante 在 platformengineering.org 对*台工程的描述（定义）是这样的：

*台工程是一门设计和构建工具链与工作流的学科。这些工具链和工作流可以为云原生时代的软件工程组织提供自助服务功能。*台工程师提供集成化产品，通常称为“内部开发*台（Internal Developer Platform - IDP）”，可以涵盖应用程序整个生命周期的所有操作需求。

*台工程通过产品方法实现了一定的开发人员自助式服务，并为各个组织和团队找到合适的抽象级别。*台团队可以结合用户研究、定期反馈和营销最佳实践，了解他们的开发人员，创建一个解决常见问题的*台，并获得关键利益相关者的内部支持。
这些*台提供了一条金光大道，可将开发人员完成日常任务遇到的阻力降到最低。这些金光大道还提供了推荐的工具和最佳安全实践，可以减轻开发人员的认知负担，同时还保留了一定的自由度。所有这些努力都确保了*台能够减少认知负担，并在开发人员对自助式服务和支持的需求之间取得适当的*衡。

简而言之，*台是从底层“能力提供者”到*台用户（如应用程序开发人员）的桥梁；并在此过程中实施和执行安全、性能、成本治理和一致体验所需的实践。下图说明了产品、*台和能力提供者之间的关系。

*台工程弥补了组织生产力不足，以及DevOps空心理论化的问题

*台工程又是一个新概念，但其本质并没有质变。为什么现在很多人提*台工程而去贬低DevOps？这本身就是因为两个概念前后错位的问题。
*台工程追求的是自服务敏捷基础设施能力，这在多年前云原生中就已经提出来了，只是大家都习惯于单体系统的建设，对底层基础设施能力没有统一的要求，但云计算使底层基础设施成为一个统一的*台。云原生应用的研发和部署运维对统一的*台支撑能力有了明确的要求，*台工程才被重视。
由于前期对DevOps的错误认知和不重视自服务敏捷基础设施的建设，把DevOps方法论等同于去构建基础的研发运维支撑*台，让研发人员去做运维但却没有基础设施的支撑和赋能，所以导致开发人员的心里落差，对DevOps没有好感。
运维的敏捷才能真正带来研发的敏捷。没有自服务敏捷基础设施的支撑，让研发人员去做运维会使生产力达不到生产关系的要求。
DevOps是方法论，协调的是生产关系；*台工程追求的是工具赋能，是生产工具；生产工具体现着生产力。也因此说科技是第一生产力，科技进步会带来生产工具变革，从而使生产力变变革，推动生产关系变革。正是因为*台工程的能力没有实现就去做DevOps，明显是生产关系超前了，生产力跟不上，就像曾经的空想社会主义一样，结果是失败的。
所以*台工程是基础，构建新的生产工具，代表新的生产力，理论上应该先推行，以促进生产力的变革，从而促进生产关系的变革。否则，只会使先进的生产关系是无法适应的，使先进的生产关系水土不服。这也是目前在推不动DevOps的时候开始关注*台工程。并不是DevOps不好，而是关系错位了。
DevOps的推行需要良好的自服务敏捷基础设施的建设，也就是*台工程所追求和需要实现的。*台工程的价值在于提供统一的标准的基础设施，赋能研发、运维等相关人员，从而减少这些人员的重复建设工作量，提升效率和敏捷性，做到运维的敏捷。所以说运维的敏捷是基础，以更好的支撑研发的敏捷。
*台工程关注的能力是层次架构分层中的中下层基础设施能力，DevOps关注的是应用生命周期中的利益*衡和协调问题。DevOps落地需要*台工程的支撑，或者说，*台工程是DevOps方法论中的一部分。两者并不矛盾，不是非此即彼的问题，而是相辅相成的。

*台工程和“基础设施、规范、工具”密切相关

说了这么多，“*台工程”只是新瓶装旧酒，在笔者看来，只是优秀的组织将自己的实践进行了总结，增加了自己的思考之后，衍生了所谓的“*台工程”。
无论怎么样，*台工程依然和以下三个方面有密切关系，相辅相成。

规范

企业 IT 环境通常会有一系列的规范，例如设施命名、账号管理、IP 分配等等；另外操作系统、容器集群等具有极大灵活性的基础设施，也通常是需要有一定的规范化管理的，这里提到的规范至少包括：

安全规范：*台团队负责制定和实施安全规范，以确保*台和应用程序的安全性。这可能包括访问控制、身份验证、数据加密、漏洞管理等方面的规范。
部署和发布规范：*台团队可以制定规范，定义部署和发布流程，并确保它们得到正确执行。这些规范可以包括环境分离、版本控制、持续集成和持续交付等。
最佳实践：各种最佳实践可以通过规范的形式进行推行和实施。将最佳实践转化为规范的形式可以确保团队成员共享相同的理解，并提供具体的指导和标准，以便在组织中广泛应用，例如访问控制规范、文档发布规范、接口管理规范等等。
资源规范：例如资源申请和分配、生命周期管理、成本控制、审计和监控等的规范，有助于组织资源的有效利用、成本控制和性能优化。

基础设施

现代软件运行需要大量的基础设施，除了传统的网络、计算、存储之外，还包括大量的服务化的中间件等能力，OpenStack、Kubernetes 等资源编排工具也属于是传统管控难题。*台团队可以综合基础设施自有的管控运维能力，使用 Terraform、Kubernetes CRD、等资源抽象和自动化手段，为开发团队及其产品，规划、搭建、自动化和优化可靠、安全、高性能的基础设施，以支持业务的运行和发展。

工具

*台工程的主要产出就是一个被称为 IDP（内部开发*台）的工具，以此工具为开发团队提供支持，在实际工作中，工具部分的工作内容至少包括：

外部（开源/商业）软件的导入：除了采用开源软件的层层关卡之外，*台工程团队还应负责补齐第三方软件的运维能力、外部软件和内部*台的配套对接、开发并实施明确、有效并且成本合理的生命周期管理过程。
基础设施的供给、隔离：在基础设施自身服务接口和运维能力基础之上，为各个开发组织以及产品，规划并供给基础设施资源，尽可能让产品团队关注资源本身，并提供成本监测、优化等技术支持能力，用隔离手段防止租户和租户、租户和管理之间的不必要的资源访问。
Dev(Sec)Ops：包含供应链安全、代码质量、环境管理等的复杂 CI/CD 生命周期相关能力。
规范实施：*台或者工具，除了是业务的加速器，同时也是管理意志的执行者。纯文本的规范举步维艰，只有靠策略保障、工具辅助等方式，才能保障规范背后的管理意图的达成。

总结

*台工程解决的问题：

开发者不愿意和基础设施打交道，企业发展又需要自己的基础设施。“*台工程”统一这两个矛盾点，或者说“*台工程”是 DevOps 的下一站。

*台工程的实现目标：

为企业构建一个协助开发者完成软件交付过程中与核心业务逻辑开发无关的支撑类操作的*台。

本篇深入浅出解释了*台工程和DevOps的渊源，后续会详细来阐述*台工程相关的构成和技术实践。

术语和概念

DevOps、SRE和*台工程的概念在不同时期出现，并由不同的个人和组织开发。

DevOps作为一个概念是由Patrick Debois和Andrew Shafer在2009年的敏捷会议上提出的。他们试图通过促进协作文化和在整个软件开发生命周期中共享责任来弥合软件开发和操作之间的差距。
SRE，即站点可靠性工程，是谷歌在21世纪初首创的，用于解决管理大型复杂系统的操作挑战。谷歌开发了SRE实践和工具，如Borg集群管理系统和Monarch监控系统，以提高其服务的可靠性和效率。
*台工程是一个较新的概念，建立在SRE工程的基础上。*台工程的确切起源不太清楚，但它通常被理解为DevOps和SRE实践的扩展，重点是为支持整个业务视角的产品开发交付一个全面的*台。

值得注意的是，虽然这些概念出现在不同的时期。它们都与软件开发和操作中改进协作、自动化和效率的更广泛趋势有关。将SRE、DevOps和*台工程等结合来看，可以更好的认识和理解系统的建设思路和发展趋势。我们不能简单的把这些概念割裂开来去看待，否则就容易得出非此即彼的错误认知。

参考