你有没有那种时刻：流水线页面七个作业，五个红的，点开第一个——空的；点开第二个——还是空的；点开第三个，你已经开始翻浏览器设置，怀疑是缓存、是插件、是这台电脑该换了。
都不是。作业压根没启动。
【舞台提示：服务器在远端礼貌地沉默】
这事儿的原文是一个实习生十月十九号发的，我读的时候笑了一下，然后想起自己干过一模一样的事——在零日志的页面上翻了二十分钟，把 diff 重读一遍，把 YAML 缩进数了一遍，最后去确认 runner 是不是掉线了。
一分钟能问清楚的事，查了二十分钟。
“作业没启动”这五个字本身就挺黑色幽默的。页面不会告诉你“我没跑”，它告诉你“我失败了”。这两句话在工程师脑子里的处理路径根本不是同一条：前者你会去查配额、查权限、查配置；后者你会去读代码。
代码读一百遍也读不出账单来。
之前有一次是 terraform 的 plan 作业，点进去零行日志，连个 stack trace 都没给。我第一反应是“GitLab 又抽风了”，第二反应是“是不是 provider 版本搞错了”，第三反应才是“今天几号”。
第三反应才是根因。
顺手说一句，评论区还有人补充过另一种零日志：群组 runner 令牌过期，没有 runner 来接活，界面同样一个字都不给。这类故障的共同点是，它们都不长在代码里，但都长得像代码的错。
然后是全篇我觉得最荒诞的一处：分钟数不挂在个人名下，挂在账户层级。想看？得 Owner。
也就是说，最需要知道余额的人，和唯一有权看余额的人，是两个不同的人。
这不是技术问题吧。这是组织架构图直接长在了产品界面上。
我甚至能想象那个评审会：有人提过一句“要不要让普通开发者也能看到剩余额度”，然后被“权限模型”四个字礼貌地请了出去。
故障没长在代码上，长在组织结构上——这句我不加粗，你们自己记。
再往下。她点了重试，页面顶上弹了个报错，大意是状态无法通过 drop 转换。她的理解是，GitLab 没法更新一个从来没启动过的作业。
这个报错文案值得裱起来。你申请一样东西，系统回你：“这笔单子的状态无法从‘不存在’转换为‘已提交’。”
听着像财务报销系统，像某些政务 App，像你妈问你到底什么时候结婚。
（最后这个跳得有点远，但我留着，因为它真的很像。）
顺便，这个重试动作本身堪称完美幂等——点三次，三次同一个报错，副作用为零，信息量也为零。我甚至想过要不要把它标记成 interruptible，可惜它连启动都没启动，打断它都属于越权。
然后是最真实的那个场景。工单几天没动，站会上你得站起来说：“工作做完了，但跑不了。”
这句话说出口是需要心理建设的，因为它听起来像借口，而它偏偏是真的。你说完，PM 点头，Scrum Master 记一笔，大家心里同时闪过“哦，又一个环境问题”。
其实不是环境问题。是这个月的分钟用完了，而当时在座的没有一个人有权限确认这件事。
你看，又绕回去了。
真正的解法：给管账户的同事发一条消息，两句话，改动已就绪、流水线因月度额度耗尽跑不起来。对方回，是，用完了，充了。重试一次，绿了。
一分钟。
前面那二十分钟的 diff 重读、缩进数数、runner 掉线排查，全是在给一张账单做无用功。这二十分钟算不上渡劫，只能算渡劫之前的热身——真正的渡劫是你查完一整圈，发现答案写在财务那边的 Excel 里。
我有时候想，把这类故障的发生频率和工程师花在上面的时间乘一乘，大概能说服任何一家公司去买点什么。算了，不推销。
顺手说个冷知识：GitLab 16.1 把 CI/CD minutes 改名成了 compute minutes。名字改了，账单没改。你搜旧帖搜不到新名，搜新名搜不到老答案，中间隔着一个版本号的距离。
有人总结过省分钟的办法，rules:changes 只让相关目录的变更触发作业之类，我看了一半就关了。不是没用，是你得先知道自己家在漏，才谈得上堵。
我现在的习惯是，遇到红叉先看日志长度。日志为空，立刻去看日历。
月末加空日志，基本可以直接去找 Owner。找不到 Owner，就去找那个平时最烦听到“预算”两个字的同事，他一般知道钱在哪儿。
这个发现我打算灰度发布给团队——先跟同桌说，看他笑不笑，笑过了再往群里发。免得又变成一次“你看，我早就说过”的复盘会。
（郑重声明：本文不构成任何配额管理建议，只构成一份“我为什么又在工位上假装很忙”的情况说明。评论区扣个同款，我去看看这个月还剩几分钟 🫠）