① FAQ：何時嚴格串行優於有限併發？
嚴格串行指同一時間僅一條「重型」管線觸碰共用可變狀態（archive、佔用 Simulator GUI 的整合測試、寫入同一依賴快取等）。延遲在尖峰會上升，但行為可預期。有限併發需工作目錄隔離、輸出不重疊並預留 RAM／I/O；若仍共用 CocoaPods／全域 npm 快取，或 VNC 開 Xcode 同時跑 CI，平行化易變事故。
實務：對重型＋共用快取先串行；CPU 約 <75%、記憶體有餘裕且工作區獨立後再提高併發。concurrency group 應與 Runner lane 一併設計，勿只調高 YAML 數字。
② FAQ：共享構建機上如何用 flock？
flock 協調的是自願遵守的檔案鎖，無法替代沙箱。應採一個共享資源域一把鎖（例如共用 Pod 快取、或「僅允許一條 GUI 測試」的 Simulator 鎖），路徑集中於維運目錄便於稽核。
- 快速失敗：
flock -n /path/to.lock -- 指令— 鎖被占用即退出，適合可改派其他節點的流水線。 - 有上限等待：
flock -w 180 /path/to.lock -- 指令— 最多等 180 秒，適合短的關鍵區段。 - 縮小臨界區：只包住會突變的步驟（安裝依賴、寫快取、重建索引），不要把整段 40 分鐘編譯無條件包進鎖，除非工具鏈要求。
③ FAQ：佇列深度、任務逾時、鎖等待逾時怎麼訂？
佇列深度上限用來避免「CI 壞了」其實只是池子塞滿卻無人察覺。實務可從全域或每 lane pending 約 20 起，超過即回傳明確錯誤（池飽和、請稍後或使用其他標籤）。任務逾時應對齊「合理最長構建」，而非某次黑客松的極端值；並在任務會外洩資源時縮短。flock -w 必須短於任務逾時：若數分鐘仍拿不到共用快取鎖，多半是另一任務卡住或臨界區過大，應告警而非整夜等待。
④ FAQ：節點穩定、卡鎖與衝突怎麼收斂？
穩定＝可觀測佇列＋有邊界副作用：追蹤中位數等待、鎖等待 P95、系統卷剩餘與 swap。衝突時先取消卡死任務、確認無行程握鎖再動鎖檔；長期宜拆互動／CI 池或加第二台構建機再談提高併發。SSH keepalive 與重連預期請對齊 SLA，避免誤判鎖競爭。
⑤ 可執行參數表（貼維運手冊）
下列為起點值，請依專案 P95 與硬體規格微調。
| 參數 | 建議起點 | 備註 |
|---|---|---|
| 重型構建串行上限 | 每個共用快取／Simulator GUI 域同時 1 個活躍 | 僅在獨立工作目錄＋分離鎖域後再提高 |
| 輕量任務併發 | 最多 2（CPU 約 <75%、可用 RAM > 約 8 GB） | 出現 swap 或磁碟延遲尖峰即降回串行 |
| pending 深度上限 | 全域或每 lane 約 20 | 明確錯誤文案＋重試指引 |
flock -n |
共享資源忙時立即失敗 | 適合可改派其他節點 |
flock -w（秒） |
依賴／快取 120～300；極短突變 30～60 | 依鎖等待 P95 調整 |
| 任務逾時（輕／標準／archive） | 15～25／35～60／45～90 分鐘 | 以各 repo P95＋緩衝為準 |
| 中位等待告警 | 持續 > 15 分鐘 | 擴容或拆分 lane |
⑥ 值班清單：佇列、鎖與衝突
- 鎖檔依資源域命名，勿依團隊名亂開 — 每個共用 Pod／npm／Simulator 域一把鎖。
- 在內部文件與 CI 錯誤訊息中公開佇列上限；超深佇列要帶重試建議。
- flock 等待必須有上限，且短於任務逾時；重複鎖逾時要告警。
- 刪除鎖檔前先確認無存活行程；記錄 runner id、commit、鎖路徑以利稽核。
- 每週檢視：佇列深度趨勢、磁碟剩餘、DerivedData 膨脹、是否需拆串行 lane。
⑦ 小結與方案／幫助
用串行 lane、flock 與逾時把共享 Mac 變可預測
Meshmac 提供多區域遠端 Mac 與 SSH／VNC；serial lane 不足時宜先加節點再拉高併發。免登入可瀏覽與下單。