本文翻译自 How Platform Engineering Can Improve DevOps Collaboration ，更多链接请点击阅读原文。

我们都在谈论平台工程这一事实是否意味着 DevOps 从未真正修复过开发人员和运营团队之间的关系？如果是这样，平台工程如何提供帮助？

您不必成为行业分析师就知道平台工程现在是一个非常热门的话题；它可以说是软件工程中的当下话题。事实上，我们对 New Stack 读者的新调查显示出对它的浓厚兴趣；我们的观众将其列为 2023 年他们想了解的主题中的第四位。

但兴趣程度也应该表明平台工程已经着手解决的问题尚未解决。如果它很热门，那是因为它引起了轰动，而不是因为它已经成熟并融入了既定的主流实践。

无论如何，主流看起来像是平台工程的最终目的地。根据 Gartner 的预测，到 2026 年，80% 的软件工程公司将拥有平台工程团队。

目前全球经济的不确定性已经引发了组织及其 IT 部门的新一轮勒紧裤腰带，给开发人员带来了比以往任何时候都更大的压力，要求他们更高效地构建和部署。

那么为什么平台工程还没有成为现状呢？我们都在谈论平台工程这一事实是否意味着 DevOps 从未真正修复过开发人员和运营团队之间的关系？如果是这样，平台工程如何帮助修复这种关系并使其更有成效？

DevOps 不仅仅是一种交付软件的新方式。它还带来了一种全新的方式来思考您作为团队中个人的角色以及您如何与周围的人互动。亚马逊首席技术官 Werner Vogels 的名言“你构建它，你运行它”作为一种全新的思维方式出现在现场。

然而，彼时彼刻。世界已经改变，2000 年代的理想主义现在看起来已经过时，不适合日益复杂和高度分布式软件系统的时代。

平台工程公司 Humanitec 的创始人兼首席执行官 Kaspar von Grünberg 告诉 The New Stack：“我认为他并不真正了解世界将会变得多么复杂。” “如果你看看我们今天部署的东西，它是一个更复杂的步骤功能——你有几十个微服务和工具；我们拥有全球规模和更快的速度。我们一直在部署。它是如此的复杂。”

这种增加的复杂性给我们构建和部署软件的方式带来了新的挑战。从团队和组织的角度来看，这会给实际从事工作的人员带来新的压力和痛苦。

SRE 等学科可能有助于管理复杂性和处理超出开发团队工作范围的问题，但它们无法解决个人现在不得不用更多工具做更多事情的根本问题——更多工具，更多复杂性，每天都要做出更多决定。

过去十年一直在平台领域工作的 IBM 产品经理 Lee Diatiangkin 认为这些问题是由两件事引起的。无论哪种方式，Diatiangkin 告诉 The New Stack，“组织试图将尽可能多的 DevOps 任务留给开发人员，这给他们带来了很高的认知负担，或者他们用花哨的新名称重新标记他们的 Ops 部门，但保持他们的基于工单的工作流程，导致各方都感到沮丧。”

Von Grünberg 回应了这一评估，称管理人员经常滥用跨职能团队和协作的 DevOps 原则，将其变成“每个人都做所有事情”。

他阐述道：“这实际上会导致大规模的倦怠，因为你对人们的要求太多了。你雇用他们是为了让他们成为 ReactJS 的佼佼者，但你也给了他们 20 件他们应该做的其他事情，这是非常非常低效的，它会导致诸如 ShadowOps 之类的事情。”

Grünberg 指出，部分问题在于“专业化”现在被视为一个肮脏的词。 “如果你有一个非常复杂的工具链，那么专业化并不是一件坏事，”他说。 “专业化并不意味着你有孤岛。”

正如 Ditiangkin 所说，“墙已经被拆除，但现在谁负责什么的界限模糊了。”

那么，问题是我们如何才能使这些界限更清晰？我们如何才能以一种简单地让人们继续他们擅长的事情的方式实现专业化？目前行业共识似乎很明确：解决方案是平台工程。

什么是平台工程？ Humanitec 的产品负责人 Luca Galante 在 Platform Engineering 网站上的一篇博文中写道，它是“设计和构建工具链和工作流的学科，为云原生时代的软件工程组织提供自助服务能力”。

“平台工程师提供的集成产品通常被称为‘内部开发人员平台’，涵盖应用程序整个生命周期的操作必需品。”

平台工程如何使 Devs 和 Ops 之间的界限更加清晰？平台工程构建 IDP，Ops 可以配置基础设施并专注于实际操作和基础设施问题。同时，开发人员可以自助服务，因此他们无需再打扰 Ops。并且 Ops 不再由开发人员的重复的请求。

在大瘟疫时代，数字化转型的重要性得到了很多强调，但即使世界上大部分地区似乎正在走出那个困难时期，在不破坏事物的情况下快速行动的能力——从而在 Devs 和 Ops 之间建立信任——变得尤为重要。的确，情况可能一直如此；但在 2023 年，利润率（字面的和隐喻的）要更加重要。

这种环境是平台工程发展的沃土。技术复杂性的增加和企业面临的挑战时代相结合，意味着改进不同技术团队合作的方式，使事情变得更简单、更高效是最重要的。

更重要的是，有明显迹象表明平台工程的实践确实在增长。例如，2022 年首次举办了 PlatformCon，这表明不仅有一个蓬勃发展的社区，而且还需要一个可以聚集在一起发展和更好地理解该学科的空间。 （2023 年活动的提案征集截止日期为 2 月 28 日。）

如果我们跟随像 Gartner 这样的分析师，我们可能会错误地认为平台工程是该行业正在面向的目标。然而，现实是平台和工具方面的考虑已经存在，这是许多工程师日常工作的共同部分。

正如 von Grünberg 所说，“有一种观点认为，您已经在构建一个内部开发人员平台——如果您不构建它，它就会自行构建。”

因此，组织应该问自己的问题与其说是“我们应该建立一个内部开发人员平台吗？”而是“我们已经拥有哪些工作流程和工具？”

然后，平台工程允许组织仔细考虑如何通过构建内部开发人员平台来支持和赋能开发团队。

即使您不购买现有的门户或采用开源解决方案，他们在行业中的知名度也可以说让开发人员在效率方面避免了很多思考。

von Grünberg 说：“很多很多平台工程团队都是从构建一个新奇的 UI 开始的，比如在某些东西之上的开发人员门户。”他认为，这是错误的方法，因为它可能会花费大量时间和金钱，但影响很小。开发人员门户或服务目录通常关注零日场景，例如从模板创建新服务。 “您正在优化每年发生 10 次的事情。你的效率提高了多少？”

Von Grünberg 渴望明确区分开发人员门户和内部开发人员平台：“开发人员门户不是内部开发人员平台。”这是业内其他人提出的观点。例如，Gartner 给出了一个明确的定义：“内部开发人员门户是开发人员发现和访问内部开发人员平台能力的界面。”

正是因为开发人员门户是一个界面，它可以以一种对于内部开发人员平台来说有点困难的方式来吸引组织的注意力。毕竟，门户是一种可视化的东西——你可以看到它；它可能具有一定的审美品质。但平台工程和内部开发人员平台提供的最重要的价值是提高开发人员的工作效率。

门户只是平台的界面，而不是平台本身。如果在平台架构本身正确之前就构建界面，就像在打地基之前先盖房子的前门一样。

相反，正如 Ditiangkin 强调的那样，您应该对您的平台采用产品方法，因为它实际上是关于“将开发人员视为客户的产品的思维方式”。

换句话说，它需要以与对待为外部市场制造的产品完全相同的方式对待。这不仅仅是一句口头禅；这种方法需要采取一些实际步骤。正如 Ditiangkin 所概述的那样，“您必须在构建平台之前进行用户研究，获得利益相关者的支持，并向开发人员宣传该平台以确保采用。”

产品管理方法使平台团队能够对其组织中开发人员的特定和独特需求保持敏感；它允许他们比一些外观变化更深入。如果有什么东西可以完成 DevOps 在将近 20 年前首次提出时应该完成的工作，那么这种向产品思维的转变可能就是它。

这并不容易：von Grünberg 强调，与开发人员门户不同，“没有开箱即用的内部开发人员平台”，它们需要根据您的特定环境的需求来构建。然而，有两个关键要素可以作为指南。

第一个是“黄金路径”的概念。该术语指的是提供清晰路线但不引人注目的路径，平衡了护栏和自主性。 “我们不想强加抽象；我们希望确保人们可以自行选择他们觉得舒服的复杂程度，”von Grünberg 说。

第二个是他所说的“设计标准化”。这确保了每个开发人员的工作方式都具有更高的效率和一致性，因为它被嵌入到平台中。例如，它可以帮助您最大限度地减少并最终减少跨团队管理的配置文件的数量。

平台工程背后的原则和理论是一回事：真正重要的是如何将其付诸实践。 Von Grünberg 建议平台团队从小处着手，专注于他所谓的“最低共同技术分母”——所有团队都在使用的东西。

这意味着什么？ “你无法为所有事物构建平台。是的，它应该与容器和 K8s 有关。”

然后，在您的工程组织（可能有数十个甚至数百个开发团队）中，确定您的未来传道者团队非常重要。你应该选择一个创新者团队，他们的应用程序完全符合你的目标技术堆栈，并且真的愿意成为你的第一个客户。开发人员等于平台工程团队的客户，使用产品和平台。

然后不断收集他们的反馈，并根据这些反馈在平台上进行迭代。

这将有助于确保您在组织内获得支持；你基本上创造了 von Grünberg 所说的“铁杆粉丝”，他们会为你作为平台团队所做的伟大工作进行宣传。

获得这种支持很重要，原因很简单，因为构建内部开发者平台很困难。一方面，这是由于技术上的挑战； von Grünberg 表示，该过程有时可能“非常手动且乏味”，这就是您在简化和标准化基础设施配置和工具时必须应对的复杂性。

这部分是 Humanitec 的用武之地；例如，它的 150 多个开源驱动程序可以帮助简化大量集成。而与平台无关的工作负载规范Score，von Grünberg 说，可以帮助开发人员“以以开发人员为中心且与平台无关的方式指定工作负载”

虽然这些类型的工具可能会在某种程度上帮助没有 Google 或 Netflix 等资源的组织更容易获得平台工程，但这只是图景的一部分。它还与继续培养一种社区意识有关，在这种社区意识中，人们将平台工程视为一门学科，并感到有动力就此进行交流、分享经验和想法。

社区和协作是 Humanitec 理念的核心部分——这就是为什么，例如，Score 和 Humanitec Drivers 是开源的（Score 于 11 月开源，前三个月在 GitHub 上获得了 7,000 多个星标和 2,500 个分支）。这也是为什么 Humanitec 是 PlatformCon 的组织者之一；该公司热衷于支持和培养社区，帮助各种组织采用平台工程。

那么平台工程是如何成为行业新常态的呢？要做到这一点还有很多步骤；例如，人才仍然是一个大问题（Von Grünberg 声称他“现在可以说出 20 个正在寻找平台产品所有者的组织的名字。”）

但随着社区的发展和知识的更好传播，平台工程角色可能会失去其神秘感，因为人们开始将其视为具有自己的一套能力和技能的可行职业选择。同样，组织将需要适应不断变化的结构和新的层级思维方式。然而，这又是关于教育的——就像内部开发者平台一样，实践本身需要传道者和传播者。

平台工程在未来几年的成功可以从它如何重新定位工程团队之间的关系来看待。用 Ditiangkin 的话来说，它能否帮助“重新明确关注点的分离，而不会让开发人员和运营人员重新陷入各自的孤岛”？肯定有很多利害关系——为了每个构建和部署软件的人，行业需要正确处理。