摘要内部开发者平台即 IDP是一种面向研发团队的自助服务平台能够帮助开发者更高效地获取环境、部署能力、数据库、日志、云资源和交付流程支持。设计优秀的内部开发者平台可以降低研发团队认知负荷标准化软件交付流程并提升组织整体研发效能。什么是内部开发者平台IDP在尝试定义数字平台时一些已有定义可以作为有用的起点。海外某技术咨询机构曾在一篇技术博客中对数字平台给出如下定义数字平台是由自助式 API、工具、服务、知识和支持组成的平台这些能力被整合为一个有吸引力的内部产品。自主交付团队可以利用该平台以更快的速度交付产品功能并减少协作和协调成本。某海外平台公司也曾对内部开发者平台即 IDP给出如下定义内部开发者平台Internal Developer PlatformIDP是一个自助服务层允许开发者独立地与组织内部的软件交付体系进行交互使他们能够自助获取环境、部署能力、数据库、日志以及运行应用程序所需的其他资源和能力。内部开发者平台可以看作是数字平台的一种具体实现。它以产品化的方式提供自助服务能力用来满足不同团队的研发和交付需求。IDP 的重点在于改进团队发布软件所需的流程和体验。不妨先思考一个问题一个现代化研发团队如果要在云端发布软件通常需要哪些东西首先他们需要一系列支撑软件交付的基础能力例如用于存储代码的代码仓库代码更新后自动运行的流水线流水线运行时自动执行的扫描和检查可能包括安全检查代码质量检查自动化测试创建临时环境用于发布变更的发布流程通常也被称为软件交付生命周期即 SDLC。在实际落地中许多企业还会借助研发管理工具来承接这些流程。例如PingCode 这类智能化研发管理工具可以覆盖从团队目标、客户反馈、需求清理、评审排期到项目开发、测试发布和知识沉淀的全生命周期并通过打通研发工具链让数据在不同环节之间顺畅流转从而进一步提升研发效能。除了发布流程之外还需要考虑运行模型。也就是说应用程序将在哪里运行由谁维护这又会进一步涉及运行软件所需的基础设施能力。需要考虑的基础设施层包括网络流量如何路由允许哪些流量通过应该开放哪些端口哪些内容应该对外暴露哪些内容应该保持私有计算团队使用的是虚拟机、容器还是无服务器架构存储数据将存储在哪里如何确保数据安全哪些人可以访问哪些数据可观测性解决方案中正在发生什么谁在访问系统他们进行了哪些更改系统当前的健康状况如何应用和服务的运行状态如何哪些告警对团队真正有帮助安全有哪些访问控制措施系统会检查和扫描哪些安全漏洞在传统本地部署模式下通常会有专门团队负责处理这些层面的工作。但随着“构建即运行”和 DevOps 模式的发展开发与运维之间的壁垒被逐渐打破这无疑带来了明显优势。与此同时它也产生了一个副作用开发团队现在需要对自己的解决方案承担更多责任而这些责任会带来更高的认知负荷。一种应对方式是招聘具备多种技能的人才让一个团队内部尽可能覆盖所有所需能力。然而这样做成本很高也容易导致大量重复劳动。内部开发者平台提供了另一种思路由一个专门的平台团队统一审视这些基础能力与产品团队协作并为工程团队创建定义清晰、可复用、可采用的解决方案。这可以降低各个工程团队的认知负荷。团队不再需要从零开始解决常见问题而是可以基于已有的平台能力进行实现和交付。此外正如海外某大型技术组织的一位高级工程师曾在相关文章中指出的那样当服务实现方式更加标准化时开发者在不同团队之间切换也会变得更加容易。总而言之内部开发者平台是一种标准化软件交付流程的方法。它通过提供一套可复用的解决方案满足产品团队的架构和交付需求并提供加快发布速度所需的一切能力同时让开发者仍然能够掌控端到端的解决方案。这种方法可以减轻产品团队的认知负担因为软件发布和运行中的许多复杂性已经提前由平台层解决。为什么企业需要内部开发者平台你的组织可能正在进行从本地部署到云端的战略转型也可能已经在使用云服务但发现随着规模扩大云端交付变得越来越复杂。如果出现以下迹象说明你可能需要内部开发者平台你计划组建多个产品团队你发现产品团队正在承受巨大的认知负荷在云端发布软件需要投入大量额外精力你计划迁移到云端并希望为新团队打造一条清晰的“黄金路径”。设计内部开发者平台应该从哪里入手明确业务目标在设计内部开发者平台之前首先需要明确业务目标。一个好的起点是组织一次由所有关键利益相关者参与的研讨会确保每个人都对核心目标达成共识。目标是提高软件发布速度吗是收集和存储有价值的数据吗是改善客户体验、改变客户的工作方式还是支持新的业务增长清晰且一致的目标将决定平台应该关注什么也会影响团队优先级的排序。设计团队结构康威定律指出任何组织在设计系统时其系统结构都会反映该组织的沟通结构。这意味着设计内部开发者平台的起点应该是团队结构以及团队之间的沟通方式。在某些情况下这可能还需要采用“逆康威策略”组织不应期待团队被动服从某种强制性的架构设计而应该主动调整团队结构使其与组织希望系统呈现出的架构保持一致。这里有一个非常重要的观点有权设计组织团队结构的人也在深刻影响软件系统的演进。团队结构和软件架构之间存在密切关联。许多组织常犯的一个错误是在不了解团队架构会对软件系统产生长期影响的情况下就贸然开始搭建团队。如何构建内部开发者平台团队如果你还没有读过关于“团队拓扑”的经典著作可以从这里入手。这类方法为如何构建软件团队提供了很好的基础也常被列入软件组织设计的推荐阅读清单。如果你正在管理远程团队配套的练习材料也会很有帮助。你还可以参考一些围绕组织设计和团队协作展开的相关访谈进一步理解其中的方法。为了便于概括这类方法通常会提出 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 这类通用项目协作系统也可以作为协作层补充帮助团队围绕统一目标推进里程碑减少信息分散和协作成本。试想一下如果各个团队没有一个清晰的共同目标也没有齐心协力地创造哪怕一点点生产价值会发生什么在上述流程的任何阶段任何一个团队都可能成为其他团队的阻碍。这种情况非常普遍但也完全可以避免。团队很容易在不知不觉中陷入“把问题丢给下一个团队”的思维模式。我们希望避免这种情况努力打造目标清晰、自主透明的团队而不是目标模糊、彼此割裂、最终形成信息孤岛的团队。这种方法可以帮助你验证流程而不仅仅是验证软件。总结内部开发者平台是提升研发效能的重要基础设施内部开发者平台可以为组织带来许多收益包括标准化软件交付流程提升其他团队的工作效率实现更快、更可靠的软件发布对软件交付生命周期进行端到端控制将复杂问题集中解决在少数团队内减少重复劳动降低产品团队和工程团队的认知负荷。在设计内部开发者平台时你应该设定清晰的业务目标让所有领导层围绕这个目标保持一致设计合适的团队结构和沟通模式从每个关键团队中抽调成员组建一个核心团队让赋能团队支持核心团队确定一小部分业务价值作为概念验证来构建让所有团队都专注于将概念验证推向生产环境让核心团队专注于构建概念验证所需的基础能力在核心团队内部让团队成员专注于各自负责的价值部分并交付成果。例如你可以这样推进确定价值例如构建一个面向已认证和授权用户展示有用数据的应用程序列出解决方案各个部分的要求例如需要向产品团队提供哪些业务需求产品团队需要向 IDP 团队提出哪些需求IDP 团队需要向云着陆区团队提出哪些需求制定里程碑计划并承诺按时完成将概念验证发布到生产环境。避免陷入“把问题扔过墙”的思维模式避免制造信息孤岛。应当专注于概念验证阶段组建一个整合各方成员的核心团队明确 IDP 的目标并在流程早期就制定清晰、简明的方向。同时还要建立合适的流程支持那些将从 IDP 中受益的团队。先将 POC 投入生产环境。等 POC 成功进入生产环境后再拆分团队并逐步进入第一天和第二天阶段。