写点什么

平台工程应知应会

作者:Luca Galante

  • 2023-05-01
    北京
  • 本文字数:3992 字

    阅读完需:约 13 分钟

平台工程应知应会

随着社区和工具生态的快速发展,平台工程显然会继续存在下去。但是,和任何(相对)新的趋势一样,平台工程仍有许多未解之谜。最近,Humanitec 发布了第一份《平台工程现状报告》——以下是该报告的关键内容以及平台工程的重要趋势。

 

平台工程是软件工程中最大的趋势之一。PlatformCon 2022 ——有史以来的第一个平台工程大会——吸引了超过 6000 名参会者,而当地的聚会小组也有数千名会员,很显然,这一趋势将持续下去。

 

自然,与软件工程的任何趋势一样,会有许多社区内外的人都好奇的未解问题。第一份《平台工程现状报告》试图回答这些持续存在的问题,提供关于平台工程现状的信息,并从社区的不同角落汇编了一些关键资源。

 

所以,话不多说,以下是你需要知道的关于平台工程的关键内容。

 

为什么平台工程是一个重要的趋势?


在过去十年中,复杂的微服务架构、Kubernetes 这样的技术以及 IaC(基础设施即代码)这样的方法已经成为行业标准。现在,即使是简单的任务也要求开发人员对工具链有一个端到端的理解,这极大地增加了他们的认知负荷,并导致组织效率低下,比如影子运维。

 

认知负荷是指“工作记忆中消耗的脑力劳动总和。”这一理论是由心理学家 John Sweller 在 20 世纪 80 年代末首次提出的。该理论认为,“当学习任务超出工作记忆容量时,学习就会受阻。”

 

2019 年,Manuel Pais 和 Matthew Skelton 认为,认知负荷是当前 DevOps 设置问题的主要副产品。这一发现推动他们创建了团队拓扑,其中有一个专门的产品团队构建了抽象层或平台,使开发人员可以免受底层技术复杂性的影响,降低了他们的认知负荷。

 

团队拓扑设计用于防止某些 DevOps 设置中反复出现的特定的反模式。在一种被我们称为“影子运维”的反模式中——Humanitec 2021年开展的DevOps基准研究证实了这一点——工程组织断定他们不再需要专职的运维专家(或至少减少人数),并将这些任务转给开发人员。通常,这会导致缺乏经验的开发人员向高级后端工程师寻求帮助。这会导致组织中一些最有才能、最重要的资源错配,工程团队的生产力因此降低。



Daniel Bryant在PlatformCon 2022大会的演讲启发

 

因此,一些组织被迫寻找更好的方法。他们成立了平台工程团队来构建内部开发平台,或者将技术和工具组合在一起,降低开发人员的认知负荷,而又不用抽象出底层技术的上下文。Netflix利用他们的平台解决了开发人员在管理多种服务和软件、了解存在哪些工具以及在不同工具之间切换上下文时所面临的挑战。Nordstrom打造了一个平台,成了“自助服务的北极星”。他们的平台帮助消除了环境准备过程的瓶颈,人们不再需要登录到生产环境。这些变化使组织能够更快地前进。Zalando利用他们的平台统一了开发体验,默认启用了合规性增强,并随着时间的推移改进了公司的运营方式。

 

这些只是其中几个成功的平台项目的示例。Puppet 2020年和2021年的“DevOps 现状报告”以及 Humanitec 2021 年的“DevOps 基准报告”等研究表明,使用 IDP 的团队,其 DORA 指标显示出了更高程度的 DevOps 演进和效能。

 

那么到底什么是平台工程呢?

 

虽然就平台工程的通用定义达成一致很困难,但这项任务很重要。我最近将平台工程定义为

设计和构建工具链及工作流的学科,为云原生时代的软件工程组织提供自助服务能力。平台工程师提供一个通常称为“内部开发平台”的集成化产品,涵盖应用程序整个生命周期的操作需求。

 

内部开发平台由专门的平台团队构建。团队拓扑讨论团队是什么,不是什么。平台团队不是 SRE 的替身,也不是处理开发者工单的影子运营团队。它不应该关注个人挑战或生产可靠性。相反,它应该以产品思维为驱动,将开发者视为平台客户。

 

平台工程原则和最佳实践


在平台团队开始构建他们的产品之前,需要定义一个明确的使命宣言来指导整个过程。宣言应符合组织的总体目标,并主动定义好平台团队在组织中的角色。它应该可以激励你的工程师。Hashicorp 平台工程基础设施总监Michael Galloway有一个很好的总结:“它应该是有感染力且鼓舞人心的……它应该是简单而有意义的。”

 

你可以从定义目标着手。这可能包括:在不增加认知负荷的情况下,实现所需程度的开发人员自助服务,或者在不强迫开发人员学习以基础设施为中心的端到端技术的情况下,实现所需的操作成本节省。在此之后,你可能会得出这样的结论:“我们的任务是标准化工作流程,改善开发体验,加快创新周期,缩短工程组织的上市时间。”但这是描述性的,不够鼓舞人心。完善你的使命宣言,实现良好的平衡。例如:“我们的使命是构建开发者喜爱的平台,提高他们的创新速度。”

 

构建平台的最佳方法是遵循产品方法。通过用户研究、用户反馈征集,从利益相关者那里获得内部支持,平台团队可以全面了解开发人员的痛点和整个组织共同面临的挑战。它可以确定开发人员需要什么功能,并构建一个可以实现这些解决方案的黄金路径。但平台之旅并未就此止步。成功的平台团队会与开发人员保持开放的沟通,并度量工程 KPI,确保开发人员采用了平台,而平台使开发人员的工作变得更轻松。

 

Lambros Charissis分享了 Wise 的平台工程团队如何制定了一套可执行的 KPI 来识别挑战和度量绩效。他们使用 KPI 树来明确 KPI:生产力、交货时间、部署频率、开发人员满意度、稳定性、效率和风险。

 

你还应该监控平台采用 KPI,如市场份额(开发人员是否在实际的工作中使用了你的平台,还是更喜欢直接使用他们自己的技术和工具?),使用平台节省的时间,以及团队之间关系的改善(例如开发人员和运营人员)。定期进行调查,看看平台是否改善了开发体验。

 

平台团队和他们提供的黄金路径是将这些复杂的设置整合在一起的粘合剂。然而,由于平台团队通常不交付面向客户的特性,所以许多组织错误地将它们视为成本中心。平台团队应该争取相关涉众团体的内部支持,确保其内部平台项目可以长久地运行下去。

 

最后,也许也是最重要的一点,成功的平台团队不会重新发明轮子。有时,最好的解决方案必须从头构建。然而,许多企业正在将他们的资源投入到针对特定的用途构建有效的解决方案。为了解决各种各样的问题,工具领域正在快速发展。只要有可能,平台团队就可以通过裁剪现成的解决方案来节省时间并创造更多的价值。

 

平台工具生态


平台工程是指构建内部开发平台。Kaspar von Grünberg 解释说,内部开发平台是“平台工程团队将所有技术和工具整合在一起,铺就一条黄金道路。”但是,都有哪些技术和工具呢?如何确定哪些最适合你的组织?

 

构建平台的方法有很多种,没有通用的解决方案,尽管有些供应商可能会做出这样的承诺。有些提供 PaaS 类体验的供应商(如 Heroku)可能适合小型初创公司,特别是那些想要快速推出 POC 或 MVP 的公司。

 

但对于大型企业或中型工程组织来说,在大多数情况下,这样的 PaaS 是行不通的,因为他们仍然需要支持他们的棕地设置,而不能启用绿地。

 

然而,平台工程专家通常会建议平台开发遵循产品方法。也就是说,你不一定要从头开始。现在有很多平台工具产品,其中许多是开源的,也有一部分是专有的。为了节省组织的时间和金钱,只要可能,就要考虑购买和定制预构建的解决方案。这就为平台团队留出了时间和资源,让他们专注于定制组织需要的特性。

 

为了更好地理解所有选项,平台工程现状报告设法对平台工具的生态进行了划分。



在一份题为“软件工程领导者改善开发体验指南”的报告中,Gartner 总结了指导平台工程建设的三个关键思想:

  1. 通过构建内部开发平台来减少开发人员的认知负荷、艰苦的重复性手工工作,从而改善开发体验。

  2. 平台不会强制使用特定的工具集或方法——它是为了让开发人员可以更容易地构建和交付软件,同时又不用抽象出底层核心服务中实用的差异化功能。

  3. 平台工程团队将平台视为产品(供开发人员使用),并设计出可以自助使用的平台。

 

这里还需要澄清下内部开发平台和内部开发门户之间的区别。Gartner 的报告也提到了这个问题。作者写道:


内部开发门户是开发人员发现和访问内部开发平台能力的界面。

 

内部开发门户提供了一个具有服务目录功能的 UI,开发人员可以使用它访问底层的内部开发平台。反过来,内部开发平台消除了艰苦的重复性工作。

 

构建开发门户并不能解决降低开发体验的底层配置和工作流问题。这就是内部开发平台和开发门户成为理想组合的原因。

 

社区与职业



平台工程社区始于 2021 年,当时在奥斯汀和柏林有多个聚会小组。如今,它在全球有 19 个聚会小组,活跃的平台工程师超过 10000 名。这种社区发展势头表明,组织越来越重视平台工程。

 

平台工程也是一条很有前途的职业道路。许多公司开始意识到,构建内部开发平台可以增加他们的利润。此外,构建内部开发平台的人平均工资也高于对应的 DevOps 岗位。

 

尽管如此,像平台工程师或平台负责人这样的职位还不是特别常见。平台工程现状报告发现,大多数正在构建组织平台的受访者都拥有像高级软件工程师、IT 架构师、首席工程师或高级 DevOps 工程师等职位。因此,虽然行业开始拥抱平台工程,但要恰当地定义平台角色仍然很困难。



考虑从事平台工程师职业的人经常会询问社区,他们需要掌握哪些技术。根据我们的调查,超过一半的受访者表示,他们最关注 Docker、Kubernetes、IaC 和 CI/CD。数据库、存储和网络技术也在清单上,不过是在不到四分之一的受访者的清单上。



说到工作安排灵活性方面,平台工程走在了前列。超过 80%的美国受访者是完全远程工作。欧洲受访者在完全远程办公和混合办公之间取得了更好的平衡。总的来说,100%在办公室办公已经成为过去式。

 

未来展望

在过去的几年中,平台工程已经取得了长足的进步,而且还没有放缓的迹象。随着工具生态和社区的日益发展,会有很多的资源可以帮助你启动平台工程或让你在事业上更进一步。

 

原文链接:

https://www.infoq.com/articles/platform-engineering-primer/


相关阅读:

从 DevOps 到平台工程|InfoQ《极客有约》

平台工程的 2023:助力云原生重构研发组织文化与组织架构

Puppet 2023 DevOps 现状报告:平台工程有助于提升开发效率


2023-05-01 08:004363

评论

发布
暂无评论
发现更多内容

产品经理训练营作业第2周

黑小白白白

极客大学产品经理训练营

SpotMax:在云上,看我帮助企业省“余粮”

亚马逊云科技 (Amazon Web Services)

云计算

产品的利益相关方

沈弋

产品作业2

Tomz

产品经理训练营

产品经理训练营 Week2 学习心得

Mai

重学JS | Ajax发送数据序列化问题以及Object序列化整理

梁龙先森

JavaScript 大前端 编程语言 28天写作

主机安全产品利益相关方

赵志广

产品经理训练营

产品经理第二周作业

克比

科技创投媒体36Kr的容器化之路

Rancher

二手车平台app利益相关方分析

戎帅

产品经理第 0 期训练营第二周作业提交

Krystal

第二周作业 - 抽奖助手利益相关者

Geek_971380

第二周作业

岛乾坤

看西联软件如何拿下四川省 7 成连锁卖场 | AWS 精选案例

亚马逊云科技 (Amazon Web Services)

Spring Boot 中使用监听器

武哥聊编程

Java springboot SpringBoot 2 28天写作

Stakeholder list

顾远山

产品训练营-第二周学习总结

Trigger

极客时间 极客大学产品经理训练营 产品训练营

产品经理训练营--第二周作业

孤星

第二周 作业

Geek_72d5ab

京东发布《未来科技趋势白皮书》,101页详解5大关键技术

京东数科风险算法与技术

产品训练营作业-week02

anyou

看 AWS 如何帮助客户以低成本造就更多可能 | AWS 创新视野

亚马逊云科技 (Amazon Web Services)

第二周总结

岛乾坤

作业2-产品的利益相关人分析

赝品

【纯CSS】画 多国国旗

德育处主任

css3 html/css CSS小技巧 28天写作 纯CSS

抽奖小程序-利益相关方分析

思亭

极客大学架构师训练营成果索引

晴空万里

架构师训练营第2期

产品经理训练营 - 第二次作业

羽室

删库跑路被判入狱,明知不可为而为之

李忠良

28天写作

产品利益相关者分析

Dylan Zhu

CSS(五)——设置文本样式

程序员的时光

程序员 大前端 七日更 28天写作

平台工程应知应会_DevOps_InfoQ精选文章