2026 年多團隊遠端 Mac 與 CI 共用 SFTP：併發工作階段、平行 Job 與 keepalive 決策矩陣

三類痛點：連得上不代表扛得住平行上傳

痛點 1：CI 矩陣一展開就斷。各階段同時建立多路 SSH／SFTP；若 MaxSessions 或半開連線上限偏緊，日誌常只顯示 connection reset，易誤判為網路閃斷。

痛點 2：互動式 SFTP 與自動化 rsync 搶同一預算。大檔拖放上傳與流水線增量同步共用 SSH 子系統，卻少有人把它們納入同一張連線與頻寬表。

痛點 3：中間設備靜默掐閒置 TCP。公司出口或 NAT 常清理 300～600 秒無流量的連線；大檔中間若遇讀碟停頓，應用層看似仍活著，實際路徑已被摘掉。沒有 keepalive 與分段驗證就只能依賴端到端重傳。

2026 年先選模型再調設定

單工作階段串行適合極小團隊與低頻發布，實作最簡但吞吐最差。有限併發為多數團隊預設：為 CI 明確上限（例如全域 2～4 條活躍 SSH）並搭配佇列。佇列化把「誰先傳」交給集中排程，適合多產品線共用同一台 Mac。分帳號／目錄隔離把不同團隊對應到不同 chroot 或前綴，並可結合每使用者連線配額，與權限與稽核的最小權限一致。

若已採暫存目錄＋軟連結切換，請把「發布瞬間」與「持續同步視窗」分開預算：原子切換只需短時間高可靠連線，日常同步可用較低併發、較長週期，兩者不可混在同一連線預算表內。

五步落地

以下順序與命令片段一致；OpenSSH 系，修改 sshd_config 後須滾動重啟並留存變更前後的 sshd -T 輸出。

1. 匯出並歸檔目前生效的 maxsessions、maxstartups、clientalive 相關項。
2. 在變更視窗調整 MaxSessions、MaxStartups、ClientAlive 系列，重啟 sshd 後再次核對 sshd -T。
3. 在 CI Runner 與維運筆電的 ssh 設定中寫入 ServerAliveInterval／CountMax，必要時啟用短時間 ControlPersist。
4. 為 GitHub Actions matrix 設定 max-parallel，或為上傳步驟增加互斥鎖／集中佇列。
5. 將活躍 SSH 連線數、斷線時的 errno、吞吐與時間點記入日報，對照防火牆閒置策略。

sshd -T | egrep 'maxsessions|maxstartups|clientalive'
# MaxSessions 10
# MaxStartups 10:30:100
# ClientAliveInterval 60
# ClientAliveCountMax 3
Host your-remote-mac
  ServerAliveInterval 30
  ServerAliveCountMax 6

圖形化客戶端請開啟等效 keep alive；見工具指南。

可引用數字

在無專用廣域網路最佳化前提下，客戶端 ServerAliveInterval 約 30 秒、伺服端 ClientAliveInterval 約 60 秒，常可穿過企業防火牆對閒置 TCP 的靜默視窗。MaxSessions 常見預設為 10，但若同機還跑遠端桌面、同步與其他 Agent，請勿盲目拉滿，應為系統與互動連線保留余量。

CI 重試建議指數退避：首次失敗後等待 15～30 秒，第二次 60 秒，並記錄斷線是否伴隨 TLS／SSH 握手失敗，以區分「配額問題」與「路徑錯誤」。單次上傳超過約 5 GiB 時，優先分片或採支援校驗斷點的工具鏈，並把發布一致性交給暫存目錄與軟連結切換，而非僅加長逾時。

FAQ 與託管遠端 Mac

• 平行 Job 斷線一定是伺服器壞？先查上限、NAT 閒置與 keepalive。
• SFTP 與 rsync 會搶資源？會，請統一併發預算。
• 與原子發布？原子發布管一致性，本文管連線穩定性。

小結：有限併發＋keepalive 可消除多數「無故斷線」。局限：自用筆電當建置機仍受睡眠、手動改 sshd、與人機混用干擾。為何考慮 SFTPMAC：託管遠端 Mac 搭配 SFTP 目錄隔離，可把連線配額與政策寫進交付規範並維持長時間在線，讓團隊專注流水線而非救火。

SFTPMAC 提供可選節點與 SFTP 隔離；可同時閱讀工具選型與原子發布，統一「傳輸穩定」與「切換安全」。