翻译自 Which Features Does Your Platform Engineering Portal Need? 。

成功设计一个提供开发人员真正需要的门户平台是一项重大的工程壮举。这里有一些特性可以确保良好的开发体验。

平台工程已作为一种社会技术解决方案出现，以填补 DevOps 中缺失的许多空白。特别是，平台工程的主要好处是它如何大规模提高敏捷性和消除孤岛——尽管这一直是 DevOps 应该做的。

改善开发者体验是关键，因为这是提高敏捷性的主要途径。从实际角度来看，这意味着开发人员可以在优化的平台工程师支持下，通过提供自助服务功能和自动化基础设施操作，完成工作而无需承担与管理运营相关的繁琐任务。

这对于在云原生环境中工作特别有用，因此开发人员可以创建应用程序或完成拉取请求，而无需参与管理 Kubernetes 的巨大复杂性和其他相关任务，例如安全性。

Gartner 预计，到 2026 年，80% 的软件工程组织将建立平台团队，作为可重用服务、组件和应用程序交付工具的内部供应商。分析师预测，平台工程最终应该解决软件开发商和运营商之间合作的核心问题。

然而，平台工程的一个经常被忽视的关键要素仍然是实际的开发人员体验。这就是所谓的开发人员内部开发人员门户发挥作用的地方，作为工程平台之上的界面，将确保开发人员能够完成他们的工作，学习曲线类似于使用无代码替代方案。

有了正确的门户，开发人员必须首先花费一年多时间学习如何为 Kubernetes 创建应用程序和在 Kubernetes 上部署应用程序的日子已经一去不复返了。相反，开发人员几乎可以立即开始应用他们的才能来开发软件，以反映敏捷开发实践的节奏实现直接的业务目标。

事实上，在过去几年中，许多组织在尝试采用平台工程时都专注于平台本身。他们通常可能设计 CI/CD 管道、云基础设施、实施 TerraForm 并设计 Kubernetes 基础设施。

然而，在许多情况下，让开发人员可以访问该平台的尝试可能会在杂草中迷失方向。

Port 的联合创始人兼首席执行官 Zohar Einy 表示：“开发人员需要能够以他们能够理解的方式使用具有类似产品体验的不同平台元素，因为他们不需要了解幕后的一切。” ，它提供了一个内部开发人员门户，可为开发人员提供自助服务体验。

“但通过适当的平台工程到位，您可以减轻开发人员的认知负担并帮助他们获得所需的一切，”Einy 说。 “这可以通过作为内部开发人员门户的现成产品来完成。”

成功设计一个提供开发人员真正需要的门户平台是一项重大的工程壮举。虽然存在开源产品，但它们需要大量内部资源来设置和管理。

根据旅游服务提供商 Luxury Escapes 的首席软件架构师 Eran Stiller 的说法，领先的开源开发人员门户网站是 Backstage。由 Spotify 的工程师开发的 Backstage 具有高度可定制性和可扩展性，但开发人员需要大量时间才能采用它，而且“您还必须自己托管它，这需要额外的时间和精力，” Stiller 说。

最近几个月，Backstage 还披露了一些可能带来安全风险的重大漏洞。

另一方面，Stiller 说，商业产品通常在功能和它们提供的可扩展性方面受到限制。

“如果该产品能够满足您的需求，并且可以与您当前的技术堆栈和平台一起使用，那就太好了。但如果不这样做，它对你的好处可能是有限的，”他说。 “提供开箱即用的高水平定制和可扩展性的商业平台具有巨大的潜力，可以帮助那些不想或不能花时间调整和托管他们自己的 Backstage 实施的开发团队。”

根据 Einy 的说法，开发人员门户应提供的特性：

自助服务，为开发人员提供灵活性，同时保持政策合规性。 门户的自助服务功能应该超越微服务脚手架，以允许开发人员对软件目录中公开的任何资产进行配置和执行第 2 天操作。同时，门户网站应确保任何操作都符合政策，并允许对某些操作进行手动批准。

“Port 是第一个在开发人员自助服务方面采取这种雄心勃勃的方法，超越了脚手架，这也是 Backstage 方法，”Einy 说。 “作为对我们愿景的验证，我们看到市场上的其他参与者也开始采用这种方法。”

门户和平台的松散耦合。 通过这种方式，平台工程团队可以自由地根据他们的规范构建底层平台，并让开发人员通过开发人员门户以他们理解的方式使用平台数据。

平台工程团队可以选择他们想要的 CI/CD、IaC、软件架构和所有 DevOps 流程。

解耦允许对底层平台进行更改，同时保持开发人员体验的一致性。

“我们不会给你一个预制的房子，里面什么都有，然后告诉你如何进行 DevOps 或平台工程，”Einy 说。 “但是我们为您提供了无代码元素来创建您梦想中的房子。这是我们与其他解决方案之间的关键区别。”

能够集成组织自己的数据模型。 数据模型被带入软件目录，这是一个可见性层，用于组织内部开发和管理的基础设施和软件。

理想的软件目录应该显示软件开发生命周期周围的整个生态系统。这些包括CI/CD流程、开发者环境、管道、部署以及任何云服务，"在所有的[研发]部署中"，Einy说，"从应用开发，甚至到数据、安全、产品和研究——基本上是每个与软件有关的团队"。

开发者门户内的工作流自动化支柱，允许机器与其交互。 在开发者门户内，机器可以使用 Port 的实时软件目录访问单个 API。这为机器提供了它们在工作流程中需要的上下文信息，例如失败的 CI 任务、自动终止资源或基于软件目录数据运行 CD 流程。

此外，机器可以订阅触发器，例如：资源生存时间达到零、Cron 作业计时器已用完，或者实体的创建、修改或删除。您可以使用订阅来触发自动化工作流或任务。

“这也是因为软件目录充当通用软件目录，而不仅仅是为开发人员抽象信息，”Einy 说。

此类门户功能“对于现代软件开发团队至关重要，”Stiller 说，并补充说，“对于那些大型团队或为多个部署单元（如微服务）构建软件的团队来说尤其如此。”

在后单体时代，软件设计要求变得更加复杂，“开发团队也随之成长，”Stiller 说。 “我们开始分发我们编写的软件。”

“这种分布导致了多个团队不断踩到对方脚趾的问题，因此我们转向面向服务的架构，后来转向微服务。问题在于，分布式架构比整体架构更难掌握和维护，从而带来了新的挑战。”

Stiller 说，在基于微服务的应用程序开发中，负责监督开发过程的架构师通常会面临理解系统工作原理的挑战，并提出以下问题：

• 应用程序部署在哪里？
• 当前运行的是哪个版本？
• 哪个服务依赖于哪个其他服务？
• 哪个服务是造成大多数客户错误的原因？

Stiller 说：“他们需要工具来帮助理解分布式的复杂性，并引导他们走向应该关注的地方。” “一个好的内部开发人员门户网站使我能够做到这一点，它允许我为构成我的应用程序的所有软件构建一个目录，无论是服务、部署管道、基础设施组件、​​云环境等。”

他说，一个好的门户允许架构师在他们的目录之上覆盖额外的信息，这些信息通常在其他系统中可用，但需要在一个位置连贯地组织起来。

“例如，我可以添加一层信息，根据我的可观测性平台中可用的数据说明每项服务的错误率，”Stiller 说。 “或者我可以添加一层信息，根据我的源代码控制系统或 CI/CD 管道中的信息显示特定横切依赖项的版本。”

添加信息后，架构师可以添加规则并创建仪表盘。

“例如，我可以根据服务的错误率排名，并对未满足[服务级别协议]的服务发出警报，我还可以对未将依赖项更新到最低要求版本的服务发出警报，” Stiller 说道。“能够这样做，并以一种易于访问的方式向团队中的所有开发人员展示所有这些信息是无价的。”