平台工程如何改进DevOps协作

平台工程现在是一个非常热门的话题。但是，平台工程计划修复的所有问题都还没有解决。根据Gartner的预测，到2026年，80%的软件工程公司将拥有平台工程团队。

当前全球经济的不确定性已经导致组织及其IT部门勒紧腰带，给开发人员带来前所未有的压力，要求他们更高效地构建和部署。

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

DevOps的局限性

DevOps不仅仅是一种交付软件的新方式。它还带来了一种全新的思考方式，即你作为团队中的一个个体扮演什么角色，以及如何与周围的人互动。

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

平台工程公司Humanitec的创始人兼首席执行官Kaspar von Grünberg表示：“今天部署的东西是一个更复杂的步骤功能，有几十个微服务和工具。”

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

站点可靠性工程这样的学科可能有助于管理复杂性和处理超出开发团队工作范围的问题，但它们并不能解决个人现在必须用更多的工具做更多的根本问题——每天都需要更多的工具、更复杂的复杂性和更多的决策。

IBM的产品经理Lee Diatiangkin表示，“要么，组织试图将尽可能多的DevOps任务留给开发人员，这给他们带来了很大的认知负担，要么，他们用花哨的新名称重新命名Ops部门，但保留他们基于票的工作流程，导致各方失望。”

Von Grünberg赞同这一说法，称管理者经常滥用跨职能团队和协作的DevOps原则，将其变成“人人都做”。“这实际上导致了大规模的倦怠，因为你向人们要求太多。如果你有一个非常复杂的工具链，专业化并不是坏事。专业化并不意味着孤岛。”

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

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

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

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

平台工程如何使Dev和Ops之间的界限更加清晰？平台工程构建IDP，Ops可以配置基础设施并关注实际运维和基础设施问题。同时，开发人员能够自助服务，因此他们不再需要麻烦Ops。Ops不再被开发人员的重复请求所困扰。

平台工程日益普及

在疫情期间，人们对数字化转型的重要性进行了大量讨论，快速行动而不破坏事物的能力，从而在Dev和Ops之间建立信任，也变得尤为重要。

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

更重要的是，有明显的迹象表明，平台工程的实践确实在增长。例如，2022年举办了有史以来第一届PlatformCon，这标志着不仅有一个蓬勃发展的社区，而且需要一个可以共同发展并更好地理解学科的空间。

关于平台工程的常见误解

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

“有一种说法是，你已经在构建一个内部开发者平台——如果你不构建它，它就会自己构建。”

因此，组织应该问自己的问题与其说是“我们是否应该构建一个内部开发平台？”，不如说是“哪些工作流和工具已经到位？”

因此，平台工程允许组织通过构建内部开发人员平台来考虑如何支持和支持开发团队。

即使你没有购买现有的门户网站，或者没有采用开源解决方案，它们在行业中的知名度也是如此之高，在开发人员效率方面，它们可以说鼓励了懒惰的思考。

“很多平台工程团队都是从构建一个花哨的UI开始的，就像一个开发者门户网站。”他表示，这是一种错误的方法，因为这可能会花费大量时间和金钱，但收效甚微。开发人员门户或服务目录通常侧重于零日场景，例如从模板创建新服务。“你正在优化一年发生10次的事情。效率有多高？”

Von Grünberg渴望明确开发者门户和内部开发者平台之间的区别：“开发者门户不是内部开发者平台。”而Gartner提供了一个明确的定义：“内部开发人员门户是开发人员发现和访问内部开发人员平台功能的接口。”

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

门户只是平台的接口，而不是平台本身。如果你在构建平台架构之前就构建了界面，这就像在打地基之前先构建房子的前门。

采用产品管理方法

相反，正如Ditiangkin所强调的，你应该对你的平台采取一种产品方法，因为它实际上是“一种将开发者视为客户的产品心态”。

换言之，它需要以完全相同的方式对待，就像你对待为外部市场构建的产品一样。这种方法需要许多实际步骤。正如Ditiangkin所概述的，“在构建平台之前，必须进行用户研究，获得利益相关者的支持，并向开发人员宣传平台，以确保采用。”

产品管理方法使平台团队能够对其组织中开发人员的特定和独特需求保持敏感；这让他们比一些表面上的改变更深入。如果说DevOps在近20年前首次被创造时应该做的工作有什么可以做的话，那么这种向产品思维的转变可能就是它了。

这并不容易。与开发者门户不同，“没有现成的内部开发者平台”，需要根据特定环境的需求来构建。然而，有两个关键要素可以作为指导。

第一个是“黄金路径”的概念。该术语指的是提供明确路线但不显眼的道路，平衡护栏和自主性。

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

将平台工程付诸实践

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

“你不可能为所有的东西建立一个平台。是的，这可能是关于容器和K8s的。”

然后，在工程组织中（可能有几十个甚至数百个开发团队），确定未来传道士团队非常重要。你应该选择一个创新者团队，他们在应用程序上与你的目标技术堆栈完全一致，并且真正愿意成为你的第一个客户。开发人员使用产品和平台，使平台工程团队的客户平等。然后不断收集他们的反馈，并根据这些反馈在平台上迭代。

这将有助于确保你在组织内获得认可，他们将为你作为一个平台团队所做的伟大工作进行宣传。

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

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

虽然这些工具可能在某种程度上有助于让没有谷歌或Netflix等资源的组织更容易使用平台工程，但这只是其中的一部分。它还涉及到继续培养一种社区意识，在这种意识中，人们认同平台工程是一门学科，并感到有动力相互谈论，分享经验和想法。

社区和协作是Humanitec理念的核心部分，这就是为什么Score和Humanitec驱动程序是开源的原因（Score于11月开源，在最初的三个月里在GitHub上获得了7000多颗星和2500个叉）。这也是为什么Humanitec是PlatformCon的组织者之一；该公司热衷于支持和培育一个社区，帮助各种组织采用平台工程。

使平台工程成为主流

那么，平台工程如何成为行业内的新常态？要做到这一点，还有很多步骤；例如，人才仍然是一个巨大的问题。

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

平台工程在未来几年的成功可以从它如何调整工程团队之间的关系来看。用Ditangkin的话说，它能帮助“在不将Dev和Ops放回各自孤岛的情况下，重新获得清晰的关注点分离”吗？当然，这其中有很多风险——为了每个人都能构建和部署软件，行业需要做好这一点。

原文链接：

https://thenewstack.io/how-platform-engineering-can-improve-devops-collaboration/