Backstage听起来不错，应该从哪里开始呢？

作者：Austin Lamon，Spotify

Backstage 最大的优点之一也带来了无休止的挑战：Backstage 是高度可定制的，允许你轻松构建适合组织需求的独特开发人员门户。这种灵活性的缺点是很难知道从哪里开始。Backstage 可以做很多事情——整合你的技术基础设施和开发人员经验的每个部分——但如果你开始构建一个开发人员门户没有一个计划，很容易被所有的可能性所淹没。为了帮助你形成你的计划，这篇文章将详细介绍 Spotify 是如何设计我们的内部门户的，并为你在设计和构建自己的门户时推荐潜在的模型。

作为科技文化的基础设施

在提供关于如何开始使用 Backstage 的建议之前，先了解一下为什么 Spotify 会做出我们所做的设计决定。没有两家公司是相同的——因此，没有两个 Backstage 的实现是相同的。

时光倒回几年前，Spotify 面临的挑战[1]是继续扩大我们的工程团队（以及创建的功能和组件的数量），但保持产品开发的速度。与 Spotify 开发者进行的一些用户研究突出了一个明显的问题：完成工作需要太多的非文档化的机构知识。没有人能找到任何东西，每个人都在打断别人，试图弄清楚事情。

Spotify 的开发者每天都面临着三大挑战：

• 他们不仅需要快速构建软件，还需要向新参与者传递关于如何最好地创建新组件的知识。
• 他们需要以某种方式维持团队拥有的系统的心理模型。（或者，如果他们幸运的话，他们发现了一个跟踪这一信息的最新电子表格。）
• 他们需要关注他们周围的团队可能正在构建什么，以确保在将来需要解决类似问题时能够重用系统。

简而言之，Spotify 的开发者需要继续以极快的速度构建行业领先的功能，同时保持 Spotify 所有软件的心理模式（噢，还要帮助每一个新加入者也开发这种心理模型！）。

三个工作：创造、管理、探索

大约在同一时间，要完成的工作[2]框架变得流行起来，幸运的是，一些 Spotifiers 帮助引导开发人员使用有意义的工具的愿景。在用户研究和多次失败的尝试之后，我们找到了三种 Spotify 开发者需要持续做的工作：

• 创造（Create）：Spotify 的开发者想要用令人难以置信的功能取悦他们的客户。他们为此开发了新软件。
• 管理（Manage）：Spotify 的开发者对他们的工作感到自豪，他们把自己的软件和数据当作产品来对待。这需要持续维护他们拥有的所有软件。
• 探索（Explore）：Spotify 的开发者希望解决新的、但尚未解决的问题。他们试图基于现有的系统来帮助他们做到这一点。

所以：制作软件，在软件的生命周期中维护自己的软件，并与他人的软件集成。

在当今复杂的开发环境中，有大大小小的障碍阻碍着这三种工作。Backstage 提供了消除这些障碍的构建模块，简化开发周期，让开发者做他们真正想做的事情：构建伟大的特性。让我们仔细看看这些工作。

创建

工作描述：你是一名工程师，准备开始构建一个新的微服务。你只是选择你想要的框架吗？如何预留能力以在生产中运行服务？那么管理 CI/CD 呢？

工具：在 Spotify，我们使用 Backstage 软件模板来简化所有这一切，只需点击几下就能缩短运行“Hello World”的时间。你不需要研究 Spring Boot 和 Helidon，打开 Jira，翻找文档，配置 CI 自动化，你只需要选择一个模板，你的项目就会自动在仓库中设置好，CI 已经在运行你的第一个构建。

结果：通过使开始新项目变得更容易，你的工程师能够更快地编写功能的优秀部分。你的组织的最佳实践被构建到模板中，鼓励标准和降低技术生态系统的复杂性。

管理

工作描述：你在一个拥有十几项服务的小团队中。当你更新和部署这些服务时，你会在 CI、AWS 控制台、安全仪表板和 CLI 之间切换，这样你就可以尝试找出你的服务最终在哪个 Kubernetes 集群上。换句话说，你有很多打开的窗口和标签，每一步都意味着切换到一个新的界面。

工具：所有团队的软件组件都被组织在 Backstage 服务目录的一个页面上。从那里进入任何服务的页面，它的 CI/CD 状态、Kubernetes 部署状态[3]、文档、安全检查——以及所有与该服务相关的东西——都被组合在一个无缝的界面中，只显示你想要的信息。

结果：在 Backstage 的一个页面有你需要管理你自己的软件的一切。没有更多的上下文切换。不再需要挖掘云提供商的模糊的管理特性。在仓库和你的 IDE 之外，你需要管理你的服务的一切都在 Backstage。

探索

工作描述：你正在构建一个新的移动功能，该功能需要确保用户为你的产品的高级版本付费——但一定有人已经建立了一个处理该功能的库，对吗？一封全公司范围的电子邮件和几个求助 Slack 的电话都没有得到回应，所以你只好自己去建立这个功能。看来你需要的库确实是有人建的。他们只是在度假，所以没看到你的信息。如何在整个组织中实现更好的发现和协作？

工具：在 Spotify，任何人都可以找到其他人的软件-因为一切都集中在 Backstage，通过 Backstage 服务目录组织和搜索。访问任何库或服务页面，你将找到所有者和文档，甚至它的 API，以及如何在需要时扩展它。

结果：在一个地方放所有东西，在一个地方搜索。开发人员可以更轻松地共享组件，在彼此的工作之上进行构建，并发现工具、库、框架、文档、系统设计、组织结构图等。

听起来不错。我从哪里开始呢？

在与那些已经采用了 Backstage 的公司交谈之后，我们看到了一些常见的起步策略。不同的策略是基于你的工程组织的规模（这通常也与你的发展速度相对应）。

我的组织有大约 200 名工程师（并且正在快速增长）

组织已经足够大，可以开始感觉到疼痛，而且只会越来越大。入职和发现是你最大的挑战。

难点：

• 这种规模似乎是引爆点——复杂性开始占据主导地位，协作开始瓦解，临时解决方案停止工作。
• 通常情况下，这也发生在公司发展非常迅速的时候（公司规模每 6-12 个月翻一番），以至于新工程师的数量超过了老工程师的数量。
• 新工程师找不到任何东西，所以他们四处打听，这就把你所有的其他工程师都拖离了任务。
• 僵局的形式。一家公司告诉我们，合并拉取请求需要 3-4 天。

推荐——探索，然后创建：

• 新工程师需要一种简单的方法来发现如何做事情，所以你不只是增加实体，你是增加快乐的，有生产力的贡献者。
• 为了简化入职流程，首先要集中你的文档，并使你的工具和软件组件可以在 Backstage 发现。
• 在这种规模下，你可能还没有一个专门的平台/基础架构团队，但是 Backstage 可以提供集中和共享知识的框架——从管理法规遵从性需求到找到正确的 API 文档。
• 这使得新旧工程师可以更有效地协作，更容易地发现最佳实践，并减少重复工作（例如，一个新的团队不会重新构建一个已经存在但没人能找到的数据库）。

我的组织有大约 1000 名工程师

组织大。越来越多的团队正在管理着越来越多的软件——而在各种各样的工具之间切换所带来的挫折感正呈指数增长。

难点：

• 碎片化和熵化是对生产力的真正威胁。从安全需求到集群管理再到一千个数据端点，需要跟踪的数据太多，导致认知超负荷。
• 千刀万剐：不断地登录到新的界面——从云提供商的控制台到一些全新的安全工具，然后再回到 CI/CD——会因为太多的上下文切换和大量的噪音而让工程师陷入困境。
• 每一天，一个团队管理自己的微服务、数据和文档都变得越来越困难，更不用说与其他团队分享他们的知识了。

推荐——管理，然后探索，然后创建：

• Backstage 将允许你的团队处理他们拥有的软件，因为他们需要管理的一切都在一个地方。
• 从 CI/CD 状态，文档到解密某仓库，Backstage 使到日常很容易管理服务（或其他软件组件）。
• 服务目录还可以帮助开发人员可视化现有的软件生态系统，而不仅仅是他们拥有的软件。使用 Backstage 软件模板，每个新的软件组件都已经添加到目录中。
• 即使是在这种规模下，一个小型平台团队也能够创造并维护你自己版本的 Backstage。在 Spotify，我们有一个 4 人团队负责 Backstage 的内部版本，所有 Spotify 的 1600 多名开发者都使用这个版本。

我的组织有超过 1000 多名工程师

集成如此规模和复杂的基础设施似乎势不可挡。将这种程度的改变带给一个拥有根深蒂固流程的成熟文化是一个更大的挑战。

难点：

• 当你这么大的时候，你已经整合了很多技术和流程，以及很多合作伙伴，每个合作伙伴都有自己的技术和流程。
• 你关注的是“替换杂项”，为你庞大的组件和工具生态系统带来可发现性和秩序。
• 让你的工具被你的工程师采用，同时现代化你的技术堆栈，并与你的基础团队协调，以改善整个公司的工程实践……这是很多。

推荐——创建，管理，然后探索：

• 给你的生态系统带来改变的最快方法是从 Backstage 软件模板开始。
• 通过使用模板创建每个新组件，你正在建立最佳实践，并以关注于开发人员需求的流线型体验来奖励开发人员——与此同时，你一直在构建新的服务目录。
• 模板越能简化启动项目的过程，你的工程师就越会采用它们，Backstage 的其他好处也会建立得越快，从而在整个组织中转化生产力。（我们在 Spotify 是这么做的[4]。）

还有关于采用 Backstage 的问题吗？

联系 Spotify 的 Backstage 团队[5]。我们将分享更多我们从 Spotify 的经验中学到的东西——以及从其他已经在使用 Backstage 来改变他们的开发者体验的公司中学到的东西。

参考资料

[1]

Spotify 面临的挑战: https://engineering.atspotify.com/2021/05/18/a-product-story-the-lessons-of-backstage-and-spotifys-autonomous-culture/

[2]

要完成的工作: https://hbr.org/2016/09/know-your-customers-jobs-to-be-done

[3]

Kubernetes 部署状态: https://backstage.io/blog/2021/01/12/new-backstage-feature-kubernetes-for-service-owners

[4]

我们在 Spotify 是这么做的: https://open.spotify.com/episode/7iuQ3ew1Wwpuiq6LbBKzCl

[5]

联系 Spotify 的 Backstage 团队: https://calendly.com/spotify-backstage