如何利用内部开发者平台（IDP）实现开发者自助服务？

摘要： 内部开发者平台，即 IDP，是一种面向开发团队的自助服务平台，能够帮助企业统一环境管理、CI/CD、应用配置、基础设施编排、部署管理和访问控制。通过建设内部开发者平台，组织可以降低开发团队认知负荷，减少开发与运维之间的事务性协作成本，并提升软件交付效率和整体研发效能。

简要概述

即使是最先进的组织，在面对日益严峻的人才短缺时，也很难持续扩大软件开发产出的规模。因此，越来越多企业和开发团队开始从内部开发者平台（Internal Developer Platform，IDP）的角度重新审视自身基础设施，希望借此应对这些挑战，并加速大规模软件交付。

海外一些分析机构、技术思想领袖、平台供应商以及大型科技公司，都已开始关注内部开发者平台。本文综合了各方观点，对内部开发者平台进行系统介绍，并提供实用建议和相关参考。与此同时，本文也将重点讨论企业级内部开发者平台在规划、实施和运营过程中的一些推荐做法。

内部开发者平台之所以成为一个重要的新概念，是因为它解决了软件交付生命周期中的三个关键挑战：

1. 提供从开发到生产的环境管理能力，并与 CI/CD 集成；
2. 集成可复用的模式，供开发团队在应用程序中使用；
3. 减少开发团队与运维团队之间的事务性沟通和协作成本。

通常来说，仅仅增加工程师人数，既不足以解决当前问题，也无法真正支撑企业长期发展。我们稍后会对此进行更详细的分析。

云计算、容器化和微服务架构为组织提供了丰富的内部工具和系统选择，用以满足新型环境下的研发需求。内部开发者平台的目标，是为开发团队提供足够的工具和资源，同时抽象掉底层运维负担。

许多开发团队无论是出于直觉，还是出于有意识的规划，都已经注意到了这些优势。与此同时，基础设施相关责任也逐渐转移到少数分散的个人身上，由他们承担提供这种抽象能力的工作。很多时候，组织并没有意识到自己实际上正在构建一个内部开发者平台，或者至少是在构建它的某种变体。

有海外技术媒体曾将内部开发者平台比作“雪花”，认为没有两个平台是完全相同的。每个平台都会因组织的技术栈、文化、代码库和工具集不同而呈现差异。

我们认为，内部开发者平台的适应性正是这一概念的核心。也正是这种适应性，使内部开发者平台对软件开发组织而言如此强大且具有吸引力。因此，本文不会试图给出一个过于学术化的定义，而是重点介绍我们在相关资料中看到的各种功能和实现模式，帮助读者结合自身情况做进一步调整。

什么是内部开发者平台（IDP）？

一个由社区驱动的网站，为理解内部开发者平台提供了一个很好的起点：

内部开发者平台由运维团队配置，供开发者使用。运维团队负责指定哪些资源应在哪些环境中启动，或应根据哪些请求启动。他们还会设置应用配置的基础模板并管理权限。这有助于自动化启动环境和资源等重复性任务，并通过强制执行标准来简化维护工作。

也有海外技术团队将 IDP 视为“一个工具系统，这些工具相互集成到一个中央平台中，用于支持内部开发流程。开发者感受到的，是一种‘内部平台即服务’”。

另一篇海外技术文章也强调了 IDP 的服务属性，即它应当满足开发团队的具体偏好：

一个优秀的内部开发者平台，应当能够抽象基础设施决策，实现自助式环境构建，与现有持续集成、持续交付和部署流程集成，并分配基于角色的访问控制。所有这些，最好都不需要开发者学习 YAML。

在企业落地过程中，IDP 往往还需要与研发管理体系形成配合。例如，PingCode 这类智能化研发管理工具，可以承接从团队目标、客户反馈、需求清理、评审排期，到开发、测试、发布和 Wiki 知识沉淀的全生命周期流程，并通过打通研发工具链，让数据在不同研发环节之间顺畅流转，从而帮助企业更系统地提升研发效能。

内部开发者平台的价值：为什么企业需要 IDP？

“所有企业都是软件企业”这句话已经流传了近二十年，并被许多企业领导者和战略负责人反复引用和阐释。它强调的是：任何组织，无论实际所处行业是什么，都需要为软件开发团队提供合适的环境，使其能够在具备竞争力的规模上，应对现代应用开发中的关键挑战。

经典的供需问题

许多组织通过云采用项目、数字优先计划和数字化转型，实现了前所未有的增长。这些举措也给传统上负责为开发团队构建和维护平台的运维团队带来了沉重负担。

仅仅通过增加工程师或开发者招聘数量，来减少积压工作并更平均地分摊工作量，并不能真正解决问题。如果缺乏清晰流程和共识，这种“增加人手”的策略并不会立即奏效。原因很简单：每个组织的内部技术栈都不同，新工程师需要时间弥补知识和经验上的差距，才能真正开始为团队创造价值。

降低开发团队的认知负荷

软件交付团队在日常工作中，往往需要兼顾大量任务和职责。内部开发者平台可以减轻繁杂日常任务带来的认知负荷。

上下文切换所造成的认知负荷，经常被认为是导致开发者生产力下降的重要原因之一。开发者生产力领域的研究者曾指出，上下文切换带来的认知负荷，是团队不堪重负的主要原因。在关于团队结构与软件交付的相关著作中，作者对此进行了精辟阐述：

如果不考虑认知负荷，团队就会疲于承担过多职责和领域。这样的团队缺乏足够精力去精进技艺，也难以应对上下文切换带来的成本。

同样，海外一份 DevOps 状态报告也指出：

大多数软件开发者和运维工程师都明白，在两种不同情境之间来回切换，会消耗大量认知资源。除了情境切换本身对人类来说就具有挑战性之外，还有一个重要原因：每种情境的细节和思维方式都截然不同。

然而，在组织规划或项目规划中，认知负荷很少被认真考虑。这会让开发团队处于明显劣势，并阻碍组织取得预期成效。

内部开发者平台为团队提供了一组可复用的模式。开发者可以在一个统一交互入口中，根据自身角色使用这些能力。这减少了上下文切换次数，从而降低了团队的认知负荷。

解决自主性与工具多样化的挑战

有海外技术专家曾很好地解释过，开发团队和运维团队在组织中面临的挑战，以及内部开发者平台如何帮助他们：

显然，一个优秀平台必须具备的特征之一，是减少积压工作的耦合。平台必须提供不依赖工单创建和任务分配的服务。自助服务是优秀平台的关键特征。平台应当为团队提供自助访问能力，具体来说，应允许团队自助配置、自助管理和操作平台的功能与资产，从而在自主多样化和强制统一之间找到合适平衡，而这一点往往很难提前预测。

让团队更快交付软件

多年来，开发团队及其所服务的企业，一直致力于以更快的速度交付更高质量的软件。这主要源于用户对新功能的需求，以及市场竞争的不断加剧。

一些互联网企业对传统行业造成冲击的案例表明，企业需要具备快速响应变化的能力，才能在瞬息万变的市场中保持竞争力。也正是这种需求，推动了敏捷开发和 DevOps 的兴起。

此后，许多公司，无论是云原生公司还是更传统的企业，都开始被称为“高绩效 DevOps 组织”。这一概念通常用来描述那些能够更快交付软件，并在各自业务领域中超越同侪的组织。用于评估组织是否具备高绩效 DevOps 能力的一些关键指标包括：部署频率、交付周期、等待时间和平均修复时间，即 MTTR。

在某年度 DevOps 状态报告中，高绩效组织与内部开发者平台采用之间存在明显相关性。报告发现，DevOps 成熟度与内部平台使用之间有着密切联系。高度成熟的公司报告内部平台使用率高的可能性，远高于中低成熟度公司。

参与内部开发者平台建设的团队

内部开发者平台通常由一个专门团队构建和管理，我们可以称之为平台团队。除了平台团队之外，运维团队负责组织的技术基础设施需求，开发团队则负责交付软件。下面将分别介绍这些团队、他们的需求以及面临的挑战。

平台团队

平台团队的组建，是内部开发者平台能否成功的关键因素之一。因此，明确并落实团队使命至关重要。

通过将平台团队定义为组织内部的独立实体，可以让其专注于特定领域，并减轻其在原有角色中承担的大量事务性工作负担。有海外技术专家对此强调道：

平台团队负责构建、部署和监控平台组件及底层平台基础设施，并随时响应相关问题。理想情况下，平台团队甚至不需要知道平台上运行了哪些应用程序，他们只需要负责平台服务本身的可用性。

平台在构建和维护过程中，需要采用产品思维。我们会在后文进一步探讨这一点。

运维团队

传统上，运维团队负责组织 IT 基础设施中的许多关键要素。与开发团队可能同时只负责少量项目不同，运维团队的工作范围通常要大得多。他们需要管理多个环境、数据库、网络、云基础设施，以及构成软件解决方案的许多其他要素。

与此同时，运维团队还负责组织的线上环境。无论是外部用户还是内部用户，都会每天通过这些环境与公司进行交互。这就要求运维团队在支持开发团队和保障业务稳定运行之间，找到一个微妙平衡。

这些团队通常遵循先进先出原则，并通过工单系统管理工作。系统故障处理的优先级通常高于其他任务。

海外相关 DevOps 状态报告强调，高效的 DevOps 组织需要投资内部开发者平台，以实现开发者自助服务，并减轻运维团队在项目和事务处理方面的负担。

许多组织其实是在不知不觉中开始为团队提供内部开发者平台的。例如，组织可能会开始标准化使用某一类云平台，或者统一部署到专用容器平台上。在构建内部开发者平台的过程中，组织会逐一解决各种依赖关系，试图在整个软件生命周期中提升交付效率。

有海外平台负责人曾写道：

如果你需要更快发布产品，就需要解决这些障碍，消除瓶颈，并制定策略来处理根本原因。

相关技术演讲中也曾提出一些有用指标，帮助运维团队评估内部平台的有效性。这些指标通常会围绕平台使用情况、交付效率、故障恢复、用户满意度以及团队认知负荷等方面展开。

开发团队

内部开发者平台的主要受益者，是组织中的开发团队。

开发团队通常承担着艰巨任务：要么将新功能推向市场，要么构建对组织日常业务至关重要的内部系统。

开发团队常常需要等待运维团队或 DevOps 团队创建环境，才能部署和测试应用程序。由于缺少负责特定应用持续集成和持续交付的集中式平台，开发团队往往会选择最适合自己的工具。

有海外从业者解释说，这会导致“整个组织的控制和审计能力有限”。这通常还会导致组织内部工具高度分散，因为各个团队会基于自己熟悉或偏好的工具，采用和构建不同工作流程。

除了工具分散之外，对于那些有严格区域合规或支付安全合规要求的组织来说，这还可能造成更大问题。

在某云原生技术大会上，许多与会者都非常强调：开发者需要能够自助维护基础设施。

在构建平台的过程中，应用开发者是关键客户，而易用性是开发者体验的重要组成部分。除非开发者能够快速、安全地配置平台运行其服务的方式，以及配置应用程序面向最终用户发布的方式，否则云原生平台的价值将无法被充分释放。

如何开始建设内部开发者平台？

通常，团队会首先规范和标准化持续集成、持续交付、基础设施即代码和容器编排相关方法。这些技术构成了大多数内部开发者平台的基础。

将平台视为产品，是构建成功内部开发者平台的关键组成部分。

有技术专家强调，构建成功的内部开发者平台需要三个关键前提：

1. 平台是一个产品，需要一个长期稳定的产品团队负责构建和运营；
2. 组织必须愿意将部分或全部应用运行职责，从集中式运维和支持部门转移到应用团队；
3. 组织必须愿意在严格实施一致性，与赋予自主应用团队自由和责任之间做出权衡。

与此同时，也有研究者从业务瓶颈角度指出，将内部开发者平台打造为产品，正是其成功的关键：

产品导向的方法关注软件的整个生命周期：软件是否实用？它是否能帮助客户和用户，并最终帮助企业？一切都围绕收集客户和市场反馈，并据此持续改进软件展开。

虽然这一观点最初主要面向业务依赖软件交付的公司，但它同样适用于内部产品。内部平台也应该赋予团队管理交付成果的能力，就像他们面对外部客户一样。

另一位海外技术作者在关于内部平台产品化的文章中写道：

无论你是平台工程师、工程经理还是产品经理，都应该始终记住，要以客户为中心，并对平台产品进行战略规划。如果没有清晰战略来展现影响力和价值，平台最终只会被忽视并长期人手不足，而再酷炫的新技术也无法解决这个问题。

在把平台作为产品持续运营时，平台团队还需要稳定管理需求、反馈、任务、文档和跨团队沟通。对于这类场景，Worktile 这类通用项目协作系统可以作为协作支撑，帮助团队围绕目标、任务、日历、甘特图、工时和审批等信息形成统一工作空间，减少平台建设过程中的信息分散。

内部开发者平台的关键组成部分

内部开发者平台是一系列紧密集成的工具和系统，旨在为开发团队提供一致的使用体验。

不同组织的平台及其构建团队通常都各具特色，但许多企业中仍然存在一些共同组件和模式。常见组件包括：应用配置管理、基础设施编排、环境管理、部署管理，以及基于角色的访问控制。下面我们将逐一介绍。

应用配置管理

跨多个不同环境管理应用配置，很容易变得复杂，尤其当应用程序由多个服务和平台组成时更是如此。

内部开发者平台通常会像管理代码一样管理应用配置：通过源代码管理平台维护应用配置，从而实现版本控制和变更管理等关键能力。

随着应用复杂度不断增加，运行、部署和管理应用所需的配置也会变得更加复杂。通过扩展源代码管理系统中存储的配置范围，团队可以在一个中心位置配置外部依赖项，并将其与关联应用一起进行版本控制和管理。

基础设施编排

内部开发者平台需要与组织现有及未来的基础设施兼容。这通常可以通过构建可扩展平台来实现。

内部开发者平台往往会与组织工具链进行广泛集成，包括流水线、集群、服务器、网络、DNS、防火墙、路由、镜像仓库、制品库等。

理想情况下，内部开发者平台应成为基础设施即代码的驱动力，允许团队以编程方式定义和管理解决方案中的各类组件。

通常，各个团队或 DevOps 团队会使用基础设施即代码工具构建和部署基础设施。但是，如果能将现有脚本集成到内部开发者平台中，团队就可以基于已知的架构目录来使用这些能力，而不必从零开始理解和维护底层脚本。

环境管理

创建新环境通常会面临多重挑战，例如平台容量不足、团队瓶颈，甚至成本限制。团队往往需要等待数天甚至数周才能获得环境，即使只是为了测试一些小功能。

内部开发者平台则以整体方式构建新的应用环境，将应用运行所需的所有依赖项整合到一个统一环境中。这使开发团队可以按需访问自助式环境，大幅减少瓶颈，并帮助开发团队更快交付成果。

内部开发者平台在环境管理方面的价值，远不止于为开发团队提供新的测试环境。它还能允许团队按需启动包含所有依赖项的完整应用堆栈，并在不再需要时销毁这些资源。

在采用按量计费模式的云环境中，这一点尤其有价值。因为大型环境，例如性能测试环境，如果长期闲置，往往会造成高昂成本。

部署管理

向用户交付软件，是任何组织中开发团队的关键职责。如何加快交付速度，也是长期存在的挑战。

持续集成和持续部署的采用，让开发团队能够更快、更频繁地部署软件，但这也往往带来新的挑战和问题。

当内部开发者平台被引入开发生命周期后，它会成为所有面向目标环境自动化部署的中心枢纽。内部开发者平台成为“自动化的自动化器”，负责部署版本控制以及其他与部署相关的事项。这种集成通常通过 Webhook 实现。

除了部署应用及相关组件之外，内部开发者平台通常还会提供一个集中入口，用于调试所有部署。它也可以成为应用版本的集中管理点，使团队能够在同一位置执行部署和回滚。

基于角色的访问控制

对于任何由多个团队共享的平台而言，基于角色的访问控制，即 RBAC，都是不可忽视的要素。

有效的 RBAC 策略可以限制不同团队与平台交互的范围，并根据成员在组织中的角色划分权限。

除了管理哪些团队可以与平台交互之外，RBAC 还可以限制未经授权人员的访问范围。在某云原生技术大会上，有安全专家深入探讨了容器编排平台中 RBAC 策略存在缺陷所带来的风险，并引用了一句颇具警示意味的话：

我们由星辰组成，但你的 RBAC 不应如此。

这句话意在提醒：环境中的系统或资源，不应像星空一样无边无际、任意开放访问权限。

结论：内部开发者平台是实现开发者自助服务的关键

总而言之，内部开发者平台是企业数字化转型和持续发展的关键要素。它使开发团队能够专注于构建真正让客户满意、并推动公司在目标市场中增长的解决方案。

但与企业内部任何项目一样，内部开发者平台也需要持续评估，以了解它对使用团队和构建团队产生了什么影响。

内部开发者平台成功的最大驱动力，是在平台创建和管理过程中采用产品思维。也就是说，平台团队需要持续收集最终用户，也就是开发者的反馈，并将这些反馈融入平台的持续演进中。

在整个过程中，关键在于不断发现下一个让开发团队和运维团队分心、使其无法专注于交付成果的任务或问题，并将其解决。

对于运维团队而言，这意味着他们可以将精力集中在真正关乎业务的关键问题上；对于开发团队而言，这意味着他们能够专注构建最终推动业务增长的功能或产品。