PR 建構越來越多，月底卻說不清哪個團隊用了多少 Mac 資源。
最快的處理方式：按 PR 驗證、正式發布、定時回歸與臨時峰值歸屬 Mac 資源成本；GitHub Actions 平台帳單另列，並事先約定專用節點與閒置容量由誰承擔。不要按開發者人數平均分攤，也不要因為 Runner 是自託管就把 Mac 主機視為免費。
這篇適合共用 Mac CI 資源的 FinOps 負責人、負責 GitHub Actions 與 Runner 的平台團隊，以及規劃遠端 Mac 預算的 IT 負責人。你可以用下列方法建立可回查、可複核的成本歸屬規則。
01先把平台帳單、Mac 資源與維運成本拆開
GitHub Actions 的平台計費規則，不等於承載 Runner 的 Mac 沒有成本。GitHub 官方文件說明，自託管 Runner 不按 GitHub-hosted Runner 的方式收取執行分鐘費用；這只界定 GitHub Actions 的計費邊界，不能推論主機、租賃、維護或容量保留均為零成本。你應以GitHub Actions 計費說明核對適用的計費項目，並以官方計費與用量文件確認用量資料的範圍。
在內部帳本中，至少把以下項目分開：
- 平台費用：依 GitHub 帳單與用量報表記錄，不與 Mac 主機費用合併。
- Mac 資源費用：依採購或租賃帳單、節點用途及成本期間記錄。
- 維運投入：例如 Runner 維護、映像檔更新、快取管理與故障處理；若企業要計入人力成本，應先定義一致的計量方式。
- 共享閒置容量：將保留但未執行工作、維護中或不可用的時段獨立標示，不能冒充某團隊的有效建構用量。
你的成本對照至少應包含三個欄位：任務歸屬記錄專案、Workflow 與成本中心；資源消耗記錄實際執行任務的 Runner 與占用；帳單來源記錄平台、Mac 資源及維運項目的憑證。缺一欄，月底就可能出現重複計費或無主費用。
02PR 驗證應依可回查的任務消耗歸屬
PR 驗證通常是共享節點上的日常工作負載。分攤前，先讓每筆建構記錄能回答：由哪個 Repository 和 Workflow 發起、對應哪個團隊、使用哪個 Runner 標籤、任務何時開始與結束，以及是否成功完成。GitHub 的Workflow Jobs API 文件可用來確認工作記錄欄位；但團隊、產品與成本中心等管理資訊，通常仍需由你自行維護映射。
可以用變數定義分攤，不先假設單價或費率：
C_mac：核算期間內可分攤的 Mac 資源成本。U_i：團隊或工作負載i經核驗的有效 Runner 占用量。U_total：同一期間所有可歸屬工作的有效占用量。C_idle：已單獨記錄的保留、閒置、維護或不可用容量成本。
若企業採按實際消耗分攤，可先按 U_i ÷ U_total × C_mac 計算團隊的資源成本，再依治理規則處理 C_idle。這個公式提供一致的核算口徑，並不代表各 Runner 的實際資源消耗完全相同；若節點規格、用途或計價週期不同，就應先分池核算，再套用相應的消耗依據。
例如，產品團隊甲的 PR 工作流使用共享 Runner，平台團隊同時安排節點維護。甲的可歸屬費用應根據任務記錄計算；維護與不可用期間則保留在共享容量帳目中。若某筆記錄缺少 Repository 或 Runner 對照，就列為待查，不要把它直接分配給當天提交程式碼較多的團隊。
落地時可以依序完成以下工作：
- 為 Repository、Workflow、團隊及成本中心建立穩定的映射表。
- 統一 Runner 標籤命名，區分一般 PR、簽名發布與定時工作負載。
- 保存 Job、Runner 使用狀態與時間欄位，確認記錄能互相對照。
- 將取消、重試、排隊、維護與節點不可用事件標記為不同狀態。
- 每月抽查原始任務與分攤結果；無法對應的項目留在待查清單，不強行攤派。
正式發布要與公共建構池分帳
正式發布若使用專用可信節點，其資源成本應依事先核准的專用服務規則歸屬，不要自動攤給所有 PR 工作負載。這類節點可能承載簽名與發布任務，也可能有獨立的存取控管；你應將節點角色、受益專案與費用責任一起記錄。GitHub 的安全使用文件可協助你檢視 Workflow 的安全使用邊界，但企業內部的成本中心映射仍需自行制定。
每筆發布成本至少保留：
- 發布專案與核准的發布任務識別資料。
- 執行任務的節點與 Runner 標籤。
- 對應的資源帳單或租賃期間。
- 負責團隊、成本中心及例外核准紀錄。
公共發布池則需要先談妥規則，再決定按實際占用或約定配額分攤。若某個團隊臨時使用專用節點完成發布，不應在月底才推定費用歸屬；應在任務啟動前留下申請人、用途與核准的計費方式。
優點是專用發布容量的成本與風險責任清楚；代價是專用節點可能有保留與閒置成本。若發布任務低頻、團隊又未同意承擔專用容量，就不宜把整個節點的固定費用事後轉給單一發布專案。
04定時回歸與閒置容量要先選定分攤口徑
夜間或週期性回歸由平台統一排程時，應依專案或 Workflow 映射歸屬，不能只按執行時間判斷。相同時段可能同時有不同產品的測試，也可能有 Runner 維護與快取處理；若只看「夜間執行」，成本很容易落到錯誤團隊。
| 分攤選項 | 適用條件 | 團隊核算方式 | 主要風險 |
|---|---|---|---|
| 按實際消耗 | 任務紀錄完整，且可對應到專案或 Workflow | 依有效占用量分配可歸屬的 Mac 資源成本；保留容量另列 | 遇到記錄缺漏或節點規格差異時，須先補映射或分池 |
| 按保留容量 | 團隊預先保留資源，且接受按配額承擔成本 | 依核准的容量份額或服務約定分配 | 實際用量偏低時，可能承擔未使用容量 |
| 平台中心池承擔 | 容量為平台整體服務水位、維護或備援需要 | 列在平台成本中心，不偽裝成產品團隊用量 | 平台需公開保留依據，避免成本長期無人檢視 |
在政策中明確指定：保底節點、快取維護與任務之間的空檔，是由平台中心池承擔，還是由受益團隊共同承擔。GitHub 的Actions 指標文件可供你核對可用的工作流指標，但這些指標不會自動替企業完成成本中心分配。
05臨時峰值需要申請紀錄與月度核對
發布高峰、緊急回歸或短期專案可能需要額外 Mac 容量。臨時擴容若沒有申請人與業務原因，月底很容易被記成平台雜費。每次新增容量時，至少記錄申請人、受益專案、資源起訖期間、核准者及費用歸屬；再按事先約定，判斷由觸發團隊承擔，或由平台彈性預算吸收。
月度核對可採取這個流程：
- 從 GitHub Actions 作業記錄匯出工作負載識別資料。
- 依 Runner 使用記錄對照節點、任務與有效占用情況。
- 對照 Mac 資源帳單及維運成本，確認費用期間和節點範圍一致。
- 將可歸屬費用對應到 Repository、專案及成本中心；缺少證據的項目維持待查。
- 由平台與財務共同檢視差異、核准例外，並記錄後續修正責任人。
GitHub 計費報表文件可協助核對平台帳單資料，但不能取代 Mac 資源帳單或內部成本台帳。初期先用 showback 向團隊展示平台費用、Mac 資源、維運與閒置容量各自的構成；待映射完整、爭議處理方式與財務責任都經核准後，再決定是否轉為 chargeback。
把原始記錄、核算公式、資料缺口、責任人和異議處理方式一起保存。若工作流標籤更動、費用期間跨月，或節點記錄無法與任務對上，就先標示差異並由負責人複核，不能為了讓帳目看似平衡而強行歸屬。
06常見分攤爭議的處理方式
常見問題不只是「某個團隊用了多少」。你還需要界定平台負責的共享成本、可追溯的工作負載費用，以及在資料不足時暫不分配的項目。正式執行前，先確認成本中心負責人接受相同口徑；若團隊對專用容量或共享閒置成本有不同認知，應先用 showback 暴露差異，再由財務與平台治理規則決定是否收費。
如果你已有可追溯的作業用量，下一步是把實際負載、Mac 資源帳單與現行採購或租賃方案逐項對照。自行採購適合長期固定負載、需要實體介面或必須由內部掌控硬體的情況；但團隊也要承擔前期採購、維護、折舊與閒置容量。若你的缺口主要是發布高峰或短期建構需求，可比較Mac mini 租用價格與週期，並參考香港遠端 Mac 方案資訊核對交付條件。VpsMesh 遠端 Mac 可作為補充彈性容量的選項；先依實際週期、權限需求與費用歸屬規則估算，再決定租用是否比增加自有設備更合適。