平台工程这个概念越来越火爆，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%则表示无所谓。

主要后果是增加了开发人员的认知负担。一方面是开发人员自助式服务带来的自由，而另一方面是通过抽象减轻认知负担，许多团队不得不重新考虑如何平衡这两方面。然而，这两方面都是必要的：自助式服务有助于提高开发速度和工作效率。但随着现代云原生世界的复杂性加剧，缺乏适当边界的自由会产生太大的压力，结果只能适得其反。

事实证明，对于许多组织来说，找到这种平衡是一项非常艰巨的任务。然而，一些优秀的组织在这个问题上找到了答案：平台工程。

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

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

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

平台工程通过产品方法实现了一定的开发人员自助式服务，并为各个组织和团队找到合适的抽象级别。平台团队可以结合用户研究、定期反馈和营销最佳实践，了解他们的开发人员，创建一个解决常见问题的平台，并获得关键利益相关者的内部支持。

这些平台提供了一条金光大道，可将开发人员完成日常任务遇到的阻力降到最低。这些金光大道还提供了推荐的工具和最佳安全实践，可以减轻开发人员的认知负担，同时还保留了一定的自由度。所有这些努力都确保了平台能够减少认知负担，并在开发人员对自助式服务和支持的需求之间取得适当的平衡。

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

下图说明了产品、平台和能力提供者之间的关系。

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

平台工程又是一个新概念，但其本质并没有质变。为什么现在很多人提平台工程而去贬低DevOps？这本身就是因为两个概念前后错位的问题。

平台工程追求的是自服务敏捷基础设施能力，这在多年前云原生中就已经提出来了，只是大家都习惯于单体系统的建设，对底层基础设施能力没有统一的要求，但云计算使底层基础设施成为一个统一的平台。云原生应用的研发和部署运维对统一的平台支撑能力有了明确的要求，平台工程才被重视。

于前期对DevOps的错误认知和不重视自服务敏捷基础设施的建设，把DevOps方法论等同于去构建基础的研发运维支撑平台，让研发人员去做运维但却没有基础设施的支撑和赋能，所以导致开发人员的心里落差，对DevOps没有好感。

维的敏捷才能真正带来研发的敏捷。没有自服务敏捷基础设施的支撑，让研发人员去做运维会使生产力达不到生产关系的要求。

DevOps是方法论，协调的是生产关系；平台工程追求的是工具赋能，是生产工具；生产工具体现着生产力。也因此说科技是第一生产力，科技进步会带来生产工具变革，从而使生产力变革，推动生产关系变革。正是因为平台工程的能力没有实现就去做DevOps，明显是生产关系超前了，生产力跟不上，就像曾经的空想社会主义一样，结果是失败的。

所以平台工程是基础，构建新的生产工具，代表新的生产力，理论上应该先推行，以促进生产力的变革，从而促进生产关系的变革。否则，只会使先进的生产关系是无法适应的，使先进的生产关系水土不服。这也是目前在推不动DevOps的时候开始关注平台工程。并不是DevOps不好，而是关系错位了。

DevOps的推行需要良好的自服务敏捷基础设施的建设，也就是平台工程所追求和需要实现的。平台工程的价值在于提供统一的标准的基础设施，赋能研发、运维等相关人员，从而减少这些人员的重复建设工作量，提升效率和敏捷性，做到运维的敏捷。所以说运维的敏捷是基础，以更好的支撑研发的敏捷。

总结

平台工程解决的问题：

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

平台工程的实现目标：

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

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

术语和概念

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

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

参考

• https://tag-app-delivery.cncf.io/whitepapers/platforms/
• https://tag-app-delivery.cncf.io/whitepapers/platform-eng-maturity-model/
• https://thenewstack.io/devops-is-dead-embrace-platform-engineering/
• https://thenewstack.io/platform-engineering/sre-vs-devops-vs-platform-engineering/

本文使用 文章同步助手 同步