整合失敗怎麼重試？設計錯誤分類、查重與安全重放紀錄

整理外部系統同步失敗的分類、有限重試、事件識別、重播前查重，以及人工告警與故障演練流程。

跨系統同步失敗，不該只靠「再跑一次」處理。要安全恢復，先分辨錯誤能否自行消失，再確認目標端是否已完成，最後留下讓人接手的證據。以下用一筆事件從分類、重試、查重到演練，整理可落地的控制流程；文中的門檻與案例均為假設，實際設定需配合流程風險與外部系統能力。流程負責人可先把每個失敗分成暫時、永久與結果不明三類，替每類寫下允許的下一步、停止條件和接手人。即使尚未建立自動化，也能先用這張規則表統一人工處理，之後再依紀錄找出最常缺少的控制點。

區分暫時與永久錯誤

先把錯誤按「原因是否會自行消失」及「這次寫入是否已發生」分開判斷。前者決定要不要修資料或環境，後者決定重送前是否必須查帳。連線逾時、暫時無法連線、服務忙碌或流量限制，通常屬於可觀察後再重試的暫時錯誤；欄位格式錯誤、必填值缺漏、權限遭拒、對照代碼不存在，則不會因為多送幾次就變好，應轉人工修正或重新授權。分類表要列出觸發條件、預設處置、負責人和轉人工方式，讓值班者能依現象操作，不必猜錯誤訊息的語氣。

另外設一類「結果不明」：請求已送出，但回應在途中遺失或逾時。此時來源系統看見失敗，不代表目標端沒有完成。先標記待確認，保存原事件和目標端查詢線索，再決定是否重播。不要把所有逾時都歸入暫時錯誤，否則剛好在目標端成功、回應卻未返回時，重送就可能多建一筆。

可用三個問題分流：錯誤是否隨時間可能消失？同一筆資料原樣再送，目標端是否可能重複執行？處理前是否需要人修改內容、權限或設定？前兩題決定是否自動重試及查重，第三題決定何時停下告警。分類規則最好能追溯到實際請求階段，例如驗證、送出、回應解析或回寫，不要只記一個「同步失敗」總類。

假設案例：訂單資料因暫時連線中斷未取得回應，列為結果不明並先查目標訂單；若回查沒有相符資料，才進入有限重試。若回應明確指出地址欄位缺漏，則標為永久錯誤，交由資料負責人補齊後建立新嘗試。這種分類會讓同一種表面上的「失敗」走不同路徑，降低盲目重送和反覆修復的機會。

制定安全重試條件

設定重試前，先確認原操作是否可安全重複。若目標端支援冪等鍵，使用同一事件的穩定識別值，讓重送可以對應到同一個操作；若不支援，就先設計查重或回查步驟，否則只要第一次結果不明，便不能直接自動送第二次。冪等鍵應源自業務事件而非每次呼叫新生成的請求編號，否則重試會被當成另一筆操作。

只對暫時錯誤啟用有限次數、逐步拉長間隔的重試，並加入隨機延遲，避免一批工作同時恢復後再次塞滿目標端。設定最大嘗試次數與最長等待時間，達到任一上限就停止自動送出，保留待處理狀態並通知負責人。間隔、上限與告警時限沒有通用答案，應依資料重要性、允許延遲和外部系統限制訂定，先在低風險流程觀察，再調整。

每次重試前都重新檢查條件：錯誤類別仍可重試、授權仍有效、資料版本未變、沒有相同事件正在處理，而且目標端尚未完成。若人工修正了資料，應保留原始失敗紀錄並建立修正後的新嘗試，避免把兩個不同輸入混在同一歷史。永久錯誤、重複風險未排除或正在維護的目標系統，都應暫停自動重試。

假設一家小店每隔一段時間重試一次，最多三次，整段流程最多等待一小時；這只是示例，不是建議標準。若三次後仍是連線錯誤，事件進入人工佇列，而不是無限循環。若第一次已回傳永久的欄位錯誤，則不消耗重試額度，直接通知資料負責人。排程還需有暫停開關、人工重送入口和狀態檢視，使值班者能停止一批錯誤重試，不必改程式或刪除紀錄。

記錄事件識別資訊

每個同步事件都要有跨系統可追查的識別資訊。至少保留來源事件編號、來源資料編號、操作種類、目標系統、建立時間、每次嘗試的時間與結果、錯誤分類，以及目前處理狀態。另產生關聯編號串起同一事件的驗證、送出、回應與人工處理紀錄；若外部系統提供自己的紀錄編號，也一併保存。這些欄位讓工程或營運人員可以回答「哪個來源、哪次操作、送到哪裡、是否完成」，而不是依賴截圖猜測。

紀錄要能分辨「事件」與「嘗試」：一個業務事件可能有多次網路呼叫，但仍是一筆待完成的同步。以事件編號作主索引，嘗試序號逐次增加，保存每次結果，不要覆寫前一次錯誤。記錄內容指紋或版本即可協助辨認輸入是否改變；避免把完整客戶資料、憑證或授權權杖寫進一般日誌。若來源系統會修改既有資料，也記錄事件產生時的版本，避免以新狀態覆蓋舊失敗。

可做一次手動追蹤演練：隨機挑一筆失敗事件，只看紀錄，要求值班者找出來源、最後一次送出時間、目標端是否已建立資料，以及下一個安全處置。若任何一項只能靠某位同事的記憶補足，就把缺少的欄位或查詢連結加入事件紀錄。欄位不必愈多愈好，每項都應回答排查、查重、責任交接或稽核中的一個問題。

重放前先做查重

重播前先查目標端是否已有相同業務結果。優先用目標單號、來源事件編號、冪等鍵或可靠的業務組合條件查詢；不能只用姓名或金額等可能重複的欄位。若查詢結果唯一且內容吻合，將事件標記為已完成或待人工核對，不再建立新資料。若查不到、查詢本身失敗，或找到多筆可能資料，狀態應維持待確認，不能把「查詢失敗」解讀為「資料不存在」。查詢失敗時保留原狀態與錯誤證據，等查詢恢復後再判斷。

查重還要處理同時發生的情況：兩個工作者可能在彼此查詢完成後，同時重播同一事件。可用事件鎖、唯一性限制或目標端冪等鍵，讓同一事件同一時間只有一個寫入流程；完成後釋放鎖並記下結果。鎖逾時或工作者中斷時，要有可檢查的過期狀態與接手方式，避免鎖永久卡住，或兩邊都以為自己可重送。

假設案例：付款同步送出後逾時，值班者先用來源事件編號查目標帳務。如果查到一筆金額、對象和原事件相符，就保存目標單號並結案；若查到金額不同或同一事件有兩筆，就轉人工核對，不能自動覆蓋或再新增。若沒有任何匹配，確認查詢正常、原操作狀態可判定，再使用原冪等鍵重播。這個例子中的比對條件應依實際業務欄位決定。

每次人工或自動重播都記錄操作者、理由、查重條件、查詢時間、查詢結果、使用的事件識別值和重播後回應。若需要更改輸入，記錄修改前後的版本或指紋。這樣發生重複時才能還原是哪個判斷讓事件通過，而不是只有一筆「已重試」的模糊紀錄。

設定人工告警門檻

告警應根據影響與可處理性分級，而不是每次錯誤都打斷所有人。需要立即處理的情況包括可能重複扣款或建立多筆訂單、關鍵流程整批中斷、目標端結果不明且無法安全查重。可延後到工作時段的情況，則可能是單筆低風險資料缺漏，且有明確負責人與不會逾期的人工補救方式。每級告警都要指定收件角色、回覆期限、接手人和升級路徑，避免通知送到群組卻沒有人認領。

設定門檻時同時觀察失敗數、失敗比例、佇列最舊事件的等待時間、同一錯誤是否持續，以及受影響流程的商業重要性。單次偶發且可安全重試的錯誤可先記錄；持續超過流程允許的延遲、錯誤集中在同一目標，或人工佇列超出處理能力時，就升級通知。不要只用固定筆數，因為每日一筆的流程與每分鐘大量事件的流程，代表的影響不同。

假設某店設定「單筆高風險事件結果不明立刻通知值班者；一般資料錯誤累積到五筆，或最舊事件等待超過兩小時時通知流程負責人」。這些數字只是店家自行設定的演練範例，不代表適用門檻。上線前要以正常流量和可接受延遲校準，並確認有人在期限內能接手。告警內容附上事件編號、分類、影響範圍、最近處置與安全的查詢入口；不要附完整個資或可直接登入的秘密。

每則告警都要能回寫處理狀態：已認領、調查中、等待外部回覆、已修復或需升級。若門檻經常觸發但沒人處理，應調整流程負責人或補救方式，不是單純把通知關掉。定期回看未認領和重複告警，合併同一根因的訊息，讓告警代表一項需要決策的工作，而非訊息噪音。

記錄故障演練結果

設計故障演練時，先挑一條低風險同步流程，寫清楚演練目標、參與角色、停止條件、復原方法與允許影響。準備連線中斷、欄位錯誤、送出後失去回應等情境，確認系統會分類、保留紀錄、停止不安全重播並通知負責人。沒有測試環境時，用不會產生外部寫入的模擬事件或桌面推演；不要用正式資料做破壞性測試。

演練時由一人依操作手冊處理，另一人記錄實際耗時和每個決策依據。觀察值班者能否找到事件識別資訊、查到目標端狀態、判斷是否可重試、停止重複操作，並把案件交給下一責任人。也演練停止重試與恢復佇列；只驗證自動成功路徑，無法證明有人能接住錯誤。

結束後留下日期、流程範圍、情境、預期行為、實際行為、事件紀錄、告警送達與認領結果、復原耗時、未解問題及負責人。把「通過」拆成可核對的結果，例如重複事件沒有第二次寫入、永久錯誤停在人工佇列、結果不明先查重、值班者依手冊完成交接。若演練依賴臨場口頭補充，應更新文件並再跑一次，而不是只記錄大家已理解。

每次修正後安排對應情境重演，確認變更沒有讓其他分類走錯路。對照前後的錯誤紀錄、告警和處理時間；若問題仍在，記下新發現的機制及下一個負責人，不要把未完成項目標成已解決。下一步可先選一種常見失敗，補上分類、查重方式與人工接手人，再做一次桌面演練。若你希望把上述分類、重試與交接規則整理進實際業務流程，可到ZhenheAI 官網了解業務流程與 AI／自動化整合規劃，並帶上這筆失敗事件及現行補救步驟，作為需求釐清與交接討論的起點。