24 小時與 72 小時探活差在哪裡？

24 小時較像門檻級 smoke：能抓明顯路徑中斷與重試策略錯配；72 小時才能覆蓋跨日尖離峰、至少一次計畫維護視窗，以及偶發的 DNS／TTL 與本地快取漂移。若業務允許，建議納入至少一個完整工作日晚間尖峰。

RTT 只看 p50 夠不夠？

不夠。p50 容易掩蓋尾部分散；驗收應同時記錄 p95／p99 與「同節點相鄰探測」的差分。尾部放大常見於晚間併發、憑證輪替與代理鏈路；閾值應寫進 Runbook，而非留在口頭共識。

2026 年六國獨佔遠端 Mac「上線前穩定性驗收」：24–72 小時探活、RTT 尾端門檻、晚間尖峰與維護視窗自查清單

若您把新加坡、日本、韓國、香港、美國東部、美國西部的獨佔遠端 Mac視為發佈前「最後一道實機門檻」，請勿以單次連線測試交差。本文將上線前驗收寫成可稽核動作：24–72 小時連續探活、從控制面到節點的RTT p50／p95 尾端門檻，以及將本地晚間尖峰與機房／電信維護視窗對齊同一時間軸。內文含六類常見假綠燈、決策矩陣、六步 Runbook、三條量化閾值，並與站內 PoC KPI、合規 RTM、SSH／VNC 權限與多區租賃組合互鏈，目標是把「感覺穩」變成「可重現的證據」。

六國遠端 Mac 上線前驗收最常見的六類「假綠燈」

探活只看 TCP 連接埠 22 通斷，不看應用層交握：SSH banner 可達，憑證登入、多因素第二段或跳板式策略仍可能在晚間尖峰逾時；日誌看似網路問題，實為身分鏈路尾端抖動被平均值塗成綠燈。建議拆成「連接埠可用」「金鑰路徑成功」「單次非互動指令結束碼 0」三層，否則易出現日間綠、夜間紅的經典事故。
以單次 ping 代表端到端 RTT：跨區路徑上，ICMP 與應用層 TLS 的排程點不同；若將 DNS 解析、Proxy 交握與 Runner 註冊混成「平均延遲」，p50 平順、p95 暴衝時，CI 會在無明顯程式碼變更下隨機失敗。指標應分欄記錄，而非全歸因於「Git 很慢」。
未對齊本地晚間尖峰與節點時區：六國節點落在不同電網尖離峰；若團隊在台灣／香港晚間放量，而節點端正值其他區域的中午淺峰，驗收結論會漂移。將業務高峰對應到節點本地時間寫進表頭，才能解釋「為何同一腳本週二失敗、週三恢復」。
忽略雲端或電信業者維護公告：短時間視窗內的 p95 上衝多半是計畫性割接，而非您的程式碼。若無維護行事曆對照，覆盤會誤擴大 Runner 併發或亂加機器。將外部視窗與內部變更凍結窗疊在同一張時間表，是穩定性驗收最低成本的紅線。
探活腳本需互動權限，卻未依真實存取路徑驗收：有人用 SSH 跑門檻，有人以 VNC 維護鑰匙圈或圖形工作階段；兩條路徑涉及的沙箱、螢幕共享與自動化權限不同。只驗其中之一，會卡在「真人可修、CI 會掛」。權限清單須與實際值班路徑一致。
證據散在聊天與截圖，缺少可歸檔材料：會議上口頭「昨晚很穩」，若無連續時序與原始探測紀錄，等同未驗收。上線前應將原始 CSV／JSONL、閾值判定腳本版號、比對基線一併凍結，以利事後對照合規與稽核。

這些假綠燈的共同點，是把「連得上」誤等同「在真實負載與時間結構下仍可預測」。獨佔遠端 Mac 的價值在環境邊界清楚，但邊界清楚不代表鏈路清楚；控制面 API、身分、憑證、Runner 與控制通道任一層的尾部放大，都會在晚間被乘數放大。若您正將 PoC 結論推廣到量產節點，建議先對照PoC 擴容與驗收 KPI 矩陣，把「穩定性」從形容詞改成可比數字，再進入六國並行驗收。

驗收材料常須回答稽核與法遵追問：哪些資料出境、哪些日誌留存、哪些金鑰輪替會影響探活口徑。將證據包依版次歸檔，並與同價區合規與證據 RTM 矩陣對齊欄位命名，可減少上線前夜的補件馬拉松。這不取代資安技術方案，而是讓遠端桌面與自動化在同一套敘事中閉合。

本文不把六國議題寫成另一篇 ping 與帳單科普：區位與租期組合請回到多地區節點租賃與成本指南逐行對照；此處只借用一項結論—將「您要驗收的那條鏈路」與節點所在大區寫在同一列，避免 Runbook 讀者混淆新加坡控制面與首爾 Runner。

維度	推薦預設（可簽核）	受控例外（需備註與到期日）	紅線（出現即停發佈或降級）
連續探活時長	至少覆蓋 24 小時並含一個完整晚間尖峰；關鍵發佈建議 48–72 小時	僅門檻環境 12 小時＋事後補測，需書面原因與回補計畫	無跨日樣本卻聲稱「生產可用」
RTT 尾端門檻	同一路徑同時回報 p50 與 p95；相鄰視窗 p95 波動須在閾值內	短時上衝若能逐筆對上維護公告並歸檔可允許	p95 連續多個視窗抬升且無法對齊已知變更或外部視窗
晚間尖峰對照	業務與節點雙時區標註；尖峰腳本與日間腳本分開紀錄	可降低取樣頻率，但不得稀釋高風險操作時段	僅在辦公時段探活卻以晚間流量承諾可用性
維護視窗	外部公告＋內部凍結窗同筆登記；異常自動標籤	視窗內可降級非核心探針	視窗內強制全數通過且不記錄降級範圍
存取路徑一致	SSH 與 VNC 所需權限各有清單與探針	暫時關閉其中之一需替代路徑與回復點	CI 與人工值班走兩套衝突權限卻未在 Runbook 揭露

analytics

第一性原則：穩定性驗收量測的是時間結構下的尾部風險，不是瞬間平均。若在意的是「發佈夜會不會翻車」，就必須讓 p95 與維護行事曆進入同一套敘事；否則數據再漂亮也只是均值層面的自我安慰。

六步 Runbook：將 24–72 小時探活寫成可重現工單

凍結驗收邊界與版次釘選：列入節點 ID、系統版次、Runner 版次、探針腳本 commit、控制面 API 版次；任何變更須走「驗收補丁」而非口頭同步。
拆三類探針：網路、身分、業務負載：網路層測連接埠與 TLS；身分層測金鑰與權杖更新；業務層跑一次最小真實 job（可抽樣）。三層解耦才能在三分鐘內定位層級。
為六國各自建立「本地尖峰行事曆」條目：至少標註業務尖峰、國定假日、已知檔期與內部發佈窗；與節點當地時區對齊，避免混用口頭 UTC。
掛載維護行事曆與變更凍結策略：外部電信／雲端視窗進入同一表；在視窗前後加對照樣本，自動標示「可解釋的上衝」。
匯出可稽核原始資料：JSONL／CSV 含時間戳與區域識別；閾值判定使用固定腳本版次；報告僅引用聚合結果，明細保留備查。
召開 30 分鐘「紅線對照會」：逐條核對表內紅線；任一觸發須有明確降級（回滾 Runner、縮功能、延後發佈），而非「再觀察一下」。

bash

# 範例：每 60 秒記錄一次 SSH 批次模式結果與耗時（請替換探測帳號、節點與實際指令）
LOG="./probe-$(date +%F)-${REGION}.jsonl"
while true; do
  ts=$(date -u +"%Y-%m-%dT%H:%M:%SZ")
  SECONDS=0
  ssh -o BatchMode=yes -o ConnectTimeout=8 "maccome-probe@${NODE}" 'echo ok' >/dev/null
  rc=$?
  printf '{"ts":"%s","region":"%s","ssh_rc":%s,"elapsed_s":%s}\n' "$ts" "$REGION" "$rc" "$SECONDS" >> "$LOG"
  sleep 60
done

權限路徑須與真實排錯一致：若發佈窗允許值班以圖形工作階段修鑰匙圈，但 CI 僅綁 BatchMode SSH，探活過關仍擋不住發佈夜的「人機差分」。將 SSH 非互動與 VNC／圖形路徑的差異寫進同一檢核表，並參考SSH 與 VNC 權限分工指南對齊最小權限集合。

三條應寫進週會與發佈審查的量化口徑（請以團隊基線替換常數）

端到端交握 p95／p50 比值：若連續 6 個1 小時視窗內該比值高於團隊基線 2.3 倍，且無法對齊維護公告或內部變更，應凍結 Runner 升級與發佈，改排查身分鏈路與 Proxy 設定。
晚間尖峰失敗率與日間失敗率差分：若尖峰段（表中標註的2 小時視窗）失敗率較日間基線高出 8 個百分點以上，即使平均仍綠，亦應視為未通過穩定性門檻。
連續零失敗的最短觀測時長：在含一次計畫維護衝撞風險的週期內，若仍要求「零失敗」，至少需 72 小時原始紀錄與對應閾值腳本版次；否則結論僅能寫成「有限條件下通過」而非「生產級承諾」。

收尾：將「穩定性」從簡報用語變成可簽核的附件包

上線前最後一哩路，最耗團隊的不是跑腳本，而是大家對「何謂綠燈」達成一致。以本篇矩陣將預設、例外與紅線寫死，再以 Runbook 釘住 24–72 小時的取樣方法，可大幅減少「我以為你驗了」的灰區。

六國並行時，建議指定一位「時間軸 owner」維護尖峰與維護行事曆的唯一真相來源，其他人只貢獻差異、不各自複製試算表。獨佔遠端節點的工程優勢在於邊界清楚＋可重複登入路徑；驗收材料越像稽核附件，越能把後期維運從救火拉回可預期節奏。

相較於自建機房或拼裝雲端個體戶只在上班時段手動連線抽樣，這類做法往往證據破碎、尾部延遲不可稽核，且難以在 AI Agent 與排程自動化場景維持一致權限面。若目標是讓長時間探活、憑證輪替與多區存取在發佈週仍可依 Runbook 重現，MACCOME 的 Mac 雲主機搭配專用節點與清晰租賃邊界，通常是更穩定、更適合自動化生產的選項。若您需將驗收與彈性租期、節點檔位與區域組合落實為可下單組合，可將本文作為技術附件併入審查；價格與週期對照建議直接查閱產品頁租賃價格說明與文件中心，免得在發佈週把成本與穩定性混成同一場會。