平台工程年度盘点与 2025 展望
TLDR
这是一篇长文，主要回顾了平台工程过去一年的主要发展动态，涉及整体趋势、社区与项目发展、标准与规范共识、解决方案与实践案例，最后对 2025 年度做了展望，特别是 GenAI 在软件开发领域的应用持续加强，将推动工程平台和开发者体验进一步重构。
平台工程在过去两年多以来着实“热闹”，甚至可称其为最耀眼的新兴技术之一。如 2024 一开年，平台工程就被咨询公司连续两年评为”年度 10 大战略技术趋势“之一，这属于非常罕见的情况。代表性项目 Backstage 正在 CNCF 孵化中阶段，作为开源的内部开发者门户（IDP）解决方案，CNCF 不仅推出了对应的培训课程，还推出了 Backstage 项目的认证考试；同时面向平台工程师的认证计划也在进行中，这足以说明围绕平台工程及 Backstage 的生态正在快速发展和加强链接。
1、平台工程相关概念与整体趋势
什么是平台？
平台：服务或支持其他产品或服务的产品。
平台（在数字化业务中）存在于多个层面。它们的范围从支持平台业务模型的上层平台到提供其他产品或服务用来提供自己的业务功能的业务和/或技术功能集合的底层平台。
支持平台商业模式的平台具有相关的商业生态系统，他们通常通过 API 向这些生态系统的成员公开其功能。
内部平台通常也通过 API 公开其功能，但它们可能会根据产品使用要求提供其他机制，例如直接数据访问。
在 平台规范 (platformspec.io)中，平台被划分为 3 大类：
● 基础设施类平台
● 开发者类平台
● 服务/SaaS 控制面平台
截至目前，我们就“平台工程”这一概念达成的共识是：
平台工程是一门设计和构建工具链与工作流程的学科，旨在为软件工程组织提供一套精心设计的工具、能力和流程，实现开发人员的自助服务，以提高最终用户的生产力并减轻开发团队的负担。平台工程师提供的集成产品通常被称为“内部开发人员平台”，涵盖了应用程序整个生命周期的操作需求。（基于 PlatformEngineering 社区及基金会、分析师等的成果编辑而来）
关键倡议涉及：
● 开发者体验 DevEx
● 平台即产品 PaaP
● 自服务 self-service
● 标准化与自动化 Standardization & Automation
● 内部开发者平台/门户 IDP
整体趋势
关于技术的发展趋势，有很多解释角度，如创新的规律，传播学视角；也有理论、框架及相关工具等，如鸿沟理论，技术炒作周期、技术雷达等。
平台工程在过去的 2023 和 2024 连续两年被 Gartner 列入年度 10 大战略技术趋势。
Gartner 2024 中国技术成熟度曲线表明，平台工程从期望膨胀期进入了“泡沫破裂低谷期”。
基于这一整体趋势，下文我们将通过回顾社区、项目、实践案例等方面的内容，结合行业动向，进一步解析更加详细的发展趋势。
2、社区发展与标准规范共识
平台工程社区发展
Platform Engineering 社区(https://platformengineering.org/) 聚集了来自世界各地的 2.2W+成员，平台会议 PlatformCon 已连续进行了 3 年(2022~2024) https://platformcon.com/ ，近期社区也宣布了 2025 年将分别于伦敦和纽约组织线下会议；同时社区官方也开发并推出了完整的培训课程与认证机制。
在中国，平台工程社区同样聚集了不少同行，密切关注者超过 500+，PECommunity 社区（https://pecommunity.cn/）也开始在多个技术活动上出现并获得关注。
PECommunity 社区 年度文章列表
● [译] Platform as a Runtime（PaaR）——超越平台工程
行业报告
平台工程 2024 状态报告：薪资、AI 及更多
https://www.youtube.com/watch?v=tl1_dhej1wU&ab_channel=PlatformEngineering
同行共识
同行共识方面最大的看点是上文提到的平台规范 Platform Specification (https://platformspec.io/) 的发布，相比于此前的 CNOE , BACK Stack，KAOPS 等更加有系统性，对平台的界定更加清晰和具体，抽象层次更高，可落地性更强，目前处于早期比较活跃的发展状态。同时与 OAM 规范相比，聚焦于工作负载规范的 Score 项目也在年中进入 CNCF 沙箱，旨在简化云原生开发者的开发工作。
软件生态的标准通常有两种产生方式，一种是由被广泛采纳的项目所代表的事实标准，如 K8s 等；另一种是由联盟或社区共同约定然后通过发起新项目来支持，比如 W3C 的很多标准。对于平台工程目前所处的发展阶段而言，暂时尚且没有以热门项目为代表的事实标准形成，因此出现了很多第二种类型的标准，甚至通过多个项目“结盟”来推进标准的共识。 以下是社区关注到的一些相关标准类项目，部分处于比较早期的框架阶段。
Platform Specification
BACK Stack 【似乎已停滞不前？】
OAM
CNOE
CNCF 白皮书 & TAG-appdelivery 的 WG-platform 工作成果
平台白皮书 https://tag-app-delivery.cncf.io/zh/wgs/platforms/whitepaper/
成熟度模型 https://tag-app-delivery.cncf.io/zh/wgs/platforms/maturity-model/v1/
2024 年的平台工程、行业趋势和新兴焦点（ 平台工程 ++：内部开发者平台整体提案）
https://tag-app-delivery.cncf.io/blog/proposal-platform-engineering-/
PaaP 平台即产品 白皮书 - 尚在进行中
当然，在知识分享方面少不了相关图书的初版：
3、平台工程相关项目、解决方案及实践案例
具体项目和标准是技术实践或理念从务虚走向务实的关键环节。在过去一年，平台工程相关的争论有所减少，多了一些更加务实的项目和标准探索。其中一些是从共识和规范自上而下开始，如上文所述，而更多的是从具体项目的发展而来，在未来可能成为事实标准。
Backstage https://backstage.io/
2020 年进入 CNCF 沙箱，2022 年中转入 CNCF 孵化阶段。
开源的构建 IDP 内部开发者门户的开源框架，作为该赛道第一个进入 CNCF 的开源项目，发展迅猛，光环加持。但门户只是在卓越平台之上的锦上添花，如果平台无法满足开发者需求，门户的价值就会非常有限。
CBA 认证与培训课程 - LF/CNCF
Backstage 入门 ：开发者门户变得简单 (LFS142)
https://training.linuxfoundation.cn/courses/122
目前已有多个基于 Backstage 的商业解决方案，如 RedHat DeveloperHub , ...
Score https://score.dev/
2024 年中进入 CNCF 沙箱
以开发者为中心的平台无关的工作负载规范，它能确保本地环境和远程环境的配置保持一致。
KubeVela https://kubevela.io/
2023 年上进入 CNCF 孵化阶段
KubeVela 是一个现代化的软件交付平台，它使在当今的混合多云环境中部署和运行应用程序变得更简单、更快捷、更可靠。KubeVela 与基础设施无关，可编程，但最重要的是，它以应用程序为中心。它允许您构建功能强大的软件，并将其交付到任何地方！KubeVela 是 OAM 规范的开源实现。
KusionStack https://www.kusionstack.io/
2024 年底进入 CNCF 沙箱
利用 KusionStack 改造你的内部开发者平台
Kusion 是一个意图驱动的平台编排器，是内部开发者平台（IDP）的核心。使用 Kusion，你可以实现以应用程序为中心的开发，开发人员只需编写一个应用程序规范--AppConfiguration。AppConfiguration 定义了工作负载和所有资源依赖性，无需提供特定环境值，Kusion 就能确保提供应用程序运行所需的一切。
平台工程无法作为一个独立的实践存在，它与 DevOps, SRE, 软件生产力，DevEx 开发者体验等密切相关，甚至在今年也与 InnerSource 内源等实践发生了更多的链接，这也符合技术生态发展的规律。
在所有平台工程实践中，最直观也是关注度最高的非“内部开发者门户 IDP”莫属，以下为我们针对 IDP 方向的一些分析：
目前 IDP 各竞品主要方向有：
1. IDP 工厂：从平台工程的描述中得出这样的结论：IDP 是无法从外部购买，只能通过内部平台团队根据内部开发者的需求构建而出。但从零开始基于 backstage 构建又面临着巨大的成本，所以企业可以通过购买一个半成品，半成品必须是高可自定义的且自定义成本不能高。
2. 企业级产品：符合企业级产品必要的条件(比如 用户，权限，审计日志)
3. 开箱即用的 IDP：围绕自身产品生态来做开箱即用的体验，例如 RHDH 插件 3scale – 把红帽 3scale 的内容同步成 backstage catalog
i. Application Topology – OCP 上的应用 Topology
ii. tekton – 可查看 ocp 平台上的 tekton 流水线信息
harness 通过创建 connector 配置 backstage 的 integration，默认是 harness code repo
i. CICD 插件 – 展示 harness cicd 流水线信息
ii. Chaos Engineering – 展示 harness Chaos Engineering 信息
iii. Feature Flags – 展示 harness Feature Flags 信息
Spotify for Backstage https://backstage.spotify.com/
Spotify Portal for Backstage：开始使用 Backstage 的最佳方式。您将很快建立并运行一个新的开发人员门户网站。
Spotify Plugins for Backstage：提升您的 Backstage。将我们的插件添加到您现有的 Backstage 实例中，在您的组织中推动最佳实践和协作。
RedHat 解决方案
https://developers.redhat.com/rhdh/overview
Red Hat Developer Hub (RHDH)
一个开放的企业级开发者平台，用于构建开发者门户，包含一个受支持且有明确观点的框架。RHDH 有助于减少工程团队的摩擦和挫败感，同时提高他们的生产力并增加其组织的竞争优势。
Humanitec https://humanitec.com/
构建驱动变革的平台
从后端到前端，我们的产品可帮助您构建可扩展的内部开发人员平台。
● Platform Orchestrator : 基于图的平台后端系统
● 门户 ：单一透明面板让使用、指标、评分和操作一目了然；直观的自服务操作界面。
getPort https://www.getport.io/
Port 允许开发者和 DevOps 建立服务/软件目录，并支持开发者自服务操作。
Harness https://www.harness.io/
AI 原生的端到端软件交付平台，帮助工程团队实现最高水平的卓越工程。
Microsoft
平台工程指南 https://learn.microsoft.com/en-us/platform-engineering/
（https://www.itprotoday.com/devops/microsoft-build-2024-highlights-advantages-of-platform-engineering）
Atlassian
Compass https://www.atlassian.com/software/compass
Empower engineers. Inspire productivity.
利用 Atlassian 开箱即用的内部开发者平台，为开发人员所需的一切进行编排，以保持流程顺畅并改善软件健康状况。
本土解决方案与案例
灵雀云 Alauda developer portal
行云创新 https://www.cloudtogo.cn/PlatformEngineering
4、度量框架与关键指标
平台工程在过去一年也将开发者体验（DevEx）推向了新的高度。对于软件开发生产力和开发者体验的度量，也是业内的焦点，目前已经从 DORA、SPACE、DevEx 等发展到 DX Core 4 阶段。这些具体的度量指标，牵引着研发团队对于效率和体验的几乎所有投入，最终能否获得预期回报，特别是能否与组织内的甲方“业务团队”对齐该指标，并与业务或商业指标关联，是平台工程成败的重要决定因素。从行业发展和技术演进的角度，加强对于人相关的指标的关注一定是一个非常大的进步，尤其是在国内过于”内卷“的情形下，更有远见的技术领导者和未来走得更远的技术团队，从当下到未来一定会加大对开发者体验的投入，这才是真正地聚焦增效。
DORA
核心模型
四大指标
2024 年度报告数据参考
https://octopus.com/blog/2024-devops-performance-clusters
SPACE
SPACE 框架是一个旨在衡量和了解软件工程团队生产率的模型。它代表满意度与幸福感、绩效、活动、沟通与协作以及效率与流程。通过整合生产力的各个维度，SPACE 框架提供了一个包含定量和定性数据的整体视角。
https://queue.acm.org/detail.cfm?id=3454124
MONK
https://octopus.com/devops/metrics/monk-metrics/
适合内部平台的四大指标
● Market share
● Onboarding time
● Net Promoter Score (NPS)
● Key customer metrics
定期的客户互动表明你正在开展健康的平台工程工作。 MONK 指标有助于：
● 确定内部开发人员平台的产品路线图
● 与客户展开重要对话
● 向付费构建平台的人员展示平台的价值
DevEx Metrics
来自 SPACE 作者的一种全新的度量框架。
https://www.infoq.cn/article/sF2is0yZ7B5yWcG8T8U9
DX CORE 4
DX Core 4 是一个用于衡量开发者生产力的统一框架，封装了 DORA、SPACE 和 DevEx。
https://getdx.com/research/measuring-developer-productivity-with-the-dx-core-4/
指标框架如此之多，并且持续演化，确实也带来了困扰。所以也有人提出了更加简洁的适合平台工程的度量指标方案，一个健康的指标模型覆盖三大维度：
● 拔高：是否允许团队以外的人看到某个指标。
● 时效性：指标是长期的还是临时的。
● 可见性：指标是可见的还是后台跟踪的。
https://octopus.com/blog/effective-devops-metrics
由以上度量框架可以总结出，至少可以分成两种类型的度量：
● 以生产力为主要目标的度量
● 以开发者体验为主要目标的度量
当然，过度度量也是一个问题。一方面可能导致所有的注意力都在关键指标上，从而忽略了那些基础的日常的工作，最终导致长远利益或健康发展基石受损；另一方面，没有指标是完美的，如果你过于追求指标 A，必然导致对指标 B 的投入减少，最终变成一场打地鼠游戏，尤其再叠加上时间的推移，人员的更替，组织的在长期战略上就会出现频繁地摇摆，最终带来长期运作效率的显著下降。
5、未来展望与本土倡议
在基于当前现状判断未来趋势之前，我们想首先分享下 Backstage 培训课程中关于开发者自治权的内容：
云原生组织不仅能从服务的可扩展性和灵活性中获益，还能从敏捷团队动态中受益。由于服务是独立部署的，团队可以完全掌控自己编写的软件组件。这带来了巨大的优势，因为正如十多年来的研究指出的那样（https://frontside.com/blog/2022-01-26-what-is-dx/），能够选择自己的工具并享受自己配置的开发人员通常表现得更好。然而，开发人员的自主权可能会导致组织的分散，从而造成工作冗余、项目孤立和不透明。
开发者自主权之所以重要，有两个原因：更快的交付速度和留住人才。正如谷歌的 DORA DevOps 报告所强调的，“没有人比实践者更清楚他们需要什么来提高效率”。这份全行业报告指出，获得选择自由和执行决策能力的团队比其他团队拥有更高的吞吐量。
此外，微软的 “开发人员生产力 SPACE 框架 ”还提到，除了选择合适的工具外，软件所有权还包括心理因素。当开发人员对自己的工作拥有控制权时，他们就会感到有力量。团队也要对其服务的质量、成本和其他方面负责，并努力优化它们。
然而，自治并不意味着无政府状态。组织必须努力提供一个有用的基线，开发人员可以在此基础上构建自己的解决方案。在限制与自由之间找到平衡点并非易事。将政策、自助服务基础设施和引导工程师进入最佳路径的管道相结合，可以带来更好的开发体验，保障自主权。
不过即使有了良好的实践，碎片化仍然是云原生组织的常见问题。组织规模越大，管理的复杂性就越高。由于每个团队都在提供自己的服务，而这些服务往往相互关联并依赖于第三方云服务，因此甚至很难知道哪些服务可用以及如何使用它们。
各自为政给普通员工、新员工和领导者都带来了挑战。普通员工在孤岛中工作，不得不四处打探，盲目地访问组织的资源。新员工被扔进了一个充满不确定性和低透明度的世界，使他们的入职培训变得更加困难。领导者看不到团队正在开发的软件，也不知道它是否符合成熟度和安全标准。
Platform Engineering 社区的 Luca 在最近的每周社区动态中也表达自己对于平台工程 2025 的三大预测：
● Backstage 的“后坐力”越来越多的企业意识到，Backstage 并不是您的平台（也远非他们所认为的那样容易赢得平台）。它可以是一个很好的基于 UI 的界面，用于访问平台或实现可视化。但是，您需要某种平台 API 来协调您的基础架构及其下的工作流，而且您不能低估设置和正确使用它所需的工作。
● 开发者可能逐步失去对基础设施的访问权业界正逐渐意识到，不受限制地访问云控制台或通过门户网站一键式创建基础设施资源的能力已导致不一致和治理难题。这往往会导致 “公地悲剧 ”的发生，即个人行为虽然用心良苦，但却对组织效率产生了负面影响。顶级组织已经在这一领域做出了重大改变，其他大多数组织也将紧随其后。
● 成功的平台工程将遵循 Pareto/帕累托原则： 我们已经看到，获得广泛采用的优秀平台都倾向于遵循 80/20 帕累托原则。它们确保覆盖 80% 的用例和开发人员的需求。重要的是，它们要么对各个利益相关者群体（开发人员、I&O 团队、安全团队、架构师、执行人员等）产生净积极影响，要么是净中性影响。这对于获得所有群体对平台工程计划的广泛支持至关重要。虽然平台可能不会大幅提升每个利益相关者的体验，但也不应减损他们的体验。成功的平台团队都会遵循这一原则。
基于当前现状和趋势，结合云原生生态的持续发展以及 AI 尤其是 GenAI 的采纳扩大，2025 年的平台工程将更加”务实“，在相关开源项目持续发展和扩大应用的同时，也将链接更多实践比如内部开源与内部开发者门户、工程效能与软件生产力工程、开发者体验与内部开发者平台/社区。
”独木难成林“，在今天任何新的技术或实践，从 0 开始独立发展壮大将越来越难，不可避免地要选择与既有生态链接。对于国内，正如咨询公司所言，中国的平台工程正在告别"期望膨胀期”，进入泡沫破裂低谷期，这与全球趋势基本一致。平台工程的初衷是与其他已有实践共同解决复杂性的问题，我们依然相信这是正确且很有价值的方向，但需要持续加大投入和更多的探索实践。 部分新的趋势也在来年可能会获得更大发展，如对临时运行环境的更多采用、AIOps 中的 AI 治理平台、GenAI 与自治系统在 DevOps 中的更多采纳等。此外，有 AI 加持的 RPA 技术也可能在未来的复杂软件系统中扮演很重要的角色，甚至可能类似于<西部世界>里的“引导员”，人类成为虚拟世界里的技术玩家。
值得期待的会议
KubeCon & CloudNativeCon China 2025
这是 CNCF 的旗舰会议，2025 年的中国站依然在香港举办，且依然设置了平台工程主题类别，欢迎关注和参与。
时间 10~11 June, 2025
地点 HongKong ,China
网站 https://events.linuxfoundation.org/kubecon-cloudnativecon-china/
同时 KubeCon & CloudNativeCon 今年还设置了印度站和日本站。
PlatformCon 2025
这是全球 Platform Engineering 社区的大型会议，作为第四届，同时设置了线上和线下（纽约、伦敦、）会场。
时间 23~27 June, 2025
地点 线上 以及 线下（纽约、伦敦）
此外，也有很多与平台工程主题间接或多或少相关的会议，比如 FastFlowConf, DevEx 相关会议，以及开发者生产力工程相关会议，最多的可能依然是 DevOps 主题的会议和活动了。
我们也期待中国的平台工程主题社区持续发展壮大，在 2025 年可以开展更多的线上线下 Meetup 等社区活动，也能更多地参与业内的技术会议和活动。这些需要你我他/她的共同关注、支持和参与。同时，我们也期待与更多其他开源社区有更多合作和互动。
结语
平台工程与 AI 的持续加速发展，必定会为软件工程带来巨变，我们每一个软件人都身在其中。社区尤其是同行网络提供了非常好的交流与协作阵地，为此我们特别倡议所有平台人和平台的使用者积极参与到社区中来，通过知识分享、实践探索、经验交流来增强共识、推动相关项目的采纳和发展，同步也更新我们自身的专业认知和技术技能。
致谢
感谢 PECommunity 平台工程社区成员的关注、支持和参与；期望我们在 2025 年有更多分享、交流和互动，共同探索平台建设之道，为内外部开发者打造更好的体验，也同时共同期待 AI 时代的软件工程新秩序。
版权声明: 本文为 InfoQ 作者【杨振涛】的原创文章。
原文链接:【http://xie.infoq.cn/article/3da886f00ba0537defecdbd7e】。文章转载请联系作者。
可编程架构 ProgArch & 工程体验 EngEx 2012-05-31 加入
不懂分析基因序列的程序员，不是好的技术传播者！ 关注： 软件过程、DevOps、平台工程、研发管理；开源文化、开源治理； 此前关注（大）数据存储、索引、检索与可视化；电商与IM；生物信息与基因组测序。
评论