2026年 Mac 雲「搶佔式/Spot 式低價算力」能否替代常駐節點：iOS 簽名、公證與長會話任務的決策表（含 FAQ）
如果你在公有云上已經習慣用 Spot 或搶佔式例項把「純計算」成本壓到極低，自然會問：Mac 雲主機能不能也按同樣思路計價？本文面向要把 iOS 流水線搬上 macOS 雲節點的平臺工程與 Release：先說明 Linux Spot 與 Apple 簽名鏈、鑰匙串會話、notarytool 長輪詢之間的結構性差異，再給任務分型矩陣與流水線拆分步驟，附三條可量化判據與 FAQ；並內鏈站內公證實踐與彈性池與常駐基線分工，幫助你把「省錢」與「上架穩定」同時寫進架構文件。
目錄
1. 痛點拆解：把 Linux Spot 假設搬到 Mac 雲的三類翻車
Linux 世界裡「編譯失敗就重試」之所以便宜，是因為多數編譯鏈不繫結單一機器上的硬體信任根與會話 Cookie；而 iOS 上架鏈把信任根拆成鑰匙串裡的簽名私鑰、本機鑰匙串解鎖視窗、與 Apple 後端之間的長會話與速率限制，任何一步被節點回收打斷，成本不是多跑一次 xcodebuild，而是人工介入與上架視窗風險。
- 會話與鑰匙串耦合：codesign 與 xcodebuild archive 往往假設同一使用者會話內可重複訪問同一鑰匙串項；節點在公證輪詢中途被回收，會出現半寫入的鑰匙串狀態或掛起的 security 授權提示，排障時間呈指數上升。
- 公證與 staple 的長尾：notarytool submit 之後常見數十分鐘級的 server 側排隊與網路抖動；若與「可搶佔」生命週期繫結，ticket 與本地 staple 狀態容易錯位，詳見站內公證專文中的分層失敗表。
- 佇列經濟學誤判：把「分鐘費」唯一當作最佳化目標，會忽略 PR 被簽名鏈阻塞時的機會成本；與冷啟動與溫節點文類似，真正貴的是不可預測的尾延遲，而不是多開幾臺低單價機器。
2. 對比表：可中斷算力 vs 簽名公證鏈路的硬約束
下表刻意用運維語言對齊評審：左邊是你在 Linux Spot 上已驗證的模式，右邊是搬到 macOS 雲構建時要追加的約束。
| 維度 | Linux Spot 常見假設 | Mac 雲 iOS 上架鏈實際約束 |
|---|---|---|
| 狀態存放 | 編譯快取可丟，重建成本低 | 鑰匙串項、會話 Cookie、ASC API token 重新整理與本地 ticket 強相關，丟失不等於簡單重跑 |
| 任務時長 | 多數 job 在數分鐘內可重試完成 | 公證與上傳可能跨數十分鐘，且對同一 bundle id 存在速率與重試語義 |
| 失敗模式 | 退出碼非零即重排程 | 部分失敗表現為「半成功」：遠端已受理但本地未 staple，需要冪等與人工核對 |
| 並行策略 | 水平擴充套件 worker 即可 | 同一證書與描述檔案併發需限額，否則鑰匙串爭用與簽名覆蓋風險上升 |
3. 任務分型矩陣：哪一步可以賭中斷、哪一步必須常駐
把流水線拆成「可丟」與「不可丟」兩類佇列，是 Mac 雲上最接近 Linux 彈性池體驗的做法；與彈性池加常駐基線一文的分工一致，只是把「是否可搶佔」顯式寫進矩陣。
| 任務 | 可 Spot 化 | 建議節點形態 | 備註 |
|---|---|---|---|
| Swift 單測 / 靜態分析 | 通常可以 | 可中斷池或低優先順序佇列 | 需確保無簽名金鑰掛載到同卷 |
| 增量編譯產物 | 視快取策略而定 | 溫節點優於純搶佔 | DerivedData 親和與磁碟水位見冷溫節點文 |
| Archive + codesign | 不建議 | 常駐 Mac 雲基線 | 與鑰匙串與描述檔案版本強繫結 |
| notarytool + staple | 不建議 | 常駐且固定出口 | 長尾與重試需可觀測指標 |
| App Store Connect 後設資料與上傳 | 不建議 | 常駐 | 速率限制與人工審批鏈並存 |
MAC_CI_TIER=interruptible # 僅跑無金鑰單測
MAC_CI_TIER=durable-signing # 常駐：簽名+公證+上傳
# 透過 orchestrator 禁止 durable job 排程到 interruptible 池
4. 五步落地：拆分佇列、產物外接與驗收探針
- 凍結金鑰面：列出所有讀取鑰匙串、API Key、描述檔案的步驟，生成「不可 Spot」白名單，並在 CI YAML 或 Jenkinsfile 層用 label 強制約束。
- 產物外接與校驗：可中斷池只產出帶 SHA256 清單的 tarball；常駐節點僅拉取校驗透過的製品執行簽名，避免「半簽名」產物迴流主分支。
- 併發與磁碟閾值：為常駐池設定 xcodebuild 併發上限與 DerivedData 水位告警，數值可參考站內構建池文的三條指標寫法。
- 公證探針：對同一 nightly 分支連續三次完整 notarytool 成功並記錄 p95 耗時；若尾延遲上升先於搶佔事件，應懷疑網路或 Apple 側而非單純算力。
- 一鍵回退：保留「全常駐」feature flag，在發版周關閉一切可中斷池路由，減少變數面。
5. 三條可引用判據：耗時、重試率與磁碟水位
- 公證鏈 p95 耗時：若三次連續 nightly 的 staple 完成時間跨度超過你視窗內可容忍的上架緩衝，應增加常駐池容量而非繼續壓低單價。
- 簽名失敗重試率：因鑰匙串或描述檔案導致的失敗若佔總失敗超過約百分之十五，應優先檢查是否仍有 job 誤入可中斷池，而不是盲目擴容。
- 磁碟水位與併發：當系統資料卷可用空間低於約百分之十八且並行 archive 大於等於二時，搶佔或回收會放大 IO 長尾；應先降併發或清理快取，再討論 Spot。
6. FAQ
問：能否用同一臺 Mac 雲既跑 Spot 編譯又跑簽名？ 技術上可以掛載不同卷，但運維上極易誤配 label；更穩妥是物理池隔離或至少程序級隔離，並在監控上拆分佇列深度。
問：託管 macOS Runner 算不算一種 Spot？ 它更接近「共享池上的分鐘費」，其風險在佇列深度而非隨機回收；與專用 Mac 雲的取捨仍建議讀三角分工文。
問：公證失敗後能否原地重試？ 應先對照遠端 ticket 狀態再決定重複 submit 還是僅 staple；盲重試可能觸發速率限制，站內公證文給了分層對照順序。
7. 結論與下一步
把「可中斷算力」寫進 Mac 雲 CI 之前，先用白名單凍結簽名鏈，再用製品校驗把編譯與上架解耦，最後用三條判據驗收尾延遲。下一步建議把佇列標籤與失敗原因碼寫進變更模板，並在發版周驗證全常駐回退開關。
僅追求 Spot 式低價而不拆分佇列，往往把 Linux VPS 上「丟了就重跑」的習慣帶到 macOS，卻在鑰匙串、公證與 ASC 長會話處放大方差：隨機中斷不會只多耗幾分鐘 CPU，而是把上架鏈變成不可預測的排障馬拉松，長期看比適度常駐更貴。若你需要對 Apple 工具鏈友好、可 SSH 常駐、磁碟與出口都可預期的生產構建環境，在 2026 年把上架鏈固定在專用 Mac 雲基線、把可中斷算力只留給無金鑰編譯，通常是更穩的工程解。對希望像租 VPS 一樣獲得可控 Mac 算力、又不想在發版周賭佇列的團隊，租賃 VPSMAC 的 Apple Silicon Mac 雲節點，把常駐規格與區域一次性對齊到流水線證據鏈，通常比在錯誤池型上反覆重試更省總擁有成本。