平台工程 | 内部开发者门户权威指南

本系列文章译自 https://www.getport.io/blog/guide-to-internal-developer-portals ，全文共 7 个小节，首发于公众号“数理话”。

内部开发者门户权威指南

1. 平台工程概述

2. 内部开发者门户驱动平台工程

3. 内部开发者门户是什么？谁需要它？

4. 优秀平台工程实践的 5 大原则

5. 打造内部开发者门户

6. 内部开发者门户的价值

7. 开发者门户的未来

平台工程逐步成为一个核心的关注点，其任务是确保良好的开发者体验，以提高生产力并持续维持。要做到这一点，内部开发者门户已经成为一项基本要求。本文介绍了建设内部开发者门户的理由和具体方式，以及它们如何影响开发者体验和生产力。

01. 平台工程概述

现代应用程序开发的速度越来越快，但同时复杂性也越来越高，包括微服务、容器和不同的 DevOps 工具及云服务供应商。今天，即使是 DevOps 领导者，在管理工程化运维方面也面临诸多挑战。

“我们有 GitHub、Jenkins、Jfrog Artifactory 和 DataDog 作为基础工具，还有各种构建和安全工具，如 blackduck 或 snyk，以及多个云服务供应商等等。你可以通过一个购物车服务就贯通我们的整个流程并体验 DevOps 工具。开发人员不可能掌握所有这些工具，没有人可以做到。”（Shlomi Benita，CyberArk）。

这就导致人们越来越关注开发者体验和平台工程。

Gartner 表示，“平台工程通过自动化基础设施运维实现了可重用工具和自服务能力，提高了开发者体验和生产力”。它使用可重用可配置的应用程序组件和服务，对用户的好处在于标准化的工具、组件和自动化流程。

这就意识到，糟糕的开发者体验和基于“工单运维”的开发者 DevOps 交互是不可持续的。在某种程度上，部署代码的能力下降、生产力下降以及开发人员的沮丧情绪的代价变得太高了。

“能让正式管理层能够在内部开发平台上工作的最大卖点之一是，用图表呈现变更耗时走势。我们展示了没有 IDP 的变更耗时以及有 IDP 的变更耗时。随着时间的推移，我们预估出：没有 IDP，变更耗时会变得更糟。这使得管理层信服。”（Shlomi Benita，CyberArk）。

或者，正如 Gartner 副总裁兼分析师 Paul Delory 所说：“平台工程的出现是为了应对现代软件架构日益复杂的情况。如今，非专业的最终用户经常被要求操作一组复杂玄妙的服务。为了帮助最终用户，减少他们做有价值工作过程中的摩擦，具有前瞻性的公司已经开始构建运维平台，这类平台介于最终用户和他们所依赖的后端服务之间”。

02. 内部开发者门户驱动平台工程

平台工程实践的第一步是内部开发者门户。正如 Gartner 所解释的：“IDP 提供了一套精心设计的工具、功能和流程。它们由主题专家选择并打包，以供开发团队轻松使用。其目标是一种无摩擦、自服务的开发者体验提供了正确的功能给开发者和其他人，使其能够以尽可能少的开销生产有价值的软件。该平台应在提升开发者生产力的同时减少认知负荷；也应当包括开发团队所需的一切，并以最适合团队首选工作流的方式呈现”。

平台工程的另一个问题是，一些开发者也缺乏在“谁创建，谁拥有”的世界中茁壮成长所需的基本知识。例如，当从单体或企业定制产品演进时，就是这种情况，这对开发人员来说并非易事。在这种情况下，内部开发者门户允许开发者以自服务模式使用 DevOps 资源，并提供产品级的使用体验，还为他们提供所需的基础防护。

IDP 还通过提供可以减少开发人员认知负载的抽象层，大大减少了 DevOps 和开发团队的日常负载。当一切都被抽象掉时，所有开发者需要关心的就是编码、Git 和使用 IDP 中的自服务功能（然后它将与 DevOps 正在使用的任何工具通过接口集成，从 K8S 到 Git、Terraform、Jenkins 等）。‍

03. 内部开发者门户是什么？谁需要它？

根据 Puppet 的 DevOps 现状报告（译注：现已升级为 DevOps 现状报告平台工程版），内部开发者平台是让成熟的工程组织与众不同的三大举措之一（另外两个是集成安全和自动化变更管理）。

什么是成熟的工程组织呢？这取决于你所在的组织，可能是一个棘手的问题。不过，让我们从工程团队的规模考虑，看看组织的规模如何影响开发者体验、开发者生产力以及开发者和 DevOps 密切合作的能力。根据下述图示，该图描绘了工程组织规模和使用开发者自服务工具的需求之间的关系：

组织越大，就越可能需要一个内部开发者门户（尽管成熟度不一定等于组织大小…）：

• 有 1~30 名员工时，一切正常。如果开发人员懂运维，他们可以自运维；如果他们不太懂，DevOps 可以很容易地为他们服务。无论如何，大部分需求都可以通过与同事在喝杯水的功夫交流或者获取内部知识库的帮助来得到解决。

• 拥有超过 100 名员工的组织通常可以采用 GitOps、直接使用开发工具等，也可以采用健康适度的工单运维。这不是最优但仍然可以工作。你可以在这里阅读这方面的内容。

• 在某些时候组织使用诸如 Jenkins 之类的 CI 工具来实现开发者自服务，但这些解决方案在规模化使用时往往容易崩溃。

• 超过 1500 名开发人员？除了内部开发者平台之外的任何解决方案都不起作用，无论是自建还是采购。

‍合规也是复杂性的重要驱动因素，因为比如 SOC2 需要对基础设施进行适当的权限管理。这可能会导致更多的工单。

但建设内部开发者门户的原因不止是组织规模。内部开发者门户网站在质量和数量上都有其价值。

要想成功，你需要有一个 IDP。我们是一家大公司，并非所有的开发人员都“懂”云。如果我们告诉他们“这是云，以及所有相关配置，使用云 SDK，使用这些 API 吧”，他们将不知道该怎么办。所以这不仅仅是教育培训问题，它还涉及到拥有一个平台及其内部的防护措施。（Guy Brodny，CyberArk）

04. 优秀平台工程实践的 5 大原则

内部开发者门户应当通过消耗 DevOps 资产，为开发人员提供满足其基础设施需求的自服务能力；还应该能够搭建、部署、浏览、操作及访问所有应该提供给他们的服务。

以下是要遵循的五个原则：

#1 产品级体验与解耦

‍在 IDP 中，开发人员应该获得基于 UI 且易于使用的类似产品级的体验，表单也应该清晰易用。IDP 中的工具应该与基础设施解耦，以便在不改变开发者体验的情况下更改基础设施。

#2 合规与安全设计

使用平台工程工具应当确保并支持合规、测试、质量和安全性。这包括基于角色的访问控制，以及在必要时添加手动审批的能力。

#3 中心化

‍开发人员应当访问一个中心化的入口，包含文档、工具、标准、模板、基础设施和云资源。视图应反映组织内管理的不同 DevOps 资产的实时状态，并可由团队/开发人员自定义。所有开发人员都应该根据自己的角色访问该系统，因为它包含了整个工程领域的 DevOps 状态。

#4 支持最广泛的自服务

自服务应该不局限于微服务脚手架，并提供开发人员需要做的任何事情：在你所设置的策略和防护范围内，对软件目录中暴露出来的任何资产（无论是否为微服务）进行供应、终止和执行 Day-2 操作。

#5 API 优先

机器人也应该拥有类似于呈现给人类用户的 IDP 接口的访问权，以便可以触发 DevOps 流并能够访问 DevOps 自动化流程及流水线的相关软件目录数据。

05. 打造开发者门户

内部开发者门户在工程组织中各不相同 —— 这取决于开发人员需要抽象的领域、代码库、DevOps 团队的需求、开发人员背景（他们是否习惯于基于云的微服务，或者他们是否在内部单体架构上工作），以及工程文化、流程以及使用的工具。不过它们也有许多共同点。

初始的定义是，平台就是提供一个抽象层（通常称为软件目录），并具备开发人员对目录中呈现的资产执行自助操作的能力。

软件目录旨在为复杂的 DevOps 相关问题提供简单的答案，这些问题通常需要开发人员在数十种不同的工具中穿梭，并需要有深度的内部知识库。

自服务是为了减轻 DevOps 和开发团队的负担。内部开发者平台使所有人都可以使用工具、服务和知识，从而将它们释放到代码中。IDP 应具有基于角色的访问控制能力，以根据工程师的角色提供对数据的合法访问。

以下是三个主要部分：

5.1 软件产品目录

软件目录应该远不止是微服务目录，其复杂性在于基础设施中会有多个实体。

软件目录是基础设施及其上部署的软件的可视化呈现。理想的软件目录应该显示 SDLC 相关的整个生态系统：CI/CD 流、开发环境、流水线、部署和所有云资源。

软件目录需要回答的主要问题是“在哪里部署了什么”，而目录的结构取决于回答这个问题所需的内容，该问题因组织而异，甚至可能随着时间的推移而改变。

软件目录应帮助工程团队快速回答以下问题：

• 给定服务在生产环境当前运行的是什么版本？

• 谁负责这个微服务，它公开了哪些 API 路由？

• 哪些 Kubernetes 集群存在于哪个云环境中？

• 为什么这次部署失败了？

• 谁在值班？

• 这个版本准备好发布到生产环境了吗？

• 给定团队、服务或开发人员的 DORA 指标

‍‍

由于回答这些问题也是“在哪里部署了什么”以及“什么”和“哪里”的相对复杂性的函数，因此软件目录并没有理想态的结构。

让我们来看一个常见的案例，比如需要（1）服务、（2）环境、（3）部署的服务和（4）部署的统一视图。在这个案例中，有了这 4 个元素，就能清楚地了解每个服务的成熟度和就绪情况，并能详细了解每个服务从第一次提交到跨不同环境运行的多个部署的完整生命周期。我们看看这个案例中的相关定义。

服务

服务可以是微服务、单体架构软件或者任何其他架构的软件。

环境

环境包括任何生产、预发布、测试、开发、按需定制或任何其他环境类型。

部署的服务

部署的服务是指一个运行在特定环境中的服务的当前“存活”版本的表示。它将包括对服务、环境和部署的引用，以及状态、正常运行时间和任何其他相关元数据等实时信息。

部署

部署可以被描述为表示一个 CD 作业的对象。它包括已部署服务的版本和指向作业本身的链接。与其他对象不同，部署是软件目录中不可变的一项。保持不可变性至关重要，旨在确保目录可以保持一致的真实来源。

然而，在某些情况下，根据环境的不同，回答“在哪里部署了什么”的问题可能要复杂得多。让我们看看这个需要映射的环境，除了（1）服务、（2）环境、（3）部署的服务和（4）部署这 4 个元素之外，还有以下元素：（5）命名空间（6）集群（7）云服务帐户，以及（8）系统和（9）产品单元。在这种情况下，回答问题需要基于所有 9 个元素的映射。

软件目录应该是实时动态的。一旦你定义好了基础，软件目录就会与你的开发生命周期集成，即时提供你需要的数据（K8S 导出组件、Terraform、GitHub 应用、Jenkins 等）。它还应该具有最小的基础设施消耗，并在自服务 UI 界面和底层基础设施之间实现完全解耦；另外还需要一个显示依赖关系的视图。

5.2 基于构建者模式的方法

不同的组织有不同的需求和架构，因此，他们需要不同的软件目录来可视化呈现他们的 SDLC 。

建议从软件目录资产的模式定义开始，这样可以很容易地构建目录。模式是基本的构建单元 —— 蓝图，它表示可以在内部开发者门户中管理的资产：

• 微服务

• 环境

• 包

• 集群

• 数据库及其他

蓝图支持任意数量的属性，并且通常包含你想要管理和跟踪的基础设施的组件和属性。如上图所示，它们是映射“在哪里部署了什么”视图中需要映射的内容的唯一方法。在下一步中，将创建映射到蓝图模式的实体。

想象一下，将 Kubernetes 数据映射到实体，以形成软件目录，并将数据放入相关实体中。你可以管理运行中集群的表示，查看包含所有命名空间的表，并查看在每个命名空间中部署了哪些服务。另一个案例是跟踪身份验证和授权资源。你将能够看到服务帐户（Pod 中运行的进程的标识），以及使用它的 Pod 以及相关规则和策略。

‍

5.3 自服务的重要性

Gartner 在其“软件工程领导者改进开发者体验指南”报告（需要订阅）中强调了开发者自服务的重要性：“开发者自服务有一个天生的好处，那就是为原本不同的流程和容易出错的手动切换带来一致性和可重复性。自服务的目标是，确保开发者拥有‘做正确的事情、直观的事情’的体验。例如，通过自服务预审来自受信任的组件目录中的开源库的能力，就提升了治理能力以及开发者体验。”

成功的关键是使用产品思维 —— 内部开发者门户应该同样易于使用，并考虑到任何软件产品的“普通”用户的用户旅程。这意味着开发人员应该很容易自助服务，但应该以更有用的方式进行抽象，帮助开发人员做出正确的决策。

在这方面，很重要的是确保自服务扩展到微服务脚手架之外，并允许开发人员在组织内的政策、手动批准和防护（包括预定义模板）之内，对软件目录中暴露的任何资产进行供应、终止和执行 Day-2 操作。让他们提供一个开发环境，申请 S3 桶的权限，或者向微服务添加一个秘钥。

5.4 不仅仅是一个 K8S 的抽象层

平台工程的挑战之一是为你的开发者客户找到正确的抽象。所谓正确的抽象对于不同组织来说也是不同的，甚至在同一组织中的开发者之间也是不同的。

每个组织都是一片独一无二的雪花，都有自己的流程和工作流。一些组织开发生产关键型产品，而另一些组织则开发“值得拥有”的开发工具产品。一些组织里的开发人员熟悉 Kubernetes 的比特和字节级细节，而有些开发人员根本就不想听到它。有些组织更专注于大数据技术，而另一些组织则专注于前端技术，等等。这就是为什么在 Kubernetes 之上创建抽象层是徒劳的，这些抽象层不能在不同的组织和角色之间进行定制。

你很可能找不到一个现成的抽象层来满足组织的特定需求。一个开发者门户对一家公司来说可能是很了起的，但对另一家公司则是灾难。

开发者门户必须可定制，以满足组织中不同开发人员的确切需求。如果没有这些定制功能，组织中的开发者门户对开发人员来说将过于复杂，对 DevOps 团队来说也不安全，或者它会将开发人员置于“黄金笼子”中，并降低研发团队的速度。

此外，DevOps 生态并不仅仅由 Kubernetes 组成，还有 Git 仓库、runbook、云服务和身份认证服务、CI/CD 流水线、工单、值班、可观测性工具等等。

开发者门户必须封装组织的 DevOps 生态中的所有活动部分，仅仅使用 Kubernetes 是远远不够的。

‍

5.5 对比 GitOps

GitOps 允许开发人员使用 Git 中的代码变更来完成任务。开发人员可以部署微服务、提供云资源、管理环境、配置等。虽然这确实提供了良好的开发者体验，但它并不能取代对开发者门户的需求。

原因如下：

• GitOps 相关的文件分布在整个代码库中，这使得很难确定需要变更的内容，且产生了严重中断的风险。

• DevOps 和开发人员资产存在于同一个文件中，这使得开发人员很难知道需要变更什么。

• 工具创建大量工单的请求激增。

• Git 不能反映真实世界的实际情况，这可能会导致开发人员做出错误的决定。

• 当有许多的代码仓库和配置文件时，缺乏清晰度。

内部开发者门户是 GitOps 之上的一个解耦接口，确保开发人员的输入得到验证，并确保开发人员走上黄金路经。开发人员不需要理解 GitOps 文件。通常，基本操作和重复操作将通过开发者门户执行。预定义的自服务操作将减少拉取请求的数量。如果你合并了自服务操作，那么这是最好的，这样以来，如果在 GitOps 中需要更改多个文件，请尝试通过在内部开发者门户中只设置一个自助服务操作来实现。

‍

5.6 对比 CI 工具

启用 Jenkins 自服务可以很好地用于开发者自服务，但由于 Jenkins 天生的开放性，存在许多已知的可见性、合规性和其他问题。在某些时候，速度和灵活性也可能会变得一团糟。

Jenkins 并不是为自服务而生的，原因有很多：

• 它是无状态的，因此很难跟踪变更和扩展操作。

• 它有一组有限的 UI 组件，因此表单不支持输入验证（包括正则表达式和针对第三方的验证）、第三方数据输入（例如，有一个包含用户所有 S3 桶的下拉列表），以及 if-then-that 特性。

• Jenkins 也是高耦合的，这使得变更更加困难。

所有这些都会给开发人员带来糟糕的体验，极有可能出现错误、合规和安全问题。

06. 内部开发者门户的价值

“我们的 KPI 是，过去一周内至少进入开发者门户一次的开发者的百分比。目前，这一比例约为 40%。我们开放的操作越多……使用的人就越多。”（Lior Rabin，http://monday.com）。

如何知道内部开发者门户已经达成了目标？一个好的内部开发者门户应该可以减轻开发人员在处理现代软件复杂性方面的负担。结果应该是开发人员只在一个地方寻找与环境、部署、软件、ETL、数据库相关的任何东西，以及他们执行所需自服务操作的简单方法。当复杂性的负担减轻时，软件的质量、成熟度、安全性和稳定性都应该得到提高，开发人员的生产力和满意度都会很高。它还会使 DevOps 能够专注于构建基础设施和自动化，这可能也会让他们更快乐。

‍不要让通过开发者门户开启的“黄金路径”变成“黄金笼子”。不能强迫开发人员始终使用开发者门户。一个好的 IDP 应该为 98% 的用例提供一条黄金路径，因此它确实实现了与之相关的好处。但总会有 2% 的用例需要在开发者门户之外进行工作—— IDP 应该接受这一点，而不是阻止它，并小心创建“黄金笼子”。重要的是，即使工程师没有使用黄金路径进行自服务操作，但其所做的任何操作都将通过从工程基础设施中获取数据而出现在 IDP 中。这会通过一个导出工具完成，该导出工具将使用来自其他系统（例如 K8S）的数据填充服务目录，即使这些更改不是通过内部开发者门户完成的。

6.1 定量收益

‍Twitter 通过其开发速度来定义其平台工程团队的成功。通过使用内部开发者门户，它预计会将其翻一番。

今天，“我们从寻找速度开始，”推特平台负责人 Nick Tornow 说。“我们将其定义为工程师在一个时间单位内可以提供的功能数量，我们希望到 2023 年底将其翻一番。”

许多行业专家估计，使用内部开发者门户可以将 DevOps 收到的工单数量减少 80%，从而释放宝贵的 DevOps 时间。

除了开发人员的速度，还可以衡量开发人员的生产力、DevOps 的生产力、云成本的降低，以及更大的目标，如减少技术债务或减少停机时间。DORA 指标也可以改进，MTTR 和新开发人员上手所需的时间也可以改进。

开发者门户的一个经常被忽视的好处是，它可以为开发人员提供部署权限的防护和开发者生产力的标准，从而为服务成熟度制定标准。这些相同的元素也可以按服务、开发人员或团队进行度量。服务成熟度可以是很多东西，但你可以使用内部开发者门户将其定义为生产准备、质量、安全性和合规性的混合体。然后，你可以立即通过团队、开发人员等对所有服务进行评分，了解哪些服务或资源符合标准，哪些不符合标准。

“我们未来考虑的一个功能是对服务的准备程度进行评分。如果一项服务没有使用我们定义为核心的包进行更新，如果在 GitHub 上没有所需的配置，如果该服务不存在于我们所有的地理区域，我们可以计算分数。分数会让我们警告服务所有者，他们的服务低于标准。如果服务下降到某个阈值以下，我们可能希望采取阻止部署到生产或类似的手段”（Lior Rabin，http://Monday.com）。

6.2 定性收益

‍在文化上做出转变，提倡左移，使开发人员更加轻松，让 DevOps 能够在更多的战略项目中发挥价值，所有这些对工程团队而言，都使公司变得更好。所有这些都可以通过采用内部开发者门户来实现。

07. 开发者门户的未来

整本电子书主要关注的是人类用户如何与内部开发者门户进行交互。除此之外还有一个未来趋势：机器也将与内部开发者门户进行交互。让我们设想这样一个例子：今天是黑色星期五，我们不希望电商网站有任何变更。在 IDP，可通过 CI/CD 流水线查询并检查部署到生产环境服务的“锁定状态”。这个例子告诉我们，IDP 将发展成为反映整个软件架构和实际状态（权限、秘密、所有者等）的中枢，所有应当和不应当进行的操作都会在此强制记录在案。在未来，IDP 还将为机器提供与人类用户相似的接口，以触发 DevOps 流。

欢迎来到 DevOps 的未来 —— 平台工程。

NOTE

如果你对平台工程、内部开发者门户等话题感兴趣，欢迎添加微信好友 nodexy，备注“平台工程交流”获邀加入我们的平台工程技术讨论群组。

也可以在 GitHub 查看平台工程主题的资源列表 https://github.com/toptechevangelist/awesome-platform-engineering

关注并加入平台工程社区 https://github.com/pecommunity