摘要

  • GitLab.com 托管任务的计算用量记在项目所属的顶层命名空间，而不是每位操作人员或每个子群组各有一份独立预算。项目管理上的分工不等于计算额度隔离。
  • 额外购买的分钟在套餐内月度额度之后使用，未用部分可以结转，但不能在群组之间转移。十二个月的有效期与目前尚未执行的过期限制，也不能合并理解为永久有效。
  • 额度是否充足、是否有适用的执行器，以及任务是否获得安全执行的授权，是三件事。换一份预算或改用自有执行器，不能代替对测试价值和运行环境的判断。

余额在公司里，不一定在需要它的地方

采购账上还有计算分钟，不代表每个 GitLab.com 群组都能使用它。官方的额外分钟购买说明明确规定，已购分钟不能从一个群组转到另一个群组。一个群组留下的余额，与另一个群组需要补充的额度，可以同时存在。

这并不是对某家客户浪费预算的指控，而是产品规则允许出现的一种情况。设想一家公司有两个顶层群组，其中一个承担季节性较强的项目，另一个持续开展开发工作。即使财务把两者视为同一个成本中心，平台也不会因此把已购分钟合并成一份随取随用的公司储备。财务汇总改变了报表，未必改变权益能够使用的位置。

这条边界值得先看清，因为买方很容易把“同一家公司付款”理解成“同一家公司内部可以调度”。云服务并不总按法人或部门预算来划分资源。在这里，群组是购买和使用额外分钟的重要边界。它既让责任归属更明确，也要求采购人员在付款时知道，未来的工作究竟会发生在哪里。

时间边界同样不能省略。额外分钟是一次性购买，用完套餐内的月度额度后才开始消耗；未用部分可以带到下个月，但不会在每个月重新增加一包。文档给出的有效期是购买后十二个月，目前尚未执行过期限制，同时又明确不保证过期后仍然有效。因此，“今天还能看到余额”和“长期有权使用这份余额”不是同一句话。

套餐升降级则属于另一类变化。文档表示，已购分钟在不同套餐之间转换时仍然保留，包括降到 Free。把这些规则分开看，才能理解储备的实际性质：它能跨月结转，能随某些套餐变化保留，却不能据此推导出跨群组自由转移或永久有效。本文没有检查客户合同，也不据此判断特殊协议、退款或个别迁移的处理方式。

群组里面，边界又比项目宽

在群组外侧不能自由调拨，在内侧却可能共享消耗。计算分钟文档把任务用量计入项目所属的顶层命名空间。某人到团队项目里触发任务，并不会因为按钮由他点击，就自动消耗他的个人命名空间额度。

GitLab 的命名空间说明区分个人和群组命名空间。群组可以包含子群组，子群组继承部分上级设置，也能拥有自己的配置。但是项目名称不同、子群组设置不同，并不等于它们各自拥有独立的顶层计算预算。

可以用另一个明确的假设理解这一点：产品团队与内部工具团队，各自管理代码、安排负责人、决定测试时间，却同属一个顶层群组。内部工具项目多跑一批托管任务，产品项目可用的共同余额就相应减少。两边不必改动彼此的仓库，也能在额度上相互影响。这不是平台异常，而是共享方式本身的结果。

共享当然有价值。如果两个团队的高峰错开，公共额度可以承接需求变化，减少逐个项目补充余额的麻烦。问题不是共享一定错误，而是共同承担需求波动的人，有没有共同决定优先顺序。项目负责人可能只看自己的进度，群组负责人却要面对几个项目加起来的消耗。组织图若没有反映这层关系，责任就会在额度吃紧时才显现出来。

这也解释了为什么“每个项目自己控制成本”不够具体。成本究竟在哪里计量，谁有能力改变消耗，谁收到告警，谁能批准购买，是四个可能不重合的位置。预算管理首先需要把它们连起来，而不是先要求所有团队减少构建次数。

一次流水线有不止一种时间

计算分钟不是从流水线开始到结束的简单秒表。GitLab 按任务执行时长除以六十，再乘以相应成本系数计算用量；处于创建和等待状态的时间不计入这段执行时长。流水线的用量则汇总其中实际运行的任务，所以任务并行时，用量可以超过流水线的经过时间。

例如，假定三个互不依赖的任务各运行十分钟，成本系数均为一，且没有其他任务或额外开销。它们同时运行，可以在同一个十分钟区间里完成执行，但合计消耗三十计算分钟。这个简化算例只说明计量方式，不能用来预测真实任务速度、报价或节省比例。

买方因而不能只用“流水线变快了”证明公共额度得到更有效利用。变快可能来自消除重复步骤，也可能来自增加并发资源，还可能来自省掉原本需要的检查。这三种变化在图表上都能缩短时间，商业含义却完全不同。

官方流水线效率指南讨论关键路径、任务依赖、执行资源、镜像与依赖准备等因素。它也指出，并行测试能够缩短总耗时，但需要更多执行器同时工作。更有价值的判断，是把任务结果与资源消耗一起看：必要验证有没有完成，失败是否更早被发现，重复工作是否真正减少。

如果只奖励速度，承担复杂而必要检查的项目可能显得不够高效；如果只奖励少用分钟，团队可能把需要完成的工作推迟到别人的时间表里。共享预算把这种考核偏差放大，因为局部选择最终会在同一份余额上汇合。

用尽后的处理，不是每个任务再送一千分钟

额度执行规则给出了比较具体的顺序。剩余额度低于百分之二十五、低于百分之五，以及降到零时，会显示应用内提示，并向命名空间所有者发送邮件。提示提供了提前决策的机会，但收件人不一定就是正在增加任务量的人。

适用的可用额度耗尽后，实例执行器停止处理新任务。已经启动的流水线中，需要这些执行器的待执行任务或重试任务会被丢弃。正在执行的任务可以继续，直到整个命名空间的用量超出配额一千计算分钟；此后仍在运行的任务也会被丢弃。项目级和群组级执行器不受这一项计算配额影响。

这里的一千分钟必须按命名空间整体理解。它不是每个项目各得一千分钟，也不是每个运行中任务都拥有自己的宽限储备，更不是对流水线最终完成的保证。多个任务仍可能同时消耗这段空间，把它当作可靠的最后一道计划，会忽略共同消耗的速度。

这一规则还要求区分两种看起来相似的现象：服务故障导致任务无法处理，与客户额度用尽导致任务按规则停止。两者都可能表现为工作不能继续，但前者需要服务恢复，后者需要有权限的人作出购买或工作安排决定。本文没有发现并声称某起 GitLab 客户停工事件，也不把文档中的执行行为写成实际故障。

因此，告警应当接上决策，而不只是被转发。所有者收到提示之后，谁核对即将开始的测试批次，谁判断是否需要补充，谁能及时完成购买，这些组织安排决定了提示的实际价值。购买角色和触发任务的权限不同，本身并不构成缺陷；没有人负责连接两者，才会让共享额度成为难以解释的障碍。

买到更多分钟，也还要有地方安全地运行

分钟余额只回答商业额度问题。GitLab 的执行器说明还列出标签、范围、状态、容量与能力等匹配条件。账户有余额，不等于任务一定能匹配到合适的执行环境，也不等于可以买到越过保护规则的权限。

托管执行器文档提出的启动时间目标，是百分之九十的任务在一百二十秒内开始执行。这是服务目标，不是本文测得的达标率，也不是为下一次任务预留机器的承诺。通常的 GitLab.com 托管任务使用新建的专用虚拟机；社区贡献等特殊安排不能被一概而论。

在观察上，也不能把各个计量面混成一个数字。CI/CD 分析页面提供流水线时长、成功与失败等表现指标，而命名空间额度反映共同资源的消费情况。流水线的中位时长下降，不能证明额度消耗下降；余额增加，也不能证明必要的检查更容易按时完成。部分任务级分析还有独立的套餐和可用性条件。

分叉仓库进一步说明，换一个资源来源并非纯粹的财务动作。合并请求流水线说明中，来自分叉的请求通常在分叉项目里运行，使用该项目的资源。获得适当权限的主项目成员可以改在主项目中触发运行，使用分叉分支的配置，以及主项目的设置、资源和发起成员的权限。

这个选择需要对代码可信度作判断。GitLab 明确提醒，运行前应审查来自分叉的不可信代码。受保护变量和执行器也有另外的限制，不能将上述说明扩大为“在主项目运行就会暴露所有秘密”。为了找一份还有余额的预算而改变执行位置，可能同时改变风险由谁承担；不能只核对付款方。

自有执行器也有类似问题。项目级或群组级执行器可以不受实例执行器的这项额度限制，但运行环境需要有人管理。自管理执行器安全说明讨论了共享、非临时环境的跨项目风险。少经过一个计量器，不会让主机维护、任务隔离或容量安排自动消失。

所以，这份采购判断的核心不是托管是否昂贵，也不是建议买方拆分所有群组。它是把一条原本容易藏在配置里的边界放回决策桌上：哪些项目应该共担波动，哪份已购储备实际可用，谁有权在公共额度耗尽之前采取行动。

资料与适用范围

本文依据截至二〇二六年九月三日查阅的 GitLab 官方文档：计算分钟、额度执行、额外分钟购买、命名空间与流水线效率。

运行与授权边界依据执行器、托管执行器、合并请求流水线、自管理执行器安全及CI/CD 分析。没有使用客户私有账单、遥测或协商合同。额度分析针对 GitLab.com，不将同一商业安排套用于所有 Self-Managed 或 Dedicated 部署。