摘要内部开发者平台即 IDP是一种面向开发团队的自助服务平台能够帮助企业统一环境管理、CI/CD、应用配置、基础设施编排、部署管理和访问控制。通过建设内部开发者平台组织可以降低开发团队认知负荷减少开发与运维之间的事务性协作成本并提升软件交付效率和整体研发效能。简要概述即使是最先进的组织在面对日益严峻的人才短缺时也很难持续扩大开发产出的规模。因此越来越多企业和开发团队开始从内部开发者平台Internal Developer PlatformIDP的角度重新审视自身基础设施希望借此应对这些挑战并加速大规模软件交付。海外一些分析机构、技术思想领袖、平台供应商以及大型科技公司都已开始关注内部开发者平台。本文综合了各方观点对内部开发者平台进行系统介绍并提供实用建议和相关参考。与此同时本文也将重点讨论企业级内部开发者平台在规划、实施和运营过程中的一些推荐做法。内部开发者平台之所以成为一个重要的新概念是因为它解决了软件交付生命周期中的三个关键挑战提供从开发到生产的环境管理能力并与 CI/CD 集成集成可复用的模式供开发团队在应用程序中使用减少开发团队与运维团队之间的事务性沟通和协作成本。通常来说仅仅增加工程师人数既不足以解决当前问题也无法真正支撑企业长期发展。我们稍后会对此进行更详细的分析。云计算、容器化和微服务架构为组织提供了丰富的内部工具和系统选择用以满足新型环境下的研发需求。内部开发者平台的目标是为开发团队提供足够的工具和资源同时抽象掉底层运维负担。许多开发团队无论是出于直觉还是出于有意识的规划都已经注意到了这些优势。与此同时基础设施相关责任也逐渐转移到少数分散的个人身上由他们承担提供这种抽象能力的工作。很多时候组织并没有意识到自己实际上正在构建一个内部开发者平台或者至少是在构建它的某种变体。有海外技术媒体曾将内部开发者平台比作“雪花”认为没有两个平台是完全相同的。每个平台都会因组织的技术栈、文化、代码库和工具集不同而呈现差异。我们认为内部开发者平台的适应性正是这一概念的核心。也正是这种适应性使内部开发者平台对软件开发组织而言如此强大且具有吸引力。因此本文不会试图给出一个过于学术化的定义而是重点介绍我们在相关资料中看到的各种功能和实现模式帮助读者结合自身情况做进一步调整。什么是内部开发者平台IDP一个由社区驱动的网站为理解内部开发者平台提供了一个很好的起点内部开发者平台由运维团队配置供开发者使用。运维团队负责指定哪些资源应在哪些环境中启动或应根据哪些请求启动。他们还会设置应用配置的基础模板并管理权限。这有助于自动化启动环境和资源等重复性任务并通过强制执行标准来简化维护工作。也有海外技术团队将 IDP 视为“一个工具系统这些工具相互集成到一个中央平台中用于支持内部开发流程。开发者感受到的是一种‘内部平台即服务’”。另一篇海外技术文章也强调了 IDP 的服务属性即它应当满足开发团队的具体偏好一个优秀的内部开发者平台应当能够抽象基础设施决策实现自助式环境构建与现有持续集成、持续交付和部署流程集成并分配基于角色的访问控制。所有这些最好都不需要开发者学习 YAML。在企业落地过程中IDP 往往还需要与研发管理体系形成配合。例如PINGCODE这类智能化研发管理工具可以承接从团队目标、客户反馈、需求清理、评审排期到开发、测试、发布和 Wiki 知识沉淀的全生命周期流程并通过打通研发工具链让数据在不同研发环节之间顺畅流转从而帮助企业更系统地提升研发效能。内部开发者平台的价值为什么企业需要 IDP“所有企业都是软件企业”这句话已经流传了近二十年并被许多企业领导者和战略负责人反复引用和阐释。它强调的是任何组织无论实际所处行业是什么都需要为软件开发团队提供合适的环境使其能够在具备竞争力的规模上应对现代应用开发中的关键挑战。经典的供需问题许多组织通过云采用项目、数字优先计划和数字化转型实现了前所未有的增长。这些举措也给传统上负责为开发团队构建和维护平台的运维团队带来了沉重负担。仅仅通过增加工程师或开发者招聘数量来减少积压工作并更平均地分摊工作量并不能真正解决问题。如果缺乏清晰流程和共识这种“增加人手”的策略并不会立即奏效。原因很简单每个组织的内部技术栈都不同新工程师需要时间弥补知识和经验上的差距才能真正开始为团队创造价值。降低开发团队的认知负荷软件交付团队在日常工作中往往需要兼顾大量任务和职责。内部开发者平台可以减轻繁杂日常任务带来的认知负荷。上下文切换所造成的认知负荷经常被认为是导致开发者生产力下降的重要原因之一。开发者生产力领域的研究者曾指出上下文切换带来的认知负荷是团队不堪重负的主要原因。在关于团队结构与软件交付的相关著作中作者对此进行了精辟阐述如果不考虑认知负荷团队就会疲于承担过多职责和领域。这样的团队缺乏足够精力去精进技艺也难以应对上下文切换带来的成本。同样海外一份 DevOps 状态报告也指出大多数软件开发者和运维工程师都明白在两种不同情境之间来回切换会消耗大量认知资源。除了情境切换本身对人类来说就具有挑战性之外还有一个重要原因每种情境的细节和思维方式都截然不同。然而在组织规划或项目规划中认知负荷很少被认真考虑。这会让开发团队处于明显劣势并阻碍组织取得预期成效。内部开发者平台为团队提供了一组可复用的模式。开发者可以在一个统一交互入口中根据自身角色使用这些能力。这减少了上下文切换次数从而降低了团队的认知负荷。解决自主性与工具多样化的挑战有海外技术专家曾很好地解释过开发团队和运维团队在组织中面临的挑战以及内部开发者平台如何帮助他们显然一个优秀平台必须具备的特征之一是减少积压工作的耦合。平台必须提供不依赖工单创建和任务分配的服务。自助服务是优秀平台的关键特征。平台应当为团队提供自助访问能力具体来说应允许团队自助配置、自助管理和操作平台的功能与资产从而在自主多样化和强制统一之间找到合适平衡而这一点往往很难提前预测。让团队更快交付软件多年来开发团队及其所服务的企业一直致力于以更快的速度交付更高质量的软件。这主要源于用户对新功能的需求以及市场竞争的不断加剧。一些互联网企业对传统行业造成冲击的案例表明企业需要具备快速响应变化的能力才能在瞬息万变的市场中保持竞争力。也正是这种需求推动了敏捷开发和 DevOps 的兴起。此后许多公司无论是云原生公司还是更传统的企业都开始被称为“高绩效 DevOps 组织”。这一概念通常用来描述那些能够更快交付软件并在各自业务领域中超越同侪的组织。用于评估组织是否具备高绩效 DevOps 能力的一些关键指标包括部署频率、交付周期、等待时间和平均修复时间即 MTTR。在某年度 DevOps 状态报告中高绩效组织与内部开发者平台采用之间存在明显相关性。报告发现DevOps 成熟度与内部平台使用之间有着密切联系。高度成熟的公司报告内部平台使用率高的可能性远高于中低成熟度公司。参与内部开发者平台建设的团队内部开发者平台通常由一个专门团队构建和管理我们可以称之为平台团队。除了平台团队之外运维团队负责组织的技术基础设施需求开发团队则负责交付软件。下面将分别介绍这些团队、他们的需求以及面临的挑战。平台团队平台团队的组建是内部开发者平台能否成功的关键因素之一。因此明确并落实团队使命至关重要。通过将平台团队定义为组织内部的独立实体可以让其专注于特定领域并减轻其在原有角色中承担的大量事务性工作负担。有海外技术专家对此强调道平台团队负责构建、部署和监控平台组件及底层平台基础设施并随时响应相关问题。理想情况下平台团队甚至不需要知道平台上运行了哪些应用程序他们只需要负责平台服务本身的可用性。平台在构建和维护过程中需要采用产品思维。我们会在后文进一步探讨这一点。运维团队传统上运维团队负责组织 IT 基础设施中的许多关键要素。与开发团队可能同时只负责少量项目不同运维团队的工作范围通常要大得多。他们需要管理多个环境、数据库、网络、云基础设施以及构成软件解决方案的许多其他要素。与此同时运维团队还负责组织的线上环境。无论是外部用户还是内部用户都会每天通过这些环境与公司进行交互。这就要求运维团队在支持开发团队和保障业务稳定运行之间找到一个微妙平衡。这些团队通常遵循先进先出原则并通过工单系统管理工作。系统故障处理的优先级通常高于其他任务。海外相关 DevOps 状态报告强调高效的 DevOps 组织需要投资内部开发者平台以实现开发者自助服务并减轻运维团队在项目和事务处理方面的负担。许多组织其实是在不知不觉中开始为团队提供内部开发者平台的。例如组织可能会开始标准化使用某一类云平台或者统一部署到专用容器平台上。在构建内部开发者平台的过程中组织会逐一解决各种依赖关系试图在整个软件生命周期中提升交付效率。有海外平台负责人曾写道如果你需要更快发布产品就需要解决这些障碍消除瓶颈并制定策略来处理根本原因。相关技术演讲中也曾提出一些有用指标帮助运维团队评估内部平台的有效性。这些指标通常会围绕平台使用情况、交付效率、故障恢复、用户满意度以及团队认知负荷等方面展开。开发团队内部开发者平台的主要受益者是组织中的开发团队。开发团队通常承担着艰巨任务要么将新功能推向市场要么构建对组织日常业务至关重要的内部系统。开发团队常常需要等待运维团队或 DevOps 团队创建环境才能部署和测试应用程序。由于缺少负责特定应用持续集成和持续交付的集中式平台开发团队往往会选择最适合自己的工具。有海外从业者解释说这会导致“整个组织的控制和审计能力有限”。这通常还会导致组织内部工具高度分散因为各个团队会基于自己熟悉或偏好的工具采用和构建不同工作流程。除了工具分散之外对于那些有严格区域合规或支付安全合规要求的组织来说这还可能造成更大问题。在某云原生技术大会上许多与会者都非常强调开发者需要能够自助维护基础设施。在构建平台的过程中应用开发者是关键客户而易用性是开发者体验的重要组成部分。除非开发者能够快速、安全地配置平台运行其服务的方式以及配置应用程序面向最终用户发布的方式否则云原生平台的价值将无法被充分释放。如何开始建设内部开发者平台通常团队会首先规范和标准化持续集成、持续交付、基础设施即代码和容器编排相关方法。这些技术构成了大多数内部开发者平台的基础。将平台视为产品是构建成功内部开发者平台的关键组成部分。有技术专家强调构建成功的内部开发者平台需要三个关键前提平台是一个产品需要一个长期稳定的产品团队负责构建和运营组织必须愿意将部分或全部应用运行职责从集中式运维和支持部门转移到应用团队组织必须愿意在严格实施一致性与赋予自主应用团队自由和责任之间做出权衡。与此同时也有研究者从业务瓶颈角度指出将内部开发者平台打造为产品正是其成功的关键产品导向的方法关注软件的整个生命周期软件是否实用它是否能帮助客户和用户并最终帮助企业一切都围绕收集客户和市场反馈并据此持续改进软件展开。虽然这一观点最初主要面向业务依赖软件交付的公司但它同样适用于内部产品。内部平台也应该赋予团队管理交付成果的能力就像他们面对外部客户一样。另一位海外技术作者在关于内部平台产品化的文章中写道无论你是平台工程师、工程经理还是产品经理都应该始终记住要以客户为中心并对平台产品进行战略规划。如果没有清晰战略来展现影响力和价值平台最终只会被忽视并长期人手不足而再酷炫的新技术也无法解决这个问题。在把平台作为产品持续运营时平台团队还需要稳定管理需求、反馈、任务、文档和跨团队沟通。WORKTILE这类通用项目协作系统可以作为协作支撑帮助团队围绕目标、任务、日历、甘特图、工时和审批等信息形成统一工作空间减少平台建设过程中的信息分散。内部开发者平台的关键组成部分内部开发者平台是一系列紧密集成的工具和系统旨在为开发团队提供一致的使用体验。不同组织的平台及其构建团队通常都各具特色但许多企业中仍然存在一些共同组件和模式。常见组件包括应用配置管理、基础设施编排、环境管理、部署管理以及基于角色的访问控制。下面我们将逐一介绍。应用配置管理跨多个不同环境管理应用配置很容易变得复杂尤其当应用程序由多个服务和平台组成时更是如此。内部开发者平台通常会像管理代码一样管理应用配置通过源代码管理平台维护应用配置从而实现版本控制和变更管理等关键能力。随着应用复杂度不断增加运行、部署和管理应用所需的配置也会变得更加复杂。通过扩展源代码管理系统中存储的配置范围团队可以在一个中心位置配置外部依赖项并将其与关联应用一起进行版本控制和管理。基础设施编排内部开发者平台需要与组织现有及未来的基础设施兼容。这通常可以通过构建可扩展平台来实现。内部开发者平台往往会与组织工具链进行广泛集成包括流水线、集群、服务器、网络、DNS、防火墙、路由、镜像仓库、制品库等。理想情况下内部开发者平台应成为基础设施即代码的驱动力允许团队以编程方式定义和管理解决方案中的各类组件。通常各个团队或 DevOps 团队会使用基础设施即代码工具构建和部署基础设施。但是如果能将现有脚本集成到内部开发者平台中团队就可以基于已知的架构目录来使用这些能力而不必从零开始理解和维护底层脚本。环境管理创建新环境通常会面临多重挑战例如平台容量不足、团队瓶颈甚至成本限制。团队往往需要等待数天甚至数周才能获得环境即使只是为了测试一些小功能。内部开发者平台则以整体方式构建新的应用环境将应用运行所需的所有依赖项整合到一个统一环境中。这使开发团队可以按需访问自助式环境大幅减少瓶颈并帮助开发团队更快交付成果。内部开发者平台在环境管理方面的价值远不止于为开发团队提供新的测试环境。它还能允许团队按需启动包含所有依赖项的完整应用堆栈并在不再需要时销毁这些资源。在采用按量计费模式的云环境中这一点尤其有价值。因为大型环境例如性能测试环境如果长期闲置往往会造成高昂成本。部署管理向用户交付软件是任何组织中开发团队的关键职责。如何加快交付速度也是长期存在的挑战。持续集成和持续部署的采用让开发团队能够更快、更频繁地部署软件但这也往往带来新的挑战和问题。当内部开发者平台被引入开发生命周期后它会成为所有面向目标环境自动化部署的中心枢纽。内部开发者平台成为“自动化的自动化器”负责部署版本控制以及其他与部署相关的事项。这种集成通常通过 Webhook 实现。除了部署应用及相关组件之外内部开发者平台通常还会提供一个集中入口用于调试所有部署。它也可以成为应用版本的集中管理点使团队能够在同一位置执行部署和回滚。基于角色的访问控制对于任何由多个团队共享的平台而言基于角色的访问控制即 RBAC都是不可忽视的要素。有效的 RBAC 策略可以限制不同团队与平台交互的范围并根据成员在组织中的角色划分权限。除了管理哪些团队可以与平台交互之外RBAC 还可以限制未经授权人员的访问范围。在某云原生技术大会上有安全专家深入探讨了容器编排平台中 RBAC 策略存在缺陷所带来的风险并引用了一句颇具警示意味的话我们由星辰组成但你的 RBAC 不应如此。这句话意在提醒环境中的系统或资源不应像星空一样无边无际、任意开放访问权限。结论内部开发者平台是实现开发者自助服务的关键总而言之内部开发者平台是企业数字化转型和持续发展的关键要素。它使开发团队能够专注于构建真正让客户满意、并推动公司在目标市场中增长的解决方案。但与企业内部任何项目一样内部开发者平台也需要持续评估以了解它对使用团队和构建团队产生了什么影响。内部开发者平台成功的最大驱动力是在平台创建和管理过程中采用产品思维。也就是说平台团队需要持续收集最终用户也就是开发者的反馈并将这些反馈融入平台的持续演进中。在整个过程中关键在于不断发现下一个让开发团队和运维团队分心、使其无法专注于交付成果的任务或问题并将其解决。对于运维团队而言这意味着他们可以将精力集中在真正关乎业务的关键问题上对于开发团队而言这意味着他们能够专注构建最终推动业务增长的功能或产品。