DevOps 的失败持续推动着组织建立平台团队。但 Gitpod 和 Humanitec 的最新报告指出，许多组织并没有衡量结果。
译自The 2024 State of Platform Engineering? Fledgling at Best，作者 Jennifer Riggins。
平台工程师面临着艰难的道路，因为很少有组织真正实现了平台工程——但如果他们不衡量其结果，他们怎么可能做到呢？
但如果平台工程师的薪资等级至少比DevOps工程师高一级，他们很可能会继续应对这一挑战。
这些只是今年“平台工程现状”报告中揭示的两个最大发现。
The New Stack在今年报告发布之前与Platform Engineering的社区负责人Sam Barlien进行了座谈。他反思了为什么组织未能实现长期投资以及解锁平台成熟度的策略，包括内部开发者平台 (IDP) 在 DevOps 组织中的作用，也许最重要的是改进，以及为什么要衡量所有这些。
平台工程：仍然是新事物
这是第三份年度报告，由Humanitec和Gitpod赞助；研究人员调查了281名平台工程专业人员。
大多数被调查的组织——56%——拥有平台团队的时间不到两年。只有13%的受访者表示他们在“平台工程”领域工作超过五年。
为什么突然增加？是什么驱使组织采用平台工程？
Barlien说，研究人员对平台工程的定义是：“在云原生时代，设计和构建工具链和工作流程，为软件工程组织提供自助服务能力的学科。平台工程师提供一个集成产品，通常被称为内部开发者平台，涵盖应用程序整个生命周期的运营需求。”
他说，这故意地足够广泛，包括数据平台工程，但它关注的是为内部客户（绝大多数是开发人员）服务的平台角色。
先有DevOps，后有IDP
今年的结果再次表明平台工程并没有取代DevOps，而只是数字转型演进的下一阶段。平台帮助工程组织更接近实现DevOps的承诺。
总的来说，受访者表示，正在他们组织中构建内部开发者平台来弥补DevOps的不足。自动化是DevOps的一个关键原则，然而，近一半的受访者抱怨由于缺乏自动化而做了太多重复性任务。
另一个DevOps原则是贯穿整个生命周期的责任驱动——你构建它，你拥有它。但是平均技术栈呈指数级增长，通常有七层之厚。这分散了开发人员的注意力，使其无法真正为客户创造价值。IDP可以抽象掉云原生复杂性，以减少开发人员倦怠和认知负荷。它还可以进一步将产品、流程和人员结合在一起。
当然，13%的受访者承认他们还将DevOps团队重新标记为平台工程，“听起来更高级”，因此Gartner可能是对的，这个学科已经滑入了“幻灭的低谷”。
今年的“DevOps加速状态”——更常被称为DORA报告——发现了令人沮丧的结果。例如，DORA研究人员发现，使用平台工程，吞吐量下降了8%，变更稳定性下降了14%。
由于这是DORA团队成员首次尝试衡量平台工程，因此他们并没有声称拥有答案——尽管他们假设，上市速度可能仅仅意味着总体上发布了更多变更，这可能会降低整体稳定性。
从DevOps到平台工程师
这份年度报告独特地展示了平台工程作为DevOps在职位角色方面的演变。 这份报告将基础设施平台工程师和DevEx平台工程师置于就业金字塔中基础设施、运营和开发角色之上。与DevOps角色相比，负责通过标准化和自动化来缓解基础层痛点的这些平台“价值驱动者”数量较少。
(来源：“平台工程现状报告，第3卷”，Gitpod和Humanitec)
报告显示，考虑到这一点，2024年，欧洲的平台工程师的收入比DevOps角色高出23%，北美高出27%。
虽然2022年平台工程师和DevOps角色之间的区别模糊不清，但这份报告显示，到2024年，平台团队对其职权范围内的内容有了更清晰的认识。平台工程师告诉研究人员，他们负责：
只有一小部分受访者认为，作为平台工程师，他们的职责是充当开发者帮助台（19%）或为高管创建仪表板（9%）。
平台工程师和DevOps工程师之间的薪资差距自去年报告以来已缩小了一半，去年报告显示平台工程师的收入比DevOps工程师高出42%。这可能再次表明平台工程仍然很重要，但也许不像业界最初认为的那样重要。
Barlien推测，“这可能是由于大规模裁员导致差距缩小，也可能是由于DevOps薪资上涨而平台工程薪资下降，[目前]尚不确定。”
过去三年来，这份报告始终衡量的是，拥有平台工程师职位的员工比拥有DevOps职位的员工拥有更长的工作经验。事实上，今年接受调查的平台工程师中有28%拥有超过15年的科技行业经验。
平台团队的成熟度如何？
仅仅一年多前，云原生计算基金会发布了其平台工程成熟度模型。
这是一个衡量平台工程计划并确定改进领域的框架，涵盖：
- 投资
- 采用
- 接口
- 运营
- 衡量
这些方面从最低成熟度到最高成熟度量化如下：
- 试运行
- 运行
- 可扩展
- 优化
去年的“平台工程现状报告第2卷”发现，平台工程组织还处于起步阶段，尚未实施最佳实践，包括：
- 变更管理流程
- 跨组织的认同
- 明确的平台团队结构
- 一种产品化平台思维
- 平台采用策略
随着平台工程进入其作为热门科技话题的第三年，今年的报告试图量化其成熟度。
简而言之，大多数团队远未成熟。
Barlien说：“这里反映的情况是，对于那些做得好的平台工程人员来说，效果非常好。而对于那些做得不好的人，结果完全相反。”
根据CNCF平台成熟度模型的标准，只有大约9%的受访者确实成熟。与这少数人相比，Barlien和他的团队发现，对于什么是平台工程，总体上缺乏清晰的认识——即使是那些据称担任平台工程师的人。
他说，对于他认为是简单的平台工程问题，“很多问题的答案是‘其他’，他们的回答是‘我不理解’”。
报告指出，虽然许多公司都在采用平台工程，但只有少数公司能够以成熟和可扩展的方式实现其潜力。
但是，如果接受采访的平均团队成立时间在0到24个月之间，这就不足为奇了。
平台团队不知道如何衡量
今年的“平台工程现状”报告揭示了工程或任何科学领域中最响亮的秘密：你无法改进你无法衡量的东西。
大约43%的受访平台团队将他们的反馈机制描述为“临时性”或“不一致”。这与CNCF的定量和定性反馈标准相差甚远。
Barlien说：“人们不知道自己在做什么。这大概就是主要的结论。” 事实上，45%的平台团队根本没有任何衡量指标，而37%的团队只衡量DORA指标。虽然DORA关注吞吐量和稳定性是开发者体验的重要方面，但这肯定无法全面展现DevEx的细节。
“如果你不进行衡量，你就不知道你是否真的产生了影响，”Barlien说，“然后突然六个月后，你进行检查，一切感觉都更糟了。”
另外26%的调查参与者报告说他们收集了数据，但实际上并没有分析这些数据。
当被问及自引入平台工程以来，指标是如何改进的时，只有22%的人报告了显著改进，而32%的人看到了轻微的改进。相比之下，17%的人报告没有明显变化，而27%的人表示不确定。
这不仅会损害平台团队的积极性——还会让证明他们已经获得了预算，并值得保住工作变得困难。
报告还指出，39%的团队报告说他们的平台“以集中方式启用，并专注于用户需求”。但如果他们没有对此进行衡量，那么这种描述可能基于假设：“这种差距表明，许多组织对自身的评价远高于实际情况。”
此外，在承认他们不知道自开始平台工程以来指标变化程度的组织（27%）与回答他们根本不进行衡量（44%）的组织之间，存在近18%的差异。这表明18%的受访者可能是基于轶事证据、非正式观察或临时测量来评估情况的。
“人们同时说，‘哦，是的，一切都很棒。’然后他们又说，‘哦，不，我们什么也没衡量，’”Barlien反思道。“当你看到像DORA这样的东西时，这就不足为奇了——不稳定性和认知负荷都在上升。
“好吧，如果这些人什么都不衡量，他们就不清楚自己在做什么。那么，为什么有些事情无法按照他们想要的方式运作就很容易理解了。”
缺少什么？产品思维
“平台工程是产品管理和一些坚定地专注于技术和工程之间的一步，”Barlien说。但他补充说，许多平台团队仍然不明白这一点。
他说，大多数平台团队仍然缺乏产品管理方面的理解，包括：
- 用户研究
- 衡量改进情况
- 了解客户（你的开发者）想要什么
- 了解你的开发者是否正在使用你的平台
- 他们是如何使用的
“与DevOps或敏捷方法不同，DevOps或敏捷方法需要工程师已经熟悉的思维方式，”Barlien反思道，“平台工程往往要求工程师进入一个全新的思维空间。”
这份报告没有使用确切的术语，而是指出平台即产品思维是少数做得好的平台工程受访者与大多数做得不好的受访者之间的主要区别。
你呢？你是否想分享你平台工程之旅的故事？PlatformCon演讲征集正在进行中。
