若你在新加坡、日本、韓國、香港、美國東部、美國西部同步運行多台遠端 Mac，卻仍把日常編譯、Simulator、Pods 解析與Archive、公證、TestFlight 上傳綁在同一台「萬能機」，遲早會在憑證漂移、match 寫入衝突、ASC 工作階段漂移上付出代價。本文提供平台與 iOS 發佈工程一張分拆架構與 FinOps 參數表：何時拆分「簽署出口機」與「全量建置機」、match 如何唯讀掛載、ASC 互動為何須與節點大區同向、租期如何壓在簽署機的最小上線視窗。讀畢你應能把可稽核拓撲寫進變更單，而非 Slack 口頭約定；並與站內Fastlane 多機構建、TestFlight 鏈路、乾淨可重現建置並列閱讀。
xcodebuild -exportArchive，失敗叢集常被誤標為「憑證壞了」，實為工作階段混用。.xcarchive 同碟競態時，公證與 stapler 階段對循序寫入放大敏感；建置峰值把簽署視窗擠到佇列尾端，發佈 SLA 直接受損。本篇與《憑證輪換與多節點一致性》分工：該文講輪換事件與回滾視窗；本篇講拓撲與讀寫邊界——先把伺服器角色寫對，再談 rotate。
另一個常被低估的變數是網路政策不對稱：企業 Proxy 往往對 github.com 與 contentdelivery.itunes.apple.com 走不同出口；把重編譯與 ASC 上傳綁在同一「政策群組」下，會在旺季把偶發抖動放大成全隊停發。分拆後你可在建置側接受「多映像來源、多快取層」的積極策略，而在簽署出口側維持窄白名單與固定 DNS 視圖，兩者互不拖累。
維運上亦須正視組織行為：當「誰都能 SSH 上去改一下 lane」成為常態，簽署機會退化成共用開發機；沒有變更單與唯讀掛載兩道閘，任何緊急 hotfix 都會以「臨時提權」名義永久改寫拓撲。文件必須載明逃逸視窗與二十四小時內收斂條款，否則分拆架構只在紙面成立。
資安與營運常會追問程式碼與構件的血緣：當簽署與編譯共用同一使用者設定檔，難以證明「輸出二進位僅由已知 Git 提交與已知 Xcode 組態產生」。分拆後，建置池可輸出帶提交雜湊與建置矩陣指紋的 manifest；簽署機只做驗證、簽章與上傳，稽核邊界因而較清晰。
評審時請在每格附上證據連結（流水線 YAML、鑰匙圈匯出稽核、ASC 上傳日誌片段），避免「我們覺得差不多」。
| 維度 | 單機全堆（不分拆） | 雙機：建置池＋簽署出口機 | CI 在共用建置池、簽署在固定區獨佔機 |
|---|---|---|---|
| 適用前提 | 團隊極小、並行低、無合規點名宿主機需求 | 中到大規模；夜間 Archive 與白天 PR 爭用明顯 | 已有 Runner 池；要把「上傳視窗」收斂到單一真相區 |
| match 邊界 | 易混用讀寫；須強流程自律 | 建置側唯讀；簽署側受控寫入或單一寫入來源 | 與左欄類似，但寫入僅在固定區主機發生 |
| ASC 工作階段 | 互動與上傳同機最理想；否則漂移風險高 | 強制簽署機大區與瀏覽器工作階段同區對齊 | 上傳機常租；工作階段與出口 DNS 綁定 |
| 租期形狀 | 月租一機到底；峰值靠加班人肉協調 | 建置池可日／週補峰值；簽署機按「上傳視窗」壓到更小租期 | 建置池彈性、簽署機長租但CPU 低配亦可（視公證 CPU） |
| 主要風險 | 除錯面過大；SLA 難寫清 | 構件傳遞與快取一致性成本上升 | 跨池構件校驗與雜湊對帳不可省 |
分拆的第一性原理：簽署出口機追求低熵環境（少套件、少並行、少互動使用者）；建置機追求高吞吐（快取命中、並行 worker）。將兩者硬綁在同一使用者工作階段，等於用一套 KPI 同時優化兩件相反的事。
git clone --depth 1 取用 match；任何需要 match nuke 類操作必須走人工發佈單。第 3 步與第 5 步之間建議插入預檢指令稿視窗：在簽署機解封前執行固定版本的 spctl／codesign 自檢與雜湊對帳，任何版本漂移須在變更單顯式載明，而非「昨晚有人 brew upgrade」。此步可吃掉大量「公證突然不過」的假陽性。
若你已實踐乾淨可重現建置，可把快照策略僅綁在建置池，而簽署機採較慢節奏的 gold image：簽署側映像九十天不變、建置側七天一滾動，兩者以文件化的相容矩陣對齊，而非強迫同一 cadence。
# 虛擬碼：CI 側取用 match（唯讀）與簽署側寫入分離
jobs:
build_pool:
env:
MATCH_READONLY: "true"
MATCH_GIT_BASIC_AUTHORIZATION: "***read***"
steps:
- run: bundle exec fastlane match appstore --readonly
- run: xcodebuild archive ...
signing_export:
needs: [build_pool]
runs_on: dedicated_signing_host_sg # 與 ASC 工作階段同區示例
env:
MATCH_READONLY: "false" # 僅維護視窗開啟
UPLOAD_LOCK_ID: "asc-session-sg"
steps:
- run: ./verify_sha256_manifest.sh
- run: xcodebuild -exportArchive ...
- run: xcrun notarytool submit ...
exportArchive、notarytool、上傳與合規問卷的分鐘數，占簽署機總上線分鐘的比例；若連續三週低於 8% 卻仍月租全堆，應考慮將簽署機降規或改短租疊加。--force。臨時峰值機缺少gold 映像與稽核指令稿，最容易在 hotfix 深夜把除錯版描述檔帶進上傳鏈；事後覆盤常發現不是 ASC 抽風，而是鑰匙圈裡多了一張過期的 intermediate。
全員本機 decrypt 則把機密平面攤到不可控端點：筆電睡眠、VPN 抖動與企業 Proxy 差異會把「能簽」變成不可重複的隨機事件，FinOps 亦無法對租期做科目分攤。
相對這類權宜之計，當你需要在六區之一落地獨佔 Apple Silicon、可把簽署出口與重編譯實體拆開，並將租期切成基線＋峰值、讓 ASC 工作階段與上傳出口維持同區同政策時，MACCOME 雲端 Mac mini通常更易把「分拆」寫成可驗收工單：節點涵蓋新加坡、日本、韓國、香港、美國東部、美國西部等關鍵區域，按日／週／月／季組合彈性租期，先把低熵簽署面坐實，再讓建置池追求吞吐，而非在同一台伺服器上互相踩腳。
分拆的交付物不是更多機器，而是三張表：資料面讀寫表、ASC 工作階段與出口對照表、租期與上線分鐘科目表。新人到職首日應能回答：我的 job 會不會觸發 match 寫入、上傳從哪一區出口、失敗日誌要貼到哪張表。
與Fastlane 峰值租期文並讀時請記住：租期策略必須能對應到角色機，否則「日租補峰值」只會變成「多租幾台萬能機」，成本曲線不會下降。
收尾五分鐘請核對兩件事：match 是否仍單一寫入來源、簽署機是否仍與 ASC 工作階段同區；否則六區節點再多，也只是把混亂地理分散式備份了一份。