如何设计内部开发者平台（IDP）：从团队结构到落地路径

摘要： 内部开发者平台，即 IDP，是一种面向研发团队的自助服务平台，能够帮助开发者更高效地获取环境、部署能力、数据库、日志、云资源和交付流程支持。设计优秀的内部开发者平台，可以降低研发团队认知负荷，标准化软件交付流程，并提升组织整体研发效能。

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

在尝试定义数字平台时，一些已有定义可以作为有用的起点。海外某技术咨询机构曾在一篇技术博客中，对数字平台给出如下定义：

数字平台是由自助式 API、工具、服务、知识和支持组成的平台，这些能力被整合为一个有吸引力的内部产品。自主交付团队可以利用该平台，以更快的速度交付产品功能，并减少协作和协调成本。

某海外平台公司也曾对内部开发者平台，即 IDP，给出如下定义：

内部开发者平台（Internal Developer Platform，IDP）是一个自助服务层，允许开发者独立地与组织内部的软件交付体系进行交互，使他们能够自助获取环境、部署能力、数据库、日志，以及运行应用程序所需的其他资源和能力。

内部开发者平台可以看作是数字平台的一种具体实现。它以产品化的方式提供自助服务能力，用来满足不同团队的研发和交付需求。IDP 的重点，在于改进团队发布软件所需的流程和体验。

不妨先思考一个问题：一个现代化研发团队如果要在云端发布软件，通常需要哪些东西？

首先，他们需要一系列支撑软件交付的基础能力，例如：

• 用于存储代码的代码仓库；
• 代码更新后自动运行的流水线；
• 流水线运行时自动执行的扫描和检查，可能包括：
  • 安全检查；
  • 代码质量检查；
  • 自动化测试；
  • 创建临时环境；
• 用于发布变更的发布流程，通常也被称为软件交付生命周期，即 SDLC。

在实际落地中，许多企业还会借助研发管理工具来承接这些流程。例如，PingCode 这类智能化研发管理工具，可以覆盖从团队目标、客户反馈、需求清理、评审排期，到项目开发、测试发布和知识沉淀的全生命周期，并通过打通研发工具链，让数据在不同环节之间顺畅流转，从而进一步提升研发效能。

除了发布流程之外，还需要考虑运行模型。也就是说，应用程序将在哪里运行？由谁维护？这又会进一步涉及运行软件所需的基础设施能力。需要考虑的基础设施层包括：

网络

• 流量如何路由？
• 允许哪些流量通过？
• 应该开放哪些端口？
• 哪些内容应该对外暴露，哪些内容应该保持私有？

计算

• 团队使用的是虚拟机、容器，还是无服务器架构？

存储

• 数据将存储在哪里？
• 如何确保数据安全？
• 哪些人可以访问哪些数据？

可观测性

• 解决方案中正在发生什么？
• 谁在访问系统？他们进行了哪些更改？
• 系统当前的健康状况如何？
• 应用和服务的运行状态如何？
• 哪些告警对团队真正有帮助？

安全

• 有哪些访问控制措施？
• 系统会检查和扫描哪些安全漏洞？

在传统本地部署模式下，通常会有专门团队负责处理这些层面的工作。但随着“构建即运行”和 DevOps 模式的发展，开发与运维之间的壁垒被逐渐打破，这无疑带来了明显优势。与此同时，它也产生了一个副作用：开发团队现在需要对自己的解决方案承担更多责任，而这些责任会带来更高的认知负荷。

一种应对方式，是招聘具备多种技能的人才，让一个团队内部尽可能覆盖所有所需能力。然而，这样做成本很高，也容易导致大量重复劳动。

内部开发者平台提供了另一种思路：由一个专门的平台团队统一审视这些基础能力，与产品团队协作，并为工程团队创建定义清晰、可复用、可采用的解决方案。

这可以降低各个工程团队的认知负荷。团队不再需要从零开始解决常见问题，而是可以基于已有的平台能力进行实现和交付。此外，正如海外某大型技术组织的一位高级工程师曾在相关文章中指出的那样，当服务实现方式更加标准化时，开发者在不同团队之间切换也会变得更加容易。

总而言之，内部开发者平台是一种标准化软件交付流程的方法。它通过提供一套可复用的解决方案，满足产品团队的架构和交付需求，并提供加快发布速度所需的一切能力，同时让开发者仍然能够掌控端到端的解决方案。这种方法可以减轻产品团队的认知负担，因为软件发布和运行中的许多复杂性，已经提前由平台层解决。

为什么企业需要内部开发者平台？

你的组织可能正在进行从本地部署到云端的战略转型；也可能已经在使用云服务，但发现随着规模扩大，云端交付变得越来越复杂。

如果出现以下迹象，说明你可能需要内部开发者平台：

• 你计划组建多个产品团队；
• 你发现产品团队正在承受巨大的认知负荷；
• 在云端发布软件需要投入大量额外精力；
• 你计划迁移到云端，并希望为新团队打造一条清晰的“黄金路径”。

设计内部开发者平台应该从哪里入手？

明确业务目标

在设计内部开发者平台之前，首先需要明确业务目标。一个好的起点，是组织一次由所有关键利益相关者参与的研讨会，确保每个人都对核心目标达成共识。

目标是提高软件发布速度吗？是收集和存储有价值的数据吗？是改善客户体验、改变客户的工作方式，还是支持新的业务增长？

清晰且一致的目标，将决定平台应该关注什么，也会影响团队优先级的排序。

设计团队结构

康威定律指出：

任何组织在设计系统时，其系统结构都会反映该组织的沟通结构。

这意味着，设计内部开发者平台的起点，应该是团队结构以及团队之间的沟通方式。在某些情况下，这可能还需要采用“逆康威策略”：

组织不应期待团队被动服从某种强制性的架构设计，而应该主动调整团队结构，使其与组织希望系统呈现出的架构保持一致。

这里有一个非常重要的观点：有权设计组织团队结构的人，也在深刻影响软件系统的演进。团队结构和软件架构之间存在密切关联。许多组织常犯的一个错误，是在不了解团队架构会对软件系统产生长期影响的情况下，就贸然开始搭建团队。

如何构建内部开发者平台团队？

如果你还没有读过关于“团队拓扑”的经典著作，可以从这里入手。这类方法为如何构建软件团队提供了很好的基础，也常被列入软件组织设计的推荐阅读清单。如果你正在管理远程团队，配套的练习材料也会很有帮助。你还可以参考一些围绕组织设计和团队协作展开的相关访谈，进一步理解其中的方法。

为了便于概括，这类方法通常会提出 4 种典型团队类型：

1. 面向业务流的团队；
2. 赋能团队；
3. 复杂子系统团队；
4. 平台团队。

团队之间通常可以通过以下 3 种交互模式进行协作：

你可以采用类似下面的团队结构，但最终形式应完全取决于你的业务目标。

在这个示例中，我们可以看到以下几类团队。

平台团队

云着陆区团队
负责确保云环境已经设置完毕并可供使用，包括治理规则、权限边界、计费机制等。

其他平台团队
可以是任何面向团队需求提供自助服务能力的平台团队。

内部开发者平台团队
负责规范软件交付流程，并为产品团队提供可复用的解决方案。

产品团队

产品团队负责具体软件产品的开发、生产和发布。

赋能团队

SRE 团队
帮助产品团队搭建流水线、自动化发布流程，并在应用程序和系统中建立正确的可观测性实践。

企业架构团队
负责审核产品团队的架构，并理解整体架构。他们帮助产品团队设计应用程序和系统架构，确保不同系统之间能够协调共存。

图片说明 / Alt 文案建议： 内部开发者平台建设中的平台团队、产品团队和赋能团队协作关系。

在平台正式建立之前，你需要先创建一个核心团队。这个团队应由来自云着陆区团队、内部开发者平台团队和产品团队的成员共同组成。

接下来，再组建赋能团队来支持核心团队。因为在初期阶段，赋能团队会与核心团队密切协作，并围绕同一个目标推进工作。

这个核心团队的目标，是共同构建第一个原型，并将其投入生产环境。

这种方法可以确保所有人紧密合作，使沟通路径尽可能短。再次强调，根本目标是尽快进入生产环境，尽快验证真实价值。

许多公司在制定 IDP 计划时都会犯一个错误：一开始目标设得过大，却没有清晰且一致的方向。由于他们同时关注太多方面，最终需要很长时间才能把平台能力真正推向生产环境。

核心团队应当充分理解业务目标，并基于这些目标，选择一小部分有价值的业务功能迁移到新平台上。之后，所有团队都应围绕这一目标开展工作。

这样一来，团队就能保持专注，并遵循“恰到好处”的原则：投入足够的努力，以获得有效结果；既不不足，也不过度，刚刚好。

内部开发者平台建设的 3 个阶段

建设内部开发者平台通常是一个分阶段推进的过程。

IDP 会不断发展和演进。因此，更合理的方法是先开始构建 IDP，并假设它会随着成熟度提升进入不同阶段，最终持续交付价值。一个便于理解的阶段模型是：概念验证、第一天和第二天。

概念验证阶段

概念验证，即 POC，指的是构建足以交付一定生产价值的最小能力。它不是为了做一个完美平台，而是为了验证：这个平台方向能否真正帮助团队交付业务价值。

第一天阶段

第一天的任务，是将核心团队逐步拆分成更明确的团队，例如云着陆区平台团队、内部开发者平台团队、产品团队，以及支持性的赋能团队，例如 SRE 团队和企业架构团队。

第一天阶段还包括完善为了支持 POC 而构建的服务，并继续规划更多产品团队接入平台后的工作。

第二天阶段

第二天的重点会转向运行模型。此时需要考虑软件的完整生命周期，包括应用需要支持和维护多长时间，也需要从全局视角考虑多个应用程序如何协同运行。

在这一阶段，成熟的 SRE 实践会成为重点。所有应用程序和服务的可观测性将成为一项关键策略。此外，通过自动化简化发布和维护任务，也会变得至关重要。

如何让内部开发者平台创造正确价值？

重要的是，让每个人都在做真正能够产生价值的事情。否则，你很容易构建出并不需要的功能，从而延迟 IDP 产生正确结果的时间。

请记住，IDP 的目的是帮助产品团队更快地发布产品。IDP 的主要目标，是扫清产品团队前进道路上的障碍。只有当产品团队能够自主发布软件之后，平台团队才应该考虑添加更多功能。

你可以遵循以下 3 个步骤，确保每个团队都在做有价值的事情。

第一步，确定团队需要产出的价值。例如，产品团队可能希望发布一个小型应用程序，用来展示一些关键数据。

第二步，列出团队发布这个小型应用程序所需的一切，例如：

• 用于自动化代码发布的流水线；
• 用于存储和检索数据的能力；
• 用于存储代码的地方；
• 运行容器化应用程序的方式；
• 安全存储和使用证书的方式；
• 安全存储和使用密钥的方式；
• 其他相关能力。

第三步，为团队制定里程碑。

完成这 3 个步骤后，即可将需求提交给 IDP 团队。

随后，IDP 团队也执行相同的 3 个步骤。他们需要产出的价值，取决于从产品团队获得的需求，例如：

• 自托管 CI 运行器；
• 供产品团队运行容器化应用程序的 Kubernetes 集群；
• 监控云端活动；
• 云端访问控制。

接下来，IDP 团队也需要列出为了满足产品团队需求而必须具备的条件，例如：

• 获得账单审批；
• 设置组织单元策略；
• 建立卓越中心团队，例如云安全与风险团队；
• 确定允许采用的云账号结构；
• 其他相关要求。

随后，他们为平台创建制定各个里程碑计划，并将列出的需求提交给云着陆区团队。

现在，云着陆区团队也可以执行相同的操作。云着陆区团队需要确保 IDP 团队能够以经过批准的方式使用云服务，从而构建 IDP。他们的工作重点可能包括更多与云相关的组织政策结构和审批流程，例如：

• 获得财务部门的账单审批；
• 制定组织单元策略；
• 制定并获得云账号策略批准；
• 制定计费规则；
• 其他相关事项。

这就是各个团队如何通力合作，为所有团队创造合适且有价值的功能，从而实现端到端成功。对于需要跨团队推进目标、任务、文档、日历、甘特图、工时和审批的组织来说，Worktile 这类通用项目协作系统也可以作为协作层补充，帮助团队围绕统一目标推进里程碑，减少信息分散和协作成本。

试想一下，如果各个团队没有一个清晰的共同目标，也没有齐心协力地创造哪怕一点点生产价值，会发生什么？在上述流程的任何阶段，任何一个团队都可能成为其他团队的阻碍。

这种情况非常普遍，但也完全可以避免。团队很容易在不知不觉中陷入“把问题丢给下一个团队”的思维模式。我们希望避免这种情况，努力打造目标清晰、自主透明的团队，而不是目标模糊、彼此割裂、最终形成信息孤岛的团队。

这种方法可以帮助你验证流程，而不仅仅是验证软件。

总结：内部开发者平台是提升研发效能的重要基础设施

内部开发者平台可以为组织带来许多收益，包括：

• 标准化软件交付流程；
• 提升其他团队的工作效率；
• 实现更快、更可靠的软件发布；
• 对软件交付生命周期进行端到端控制；
• 将复杂问题集中解决在少数团队内，减少重复劳动；
• 降低产品团队和工程团队的认知负荷。

在设计内部开发者平台时，你应该：

• 设定清晰的业务目标；
• 让所有领导层围绕这个目标保持一致；
• 设计合适的团队结构和沟通模式；
• 从每个关键团队中抽调成员，组建一个核心团队；
• 让赋能团队支持核心团队；
• 确定一小部分业务价值，作为概念验证来构建；
• 让所有团队都专注于将概念验证推向生产环境；
• 让核心团队专注于构建概念验证所需的基础能力；
• 在核心团队内部，让团队成员专注于各自负责的价值部分，并交付成果。

例如，你可以这样推进：

1. 确定价值，例如构建一个面向已认证和授权用户展示有用数据的应用程序；
2. 列出解决方案各个部分的要求，例如：
   • 需要向产品团队提供哪些业务需求；
   • 产品团队需要向 IDP 团队提出哪些需求；
   • IDP 团队需要向云着陆区团队提出哪些需求；
3. 制定里程碑计划，并承诺按时完成；
4. 将概念验证发布到生产环境。

避免陷入“把问题扔过墙”的思维模式，避免制造信息孤岛。应当专注于概念验证阶段，组建一个整合各方成员的核心团队，明确 IDP 的目标，并在流程早期就制定清晰、简明的方向。同时，还要建立合适的流程，支持那些将从 IDP 中受益的团队。

先将 POC 投入生产环境。等 POC 成功进入生产环境后，再拆分团队，并逐步进入第一天和第二天阶段。