来自三家大型全球公司的技术领导者分享了他们从 DevOps 到内部开发者门户的旅程中获得的经验教训。
译自 Internal Developer Portals: 3 Real World Examples，作者 Sooraj Shah。
无论行业、背景、技术栈和团队构成如何，所有组织都在努力用平台工程和内部开发者门户解决相同的问题。
在Portal Talks 2024由Jennifer Riggins主持的一场会议上，来自三个组织的领导者回答了一些关于内部开发者门户在现实生活中如何使用的一些关键问题：
- Tiffany Grafton，财产和意外险公司Great American Insurance Group(GAIG)的技术产品经理，该公司拥有超过7000名员工。
- Pavel Pikat，AMCS Group的技术产品负责人，该公司为全球80多个国家的废物管理、回收、运输、制造和公用事业行业提供业务管理软件。
- Louis Bailleul，PGS的首席企业架构师，这是一家拥有近1000名员工的能源数据和情报公司。
您可以在 YouTube 上观看完整的Portal Talks 会议。
为什么选择平台工程？
AMCS Group 在遵循 DevOps 实践五年或六年后认识到对平台工程的需求。虽然这推动了工程卓越，但该公司从 200 人快速增长到 1200 人，而中央DevOps 团队在扩展方面遇到了挑战。
“我们当时在使用‘TicketOps’，不同的业务部门或团队会提出请求，例如构建管道或在云中建立服务，”Pikat 说。“随着我们的发展，这变成了一个积压，我们无法及时满足需求。我们实际上成为了组织的瓶颈。”
在查看行业趋势后，Pikat 意识到 AMCS 需要平台工程来实现扩展。
对于 PGS 来说，对平台工程的需求来自完全不同的角度。它在 2018 年开始转向云原生技术时也采用了 DevOps。它发现这赋予了开发人员和软件工程师权力，但在 2020 年，该公司不得不因疫情而裁员。
“由于[IT] 组织留下了大量的系统和服务，而实际维护它们的人力却少了很多，”Bailleul 说。
“这加剧了向云的过渡，因此我们有必要找到一种更好的方法来分配工作负载，以便更多的人参与到实际的机器操作中。这就是我们最终采用平台工程概念的原因，确保我们可以提供一个产品，让组织的其他部门能够使用它来构建和维护 IT 服务，”他补充道。
为什么需要内部开发者门户？
最终，平台工程 是为了确保软件开发过程尽可能高效有效，并提供良好的开发者体验。这就是 GAIG 决定构建内部开发者门户的原因。
“我们希望赋予开发人员权力，并最终推动我们公司盈利能力的提升，”Grafton 说。
Bailleul 解释说，PGS 的第一个平台工程实施是针对Kubernetes的，但由此产生的复杂性导致该公司寻求内部开发者门户。
“它是基于 GitOps 方法的，我们有一堆仓库，人们需要操作这些仓库才能做他们想做的事情。这很棒，效果也很好，但使用它的认知负担太大了。对于那些只想获得命名空间并部署应用程序的人来说，这太复杂了，”他说。
“我们意识到我们需要隐藏这些东西，但构建一个 UI 或一个新产品来抽象这些东西——这不是我们的工作；我们只是使用者。所以这就是我们寻找解决方案来解决这个问题的原因，”Bailleul 补充道。 AMCS 的 Pikat 表示，他们在使用版本控制系统中的常规管道运行自助服务工具方面取得了一些成功，尽管这仅限于简单的场景。对门户的需求很明显，因为平台团队希望建立更困难的自助服务操作并构建企业软件目录，而其他业务部门的其他利益相关者则希望能够查看安全和合规性指标。所有这些项目都可以通过内部开发者门户实现。AMCS 的初步研究集中在 Backstage 上。
“大多数平台工程团队最初都会考虑 Backstage，但首先想到的是复杂性，因为你必须自己处理它，而我们团队很小。因此，在尝试本地运行它之后，很明显我们没有资源去探索它，所以我们转而探索 SaaS [软件即服务] 替代方案，”Pikat 说。
将门户作为产品使用
当 GAIG 决定构建门户时，他们采用了 门户即产品 方法，有效地将开发人员视为客户。
“我们考虑了我们的高级目标、范围以及我们首先要追求的目标。[我们] 真的专注于我们能了解的关于开发人员需求的信息，并收集我们能收集到的所有反馈，[包括] 预先和一路上的反馈，”Grafton 说。
这意味着与大约 20 名团队成员、几位 IT 高管赞助人和各种利益相关者进行会议，以确保 满足开发人员的需求 以及项目与业务目标保持一致。
Pikat 在 AMCS 也采用了同样的方法。
“我们正在为内部人员构建一个产品。你自然会把它当作产品来思考，就像任何其他产品开发团队构建产品一样，使用 scrum 团队、产品负责人和 scrum 主管，以及 sprint。你获得反馈并处理人们提出的低垂果实或请求。然后你发布他们需要的东西，这会逐步增加价值，”他说。
GAIG 还进行了一项 团队拓扑 练习，以绘制组织结构图并了解开发人员团队的工作方式。这包括 UX 团队运行原型人物工作坊，以便那些创建门户的人能够确定开发人员的 UX 需求。
专注于开发人员的痛点和黄金路径
对于 GAIG 的初始门户发布，重点是软件目录中的可发现性和搜索。目标是为开发人员提供一个单一视图，让他们了解所有服务和资源。这是因为他们在范围界定会议中发现，开发人员在了解可用服务方面存在问题，因此过度依赖其他开发人员来查找正确的信息，或者难以从多个工具中拼凑文档。
“我们知道，如果我们能首先解决这些需求，我们将有一个强大的起点，”Grafton 说。初步观察显示 GAIG 已经出现了一些早期效益迹象。
“在一个小的初始控制组中，我们观察到，对于我们的一些开发人员来说，识别谁支持特定服务的耗时从 30 分钟减少到 2 分钟，”Grafton 说。该团队希望他们能够在未来减少开发人员在其他许多任务上花费的时间。
虽然门户即产品方法往往能为获得门户的信任和采用带来最佳结果，但对于构建门户的团队来说，可能有一些更明显的痛点。例如，PGS 团队注意到，尽管拥有大量文档和教程，但开发人员没有办法了解如何做事的最佳实践。
“我们有很多服务，它们以类似的方式构建，但并非完全相同，这造成了很多挫折。因此，在不同产品或服务上工作的团队在兼容性或一致性方面存在问题，”Bailleul 说。
该团队决定，作为拥抱平台工程的一部分，它需要 黄金路径。
“这是做某事的首选方式，一种轻松实现目标的方式，通过将其设为首选方式，你降低了实现目标的门槛。这是我们为所有平台提出愿景的核心基础之一，”他说。
引入内部开发者门户使 PGS 能够使用黄金路径，Bailleul 相信该公司已经开始收获回报。 “当我们开始拥有良好的黄金路径和许多良好的自助操作时，它就成为了一个倍增器。我们看到一些人以前不愿意通过 TicketOps 或创建新事物，现在他们被赋能并能够做到。这对我们组织来说非常棒，可以提高效率并交付更多，”他说。
这种对带有自助操作的黄金路径的认识，也给 AMCS 集团带来了革命性的变化。
“开发团队需要处理很多复杂性，所以[通过]告诉他们去执行创建良好存储库或授予他们访问云资源以进行故障排除等任务，而没有黄金路径，你就是在让他们[选择]在自己的时间内完成这些任务，并且仍然需要交付所有这些东西，”Pikat 说。
这就是为什么 Pikat 想要以一种考虑治理并抽象掉复杂性的方式来实现自助服务。为此，他们实施了简单的自助服务表单，开发人员需要填写这些表单才能获得访问权限或采取行动，这提供了带有内置黄金路径和护栏的自主权。
“我们不仅可以让人们以直观的方式获得他们想要的东西，并将涉及多人的 85 分钟任务缩短到[自己]在 5 分钟内完成，而且我们可以在晚上安心地知道他们会遵循我们为他们设计的黄金路径。我们不会违反任何规则；我们不会在我们的版本控制系统中错误的项目中创建 Git 仓库；他们不会忘记添加我们要求的分支策略，等等，”他说。
收集反馈并迭代
GAIG 团队在将门户网站推广到更多团队时，一直在收集反馈。软启动涉及大约 50 名应用程序开发人员的小团队，以获得初步反馈，GAIG 在将门户网站再次推广到大约 300 名开发人员的更广泛群体之前，将更改合并到门户网站中。
对于 AMCS 来说，其内部开发者门户的反馈非常积极。
“我们从利益相关者那里听到的第一条也是最常见的反馈，这些利益相关者不一定是开发人员，[也包括]支持、专业服务和整个工程社区，就是他们完成任务和工作的速度有多快。他们非常喜欢它，因为它可以立即让他们能够使用，”Pikat 说。
“这也让我们为自己的工作感到自豪，因为帮助同事提高工作效率，成为团队的驱动力，并帮助企业发展，这是一种非常棒的感觉，”他补充道。
在 PGS，许多在他们的门户网站第一个版本中加入的开发人员都经历过手动 GitOps 流程的痛苦。
“他们进入门户网站，对它变得多么简单感到震惊，”Bailleul 说。
同时，使用门户网站的第二波开发人员没有任何抱怨，Bailleul 解释说，这本身就意义重大。
“当你的团队使用新服务并且你没有收到任何负面反馈时，你就知道它有效，你做得很好，”他说。
该公司比较了票证和自助服务操作之间的平均故障时间 (MTTR)，Bailleul 说，差异“非常令人印象深刻”。
现在，使用所有三个组织门户网站的开发人员和其他利益相关者都在询问它还能做些什么。他们还提出了关于新想法或功能的建议，以使门户网站对组织的影响更大。
