平台团队若仍把 Mac mini 主机当成可替换的「构建虚拟机」，往往忽略核心：队列时间是产品体验指标，不是单纯服务器图表。本篇说明如何测量等待时间分位数、区分调度误设与真实容量缺口，并判断何时加租另一台 Apple Silicon M4 比长期调标签更划算——含对照表、七步规模流程，以及可直接贴进仪表板的数值目标。
若尚在接线 Runner，请先阅读 在 Mac mini M4 上自建 GitHub Actions 掌握注册与安全基线。若失败看起来像重跑而非容量问题，扩硬件前请交叉阅读 不稳定测试隔离与重试预算。
常被误判为「需要更多 Mac」的征兆
- 重试风暴：单一不稳定测试套件可占用绿色构建 约 3 倍 的墙钟时间，抬高队列深度却未增加真实吞吐需求。
- 标签饥饿：任务绑在
macos-xcode15-only却闲置，通用 Runner 却在忙，代表调度器未回填符合条件的工作。 - 单体流水线：单一巨型 workflow 占用 Runner 45～70 分钟，两个 PR 排队也像事故。
- 跨区延迟：从远端对象存储拉 artifact 可能主宰「构建时间」；若桶锁在美东，仅在新加坡加节点而无边缘缓存，问题不会消失。
信号矩阵：队列痛苦与可能根因
建议每周容量检讨使用下表：列描述仪表盘上的主诉，栏指向在核准资本或云端租赁前应先追查的线索。
| 主要征兆 | Runner 平均 CPU | 可能根因 | 首要动作 |
|---|---|---|---|
| p95 等待 > 15 分钟且持续 | > 78% | 真实容量不足 | 加节点或按工作负载类型拆分池 |
| p95 高但仅尖峰 | < 40% | 调度／标签不符 | 审计任务与 Runner 亲和规则 |
| 队列深度随小时波动 | 55～70% | 时区型提交批次 | 重任务时间平移或短期加租 |
| 磁盘延迟警示 | 不限 | DerivedData 或 Docker 层频繁变更 | 缓存挂载、精简镜像、NVMe 运维 |
容量陷阱：平均利用率仅 32% 就买第四台 Mac，多半代表调度器把可用槽位藏在过严的并发上限后面——而非 Apple Silicon 太慢。
决策核对：调校、分片或花钱
| 若此事为真… | …且此事亦真… | 决策 |
|---|---|---|
| 不稳定率 > 任务 8% | 夜间重试后队列变长 | 先隔离测试再扩硬件 |
| 单一 repo 占 > Runner 40% 时数 | 他团每周未达 SLO | 项目专线＋共用溢流池 |
| 亚洲 PR 等待最久 | Runner 仅在美国 | 在港／日／韩／新邻近加 Mac 节点 |
| 任务中位数 < 12 分钟 | p95 > 38 分钟 | 追查尾延迟（测试、签名、网络） |
建立可辩护的等待时间 SLO：七步骤
任何编排器皆可套用；只要能导出入列、开始、结束时间戳，数学同样适用 GitHub Actions 与类 Buildkite 队列。
- 白话定义 SLO：例：「营业时间内 90% 的 macOS CI 在 8 分钟内开始执行」。
- 等待时间 = 开始时间 − 入列时间：除非产品要把手动核准冻结算进同一预算，否则应排除。
- 跟踪每台主机同时执行任务数：绘制最大值，尖峰才是用户有感变慢的主因。
- 按 workflow 类型分段：UI 测试、单元测试、发布构建应有不同 SLO 与并发上限。
- 每周记录 p50／p95／p99：保留 13 周滚动数据以察觉季节性，便于预算季对齐。
- 每季演练「少一台节点」：若抽掉单机即违反 SLO，代表余裕已过薄。
- 文档化升级路径：当 p95 连续 3 个工作日超过目标 2 倍，应自动开容量工单并附图。
区域 Mac 节点如何改写成本与体验
队列深度不只关 CPU。东亚开发者跨太平洋拉多 GB 缓存时，美国 Runner 看起来仍空闲，但体感 CI 极慢。在港、日、韩、新、美放置专属 Mac mini M4 可缩短 SSH、artifact 同步与交互调试的往返。相较每个 clone 都跨洋，Runner 在同区时，握手与 git fetch 每跳常可缩短 18～35 毫秒 量级的延迟累积。
NodeMac 提供 区域方案定价，方便容量负责人建立「美国主容量＋亚太尖峰」模型而无需重复采购硬件。搭配 帮助文档 中的 SSH／VNC 操作要点，工程师需 GUI 调试签名或模拟器时可快速接入。
可信的吞吐护栏：每小时任务数
等待时间恢复正常后，仍应检验可持续吞吐。M4 级主机跑混合流水线时，若任务中位数约 18 分钟，每小时很难长期维持超过 9～11 个满载重任务——维护窗、缓存冷启动与签名服务都会注入抖动。仅 SwiftLint 等轻任务可提高每小时件数，但请在内部 runbook 注明假设，避免财务把营销数字乘以人头。
| 工作负载轮廓 | 任务中位数长度 | 实务上限（每小时／每台） |
|---|---|---|
| Xcode 构建＋单元测试 | 14～22 分钟 | 3～4 |
| UI＋模拟器矩阵 | 35～55 分钟 | 1～2 |
| 仅 lint／类型检查 | 3～6 分钟 | 8～12 |
若实测吞吐持续低于模型 15% 且 CPU 未饱和，核准更多机器前先查 I／O 与外部服务限流。反之若模型与现实一致但 SLO 仍破，则属调度或公平性问题，单颗更快芯片无法根治。
落地实践补充：指标治理与跨团对齐
建议将「等待时间」与「Runner 利用率」放在同一仪表并标注数据来源版本，避免不同团队用不同定义争论是否扩容。平台方可与各产品线约定每季检视：谁拥有 SLO 豁免、谁负担额外节点成本，以及夜间批次与交互 PR 是否分池。对跨国团队，宜在文档中明确写入「地理公平」条款——例如亚太与美洲在相同 SLO 分位上的对照曲线，避免永远由远端同事承担较长等待却无法在预算会议上被看见。当你引入短期云端 burst 租赁时，请同步定义退租触发条件（连续两周 p95 低于门槛即降级），以免临时容量变成永久沉默成本。
另建议把「变更关联」纳入同一套仪表：每次调整 Runner 标签、并发上限或缓存挂载策略，都在变更单附上预期对 p95 的影响与回滚步骤。这样当周一与周五的曲线无法比较时，你能快速判断是流量形状改变还是配置漂移，而不是盲目再加机器。
常见问题
平均队列深度够用来规划采购吗？
不够——平均会掩盖尾端风险。产品与安全稽核在意的是最差体验。请永远把平均深度与 p95 等待、以及按团队分桶的超标任务数一并呈现。
AI 代理工作负载应与人类 CI 共用同一 Mac 池吗？
通常不应在无护栏下共用。代理可产生编译图的爆量请求，对共享队列像 DDoS。请以独立标签与额度预算隔离，或给专用租赁节点，让人类 PR 延迟维持可预测。
2026 年 Mac mini M4 仍是 Apple 平台 CI 的务实积木：Apple Silicon 在单机内整合 CPU、GPU 与 Neural Engine 且省电，原生 macOS 让 Xcode 与模拟器免于脆弱虚拟化，专属实体机比时间共享主机更能稳定支撑 2～3 个并发重任务。NodeMac 在港、日、韩、新、美提供具 SSH 与 VNC 的实体 Mac mini，让集群像数据中心节点而非会睡眠的笔记本。按需租赁把尖峰周转成运营费用，同时把队列 SLO 留在工程可控范围内。