先定義斷線期間必須保住什麼
工廠網路可能因電信線路、路由器、防火牆、DNS、憑證或雲端服務異常而中斷。設備與邊緣閘道通常仍在運作，因此核心問題不是如何避免所有斷線，而是哪些資料必須保存、可以延遲多久，以及何時允許丟棄。警報、批次追溯、品質量測與能源累積值通常需要可靠保存；高頻振動原始波形則可能只保留特徵值，或在儲存壓力升高時依政策降採樣。
工程團隊應為每一類資料定義可接受的遺失範圍、最長離線時間、補傳期限、順序需求及雲端不可用時的本地功能。緩衝容量可用事件速率、單筆序列化後大小及最長離線時間估算，再加入檔案索引、重試佇列與磁碟維護空間。不要只看平均流量；開機同步、批次結束及警報連發往往形成尖峰。若磁碟用盡，系統也必須有明確的淘汰順序，而不是讓作業系統任意失敗。
在邊緣端建立可持久化的 store-and-forward
僅把資料放在記憶體佇列並不算容錯。斷電、程序重啟或容器更新都可能清空佇列。較穩健的做法是先將事件寫入本地持久化儲存，確認寫入成功後才向設備端確認接收，再由獨立的上傳工作程序傳送至雲端。SQLite、嵌入式日誌或分段檔案都可行；選擇重點是崩潰後能否恢復、寫入放大是否適合儲存媒體，以及是否容易依時間與狀態清理。
每筆事件應包含穩定的設備識別、來源時間、邊緣接收時間、序號、資料版本與唯一事件識別。來源時間有助於還原製程順序，接收時間可協助發現設備時鐘漂移；兩者不應互相取代。上傳成功也不應只代表 HTTP 連線完成，而要等到雲端已持久化並回覆可核對的確認資訊後，才能把本地事件標記為可刪除。
- 至少一次傳送：實作較務實，但雲端必須依事件識別做冪等寫入與去重。
- 順序控制：只在同一設備或同一資料流內維持順序，避免全廠共用單一序列造成阻塞。
- 分段儲存：依時間或容量切分檔案，讓確認、清理與損毀隔離更容易。
- 容量保護：設定警戒水位，優先保留警報與追溯資料，必要時降低非關鍵資料頻率。
重連後要控制補傳，而不是全速傾倒
長時間斷線後，邊緣端可能累積大量資料。如果重連後立即以最高速度補傳，會同時壓迫工廠出口頻寬、雲端訊息服務、資料庫與即時監控。上傳器應把即時流量與歷史補傳分開排程，為即時事件保留頻寬，再以批次大小、併發數與速率限制逐步清空積壓。雲端若回覆節流或暫時性錯誤，應採用帶隨機抖動的指數退避，避免多台閘道同時重試。
補傳順序必須配合資料語意。警報與狀態轉換通常要依來源序號處理；可交換順序的遙測資料則可批次壓縮。雲端消費者也要能辨識遲到資料，不能把抵達時間當成事件時間。例如報表可依事件時間回補，告警引擎則需定義過期警報是否仍通知。若資料格式在離線期間升級，接收端應依版本解析，而不是假設所有積壓資料都符合最新結構。
把可觀測性與故障演練納入交付條件
系統顯示連線正常，不代表資料管線健康。至少要監測最後一次設備取樣、最後一次本地落盤、最後一次雲端確認、佇列筆數、最舊未送事件年齡、磁碟剩餘空間、重試原因與去重結果。告警應區分設備無資料、邊緣程式異常、網路不可達及雲端拒收，否則維運人員只會看到籠統的離線訊息。
上線前應主動拔除外網、阻擋 DNS、讓雲端回傳錯誤、重啟閘道、模擬磁碟接近滿載，並在積壓尚未清空時再次斷線。驗證重點包括事件是否遺失或重複、順序是否符合約定、重啟後能否續傳，以及補傳是否影響即時資料。資安也不能因離線模式而降低：本地資料需要權限控管與必要的靜態加密，憑證輪替失敗要可診斷，設備身分不可因重裝而意外改變。
- 驗收資料完整性：以來源序號或測試事件清單核對端到端結果。
- 驗收復原行為：觀察重連、退避、續傳、去重及清理是否符合狀態機設計。
- 驗收維運能力：確認現場人員能從指標判斷問題位置，且不需直接修改資料庫。
真正可靠的架構會把離線視為正常運行狀態之一，並讓保存、降級、補傳與清理都有明確規則。若設備協定、網路、雲端資料模型與既有 ERP 或維運流程分屬不同團隊，可由具整合經驗的工程團隊共同定義端到端責任邊界。