PR 和模擬器工作一多，Mac Runner 就開始排隊，發布任務也被拖慢。最快的解法不是按開發者人數加機器：先用真實佇列與執行記錄拆分工作負載，再估基線容量，最後以試點決定是否擴容或租用。
這篇適合要規劃 iOS CI 資源並準備採購或租賃申請的企業 IT 负责人。
若你負責 GitHub Actions 自託管 Mac Runner 的路由與排隊治理，文中會提供可核對的資料欄位。
FinOps 负责人也可用本文的變數模型，建立能由團隊記錄重算的預算假設。
先分清平台佇列與 Mac 節點容量
GitHub Actions 自託管 Runner 不會因工作流程已啟動，就自動接下任何工作。工作必須符合 Runner 的標籤和 Runner Group 等路由條件；符合條件的 Runner 忙碌或離線時，工作便可能留在佇列。先確認工作是否「找不到合格節點」，再判斷節點不足，否則加機器也未必能消除排隊。GitHub 說明了自託管 Runner 的工作匹配與排隊規則，亦列出工作流程選擇 Runner 的路由方式。
GitHub 文件中的平台並發限制，與企業自行管理的 Mac 節點容量，是不同層次的問題。查閱Actions 限制說明時，要核對限制適用的產品與工作類型；不要把平台配額直接當成企業應配置的 Mac 數量。
怎樣從 GitHub Actions 排隊情況估算自託管 Mac Runner？
不要只看佇列長度的單一快照。相同的佇列數，可能來自短時間集中提交，也可能是節點長期滿載；兩種情況的擴容方式不同。把工作進入佇列、開始執行和完成的時間，與 Runner 標籤、執行結果及節點識別資料對照，才能分辨路由錯誤、短暫尖峰和持續容量不足。
GitHub 的 workflow_job Webhook 事件可用來追蹤工作狀態，並檢查工作標籤及 Runner 相關欄位。你可把事件記錄與 CI 平台的工作執行紀錄配對，計算排隊時間與實際佔用時間，而不是用團隊人數推估工作量。官方事件文件列出 workflow_job 的事件與 payload 欄位。
| 工作場景 | 容量輸入 | 主要限制 | 應核對的證據 |
|---|---|---|---|
| PR 檢查與一般建置 | 進入 Mac 工作的頻率、執行時間、同時執行量 | 通用 lint、文件檢查等步驟未必需要 macOS | 流水線步驟、Runner 標籤、佇列與開始時間 |
| 模擬器測試與回歸 | 測試工作數、矩陣展開方式、工作佔用時間 | 模擬器、Xcode 與測試資料可能限制共用 | 測試工作紀錄、環境標籤、重試和排隊情況 |
| 歸檔、簽名與發布 | 發布任務時間、觸發方式、排程窗口 | 憑證權限、受保護環境和發布流程可能要求隔離 | 發布工作流程、憑證授權與實際執行紀錄 |
| 專用工具鏈或遺留任務 | 特定 macOS、Xcode、架構與工作頻率 | 不相容的環境不能視為同一個容量池 | 標籤路由、工具鏈需求、工作失敗及重試紀錄 |
依工作場景拆分 Mac 建置池
PR 建置和模擬器測試要不要共用節點？
先看限制，不要只看兩者是否都在 macOS 上執行。PR 建置通常較容易拆出不需 Mac 的通用步驟；模擬器測試則可能有工具鏈、測試資料或環境狀態要求。若兩類工作使用不同標籤，或測試環境需要固定版本，應先分開統計需求，再判斷是否能共用節點。
GitHub 的標籤可用於指定自託管 Runner；Runner Group 則能協助管理哪些工作可以使用哪些 Runner。把路由條件寫清楚，才能知道一個工作池是否真的有資格接下某項工作。Runner 標籤文件與Runner Group 說明可供你核對這些設定。
| 配置方式 | 適用狀況 | 主要風險 | 判斷依據 |
|---|---|---|---|
| PR、測試與發布共用池 | 工具鏈相容，路由和權限要求一致 | 測試或發布工作佔住一般建置容量 | 同時執行紀錄、工作等待時間、隔離政策 |
| 一般建置與測試分池 | 模擬器或測試環境有專用要求 | 池間容量可能無法互相補位 | 標籤需求、測試尖峰、空閒容量 |
| 發布任務獨立池 | 簽名憑證或受保護環境限制共用 | 專用資源可能在非發布時段閒置 | 發布時段、憑證權限、審批流程與真實排隊 |
| 遺留工具鏈獨立池 | 任務只能在特定系統或工具鏈執行 | 需維護額外環境，彈性較低 | 工作路由標籤、實際觸發頻率與相容性紀錄 |
PR、模擬器和發布是否分池，應由實際路由及隔離要求決定。不能只按建置耗時推導可共用程度：簽名任務即使執行時間短，也可能因憑證權限和受保護環境而必須走獨立路由。反過來說，若工具鏈相同、權限政策允許，而且記錄顯示工作能互相讓出容量，分池也未必帶來好處。
專用工具鏈與發布任務的隔離界線
把需要特定 macOS、Xcode 或架構的工作標上可辨識的標籤，並核對工作流程是否確實路由到相應 Runner。標籤名稱本身不是隔離證明：你還要檢查 Runner Group 的存取範圍、憑證可用對象與發布審批設定。
對簽名和發布工作，先查清楚誰能觸發工作、哪些環境可存取簽名資料，以及發布工作是否能與一般 PR 任務共用同一節點。若安全政策要求分離，就把它當作容量池的硬性條件；不要為了提高利用率而把不同信任層級的任務混跑。
用團隊記錄推算基線與尖峰容量
容量估算要同時看工作量與工作重疊，而不是只平均建置時間。對每個工作池，記錄觀察期間內的工作數、每項工作佔用 Runner 的時間、觀察窗口、可接受的利用率假設，以及因維護或不可用造成的折減。再用實際同時執行與排隊資料檢查模型是否低估尖峰。
| 模型項目 | 團隊要填入的資料 | 用途 |
|---|---|---|
| 工作量 | 指定觀察窗口內，各工作池的任務數 | 區分一般建置、模擬器、發布與專用工具鏈需求 |
| Runner 佔用時間 | 工作開始至完成的時間，排除單純佇列等待 | 換算工作消耗的節點時間 |
| 可用窗口 | 你希望完成該批工作的時間範圍 | 對應團隊可接受的等待目標 |
| 利用率假設 | 團隊自行設定並以試點驗證的安全餘裕 | 避免用滿載理想值推算容量 |
| 可用性折減 | 維護、重啟或環境準備造成的實際不可用時間 | 修正紙面容量與可接單容量的差距 |
| 尖峰及隔離需求 | 同時工作紀錄、路由條件、發布限制 | 推出峰值與專用池的最低承載要求 |
對單一工作池，可用「工作數 × 平均 Runner 佔用時間 ÷（觀察窗口 × 利用率假設 × 可用性折減）」估算基線，再依團隊的節點粒度向上取整。這是企業內部的估算模型，不是 GitHub 官方指標，也不會自動保證特定等待時間。尖峰容量則要用實際重疊工作的紀錄校驗；如果模型算出的基線能承接平均工作量，卻仍在集中合併時形成長佇列，就要調整尖峰方案，而不是把平均值當成完整答案。
GitHub 提供 Runner Scale Sets 等擴縮方式，但平台的擴縮機制不會替你決定工作池的安全界線或容量目標。可參考Runner Scale Sets 概念文件及部署與設定說明，再以團隊實際佇列和執行記錄調整方案。
容量試點與擴容里程碑
團隊 iOS CI 負載波動時，如何安排 Mac 節點擴容？
先分清楚尖峰排隊是短暫突發，還是基線容量長期不足。集中合併或回歸測試可能造成短時間需求上升；若工作在尖峰後迅速消化，增加常駐節點未必划算。若佇列持續出現，或關鍵發布工作反覆等待，就應檢查工作池是否不足、路由是否錯誤，以及節點是否受工具鏈和權限限制。
依以下檢查清單完成容量試點；每項都應留下可供 IT、平台工程與 FinOps 一起覆核的記錄。
- [ ] 從 CI 紀錄匯出工作觸發、排隊、開始、完成和失敗資料，並標明工作池。
- [ ] 把可改由非 Mac Runner 執行的通用步驟移出 Mac 工作流程，重新統計 Mac 任務。
- [ ] 依標籤與 Runner Group 核對 PR、模擬器、發布和遺留任務的實際路由。
- [ ] 將簽名憑證、受保護環境與發布審批列為硬性隔離條件，不能以節點利用率取代安全判斷。
- [ ] 用工作數、Runner 佔用時間、窗口、利用率假設和可用性折減計算各池基線。
- [ ] 對照集中提交、回歸和發布時段的同時執行紀錄，推導尖峰與備援需求。
- [ ] 以試點記錄比較擴容前後的排隊時間、失敗重試和節點可用狀況，再決定常駐或彈性容量。
把試點結果分成基線、峰值和備援三種需求。基線用來承接日常工作；峰值對應已觀察到的突發佇列；備援則處理維護、重啟或特殊工具鏈造成的不可用情況。這三者不必全部轉化為長期自購設備：若尖峰短暫、工作池可清楚隔離，而且租期與交付方式符合團隊排程，可以評估彈性租用；若工作全年穩定且持續高負載，則應把自購或長期配置納入總持有成本比較。
自購、租用與混合配置
每種做法都要計入設備或租期成本以外的項目。自購的成本還包括採購交期、維護、折舊與閒置容量；共享建置機則要處理排隊、環境互相影響及權限邊界；遠端租用也需核實配置、租賃周期、交付方式、資料處理要求和服務是否適配你的工作負載。沒有團隊自己的任務量與預算資料，就不應直接宣稱哪種方式一定較便宜。
你可先對照 VMSPIN 的價格與租期資訊，再確認頁面列出的配置和交付方式是否符合工作池要求。若仍在規劃可行性，先以現有自購設備或暫時保留的容量完成試點；只有在佇列證據顯示需要補充 Mac 資源，而且租用條件可核對時，才把租賃容量納入正式方案。確認符合需求後，可查看 VMSPIN 的 Mac 租用選項。
若你目前以團隊自購 Mac 作為常駐建置機，前期資本投入、設備維護和尖峰以外的閒置，都是需要納入 TCO 的真實成本；若改用一般非 Mac 執行環境，則不能假設它能承接必須由 macOS 與 Xcode 執行的工作。對短期試點、突發回歸或尚未確定長期節點數的團隊，租用 VMSPIN 的遠端 Mac 可作為補充容量的選項；先按工作池核對配置、租期與交付，再用實際排隊記錄決定是否保留。若你的負載長期穩定且持續偏高，或任務必須使用現場實體介面，則不應只為追求彈性而租用，應先比較自購與混合方案的總成本及操作限制。