雲 Mac 上跑 CI 爲什麼總卡在隊列與磁盤兩頭燒
很多團隊把「能上 Xcode」誤當成「能上 CI」。實際上 CI 的瓶頸往往來自三類耦合：第一類是網絡耦合，Runner 與私有 registry、對象存儲或內部 Maven/NPM 代理不在同一區域，git fetch 與 large file 拉取會把 p95 拉長到分鐘級；第二類是磁盤耦合，Xcode 的 DerivedData、模擬器運行時與並行測試日誌同時增長，256GB 與 512GB 檔位在兩周內就可能進入持續抖動；第三類是調度耦合，交互式遠程桌面會話與無人值守的 nightly 任務共享同一標籤隊列，導致高峯期出現「人類搶不過機器」的飢餓現象。
在新加坡、日本、韓國、香港、美國東部與美國西部六類節點都可選的前提下，2026 年更穩妥的做法是先凍結工作負載類別，再談選區。下面五個痛點對應五類真實事故籤名，可直接貼進你們的值班手冊作爲一級分類。
跨區製品拉取：Runner 在東京而只讀製品桶在新加坡，夜間並發 20 路 job 時，對象存儲的跨區域讀帶寬成爲硬頂，構建排隊呈指數上升而非線性。
LFS 與二進制依賴：美術資源、預編譯框架與測試夾具走 LFS 時，若未在 Runner 側做同區緩存或近鄰鏡像，單次 pipeline 的冷啓動成本會吞噬掉「換區省下的交互延遲」。
DerivedData 與模擬器並發：多模擬器並行 UI 測試會把統一內存與 NVMe 隨機寫同時頂滿，表現爲偶發超時而非穩定失敗，排錯時極易誤判爲網絡問題。
隊列標籤過粗：所有任務都打 mac-ci，導致輕量 smoke 與全量編譯搶同一併發槽，發布窗口前出現無意義的 retry 風暴。
租期與峯值錯配：爲兩周衝刺包月兩臺高配，卻在第三周起長期閒置；反過來只用日租卻未預留鏡像預熱窗口，導致「省錢反而更貴」。
把上述五類問題拆開之後，選區與規格決策會顯著變簡單：交互類任務優先貼近成員 RTT，製品與 CI 類任務優先貼近只讀依賴與控制面，常駐 agent 再單獨評估 CPU 佔用與心跳穩定性。若你希望把「成員與 API 雙路徑」寫成更完整的團隊級策略，也可以對照站內另一篇《2026年跨區域開發團隊 Mac mini M4 雲租策略》裡的矩陣方法，把本文的隊列與製品規則嵌進去作爲執行層。
DerivedData 滿了該擴容、並聯還是短期日租第二臺
這張矩陣刻意用「可觀測信號」而不是口號來分界：當你能持續看到磁盤水位與隊列深度兩條曲線同時上升，優先懷疑磁盤與緩存；當磁盤健康但隊列深度長期高於並發能力，優先懷疑並行度與機型檔位；當峯值只在發布周出現，優先用短期第二臺實例做對衝而不是立刻把主實例鎖到頂配長租。
| 維度 | 同區加盤或升 SSD 檔位 | 並聯第二臺同區 Runner | 短期日租 burst 緩衝機 |
|---|---|---|---|
| 典型觸發信號 | 磁盤使用率持續高於 85%，IO 等待佔比升高 | CPU 多核長期飽和且 job 排隊不隨磁盤清理下降 | 發布窗口或合併周出現 3–7 天尖峯 |
| 主要收益 | 降低 Swap 與編譯緩存抖動，縮短尾延遲 | 提高並行度，隔離不同分支或不同團隊隊列 | 現金流友好，峯值結束即可回收 |
| 主要成本 | 月費或季費上升，需評估緩存治理是否已做滿 | 需要額外的隊列路由、鏡像與密鑰分發紀律 | 需要預熱腳本與鏡像對齊，否則冷啓動吞收益 |
| 與製品同區關係 | 強相關，磁盤本地緩存命中率提升 | 中等相關，兩臺都要掛載同一套緩存策略 | 弱相關，更依賴自動化預熱與只讀鏡像 |
| 更適合誰 | 單倉庫體積大、構建緩存路徑長 | 多倉庫、多產品線並行 CI | 活動類、外包峯值、臨時合規駐場 |
隊列問題的根因很少是「再買一臺 Mac」這麼簡單；先用標籤把 workload 切開，再用同區製品把冷啓動砍下來，最後才用並聯或租期組合解決結構性並行度。
在裸金屬雲 Mac 場景下，獨佔 NVMe 通道讓「磁盤是否成爲編譯尾延遲主因」更容易被觀測到：當你清理 DerivedData 後構建時間立刻下降，但幾小時後又回升，這幾乎總是緩存策略與並行度配置問題，而不是單純「機器不夠快」。此時若直接把機型跳到 M4 Pro 64GB，卻不同步收緊並行模擬器數量，預算上升但 p95 可能幾乎不動。
六區 Runner 標籤、製品同區與 LFS 路由骨架怎麼寫
下面這段骨架不是某個單一 CI 產品的私有語法，而是把「區域、檔位、工作負載」三段信息固定在標籤裏，便於任何控制面做路由。region 建議與你們內部監控裏的區域代碼一致，避免口頭叫新加坡而指標裏寫 ap-southeast-1 這類雙軌命名。workload 至少拆 ci-nightly、ui-smoke、interactive 三檔，interactive 嚴禁與 ci-nightly 搶同一併發池。
region: sg | jp | kr | hk | use | usw tier: m4-16 | m4-24 | m4pro-64 workload: ci-nightly | ui-smoke | interactive | agent 示例 Runner 名: mac-ci-sg-m4pro-64-nightly-01 製品只讀鏡像: registry.internal.sg/…（與 sg Runner 同區） LFS 緩存: lfs-cache-sg.internal（與 Runner SSH 同路由域）
製品同區的落地要點是「只讀依賴與控制面」跟 Runner 走同一邏輯區域，而不是強求所有開發者個人電腦也在同區。對於 git LFS，建議在 Runner 啓動腳本裏先做一次 lfs pull 到本地 SSD 固定路徑，並把該路徑納入構建緩存鍵；對於容器化步驟，如果必須跨區拉 layer，至少把 base image 緩存在同區 registry，避免每次從公共倉庫冷拉。
跨區域團隊還需要一條硬紀律：失敗重試必須帶區域親和性。也就是說 smoke 失敗默認在同區重試一次，再考慮跨區 fallback；否則你會在日誌裏看到大量無意義的跨洋重試，把已經緊張的夜間窗口進一步打碎。把這條策略寫進 pipeline 的默認模板後，排錯會輕鬆很多。
提示：若你們已在使用靜態 IP 與 1Gbps 獨佔帶寬類套餐，請把「控制面到 Runner 的探測」與「Runner 到製品庫」分成兩條監控鏈路，避免把 SSH 流暢誤判爲製品也流暢。
六步把多區雲 Mac CI 從能跑變成可審計
凍結四類 workload：分別統計交互調試、自動化測試、CI nightly、常駐 agent 的周 CPU、磁盤寫入與網絡出站，禁止混在一個「平均利用率」裏。
爲每個活躍區域建立只讀製品錨點：在新加坡、日本、韓國、香港、美東、美西中，只爲實際有 Runner 的區域創建 registry 或緩存前綴，並記錄 DNS 與 TLS 證書負責人。
下發統一 Runner 標籤模板：把 region、tier、workload 三段寫入安裝腳本，並在控制面側禁止手工改標籤，避免漂移。
配置帶區域親和的重試策略：同區失敗重試一次，跨區 fallback 僅對可冪等任務開放，並在日誌裏打印區域標籤便於追責。
建立 DerivedData 與日誌輪轉閾值：例如磁盤水位 80% 觸發清理腳本，85% 觸發告警，90% 自動從 nightly 隊列摘除該 Runner。
把租期與峯值寫進成本臺賬：爲每次 burst 記錄起止日期、機型與並行度，季度復盤時對照矩陣決定下一季是加盤、並聯還是調整區域布局。
三條可直接寫進評審材料的規劃口徑
隊列深度與並發槽：以「每核可持續佔用」估算 nightly 並發，不要以峯值瞬時 CPU 作爲下單依據；Apple Silicon 在編譯與模擬器混合場景下更容易出現長尾。
製品同區 ROI：把「冷啓動分鐘數 × 工程師時薪」與「同區緩存月費」做一張簡單表，通常同區只讀鏡像在第三周即可打平跨區拉取的隱性人力成本。
burst 窗口長度：若峯值穩定短於 10 個工作日，優先用短期第二臺或日租組合承接主隊列溢出，而不是直接把主實例鎖到頂配長租。
注意：本文中的跨區域延遲區間僅用於規劃對照，真實數值必須以你們 orchestrator 與辦公室出口網絡實測為準，避免把規劃表當成 SLA 合同條款。
把 Mac 當成「能遠程登錄的桌面」來租，往往會在 CI 與自動化階段暴露隱性成本：虛擬化或共享存儲會放大編譯尾延遲，而跨區製品拉取會把夜間窗口打碎成不可預測的排隊。相對地，獨佔 Apple Silicon 裸金屬、按天到按季彈性租期、以及覆蓋新加坡與日本、韓國、香港、美國東部與美國西部的多節點布局，更適合作爲 iOS 與 macOS 工程團隊的長期執行層。MESHLAUNCH 的 Mac Mini 雲端租賃通常是更優解：它把「算力、磁盤與網絡」從辦公室消費級寬帶裏解耦出來，讓你可以把隊列、製品與租期策略寫成可審計的 runbook，而不是靠個人電腦硬扛。