企業 Mac CI 監控不能只看主機在線或 Runner 顯示空閒；你應同時驗收 Runner 連線與任務狀態、構建結果和階段日誌、主機資源，以及告警後的診斷閉環。只有訊號能對應到同一節點與任務，才足以支援生產決策。
這份清單適合需要為 Mac 構建機建立生產監控與故障響應門檻的企業 IT 負責人。平台工程與研發效能團隊也可用它檢查現有觀測是否留下盲點。
01 先定義監控邊界：在線不等於構建健康
主機可連線、Runner 已註冊、工作流程成功、產品已發布，是不同狀態。將它們合併成一個「健康」燈號，會讓你難以判斷問題發生在主機、派工、構建還是發布環節。
先選定一條真實 iOS 流水線作為驗收對象，例如由程式碼變更觸發測試，最後產生可追溯的構建結果。每種監控訊號都要能找到所屬節點、工作流程與工作任務；否則即使儀表板有圖表，值班人員仍無法從告警走到原因。
主機正常、Runner 卻沒有接到任務時，先查什麼？
先核對 Runner 是否在線、是否忙碌、標籤是否符合工作流程需求，以及該工作流程是否真的進入等待或執行狀態。GitHub 的 Runner 監控說明將連線狀態與任務執行情況分開處理；Runner API 文件亦列出可用於檢查 Runner 的欄位。這些資訊可以縮小排查範圍，但不能單獨證明 Xcode 工具鏈可用或構建已成功。
02 驗收 Runner 與派工訊號
在控制面板或 API 中檢查 Runner 的連線狀態、忙碌狀態及標籤。再將它們與工作流程的派工條件比對。若節點在線但工作長時間未開始，問題可能在標籤、路由或工作流程佇列，並不一定是 Mac 主機故障。
使用 GitHub 自我託管 Runner 監控與排障說明核對狀態語意與診斷方向。記錄應能回答：哪個 Runner 接到哪個任務、何時開始執行、目前是否忙碌。不要把「在線」當成「可接任務」，也不要把「空閒」當成「工具鏈健康」。
GitHub Actions self-hosted runner 顯示在線，但沒有構建任務時，驗收是否通過？
不通過。你還要核對標籤是否與工作流程要求相符，並確認工作流程與工作任務的狀態。可分別檢查 工作流程執行 API及工作流程任務 API，避免只看 Runner 畫面就判定派工正常。
03 把任務結果與階段日誌接成同一條診斷鏈
每次驗收都要能從工作流程找到工作任務，再由任務進入相應日誌。排隊、開始、成功、失敗與取消等結果，應與構建階段的紀錄一起檢視。單看整體成功率或平均耗時，無法指出某次失敗發生在哪個步驟。
至少準備一筆成功任務與一筆失敗任務，請值班人員實際定位任務日誌、構建階段及結果。依照工作流程執行日誌說明核對日誌取得方式。失敗率與耗時趨勢應跟團隊自己的歷史基線比較，不要直接套用沒有工作負載背景的通用門檻。
Xcode 構建失敗後，怎樣把任務記錄與結果日誌連起來？
保留工作流程與工作任務識別資訊，並在失敗紀錄中記下對應節點、構建階段與 Xcode 結果包位置。Apple 說明，測試結果可透過 Xcode 檢視與解讀；執行測試與解讀結果的文件可用來確認結果內容。若流水線使用 xcodebuild，也要確認命令列參數與結果輸出方式符合官方命令列工具參考。
04 主機資源要能解釋實際構建故障
Mac 構建機可觀測性至少要涵蓋 CPU、記憶體、硬碟空間、網路可達性，以及 Xcode 和必要構建環境的狀態。重點不是把所有主機數值都收進儀表板，而是確認它們能否解釋你在流水線中遇到的等待、失敗或結果缺失。
記憶體指標應使用一致的觀察口徑；Apple 的活動監視器記憶體說明可協助你了解系統提供的記憶體資訊。磁碟監控要能指出空間不足的是哪個檔案系統或工作目錄。網路檢查則要區分主機可達與服務可用，避免只用一個連線結果代表整條構建鏈路正常。
先收集團隊自身的持續構建紀錄，再依照實際故障調整門檻。不要把通用 CPU、記憶體或磁碟數字直接定為生產標準；沒有本站節點或團隊歷史遙測支援時，本文不替你虛構閾值。驗收時可檢查告警是否在資源異常後，能連到同一時段的任務與日誌。
05 診斷證據與告警閉環必須可追溯
先確認 Runner 診斷資訊、工作流程日誌和 Xcode 測試結果能否留存、搜尋及按任務追溯。GitHub 的監控與排障文件說明 Runner 與工作任務的診斷資訊；請依文件核實實際環境中的存放位置與取得方式，而不要假設每個節點的目錄設定相同。
再模擬代表性事件：Runner 離線、工作任務失敗、磁碟告警，或構建結果缺失。值班人員應能收到告警，找到相關節點與任務，讀取診斷資料，並留下恢復後的驗證證據。Mac CI 告警若只通知「發生錯誤」，卻沒有對應任務、節點或日誌，就不能算完成驗收。
下列勾選項可直接套用在一條真實流水線：
- [ ] 主機狀態與 Runner 狀態分開顯示，且可辨認節點。
- [ ] Runner 的連線、忙碌狀態與標籤可以核對工作流程路由。
- [ ] 成功與失敗任務都能找到工作流程、工作任務及階段日誌。
- [ ] CPU、記憶體、硬碟、網路與工具鏈訊號可用來解釋實際故障。
- [ ] Xcode 測試結果可依任務追溯，並能交由值班人員檢視。
- [ ] 代表性告警有明確接收人、定位步驟及恢復驗證紀錄。
06 用驗收結果決定生產准入
| 驗收選項 | 適用判斷 | 下一步 |
|---|---|---|
| 通過 | 主機、Runner、任務結果、診斷證據與告警都能串連到同一節點及任務 | 按團隊發布流程准入，持續檢視趨勢與告警品質 |
| 限期整改 | 訊號大致可用，但特定任務、階段日誌或恢復證據仍有缺口 | 指定負責人補齊觀測，完成後重跑相同驗收 |
| 暫緩生產放量 | 重要任務無法追溯、告警無人接收，或失敗後無法取得診斷證據 | 先修復可觀測性與響應流程，再重新驗收 |
這份驗收只判斷監控能否協助定位與響應，不代表已完成備份、故障恢復或發布審批。若同一任務無法連結到 Runner、主機資源與診斷結果，就應先限期整改；若連關鍵失敗都無法追溯，則暫緩生產放量。
若你正在評估新增 Mac CI 節點，可先用一條真實流水線找出上述驗收缺口，再比較自建主機與按需使用遠端 Mac 的管理方式。自建方案可能需要自行承擔硬體採購、維護與閒置容量；短期測試時，固定採購也不一定符合使用週期。若需要臨時節點或 PoC 環境，可查看 CALMVPS 的方案資訊與租用選項，並把本文的任務追溯與告警項目納入驗收；若是長期、高負載且需要實體介面的工作，則應先評估自購主機是否更合適。