【翻译】如何设计一个内部开发者平台

在试图定义

IDP

时，有几个现有的定义形成了一个有用的起点。Thoughtworks，通过Martin Fowler的博客，给我们提供了数字平台的定义：

数字平台是一个由自助服务API、工具、服务、知识和支持组成的基础，被安排为一个引人注目的内部产品。自主的交付团队可以利用该平台以更高的速度交付产品功能，并减少协调。

而Humanitech，赞助了我们的白皮书《内部开发者平台的崛起》，对内部开发者平台（IDP）有这样的定义：

内部开发者平台，或IDP，是一个自助服务层，允许开发者与他们组织的交付设置独立互动，使他们能够自我服务环境、部署、数据库、日志和其他任何他们需要运行的应用程序。

内部开发者平台（IDP）可以被看作是数字平台的具体实施，作为一种产品提供自助服务功能，以满足团队的各种需求。内部开发者平台的重点是改善团队在发布软件时需要遵循的发布流程。

让我们想想一个现代团队在云端发布软件时可能需要什么。

• 一个存储代码的仓库
• 在代码更新时运行的管道
• 在管道运行时自动扫描，其中可能包括：
  • 安全检查
  • 代码质量检查
  • 运行测试
  • 创建短暂环境
• 用于发布变更的发布流程（通常称为软件交付周期或SDLC）

除了发布流程，还有运行模式；也就是说，应用程序将在哪里运行并被维护？这反过来又导致需要有运行软件的基础设施。需要考虑的基础设施层包括：

• 网络
  • 如何处理流量？
  • 允许哪些流量？

• • 哪些端口可以访问？
• • 哪些应该是公共的，哪些应该是私有的？
• 计算
  • 团队是使用虚拟机、容器，还是使用无服务器？
• 存储
  • 数据将在哪里存放？
  • 数据如何保持安全？
• • 什么和谁可以访问这些数据？
• 可观察性
  • 在你的解决方案中发生了什么？
  • 谁在访问你的系统，正在做什么改变？
  • 你的系统有多健康？
  • 你的系统表现如何？
  • 什么警报将帮助你的团队？
• 安全性有
• • 什么访问控制？
  • 什么检查和扫描的安全漏洞？

• • 
    

在企业内部，通常会有一些团队来处理这些层面的问题，但是，虽然向 "你建立它，你运行它"/DevOps方法的转变在打破开发和运营之间的孤岛方面有明显的优势，但一个副作用是，开发团队现在对他们的解决方案拥有更多的责任。这种责任有

一个

很高的成本，那就是增加认知负荷。

一个解决这个问题的方法是雇用各种具有不同技能的人，从而使具有你所需要的技能的人都在一个团队中。然而，这可能会变得很昂贵，也会导致大量的重复工作。

有了内部开发者平台，你就有了一个专门的团队来关注这些层，与产品团队合作，并为工程部门创造明确的解决方案，供其采用和使用。

这降低了单个工程团队的认知负荷，因为他们不再需要自己解决常见问题，而是可以专注于基于现有解决方案的实施。此外，正如Monzo的Suhail Patel在WTF的其他地方指出的

那样

，服务实现方式的标准化程度的提高使得开发人员更容易在不同的团队之间移动。

总而言之，内部开发者平台是一种规范你的软件交付流程的方法，提供解决方案以满足产品团队的架构需求，并提供一切所需，以便更快地发布，同时控制他们整个端到端的解决方案。这种方法减少了产品团队的认知负担，因为围绕发布和运行软件的复杂问题已经提前解决了。

为什么你想要一个内部开发者平台（IDP）？

你可能正在进行战略转移，从房舍到云。你可能已经在云上了，但发现向云的转移变得越来越有挑战性。

一些迹象表明你需要一个内部开发者平台（IDP）：

• 你计划有多个产品团队
• 你注意到你的产品团队正在经历大量的认知负荷
• 在云上发布软件需要很多努力
• 你计划迁移到云上，并希望为新团队创造一个黄金路径

设计IDP时从哪里开始？

业务目标是什么？

在设计IDP之前，你需要统一业务目标是什么。作为一个起点，与所有的利益相关者在一个房间里开一个研讨会，确保每个人在关键目标上保持一致。

目标是提高发布软件的速度吗？目标是收集和存储有价值的数据吗？

目标是

改变客户的生活吗？

有一个明确的、一致的目标将推动平台的重点和团队的优先级。

设计你的团队

康威定律--"任何设计一个系统（广义的定义）的组织将产生一个设计，其结构是该组织通信结构的副本。"--明确了设计IDP时的起点应该是团队结构和他们之间的沟通。在某些情况下，这可能涉及到执行 "反康威演习"（Inverse Conway Manoeuvre）：

一个组织应该专注于组织团队结构以匹配他们希望系统表现出的架构，而不是期望团队遵循规定的架构设计。

James Lewis

这里有一个有趣的观点，那就是有能力设计组织团队的人也是影响软件的人。

这

两者之间有很强的关联性，而组织所犯的一个大错误就是在不了解它对软件的长期影响的情况下就构建团队。

你应该如何构建你的团队？

如果你还没有这样做，一个好的开始就是阅读《团队拓扑

》这

本书，它为如何构建软件团队提供了一个良好的基础，也是我们推荐阅读清单上的内容。如果你与远程团队一起工作，后续的工作手册是很有用的，你可以收听我们 与作者之一Manual Pais的"黑客组织 " 播客，了解更多信息。

然而，为了给出一个高层次的概述，书中建议有4种团队类型：

• Stream-aligned team
• Enabling team
• Complicated-subsystem team
• Platform team

然后有3种互动模式，团队可以用来处理沟通：

你可以决定一个与此类似的结构，但这完全取决于你的业务目标：

在这个例子中，我们有以下团队。

平台团队：

• 登陆区--负责确保云的设置使用，这可以包括治理规则，处理计费
• 其他平台--这些可以是任何自助服务类型的平台，满足团队的需求
• 内部开发者平台--负责规范你的软件交付流程，为产品团队提供解决方案

产品团队。

负责

• 生产和发布软件的各个产品团队

扶持团队：

• SRE团队--他们负责帮助产品团队设置管道，自动发布流程，并在其应用程序和系统中设置正确的可观察性实践
• 企业架构团队--他们审查产品团队的架构，并负责理解大局。他们帮助产品团队为他们的应用程序和系统设计架构，使其与其他部分和谐相处。

在绝对的开始，在任何平台存在之前，你将需要创建一个核心团队，由来自登陆区、内部开发者平台和产品团队的团队成员组成。

从那里，开始建立你的使能团队来支持核心团队，因为他们在开始时将与核心团队紧密合作，并有相同的目标。

这个核心团队的目标是一起建立第一个原型，并将其发布到生产中。

这种方法确保每个人都非常紧密地合作，并确保沟通流尽可能快。要再次强调的是，关键的目标是进入生产阶段。

许多公司在创建IDP时犯的一个错误是，他们开始的规模太大，没有一个明确的统一的目标。

这个核心团队应该知道业务目标，并从业务目标中决定和选择一小部分有价值的业务功能转移到新平台上。

以这种方式保持团队的注意力，将确保他们遵循 "恰到好处 "的方法，即他们投入的努力恰好能够看到有效的结果。不多也不少。

把它分成几个阶段

创建IDP将是一个分阶段的过程：

IDP将不断发展，所以这种方法是开始建立IDP，并假设它将经历其他的工作阶段，并随着它的成熟提供价值。关于你可能面临的阶段类型，一个很好的心理模型是POC、Day 1和Day 2阶段。

POC是已经描述过的东西。构建足够的东西来为生产提供集中的价值。

第1天是将核心团队分成各自的团队。例如，登陆区平台团队、IDP平台团队、产品团队，然后，如果他们还不是独立的团队，则是授权团队（以SRE和企业架构为例）。第1天的部分工作还需要使为支持POC而建立的服务成熟。然后着手规划更多产品团队的工作。

第2天是重点转移到运行模式的地方。考虑软件的寿命，以及需要支持和维护多长时间。还要考虑大局，多个应用程序要如何并肩运行。在这个阶段，成熟的SRE实践成为一个更大的焦点。所有的应用程序和服务的可观察性成为一个关键战略。

记住IDP是为了帮助产品团队更快的发布

。

IDP的主要重点应该是把产品团队的障碍移开。只有当产品团队有能力自主发布他们的软件时，平台团队才应该考虑其他的功能。

你可以按照这个3步方法来确保每个团队都在做一件有价值的事情。

决定团队需要产生的价值，例如，产品团队想发布一个显示一些关键数据的小应用程序。在此基础上，列出团队为发布小程序所需要的东西，例如：

• 自动发布代码的管道
• 存储和检索数据的地方
• 存储代码的地方
• 运行容器化应用程序的方式
• 存储和使用证书的安全方式
• 存储和使用秘密的安全方式
• 等等

然后为团队创建里程碑。

一旦完成这三个步骤，需求就可以传递给IDP团队。

IDP团队然后将做同样的三个步骤。他们需要产生的价值是基于他们从产品团队得到的要求，例如：

• 自我托管的GitLab运行者
• EKS集群，让产品团队在上面运行他们的容器化应用程序
• 监测整个云的活动

整个

• 云的访问控制

IDP团队然后做同样的事情，也就是说，他们列出他们需要的要求，以便能够解决产品团队的需求，例如。

• 获得计费批准
• 设置OU政策
• 设置卓越中心团队（如云安全和风险）
• 决定允许的AWS账户结构
• 等

然后他们规划出创建平台的里程碑。

现在登陆区团队也可以做同样的事情。着陆区团队需要确保IDP团队能够以批准的方式消费云，以便建立IDP。他们的重点可以包括更多的组织政策结构和对云的批准，例如：

• 从财务部门获得计费批准
• 计划组织的OU政策
• 决定并获得AWS账户政策的批准
• 决定计费规则
• 等

这就是每个人如何一起工作，在所有团队中创造正确的有价值的功能，实现端到端的成功。

想象一下，如果这些团队没有对准一个明确的共同目标，没有一起关注，把一小块价值带到生产。在上面提到的流程中的任何一点，一个团队都可能成为其他团队的阻挠者。这是非常常见的，但也是可以避免的。团队可以非常容易地回到 "把它扔到墙上 "的心态而不自知。我们要避免这种情况，通过努力实现有明确目标的自主、透明的团队。

这样的工作方式有助于你的POC过程，而不仅仅是你的软件。

总结

一个IDP可以为你的组织提供许多好处。这些好处包括：

• 标准化你的软件交付流程
• 提高其他团队的效率
• 更快、更可靠的软件发布
• 对你的软件交付生命周期进行端到端的控制
• 在一个团队内解决复杂的问题，减少多余的工作
• 减少认知负担

在设计你的IDP时，你应该。

• 有一个明确的商业目标
• 使所有的领导层与该目标保持一致
• 建立一个由每个团队的个人组成的核心团队
• 使能团队组成并支持核心团队
• 确定一小块商业价值作为POC来构建
• 所有的团队专注于将POC投入生产
• 核心团队专注于只为POC构建足够的功能
• 在核心团队中，将团队成员集中在他们各自要交付的价值

上 举

例来说。

• 决定价值（例如，向经过认证和授权的用户显示有用数据的应用程序）
• 列出解决方案不同部分的要求，例如：
  • 业务要求交给产品团队
  • 产品团队的要求交给IDP团队
  • IDP团队的要求交给登陆区团队
• 计划出里程碑（承诺交付）
• 发布POC到生产

避免陷入 "翻墙 "的思维方式和创造孤岛。专注于POC阶段，并创建一个IDP的核心团队，将所有团队的成员结合起来，并在这个过程的早期商定明确的简单目标。建立正确的流程来支持那些将从IDP中受益的团队。将POC投入生产。一旦POC进入生产阶段，将各团队分开，进入第1天和第2天阶段。