采用战略

本文档概述了 Backstage 在 Spotify 内部取得成功的一些通用最佳实践。 每个公司的情况都不尽相同，因此其中一些经验并不适用于贵公司。 我们希望本文档能够成为一份有生命力的文档，并强烈建议您将在公司内部采用 Backstage 时收集到的任何经验反馈给我们。

组织结构

当 Backstage 变得_这_个因此，重要的是要认识到您需要一个中心团队来管理Backstage部署，并将其视为产品。

该团队将有四主要目标：

1.维护和运行您的 Backstage 部署，包括客户支持、基础设施、CI/CD，以及随着 Backstage 产品的发展，提供随叫随到的支持。 2.推动客户(贵公司的开发人员)采用 Backstage。 3.与高级技术领导层和架构师合作，确保贵公司的软件开发最佳实践被编入一套 软件模板。 4.向其他基础设施/平台团队宣传 Backstage 作为中心平台的优势。

内部布道

最后一个目标值得更多关注，因为它最不明显，但也是成功创建整合平台的最关键因素。 如果做得好，Backstage 就会成为 "平台中的平台 "或信息/平台团队与最终用户之间的市场：

虽然贵公司的任何人都可以为平台做出贡献，但绝大多数工作都将由以内部工程师为客户的团队完成。 中心团队应将这些工作视为贡献团队也是该平台的客户。

这些团队应该能够自主地直接为客户提供价值。插件贡献团队本身应将其插件视为其维护的产品或产品的一部分。

案例研究：在 Spotify 内部，有一个团队拥有我们的 CI 平台。 他们 > 不仅维护管道和构建服务器，还通过一个插件在 Backstage 中 > 公开他们的产品。 由于他们还 > 维护自己的 API，他们可以通过在 API 和 UI 上同步迭代来改进他们的产品。 由于该插件 > 遵循我们的 平台设计指南，他们的客户获得了 > 与平台上其他工具一致的 CI 体验(而且用户 > 无需成为 Jenkins 专家)。

战术

我们用于在内部宣传 Backstage 的策略范例：

• Arrange "Lunch & Learns" and seminars. Frequently offer teams interested in Backstage development to come to a seminar where you show, for example, how to build a plugin from scratch. * Embedding. As contributing teams start development of their first plugin it is often very appreciated to have one person from the central team come over and "embed" for a Sprint or two. * Hack days. Backstage-focused Hackathons or hack days is a fun way to get people into plugin development. * Show & tell meetings. In order to build an internal community around Backstage we have quarterly meetings where anyone working on Backstage is invited to present their work. This is not only a great way to get early feedback, but also helps coordination between teams that are building overlapping experiences. * Provide metrics. Add instrumentation to your Backstage deployment and make metrics available to contributing teams. At Spotify, we have even gone so far as to send out weekly digest emails showing how usage metrics have changed

关键绩效指标和衡量标准

您可以使用这些指标来验证 Backstage 是否对您的软件开发流程产生了成功的影响：

• Onboarding time Time until new engineers are productive. At Spotify we measure this as the time until the employee has merged their 10th PR (this metric was down 55% two years after deploying Backstage). Even though you may not be onboarding engineers at a rapid pace, this metric is a great proxy for the overall complexity of your ecosystem. Reducing it will therefore benefit your whole engineering organization, not just new joiners. * Number of merges per developer/day Less time spent jumping between different tools and looking for information means more time to focus on shipping code. A second level of bottlenecks can be identified if you categorize contributions by domain (services, web, data, etc). * Deploys to production Cousin to the metric above: How many times does an engineer push changes into production. * MTTR With clear ownership of all the pieces in your microservices ecosystem and all tools integrated into one place, Backstage makes it quicker for teams to find the root cause o

此外，这些代理指标还可用于验证Backstage是否成功，因为我是说______________________。平台：

• 至少贡献了一个插件的团队数量(目前 Spotify 内部有 63 个) * 插件总数(目前 Spotify 内部有 135 个) * 来自Backstage中央团队以外贡献的百分比(目前 Spotify 内部有 85%) * 访问量(MAU、DAU 等)和页面浏览量等传统指标。 目前约有 50% 的 Spotifiers 每月使用Backstage，尽管工程师的比例低于 50%。 大多数工程师实际上每天都使用Backstage。

请使用页面底部的 "编辑 "按钮提出建议。

_*注意！ 尝试优化 Backstage 的使用和 "参与 "可能很有诱惑力。 即使你想把所有工具和技术文档都整合到 Backstage 中，也必须记住，花在 Backstage 中的时间并不是用来编写代码的时间。🙃