自託管 macOS Runner 的團隊幾乎都踩過同一坑：無節制的重試掩蓋真實產品缺陷、燒穿 Apple Silicon 機時，並讓開發者預設「多跑幾次就好」。本文給出如何分類不穩定訊號、何時自動重跑與何時攔截合併，以及如何在獨佔 Mac mini M4 上落地「連續失敗即隔離」策略——含兩張決策表與六步推廣清單，可直接套用到 GitHub Actions 或其他編排器。
若你已在多機上拆分 UI 任務，請同時閱讀 Mac mini M4 上的 iOS UI 測試分片，避免分片傾斜被誤判為測試不穩定。Runner 基線可參考 雲上自託管 GitHub Actions macOS Runner，並保持全叢集 Xcode 版本一致。
為什麼「無限重試」會毀掉 Mac 構建叢集的信任
macOS CI 的狀態比 Linux 容器更「粘」：鑰匙串條目、模擬器快取、鎖屏與公證守護程序都會引入看似隨機的失敗。沒有書面化的重試預算時，值班同學會把「紅變綠」解讀為「自己好了」，合併風險被悄悄放大。
- 指標失明：若只統計工作流層級的透過/失敗，你無法分辨某測試是在 三臺不同 Runner 上失敗，還是同一臺過熱機器連續失敗三次。
- 經濟拖累：單個不穩定 UI 套件在每個 PR 上重試兩次，可能在程式碼穩定時仍吃掉每週 Mac Runner 分鐘的 20%–35%。
- 錯誤學習：工程師開始在本地「跑到綠為止」，繞過合併門禁本應保護的訊號。
失敗指紋：基礎設施、測試還是產品？
調整配額前，先給失敗打指紋，讓儀表盤能區分訊號與噪聲。下表是討論起點，請按合規要求微調「首要動作」列。
| 指紋 | 可能根因 | 首要動作 |
|---|---|---|
| 同一 Runner 主機名、不同測試 | 磁碟、散熱或 USB 集線器不穩 | 排空任務；檢查 SMART 與剩餘空間（可用空間低於 15% 立即清理） |
| 同一測試、任意 Runner | 測試隱含依賴牆鍾、動畫或區域設定 | 開隔離工單；修復前重試上限 1 次 |
| Xcode 升級後尖峰 | 工具鏈或模擬器迴歸 | 固定 SDK；先在單臺黃金 Mac 跑金絲雀再全量推廣 |
| 僅 fork 的 pull_request | 金鑰可用性或沙箱差異 | 拆分工作流；絕不讓 fork 任務接生產簽名標籤 |
按團隊成熟度配置重試預算與隔離閾值
成熟團隊把重試當成帶利息的借貸。下表給出三檔策略與運維旋鈕，可按倉庫分級選用。
| 策略項 | 起步 | 平衡 | 企業 |
|---|---|---|---|
| 每任務自動重試 | 2 次 | 1 次（僅基礎設施錯誤） | 0–1 次並配錯誤白名單 |
| 觸發隔離的連續失敗 | 夜間報表 | 24 小時內 3 次失敗 | main 上 2 次失敗 |
| 隔離測試的合併規則 | 警告徽標 | 負責人審批後可跳過 | 除合規特例外硬攔截 |
| Runner 遙測保留 | 7 天 | 30 天 | 90 天 + SIEM 匯出 |
審計提示：隔離跳過測試時，在工作流日誌中記錄提交 SHA、操作者與工單號。監管與客戶越來越需要證明「跳過檢查」是有意識決策，而非意外綠構建。
在雲 Mac Runner 上落地連續失敗隔離的六個步驟
以下步驟假設你可透過 SSH 維護主機。連線與賬號規範見 幫助中心。
- 輸出結構化 Runner 資訊：在每條作業摘要寫入
RUNNER_NAME、系統構建號、Xcode 構建號與磁碟剩餘 GB。 - 分類重試：區分
infra_retry（超時、模擬器啟動）與test_retry（斷言失敗）。 - 按測試統計連續失敗：將計數寫入小型資料庫或物件儲存；僅在
main連續 10 次綠後再清零。 - 接入合併門禁：超過閾值除非維護者打標籤否則攔截。
- 輪換問題機器：若某主機名一週出現在 40% 的基礎設施重試中，下線並重灌映象。
- 週會覆盤：會議控制在 25 分鐘內，用儀表盤列出 Top 不穩定貢獻者與已恢復測試。
事故覆盤前應匯出的指標
管理層要看綠率，可靠性工程師要看分佈。用定時任務把下列聚合寫入數倉，隔離決策才能基於資料而非政治。把這些指標與 Runner 主機名、Xcode 構建號關聯，通常能在工單爆發前定位單臺壞節點。
- 含重試耗時：統計包含所有嘗試的牆鍾時間，與首次嘗試對比以量化重試稅。
- 間歇性指數：無新提交卻紅變綠的作業佔比；目標壓到每個迭代 macOS 作業的 5% 以下。
- 隔離 backlog 賬齡：記錄每個被跳過測試距上次在 main 成功透過的天數；超過 14 天要升級處理。
- 模擬器啟動 p95：與測試體分開統計——啟動時間攀升常先於 SMART 報警暴露儲存問題。
- 按金鑰域分類失敗：單獨統計鑑權錯誤，避免把配錯的
APP_STORE_CONNECT金鑰當成隨機不穩定。
當指標與釋出事件同庫，你可以在數分鐘內回答審計問題：哪臺 Mac 碰過某製品、尖峰期線上有哪些 Xcode 版本、以及重試是否在 main 上掩蓋迴歸。對簽有內部開發者平臺 SLA 的合同客戶，這種敘述與原始透過率同樣重要。
常見問題
fork 的拉取請求能否與正式發版共用 Mac 標籤？
絕不能。把帶簽名能力的標籤與不可信程式碼路徑混用極其危險。將 fork 視為不可信租戶：拆分 Runner 池、拆分金鑰域，並收緊重試預算，避免惡意工作流探測基礎設施。
地域選擇與不穩定率有何關係？
依賴網路的測試（推送、CDN 邊緣）應靠近真實使用者區域執行。NodeMac 在香港、日本、韓國、新加坡、美國提供節點——建議每月在各區域跑一次金絲雀任務，在全員踩坑前捕獲 DNS 或 TLS 漂移。
若準備為隔離套件增加獨立 Runner，可先對照 NodeMac 套餐 評估成本，再與「假紅」消耗的評審時間對比。
Mac mini M4 很適合本文策略：Apple Silicon 在 Xcode 編排上具備強勁單執行緒效能，統一記憶體利於多模擬器服務，空閒功耗低適合 PR 之間的等待。NodeMac 提供帶 SSH 與 VNC 的 獨佔物理 Mac mini，覆蓋港、日、韓、新、美，讓每臺 Runner 對應可遠端排障的真實硬體。相較一次性採購整櫃 Mac，按需租用 可在用真實遙測驗證分片與隔離策略前壓低資本支出。