开发者基础设施团队建模：从开发工作流到组织协作

过去近十年里，我一直在管理开发者基础设施团队。这样的团队有时也被称为开发者加速团队、开发者生产力团队等。开发者基础设施通常简称为 Dev Infra，覆盖范围非常广。尤其是在一些高度重视工程效率的海外公司中，这一领域往往包括开发环境、持续集成与持续部署（CI/CD）、框架、库，以及各类提升研发效率的工具。

当我开始同时管理多个团队后，我逐渐意识到，为开发者基础设施团队之间的协作方式建立一个思维模型，对我非常有帮助。这不仅有助于我自己理解组织，也能帮助团队中的每个人，包括管理者和一线工程师，更清楚地看到自己的工作位置。

首先，模型可以帮助我们厘清不同团队、不同领域之间的联系与依赖关系。进一步说，它让我们能够以更整体的视角设计系统，减少局部最优带来的问题，避免让用户和开发者体验受到割裂式方案的影响。理解这些联系之后，我们也更容易发现解决方案中的空白，以及不同环节之间衔接不顺畅的地方。

其次，模型能帮助每个人把自己的工作与更大的愿景连接起来，而这对于提升员工投入度非常重要。许多人只有在看清自己的工作如何融入整体图景之后，才会产生更强的动力。

当然，并不存在一个完美且唯一的模型。事实上，使用不同模型来突出不同关系，往往更有价值。团队结构也会不断变化，这可能要求我们重新思考不同团队之间的连接方式。下面我要介绍的是去年我用来理解自己职责范围的一种模型，它反映的是当时的组织结构。实际上，构建这个模型也帮助我重新思考了团队的组织方式，并最终推动我们采用了新的结构。

在展开这个模型之前，先简要介绍一下当时向我汇报的几个团队。

本地环境团队：该团队负责提供工具，帮助开发者在本地开发机上接手新项目或已有项目。这包括克隆代码仓库、安装依赖、运行后端服务，以及完成其他常见开发准备工作。

云环境团队：这是一个相对较新的团队，目标是探索远程、按需开发环境。

测试基础设施团队：该团队负责 CI 系统，持续改进这些系统，并尝试新的方案，以适应公司工程规模的增长。

部署团队：该团队负责开发流程的最后几个环节：将提交合并到主分支；通过金丝雀系统进行验证；并将变更逐步推广到生产环境。

Web 基础团队：由于公司拥有一些规模庞大的前端代码库，我们组建了一个团队，通过工具、库和基础设施来提升基于 React 的应用开发效率。

React Native 基础团队：这个团队类似于 Web 基础团队，但专注于标准化并改进 React Native 应用的构建方式。

移动工具团队：移动应用与 Web 应用存在许多差异，因此该团队专门为移动开发者构建相关工具。

开发者基础设施中的开发工作流

标准开发流程的各个阶段和团队及其职责范围。

理解开发者基础设施团队的一种方式，是把它们放到开发工作流，或者说开发流水线中来看。这个工作流可以分为三个阶段：

开发：设置本地依赖、创建补丁，并进行本地测试。

验证：基于持续集成系统构建代码，并运行测试套件。

部署：将补丁合并到主分支，并把最终镜像交付给生产基础设施。

本地环境团队、云环境团队、测试基础设施团队和部署团队，分别对应上述工作流中的某个阶段。这些团队的职责范围很广，但默认都会支持 Ruby on Rails 应用。

Web基础架构在开发阶段的职责映射

相比之下，移动工具团队、Web 基础团队和 React Native 基础团队所开发和支持的应用与系统，往往会跨越多个阶段。以 Web 基础团队为例，他们的大部分工作集中在开发阶段，包括框架、工具和库；但该团队也维护着一个在验证阶段运行的应用，用于监控包体积。

Web 基础团队构建在本地环境、云环境、测试基础设施和部署团队所支持的系统之上。它们的工作彼此互补，为前端开发提供了更有针对性的工具。

移动工具/React Native 基金会在开发阶段的职责图

移动工具团队和 React Native 基础团队的工作则覆盖全部三个阶段。不过，由于移动应用的发布流程与通用工作流存在明显差异，因此它们在部署阶段往往会采用独立于通用工作流之外的流程。

横向一体化与纵向一体化

我们可以借用商业领域中的一个概念，进一步扩展这个开发工作流模型，从而观察这些团队之间的关系。

在制造业中，横向一体化意味着供应链中的不同环节由不同的、通常规模较大的公司分别承担。生产商、供应商、制造商等都是独立实体，并且在各自的特定领域拥有高度专业化的能力。

本地环境团队、云环境团队、测试基础设施团队和部署团队，可以被视为类似的横向一体化团队。通用开发工作流就像一条供应链，每个团队负责其中的一部分，也就是工作流中的某个阶段。每个团队都专注于该阶段涉及的特定问题领域，通过维护相关系统、优化工作流，并扩展解决方案，来满足不断增长的开发需求。

相比之下，纵向一体化是指一家公司掌控供应链中的多个环节。某家海外家居零售企业就是这种模式的典型例子：它能够掌控从原材料到零售门店的多个环节。由于整条供应链都服务于同一个特定行业，也就是家具及其他家居用品，它便可以以更加整体的方式经营业务。

移动工具团队、Web 基础团队和 React Native 基础团队，可以被视为类似的纵向一体化团队。每个团队负责的一组系统，合在一起覆盖了工作流中的两个阶段，甚至全部三个阶段。

如前所述，这些团队也依赖通用工作流所支持的系统。它们自身的特定解决方案，要么构建在这些系统之上，要么与之并行。因此，它们并不是完全纵向一体化的团队；更准确地说，它们是在特定技术开发工作流中的领域专家，而不是只专注于开发流程中某一个阶段的通用团队。当通用解决方案无法充分满足需求时，它们会根据自身工作流的需要构建相应的解决方案。

用模型分析开发者基础设施团队

现在，我们可以结合开发工作流的概念，以及横向一体化和纵向一体化团队的框架，总结出一些有意思的观察。首先，看看这些团队有哪些共同点和差异。

Dev Infra 中每个团队的工作，通常都可以对应到开发工作流中的一个或多个阶段。这为 Dev Infra 的整体发展提供了一个清晰框架，也帮助我们与上级组织中的其他团队区分开来。反过来，这让我们能够专注于核心工作，避免承担那些不符合这一模式的任务。

基于这个理解，我们为 Dev Infra 制定了这样一条使命宣言：

改进并扩展工程组织的开发—验证—部署周期。

一个有趣的对比是：横向团队面向的用户规模更大，而纵向团队承担的职责范围更广。

横向团队需要支持整个工程组织。几乎每位开发者都会与开发环境、测试基础设施和部署系统发生交互。对于一家持续增长的公司来说，这意味着这些系统的使用量和流量也会持续增长。

另一方面，纵向团队专注于工程组织中更小的细分群体，主要是负责前端和移动应用开发的团队。然而，它们需要为这些技术的完整开发工作流提供有针对性的改进，因此职责范围反而更广。

此外，由于覆盖范围更广，纵向团队也拥有更多协作机会。不过，产品团队也常常会自行解决一些开发者基础设施团队暂时无法优先处理的具体问题。因此，我们必须与产品团队保持紧密联系，避免重复建设，并对那些超出单个产品团队能力范围的基础设施项目进行长期管理。

相比之下，由于支撑公司规模的基础设施通常非常庞大且复杂，横向团队获得的外部贡献相对较少。不过，也正因为几乎没有办法绕过这些系统，它们的使用方式往往更加一致。

从开发者基础设施分析走向组织行动

基于上述分析，我们开始对正在进行和计划开展的工作进行分类。在开发流程的任何阶段，通常都存在三类建设方向。

聚焦：巩固并改进现有系统，提升用户体验，并实现渐进式或线性扩展。

拓展：向外延伸，在问题领域中寻找新的机会，并实现阶跃式或指数级增长。

衔接：改善不同开发阶段之间的连接点，包括数据流和用户体验；同时识别现有团队可以扩展的空白领域，或判断是否需要创建新的团队。

横向团队和纵向团队在这些建设方向上的表现也自然不同。

横向团队的职责范围更加明确，因此更容易确定优先级，但它们的影响也更集中于特定领域。对横向团队来说，衔接类工作往往更难推进，因为这类工作通常涉及多个团队。

纵向团队的职责范围更广，潜在影响也更大；但也正因如此，判断应该在哪些地方投入，才能产生最大作用，会变得更加困难。不过，如果要改进的是同一团队负责的组件之间的连接点，那么推进起来通常会相对直接。

如果希望把这类开发者基础设施模型真正落到日常研发管理中，企业也需要一套能够贯穿目标制定、需求管理、开发协作、测试发布与知识沉淀的工具体系。例如，PingCode 这类智能化研发管理工具，可以帮助团队把研发过程中的目标、需求、项目、测试、发布和知识经验连接起来，让研发管理更加自动化、数据化和智能化。

我们也利用这项分析来调整组织结构。前面提到过，今年早些时候，我们对上级组织做了一些调整。其中一项变化，是成立客户端基础架构团队。这个团队本质上由一些纵向一体化、并且专注于特定技术领域的团队组成，主要面向前端和移动开发。

在开发者基础设施方面，如果其他组织中的现有团队能够帮助我们扩展开发工作流模型，并提供新的横向一体化能力，我们也可能会将它们纳入团队。与此同时，我们正在尝试推动团队之间更积极的协作，帮助开发者更全面地理解整个工作流。

最后，我们计划开展一些覆盖完整开发工作流的用户调研。过去，我们所做的大多数深入调研都局限在团队层面。例如：移动开发者面临哪些重复性任务；测试基础设施存在哪些不足；如何让部署系统更加直观易用。

现在，我们可以进一步研究开发者从编写补丁到最终上线的完整流程。这将帮助我们理解如何构建更全面的开发者基础设施解决方案，并为开发者提供尽可能顺畅的体验。

总结

开发者基础设施团队的价值，不仅在于提供工具和平台，更在于持续改进开发、验证、部署这一完整工程周期。通过为团队建立清晰模型，组织可以更好地理解不同团队之间的职责边界、依赖关系和协作机会，从而提升工程效率、开发者生产力和整体研发体验。

作者负责海外某大型公司的开发者基础设施工作。他在软件行业拥有二十年经验，曾在多家初创公司担任开发者，随后加入某海外开源技术组织，并逐步走上管理岗位。他职业生涯的前半段专注于软件工具和开发者效率提升，并致力于将产品管理理念引入这一领域。