平台團隊若仍把 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 留在工程可控範圍內。