Netflix是如何利用联合平台控制台统一工程体验的

摘要

为了解决开发人员在日常工作中，面对工具和服务碎片化所带来的效率下降，Netflix 的 Brian Leathem 团队开发了一个联合平台控制台，统一了开发人员的工程体验。

本文最初发表于Platform Engineering网站，由 InfoQ 中文站翻译分享。

大多数开发人员的日常工作都是低效的，主要是因为他们在构建、运行和扩展应用的时候，会使用数十种碎片化的服务和工具。这种低效在无意间会导致生产力的损失。对于小公司来说，碎片化的开发体验或许是可容忍的，但是随着业务的增长，统一它们的需求也会不断增长。

在 Brian Leathem 的带领下，Netflix 的开发人员很早就采用了微服务架构，但是随着平台工具的增加，他们发现这种方式过于琐碎，于是，他们需要在公司的软件开发生命周期 Software Development Life Cycle（SDLC）中统一开发人员的体验。在 PlatformCon 2022 上，Brian Leathem 分享了如下的经验。

为了在 Netflix 的 SDLC 中统一开发人员体验，Netflix 的平台体验和设计（Platform Experiences and Design，PXD）团队决定建立一个联合平台控制台（federated platform console）。Netflix 的联合平台控制台是一个一站式的商店，提供了工程师开发和部署软件需要的所有工具。它将开发人员使用的几十种服务和工具整合到一个单一的、易于使用的界面中。

通过这个控制台，Netflix 希望能够解决在与开发人员访谈时所发现的主要的碎片化挑战，其中包括：

1.管理多个服务和软件

开发人员每天都要使用太多的工具了，这给开发、交付以及运维服务和软件带来了挑战。例如，在整个 SDLC 过程中，开发人员需要分别使用 Bitbucket 来审查 pull request，Spinnaker 来检查部署流水线，Jenkins 来检查构建失败，并且使用内部告警度量工具来检查运维状态等。除此之外，他们可能需要多次重复这些工作流程。

2.平台发现

Netflix 的产品服务所有者已经为开发人员创建了工具和文档，但是很多开发人员不知道这些工具的存在。所有开发人员都无法立即知道他们的团队正在使用的众多工具和文档，他们可能会发现自己依赖于团队内传递给新成员的部落知识（tribal knowledge，这里指的是只有部落内部成员知道的信息，部落外面的人所不知道的知识，也就是所谓的小圈子——译者注）。另一方面，工作时间比较久的开发人员可能不知道为改善他们的日常工作流程而增加的新工具。

3.在不同工具之间切换上下文

当开发人员需要使用多个服务和工具时，他们需要在它们之间进行上下文切换。这可能会导致效率低下和错误，因为开发人员切换到另外一个工具时可能会忘记他们在当前工具中的工作。

Netflix 的 PXD 团队很清楚，开发人员能够从一个平台控制台中获益，该控制台可以作为一个共同的入口，让他们能够从一个统一的地方来查看和评估其服务的状态，并且可以作为一个启动点，从中能够发现和访问用来管理服务的必要工具。

控制台平台的初始理念

PXD 团队希望利用他们在 Netflix Studio 部门中 GraphQL Federation 的成功经验来建立控制台的后端架构。GraphQL Federation 允许用户建立一个领域图服务（domain graph service，DGS），将其服务作为单个联合图的一部分对外进行暴露，这个联合图可以被一个联合图网关来访问。当网关处理请求时，它会委托对应的 DGS 来完成该请求中引用的所有字段。

该团队对基于 GraphQL 平台 API 的投资不仅可以为新的平台控制台提供动力，还可以为其他体验提供支持，包括更专用的 UI、CLI 和 Slack bot。

对于前端，平台体验和设计团队希望跨多个平台团队和服务提供联合方案，这些服务会在平台控制台中汇聚在一起。他们知道，这项工作的范围不是一个团队可以实现的，需要利用领域的专业知识，以及平台、供应商和合作伙伴的代码贡献。

利用 Netflix 内部的设计系统 Hawkins

PXD 的第一站是 Netflix 的内部设计系统 Hawkins，它有 80 多个应用。这些应用为 Netflix 的内容生产提供了支撑，其范围涵盖从初始评估，到财务预测以及资产交付。在所有的平台产品中使用 Hawkins 可以实现更多的跨工具工作流，并为用户提供一致的体验。

按照设计，Hawkins 是可重用、可配置和可组合的，它为套件中的所有应用提供了一致的用户体验，降低了用户的学习曲线。它允许工程师重用组件、工具集和设计模式，这提升了效率，同时降低了成本。

调查现有的开源和专有方案

Leathem 的团队并不想直接开发另一个开发人员门户和服务目录，并将其置于他们的平台之上。相反，他们首先评估了可以解决这个问题的开源和专有工具，他们基于终端用户和平台合作伙伴供应商的需求和期望来考虑这些工具。团队最终确定 Backstage 是最适合其使用场景的工具。

Backstage 是 Spotify 的开源开发人员门户，基于如下原因，它非常适合该团队：

• Backstage 在前端和后端之间实现了松耦合，允许团队轻松整合现有的后台解决方案，包括联合 GraphQL。
• Backstage UI 技术与 PXD 的专业技能非常契合。
• Backstage 的插件是轻量级的。

对比使用 Backstage 与重新构建一个开发人员门户

使用 Backstage（现有的开源工具）与构建一个定制的内部解决方案相比，好处在什么地方呢？为了回答这个问题，PXD 根据其功能和各自的要素进行了评估。借助 Wardley Map，它们评估了将开发人员资源投入到从头创建一个内部工具，或基于 Backstage 进行构建，以确定哪个方案更好。

“我们确定了系统的各个组件，根据它们对最终用户体验的影响程度对其进行纵向定位，并根据它们在行业中的商业化程度进行横向定位。组件被分解成组件，抽取出已经被商业化的组成部分”——Brian Leathem

Wardley Map 是一种可视化技术，它将组织的开发速度与价值链进行对比，并形成自定义 UI 组件对商业成功关键程度的见解。该团队发现，最关键的增值部分是自定义 UI 组件，这些组件是通过明确每个平台的特性、功能和特征而形成的。他们意识到，与其重建 Backstage 上的插件和核心 API，不如将开发资源投入到创建自定义 UI 组件上。

通过联合平台控制台 MVP 的提供连接体验

开发平台控制台 MVP（最小化可行产品，Minimum Viable Product）的最初目标是建立一个具有共同入口的连接体验，让开发人员在整个 SDLC 中查看和访问项目的状态，然后链接控制台中现有的工具。计划随着的时间推移有了新的变化，将控制台从连接体验升级为集成体验，并最终升级为一个平台，让组织所有的周边工具得到全面管理。

在设计和开发这些插件时，团队很谨慎，没有简单地将现有的经验提升并转移到控制台中，而是利用这个机会重新思考用户从数据中所获取的经验和价值。为了解决管理多个服务软件的问题，他们引入了集合的概念。有了集合，用户可以将服务进行分组，一起查看和评估它们的状态。

Paved Roads 通过一个中心化的产品仓库和组织框架，协助工程师为特定的问题找到合适的工具，在产品知识和工程过程之间搭起了桥梁。

控制台还包括为集合中的服务启动批量突变（bulk mutation）的能力，这个概念在 Netflix 的任何其他平台工具上还不存在。为了解决平台和工具的发现问题，Leathem 和团队想出了 Paved Roads 这个概念，旨在将产品文档集中到一个地方，并且它们的组织方式能够帮助工程师找到解决其挑战的最佳工具。

用户采用和反馈

PXD 团队一直在不断地推出 MVP，让它出现在 Netflix 的工程师面前。MVP 已经达到了提供最小价值特性集的目标，用户可以用它来查看和评估软件的状态。然而，团队通过用户反馈和新的研究发现，仅靠这种综合功能还不足以吸引开发人员，并打破他们围绕现有工具的既定常规思路和习惯。

因此，该团队正在研究将控制台插入现有的工作流程或完全创建新的工作流程，以推动用户使用该平台。他们还希望用新的功能来丰富控制台，希望用户能够围绕平台控制台形成新的常规思路和习惯，并有机地将其添加到他们的工具链中。

总结

以下是 Brian Leathem 在虚拟 PlatformCon 2022 会议上分享的主要内容总结：

• 联合平台控制台有助于统一 Netflix 的工程体验，为开发者提供一个共同的入口来查看和访问他们在整个 SDLC 中的项目状态。
• Brian 和他的团队创建的平台控制台 MVP 已经达到了提供这种最小价值特性集的目标，用户可以用它来查看和评估其软件的状态。
• 该团队正在考虑将控制台插入现有的工作流程或完全创建新的工作流程，以推动用户使用该平台。他们还希望用新的功能来丰富控制台，希望用户能围绕平台控制台形成新的常规思路和习惯，并有机地将其添加到他们的工具链中。
• 该团队承认，仅仅整合功能是不够的。为了成功，平台控制台必须被整合到现有的工作流程中，或者创造出对开发人员来说有足够价值的新工作流程，以打破他们既定的常规流程。