如何为大规模企业场景设计 GitLab

在企业规模下，即便是很小的架构选择，也可能带来远超预期的后果。一套只服务几个团队的部署方案，一旦要支撑成千上万的开发者、仓库和流水线，就可能变成瓶颈。正因如此，部署前做出的每一个决定都格外关键。比如：

部署模式决定了你的团队需要自己运维哪些部分
runner 策略决定了 CI/CD 工作负载如何执行、如何保持隔离，也决定了平台团队要承担多少运维负担
可用性目标决定了冗余和恢复方案
工作负载决定了平台需要多少容量

这些因素共同决定了平台能否在扩张时从容应对，而不是制造出新的运维约束。本指南涵盖：

扩展之前需要敲定的架构决策
如何规划 runner 策略
高可用与灾难恢复的规划
流水线性能在规模扩大后会在哪里出问题
Kubernetes 与云原生部署的注意事项
面向平台团队的架构验证清单

扩展之前需要敲定的架构决策

GitLab 的部署模式决定了平台中哪些部分需要你的团队来定容量、做安全加固、监控、升级和恢复。企业级部署有三种核心选择：GitLab.com： GitLab 的多租户软件即服务（SaaS）产品。应用和底层基础设施由 GitLab 运维，你的组织负责管理自身的 GitLab 配置、集成以及任何自管理的 runner。GitLab Dedicated： 托管在 Amazon Web Services（AWS）上的全托管、单租户 SaaS 产品。底层基础设施由 GitLab 运维，包括更新、高可用和灾难恢复；你的组织通过应用层控制来管理用户和数据访问。GitLab Self-Managed： 你的组织自行安装、管理和维护 GitLab 实例。基础设施由你管理，环境的运维、扩展、安全加固和恢复也由你负责。选择哪种模式，取决于你的组织需要多少控制权，以及能承担多少基础设施责任。例如，你可能倾向于选择：

GitLab.com：多租户 SaaS 模式即可满足需求，且优先考虑尽量减少基础设施运维工作时
GitLab Dedicated：需要单租户隔离，或希望对网络、数据驻留等方面拥有控制权，同时不想自行运维 GitLab 基础设施时
GitLab Self-Managed：需求要求直接控制底层基础设施，且团队有能力运维该平台时

在做决定之前，先把可能直接决定某个选项可行与否的需求写下来。尤其要关注数据驻留、网络隔离、恢复目标和基础设施控制权。然后梳理每种模式留给团队的实际运维工作，包括升级、监控、容量规划、备份和事件响应。做完这一步，核心权衡就会清晰起来：你的组织需要承担多少基础设施责任，又能现实地承担多少。划定了这条运维边界之后，就该规划执行 CI/CD 负载的计算层了。

如何规划 runner 策略

GitLab Runner 负责执行 CI/CD 作业，GitLab 应用则负责协调其背后的流水线。在企业规模下，这种分离很重要，因为应用容量和 runner 容量应对的是不同类型的需求。应用处理 Git、Web、API 和自动化流量；runner 集群承受 CI/CD 工作的量和并发。因此，runner 集群的规模应依据工作负载本身来确定，而不是按开发人员数量来推算。先记录以下信息：

作业数量和时长
峰值并发
操作系统和计算资源需求
网络路径和专用硬件
需要特权或涉及敏感数据的作业
发布窗口、定时扫描等高峰时段

用这些数据估算：要达到你设定的排队时长目标，需要同时运行多少作业。工作负载数据比团队规模更重要，因为开发人员数量相同的两个组织，可能因流水线频率、自动化程度和作业需求的不同，产生截然不同的 CI/CD 需求。

选择合适的 Runner 作用域

Runner 作用域决定了各资源池可供团队使用的范围。实例 Runner 可服务整个 GitLab 实例中的项目，群组 Runner 则只允许指定群组内的项目和子群组访问。项目 Runner 的作用域最窄，适合需要专用凭证、特殊基础设施或更强隔离的工作负载。由于这部分容量只为较少的工作负载保留，当任务量不稳定时，项目 Runner 也可能闲置，因此做决定时要把利用率考虑进去。在满足工作负载信任与算力要求的前提下，选择尽可能宽的作用域。资源池越宽，利用率通常越高；而敏感部署任务或特殊工作负载则可能值得使用专用基础设施。

为自动扩缩容做好规划

自动扩缩容让 Runner 容量可以随需求增减，但运维这套基础设施同样要占用平台工程时间。如果自行管理 Runner 集群，要考虑新资源多久才能可用：实例开通、云配额、镜像下载和缓存可用性都会影响高峰期的排队时长。在额外算力上线之前，要保留足够的就绪容量来吸收短期需求。也可以把这部分运维工作交给 GitLab。GitLab 托管的 Runner适用于 GitLab.com 和 GitLab Dedicated，底层 Runner 基础设施和自动扩缩容由 GitLab 管理。对于希望减少开通、打补丁和扩缩容 Runner 机器所耗时间的团队来说，Runner 策略由此从基础设施管理决策，更多转变为容量与工作负载放置的决策。

让 Executor 与工作负载相匹配

Executor 的选择决定了 CI/CD 任务在哪里运行，以及团队必须运维哪些基础设施。对于云原生环境，Kubernetes executor使用现有的 Kubernetes 集群。对于公有云虚拟机上的自动扩缩容工作负载，GitLab 提供了 Docker Autoscaler 和 Instance executor。哪种合适，取决于任务所需的环境以及团队准备管理的基础设施。使用 Kubernetes executor 时，每个 CI/CD 任务都在自己的 Pod 中运行，集群行为因此成为 Runner 性能的一部分。调度延迟、资源请求与限制、节点容量和自动扩缩容都会影响任务启动和完成的快慢。把这些约束纳入容量规划，Executor 才不会随着 CI/CD 需求增长而成为瓶颈。

高可用与灾难恢复规划

可用性规划应当从停机和数据丢失对业务的影响出发。需要明确：

服务等级目标（SLO）：平台在正常运行期间应维持的服务水平
恢复时间目标（RTO）：服务中断后必须在多长时间内恢复
恢复点目标（RPO）：组织能够容忍多少数据丢失

这些目标共同决定了架构所需的冗余和恢复能力。其中多少工作落在平台团队身上，取决于部署模式。如果使用 GitLab Self-Managed，这些架构决策由你的团队负责。可以把 GitLab 参考架构作为生产可用的起点，再根据自身的可用性和恢复要求调整拓扑。使用 GitLab Dedicated 时，底层灾难恢复基础设施和故障转移流程由 GitLab 管理。客户可以选择一个备用 AWS 区域用于基于地理位置的灾难恢复，GitLab 负责维护主区域与备用区域之间的复制，并在需要时执行故障转移。对于 Self-Managed 部署，恢复设计应把高可用、灾难恢复和备份视为三个不同但互补的层次：

高可用限制主环境中组件故障的影响范围。
灾难恢复在站点或区域整体失效后恢复服务。
备份防范损坏、删除，以及复制可能一并带到备用站点的其他故障。

此外，对于 Self-Managed 部署，要把恢复目标转化为架构要求。确定哪里需要冗余、数据如何复制、备份如何保护关键数据。恢复计划中要包含身份认证、网络等依赖服务。GitLab Geo 提供主动-被动式灾难恢复架构，备用站点从主站点同步。在 Self-Managed 环境中，故障转移需要客户自行执行运维步骤，因此要在接近真实的条件下演练流程，并用 RTO 和 RPO 衡量结果。记录下任何失败的依赖项或可能拖慢恢复的手动步骤，再据此改进设计。

规模化之后，流水线性能在哪里掉链子

GitLab 用得越多，性能规划的重点就会从“按预期需求做容量估算”转向“验证平台在真实负载下的表现”。第一步是找出时间耗在哪里。GitLab 把排队时长和执行时长分开统计，这为排查提供了一个不错的起点。作业的排队时长反映它等了多久才开始，作业时长则记录实际执行时间。流水线时长衡量的是流水线运行所花的时间，不含排队等待。这几个指标指向的瓶颈并不相同。排队时长偏高，可能是 runner 容量不够。执行时间偏长，则可能出在流水线设计、测试套件、依赖下载或仓库传输上。

建立性能基线

在正常负载和峰值负载下分别测试有代表性的项目，看性能从哪里开始劣化。把发布窗口、定时安全扫描、提交密集期等情况都纳入测试，然后跟踪那些能暴露瓶颈的信号：

排队时长
作业时长与流水线时长
runner 利用率
重试与失败
缓存命中表现
制品传输时间
基础设施饱和度

结果要按 runner 池和工作负载类型拆开看，否则全组织范围的平均值会掩盖只影响某些团队或某类负载的瓶颈。据此设定阈值，用来决定何时扩容 runner、优化流水线，或对 GitLab 应用本身做横向扩展。

大仓库和 monorepo 要单独测

大仓库和 monorepo对 GitLab 和 runner 基础设施提出的要求不一样。频繁的 clone 和 fetch 会推高 CPU、内存、磁盘和网络占用，多条流水线同时访问同一个仓库时尤其明显。估算影响时别只盯着仓库大小。clone 频率、并发的 CI/CD 活动、分支模式，以及每个作业传输的数据量，都会影响平台负载。

先优化工作负载，再扩容

优化 Pipeline 设计本身就能减轻平台的压力。让相互独立的 job 并行运行，去掉不必要的 pipeline，缓存频繁下载的依赖，并限制产物的保留时间。对于 monorepo，只在相关路径发生变化时触发 job，并减少每个 job 需要传输的仓库数据量。上线后仍要持续测量，因为使用情况会不断变化。在 Self-Managed 环境中，实际的资源利用情况和工作负载模式才是判断架构何时需要扩容的最清晰信号。

Kubernetes 与云原生部署的考量

在 GitLab 架构中，Kubernetes 可以扮演两种不同的角色。Kubernetes executor 可以把 CI/CD job 作为 pod 运行在现有集群中，而 GitLab Self-Managed 则可以以云原生架构运行在 Kubernetes 上。这两个选择影响的是平台的不同部分，应当分开评估。用 Kubernetes 跑 runner，改变的是 CI/CD 算力的供给和扩容方式；把 GitLab 跑在 Kubernetes 上，改变的则是团队运维该应用及其配套基础设施的方式。

把 Kubernetes runner 当作集群的一部分来规划

使用 Kubernetes executor 时，runner manager 会调用 Kubernetes API，为每个 CI/CD job 创建一个 pod。这样一来，集群本身就成了 runner 架构的一部分。要规划好这些 job 所依赖的 Kubernetes 资源和管控措施，包括 namespace、service account、资源 requests 和 limits，以及工作负载隔离。涉及敏感操作的部署 job，可能还需要与可信度较低的构建工作负载做更强的隔离。容量和配置同样重要。要测试集群自动扩缩容能否足够快地增加节点，以满足你对排队时长的目标。即便集群最终能提供足够的算力，节点供给过慢也会在需求高峰时让 job 一直排队等待。

为 Kubernetes 上的 GitLab 选择合适的架构

把 GitLab 本身跑在 Kubernetes 上，需要做的是更上层的架构决策。对于新的 Self-Managed 部署，GitLab 推荐使用其 Cloud Native 参考架构。在这种模式下，GitLab 各组件运行在 Kubernetes 中，而 PostgreSQL、Redis 和对象存储仍留在外部。当某些特定组件必须留在 Kubernetes 之外时，Cloud Native Hybrid 仍然是一个可选方案。例如，如果团队需要 Gitaly Cluster 来实现仓库级别的高可用，就应当考虑混合架构或基于 VM 的参考架构，因为标准的 Cloud Native 架构中 Gitaly 运行在非集群配置下。无论选择哪种模式，都要把 Kubernetes 纳入整个 GitLab 平台的运维计划。团队需要覆盖集群和外部服务的可观测性，还需要一套把 GitLab 及其基础设施依赖都考虑在内的升级流程。容量测试和恢复测试应当把集群作为生产环境的一部分来覆盖。GitLab 云原生概览对这一部署模式有更详细的说明。当 Kubernetes 的运维模式契合你的基础设施需求，并且团队具备可靠运维它的能力时，再选择它。

平台团队的架构验证清单

在正式上线前，用这份清单逐项验证部署、规格、Runner、恢复和性能方面的关键架构决策。每一项都要么留下支撑该决策的证据，要么指定负责人把缺口补上。

验证内容	证据或负责人
部署模式
所选部署模式满足数据驻留、隔离、网络和定制化要求。
GitLab、平台团队和基础设施提供商之间的职责划分清晰。
升级、维护、支持和容量管理都有明确的负责人和成文流程。
应用规格
预期 RPS 决定了 Self-Managed 部署的基线架构规模。
规格计算反映了 API、Web 和 Git 流量的构成。
设计考虑了大型 monorepo、高负载自动化等非典型工作负载。
Runner 策略
Runner 规格反映了作业量、时长、峰值并发和算力需求。
Runner 作用域与信任边界、特权访问和工作负载隔离要求相匹配。
自动扩缩上限、云配额、启动时间和就绪容量已在峰值负载下测试过。
排队时长和流水线时长目标分别定义并分别监控。
Runner manager 架构避免了关键工作负载的单点故障。
可用性与恢复
SLO、RTO 和 RPO 目标已获业务负责人和技术负责人批准。
冗余、备份、复制和故障转移流程覆盖了所需的故障场景。
恢复测试涵盖身份、DNS、密钥、网络和外部集成。
最近一次恢复演练达成了目标，或已安排整改工作。
性能与增长
具有代表性的项目、monorepo、安全作业和发布工作负载已在预期峰值负载下测试过。
仪表盘跟踪排队时长、作业与流水线时长、错误、基础设施饱和度和 Runner 利用率。
扩缩阈值明确了何时扩容、何时优化工作负载。
架构有固定的评审节奏，以应对使用模式和组织需求的变化。

企业规模会给每一个早期架构决策带来压力。最稳健的 GitLab 环境能够反映组织的实际运作方式，并为需求变化留出足够空间。随着采用范围扩大，这些条件也会演变。持续度量，在需求变化时重新审视架构，让证据驱动下一个决策。这种纪律能让 GitLab 从一个仅仅支持更多用户的平台，变成一个能够跟上组织步伐的平台。

💡 了解 GitLab Dedicated 如何支持企业规模。