一次运行的团队来自它的项目
不是来自你。一次运行的团队取自它的项目，并在提交时盖在作业行上。 两半都很关键。一个人可以属于多个团队，所以按团队成员求和会把一次运行算到所有团队头上。而一个项目 在部门之间挪动，不能改写上个季度的用量，这正是团队被冻结在那一行上、而不是读取时再 join 的原因。 所以要改一次运行算在哪个团队头上，就是挪那个项目：两份配额，而且读法不同
你自己的配额和你团队的配额都会被检查。团队那一侧有两条语义和按用户的那套正好相反，值得知道是哪两条：
超出团队配额时，作业带一个
teamQuota 原因在 QUEUED 里等，和个人配额完全一样。信息里会点名那个
团队。
借用，以及什么能被要回去
开了抢占并有许可证时，团队配额不再是一个上限，而变成一个保障额度。集群空闲时你的团队可以跑到 它之上，而超出的那部分是可被回收的。 在你一个正在跑的作业被回收之前，五个条件必须全部成立：- 索取方的团队低于自己的保障额度。否则这只是一个团队在竞价压过另一个。
- 你的团队高于自己的保障额度。否则回收会打破配额唯一的那个承诺。
- 是不同的团队。
- 你的作业已经跑过一个最短运行时间。否则一个繁忙的队列会整天地回收、准入、再回收，而集群把时间 花在写 checkpoint 上。
- 你的作业持有的正是紧缺的那个卡型。
QUEUED。见
作业状态。
让一次运行过掉预算
你团队花完这个月的预算时，一个排队中的作业会这么说。为那一次运行申请一个例外：申请更多配额
subject_type 是 user 或 team。你没写的字段不会被改动。
只有一级审批，没有链式。联签属于你们组织已经在用的那套审批系统；这个平台对它欠的是一条记录和一个
webhook。
跟踪一个请求
status 是 pending、approved、rejected 或 expired。每个请求都带一个有效期，所以没人回答的
请求不会永远敞着。
确认成功
QUEUED，
不用你重新提交。
决定会在任何东西被应用之前就把请求推到它的终态，所以两个审批人同时点，产生一个效果。