2026 年 iOS CI「彈性池 + 常駐基線」：GitHub Actions 託管 macOS 分鐘費與專用 Mac 雲節點如何分工 PR 與 Nightly（容量閾值與佇列 SLO 決策表）
如果你已經習慣像管 VPS 一樣寫 Actions YAML，卻仍在月底被「分鐘費 + 排隊」雙重暴擊，問題多半不是少買幾核，而是把尖峰 PR 流量和低頻但重的 Nightly/Archive 綁在了同一種算力上。本文給平臺負責人一套 2026 可落地的「彈性池 + 常駐基線」模型：先拆痛點，再給三種模式對照表，接著是 PR/Nightly 路由規則、容量閾值與五步清單，最後附 FAQ；讀完你能用一張表向財務解釋為何既要託管分鐘數，也要獨佔 Mac 節點。
目錄
1. 四類痛點：為什麼「只買託管分鐘」或「只租一臺 Mac」都會翻車
2026 年成熟團隊很少在「要不要 macOS」上爭論，真正消耗會議時間的是：同一套流水線裡，誰在承擔排隊方差，誰在承擔磁碟與鑰匙串的長期漂移。
- 分鐘費與排隊耦合：GitHub Actions 託管 macOS 把「等池子」和「真編譯」混在一條賬單曲線裡；若不拆指標，財務看到暴漲會誤判為程式碼變重，而根因可能是組織級併發頂到共享池天花板。
- 單臺常駐 Mac 的資源爭用：把 Nightly Archive、UI 測試和臨時實驗分支全堆在一臺裸金屬上，DerivedData 與鑰匙串爭用會讓失敗模式看起來像 flaky test，實際是 IO 與併發策略缺失。
- 映象漂移 vs 黃金工具鏈：託管映象升級快，利於安全補丁；但對需要凍結 Xcode 小版本與 Ruby/Node 側車的團隊，頻繁漂移會拉長「為什麼上週能過」的排障鏈。
- 低頻重任務的可預測性：上傳符號表、公證、長時 UI 矩陣對「穩定出口與磁碟餘量」敏感；這類任務放在彈性池也能跑，但尾部延遲與重試成本往往高於在專用節點上預留槽位。
2. 決策矩陣：僅彈性池、僅常駐 Mac、混合三種訊號
混合不是「再買一個神秘中介軟體」，而是明確：尖峰用託管池吸收，重鏈路用 Mac 雲基線兜底。
| 維度 | 僅 GitHub 託管 macOS（彈性池） | 僅專用 Mac 雲（常駐基線） | 混合：PR 彈性池 + Nightly 常駐 |
|---|---|---|---|
| 典型適用 | 分支多、PR 頻、單 job 輕到中等 | 強合規、固定出口、多 Xcode 並存、長期 Daemon | 既要控制月底分鐘費尖峰，又要穩定上架鏈路 |
| 佇列風險 | 組織併發與共享池敏感 | 由你設定 max parallel，風險轉為本地磁碟 | PR 等池；上架相關 job 跳過池子排隊 |
| 賬單形態 | 按分鐘尖峰，易與提交頻率相關 | 主機租金屬性更平滑 | 分鐘費覆蓋高頻輕任務，租金屬性覆蓋重任務 |
| 運維心智 | 偏 YAML 與快取策略 | 偏 SSH、launchd、磁碟水位 | 需要統一標籤路由與觀測面板 |
2.1 PR 與 Nightly 的可執行路由規則（建議預設）
把路由寫進分支保護與標籤策略，避免「誰先在 YAML 裡搶到 runner」變成隱性優先順序。
- PR / feature 分支：預設
runs-on: macos-latest（或組織內更大記憶體規格），限制並行矩陣上限；禁止在 PR 上預設開啟全量 UI 目的地矩陣。 - main 合併後 Nightly：使用自託管 label（例如
runs-on: [self-hosted, mac-ci-baseline]）指向專用 Mac 雲；同一節點用佇列深度 1～2 控制 Archive 爭用。 - Release / Tag：強制走常駐節點並繫結單一構建使用者與審計域；與內部製品倉同區域以降低上傳尾延遲。
jobs:
archive:
if: startsWith(github.ref, 'refs/tags/')
runs-on: [self-hosted, mac-ci-baseline]
3. 五步落地：從度量到路由到驗收
- 拆賬單與耗時：在 Actions 側匯出四周資料，把排隊、編譯、上傳、快取恢復分段；若排隊佔比連續高於內部閾值，把最重 job 遷出託管池。
- 寫清標籤契約：
mac-pr-elastic與mac-ci-baseline兩類 label 文件化，禁止個人倉庫預設佔用 baseline。 - 磁碟預算：為每個併發 Archive 預留約 40GB 可用餘量；DerivedData 按 job 隔離路徑，夜間 gc 非同步執行。
- 佇列 SLO：對 Nightly 定義「開始執行」的 P95 目標；超過則增加 baseline 槽位或拆分重鏈路，而不是盲目加託管併發。
- 試點驗收：選非核心業務倉庫先跑雙軌一週，對比失敗型別（超時 vs 編譯 vs 簽名）與分鐘費曲線，再切換主倉。
4. 三條可引用指標：佇列、磁碟、賬單結構
- 排隊佔比：若排隊時間佔端到端超過 15% 且與提交頻率相關，彈性池已出現結構性瓶頸訊號。
- 磁碟水位：NVMe 可用空間低於約 15% 時，Swift 大工程連結階段長尾顯著變長；這是常駐節點最常見的隱性故障源。
- 分鐘費結構：當「重試 job」分鐘數超過總分鐘數的 25%，優先檢查是否把 Archive 與輕量 lint 混在同一佇列策略裡。
5. FAQ：分鐘費暴漲、搶鎖、多 Xcode
問：混合會不會讓運維複雜度翻倍？ 複雜度從「神秘變慢」遷移為「可觀測的兩類 runner」；用統一標籤與儀表盤反而更易審計。
問：只有一臺 Mac 夠嗎？ 作為 baseline 至少保證 Nightly 與 release 不互相搶鎖；PR 仍走託管池。規模上來後再水平加第二臺 baseline 做熱備。
問：多 Xcode 版本放哪？ PR 池保持單一黃金版本；baseline 用分割槽或不同使用者環境隔離 DEVELOPER_DIR，避免隱式 xcode-select 漂移。
6. 結論與下一步
僅堆託管分鐘能緩解短期排隊，卻難以為 Archive、公證與固定工具鏈提供可審計的長期宿主；只租一臺 Mac 又容易被 PR 尖峰與 Nightly 爭用拖入 flaky 地獄。把兩者拆開路由，才是 2026 年平臺團隊最省會議時間的做法。
純託管路徑在磁碟形態與併發控制上仍受多租戶策略約束，難以把 macOS 當成你完全擁有的構建土地；單點自建 Mac 則要承擔補丁、監控與電源半徑。對要把 iOS 交付做成穩定產能的團隊，租賃 VPSMAC 的 Apple Silicon Mac 雲節點，用 SSH 與 launchd 延續你從 Linux VPS 養成的運維習慣，同時把重鏈路從共享池排隊裡解放出來，通常比繼續在一張賬單上「硬扛尖峰」更接近問題本質。