Mac CI 服務 SLA 怎麼驗？2026 企業採購清單
Mac 構建伺服器明明可以連線，Runner 卻沒有接單，或構建完成後找不到可交付的產物。
較適合的做法：不要只看主機可用率；把 CI 任務能否啟動並完成、停機怎麼計時、誰負責恢復，以及如何核對證據，一併寫進 Mac CI 服務 SLA 驗收條款。目標值須由團隊業務需求與服務合約共同確定，不宜直接套用通用數字。
企業 IT 或採購負責人：需要把服務承諾整理成可比較、可簽字的條款。
平台工程負責人：需要分辨服務狀態和真實構建是否成功。
技術總監或研發效能負責人：需要釐清事故責任，以及發布風險由誰承擔。
主機可連線 vs. CI 任務真正可用
SSH、VNC 或控制台可連線，只能證明部分存取路徑正常；不能因此推定 Runner 能接單、Xcode 能完成構建，或產物已交付。Mac 打包伺服器採購時，驗收對象應包含團隊實際依賴的工作流程，而不是單看機器是否在線。
Google SRE 的服務等級指引將服務水準指標（SLI）、目標（SLO）與協議（SLA）區分：指標用來量度服務狀態，目標設定預期水準，協議則界定承諾與後果。採購文件應分開記錄這三者，並用服務等級指標與目標的定義避免把監測指標誤當成合約承諾。
| 驗收對象 | 要確認的狀態 | 可留存的證據 |
|---|---|---|
| 遠端存取 | 約定的連線方式可用 | 服務狀態紀錄、連線測試結果 |
| Runner 接單 | 代表性任務已被工作節點接受 | 流水線紀錄、Runner 日誌 |
| 構建完成 | 任務按約定條件成功或明確失敗 | Xcode 命令輸出、任務狀態 |
| 產物交付 | 預期產物可取得並通過檢查 | 產物清單、保存或下載紀錄 |
Xcode 命令列工具可用於執行構建相關工作；Apple 的Xcode 命令列工具說明可協助界定驗收任務涉及的指令範圍。但指令可以執行，不代表整條 CI 流程已成功：合約還要寫清任務輸入、成功條件、產物檢查，以及外部依賴失敗時如何歸因。
停機起點明確 vs. 只寫一個可用率
一個百分比若沒有統計對象、期間和起訖規則，難以比較，也難以核實。企業 iOS CI/CD 應先決定究竟衡量遠端存取、Runner 接單，還是端到端構建任務，再約定統計窗口與可接受證據。
| 條款項目 | 簽約前要釐清 | 容易留下的漏洞 |
|---|---|---|
| 統計對象 | 主機、Runner、構建任務或產物交付 | 以主機在線替代整條流程 |
| 統計窗口 | 起訖時刻、時區及計算方式 | 雙方採用不同時區或期間 |
| 故障起點 | 監測告警、服務通知或任務失敗 | 只從工單受理時開始 |
| 故障終點 | 遠端連線恢復，還是構建及發布驗證完成 | 存取恢復便宣告事件結束 |
| 證據來源 | 日誌、狀態紀錄及時間戳如何採認 | 事後無法對照或追溯 |
Google SRE 建議以使用者實際感受到的服務體驗定義目標，而非只量度容易取得的內部訊號；因此，遠端 Mac 服務可用性應與受影響的 CI 任務相連結。服務目標的實務原則可作為設計指標的參考，但不會自動構成供應商承諾。
回應確認 vs. 業務恢復
「已收到工單」不等於「構建已恢復」。條款應把事件確認、開始處置、遠端存取恢復、構建能力恢復，以及發布驗證完成分開記錄；如責任在服務方與客戶團隊間交接，也要寫清負責人、通知渠道和升級路徑。
Google SRE 的事故管理資料強調事故處置中的角色分工與交接；其事件管理說明和事件回應工作手冊可用來檢查通報與協作流程是否完整。這些是流程設計參考，不代表特定服務必須提供何種回應時限。
可用流水線執行紀錄建立可複核的時間線。自託管 Runner 的監測與診斷資料能協助定位工作節點狀態，但仍須與服務端事件紀錄及任務結果交叉核對；相關自託管 Runner 監測與診斷文件不應被解讀為本服務的 SLA。
注意：若條款只承諾回覆時間，卻沒有說明構建何時算恢復，採購方就無法據此判定發布風險已解除。
維護排除 vs. 環境變更責任
計畫維護、重啟、macOS 更新與 Xcode 環境變更，可能影響 Runner 接單或既有工作流程。服務條款應說明哪些情況適用排除、通知如何送達、紀錄保存在哪裡，以及構建驗收和設定回退由哪一方負責。只寫「維護時間不計入」而不界定範圍，會使停機統計失去可比性。
| 變更情境 | 合約或作業文件應交代 |
|---|---|
| 預先安排的維護 | 通知內容、通知渠道、影響範圍與狀態記錄 |
| 系統更新或重啟 | 是否屬排除項目，以及服務恢復的驗收條件 |
| Xcode 或構建環境變更 | 相容性確認、任務驗收與回退責任 |
| 客戶端設定或依賴變更 | 如何區分服務故障與客戶端因素 |
工作流程日誌有助於查看任務步驟及失敗位置；工作流程執行紀錄說明可參考其記錄方式。若驗收要求產物留存或交接，也要說明保存與存取的責任邊界，並參考工作流程產物保存與共享文件釐清產物證據應包含哪些項目。
服務抵扣 vs. 團隊恢復能力
抵扣或其他補救措施，不能取代備用構建路徑、發布窗口保護和團隊自己的恢復演練。合約應列明補救措施的觸發條件、申請方式、時限與證據要求；同時由平台團隊確認主構建環境失效時，發布工作能否切換或延後。
簽約前可依以下條件分流：
- 若 SLA 能界定代表性任務、成功條件及失敗歸屬，便將該任務納入交付驗收；否則先補上端到端任務定義。
- 若停機起訖、統計窗口和維護例外都能由雙方記錄核實，便進入條款比較；否則要求服務方補充口徑與樣例。
- 若事件有明確負責人、通知方式和恢復判定，便安排簽約前演練；否則把責任缺口列為待解決事項。
- 若補救條款明確，但團隊沒有替代構建或發布安排，便先補足內部恢復方案；否則不能只憑抵扣條款判定風險可接受。
採購簽字 vs. 證據不足
簽字資料應能還原一次服務事件，也能證明代表性 CI 任務通過驗收。建議在採購檔案中集中保存：SLA 條款、服務狀態紀錄樣例、故障通報與交接流程、維護規則、構建任務日誌，以及產物驗證記錄。客戶端日誌、服務端狀態與雙方確認的時間戳，須能互相對照。
正式驗收前，可先跑一個不含敏感憑證的代表性任務，檢查命令結果是否清楚呈現任務狀態。以下只示範輸出欄位，不是服務實測結果：
task_state: <success_or_failure>
runner_state: <accepted_or_unavailable>
build_result: <pass_or_fail>
artifact_check: <verified_or_missing>
event_reference: <shared_record_id>
如果報告只顯示主機可連線，沒有任務狀態、失敗歸屬或產物檢查，就不足以驗收 CI 交付。若 SLA 沒有可量度指標、維護例外界線不清，或恢復責任找不到負責人，應要求補充條款，或暫緩採購，而不是用未經驗證的通用目標值填空。
本清單只協助核對合約口徑，不代表任何供應商已承諾特定可用率、回應時限或賠付。若現行做法是自購 Mac 作為打包機，優點是團隊能直接管理硬體；代價則包括前期採購投入、閒置容量，以及更新、維護與故障處理責任。對需要短期試行、跨地點存取或彈性配置的團隊，按期租用遠端 Mac 可省去自行持有主機的部分管理工作，但仍須逐條核對服務合約與交付證據。可先參考企業 Mac 租賃方案資訊及租用方案與價格頁面，再用本文的指標表檢查實際條款；若團隊需要長期滿載運行、必須連接特定實體設備，則應優先評估自購或混合部署。