企業(yè)把訂單、工單、合同或報銷流程自動化后，最危險的問題不一定是“流程沒跑”，而是同一件事跑了兩遍：生成兩張單、發(fā)兩次通知、重復扣減庫存，或者把同一個文件再次寫進系統(tǒng)。表面看是偶發(fā)故障，真正缺的是重復輸入和重試邊界。
自動化流程重復執(zhí)行并不只發(fā)生在復雜系統(tǒng)里。定時輪詢、Webhook 重送、連接超時、多個流程副本、并發(fā)處理和人工補跑，都可能讓同一個業(yè)務(wù)對象再次進入流程。企業(yè)需要保證的不是“每次只觸發(fā)一次”，而是“即使觸發(fā)多次，業(yè)務(wù)結(jié)果也只完成一次”。
看到失敗，不代表前一步?jīng)]有成功
自動化調(diào)用另一個系統(tǒng)時，可能已經(jīng)成功創(chuàng)建訂單，但返回結(jié)果在網(wǎng)絡(luò)中斷時丟失。當前流程只看到超時，于是按重試策略再發(fā)一次。如果目標系統(tǒng)無法識別這是同一次業(yè)務(wù)請求，就可能創(chuàng)建第二條記錄。
AWS 在關(guān)于安全重試的技術(shù)說明中強調(diào)：臨時故障可以通過重試恢復，但前提是重試不會產(chǎn)生額外副作用。否則一次創(chuàng)建資源的請求被重復執(zhí)行，就可能得到兩個結(jié)果。
所以流程日志不能只有“成功”和“失敗”。至少還要能表達“已發(fā)送但結(jié)果未知”“目標已存在”“等待人工復核”和“確認可以重試”。結(jié)果不明確時直接重跑，是重復處理最常見的入口之一。
另一個容易忽略的來源，是同一套流程存在多個副本。測試環(huán)境沒有關(guān)閉、舊版本仍在運行，或者兩個部門各自建立了相同觸發(fā)條件，一條新記錄就可能同時啟動兩條流程。此時單看每條流程都沒有報錯，但業(yè)務(wù)端已經(jīng)收到兩個結(jié)果。因此上線清單里還要記錄流程名稱、環(huán)境、負責人和啟用狀態(tài)。
先識別同一件業(yè)務(wù)，再談流程次數(shù)
很多流程只有每次運行自己的 Run ID，卻沒有業(yè)務(wù)唯一編號。系統(tǒng)知道今天跑了兩次，卻不知道兩次處理的是不是同一張訂單。
企業(yè)應(yīng)該為需要避免重復的對象選擇穩(wěn)定標識，例如來源系統(tǒng)訂單號、工單號、合同編號或“來源系統(tǒng) + 記錄 ID”。這個標識代表業(yè)務(wù)意圖，不應(yīng)隨著每次重試重新生成。
還要注意，唯一編號本身不能包含密碼、身份證號、客戶郵箱等敏感信息。需要跨系統(tǒng)傳遞時，可以使用內(nèi)部記錄 ID 或不可逆摘要，并在本地保留對應(yīng)關(guān)系。
業(yè)務(wù)唯一編號和每次運行編號要分開。運行編號用于排查這一次執(zhí)行，業(yè)務(wù)編號用于判斷多次執(zhí)行是否屬于同一件事。如果每次重試都生成新的業(yè)務(wù)編號，去重機制就會把它當成新訂單；如果不同訂單誤用了同一個編號，系統(tǒng)又可能把真實的新業(yè)務(wù)擋掉。編號規(guī)則必須在來源系統(tǒng)確定，并經(jīng)過重復與沖突測試。
冪等不是“發(fā)現(xiàn)重復就全部跳過”
冪等的大白話解釋是：同一個操作執(zhí)行一次和執(zhí)行多次，最終業(yè)務(wù)結(jié)果保持一致。Microsoft 在 Power Automate 觸發(fā)器排障文檔中也建議流程考慮重復輸入，例如創(chuàng)建 SharePoint 文檔前先檢查是否已經(jīng)存在，或者用數(shù)據(jù)鍵約束阻止重復記錄。
但判斷重復不能只看客戶名稱、日期或文件名。兩個客戶可能同名，同一客戶也可能在一天內(nèi)下兩張訂單。企業(yè)要把業(yè)務(wù)唯一編號、關(guān)鍵輸入摘要和處理狀態(tài)一起保存。
如果同一編號再次到達、輸入完全一致且第一次已經(jīng)完成，可以返回原結(jié)果；如果同一編號對應(yīng)的金額、明細或版本發(fā)生變化，就不能靜默跳過，應(yīng)進入沖突隊列讓責任人判斷。
寫入前檢查，寫入后再回讀
可靠流程通常需要一張?zhí)幚碛涗洠辽侔簶I(yè)務(wù)唯一編號、來源、首次接收時間、當前狀態(tài)、目標系統(tǒng)記錄號、最后一次嘗試、錯誤原因和復核人。
在創(chuàng)建訂單、發(fā)送正式通知、生成合同或扣減庫存前，先查詢該編號是否已經(jīng)處理；執(zhí)行后再回讀目標系統(tǒng)，把真實記錄號寫回。只有這樣，流程恢復時才知道應(yīng)該繼續(xù)、跳過、補償還是交給人工。
日志記錄也不能代替數(shù)據(jù)庫約束。兩條并發(fā)流程可能在幾乎同一時間查詢，都看到“尚未處理”，隨后各自創(chuàng)建一條記錄。對關(guān)鍵對象，除了流程層檢查，還應(yīng)讓目標系統(tǒng)通過唯一鍵、受控的更新方式或事務(wù)邊界阻止并發(fā)重復；做不到時，應(yīng)把寫入動作串行化并設(shè)置人工異常隊列。
Stripe 的接口文檔用 idempotency key 識別同一次創(chuàng)建或更新請求的重試，避免重復創(chuàng)建對象。企業(yè)不一定使用同一產(chǎn)品，但“同一業(yè)務(wù)意圖使用同一個鍵、輸入變化不能假裝是同一次請求”的原則可以借鑒。
五項上線前檢查
- 為訂單、工單、合同或報銷記錄確定一個跨流程穩(wěn)定的業(yè)務(wù)唯一編號，并寫清生成責任。
- 列出哪些動作有不可忽略的副作用，例如建單、扣庫存、發(fā)正式郵件、生成文件和寫財務(wù)記錄。
- 增加處理狀態(tài)與目標記錄號，流程超時后先查詢實際結(jié)果，不憑“失敗”字樣直接重跑。
- 對同一編號但輸入發(fā)生變化的情況建立沖突隊列，不覆蓋舊結(jié)果，也不自動跳過。
- 用同一測試記錄連續(xù)觸發(fā)兩次，確認最終只有一個業(yè)務(wù)結(jié)果，同時日志能看到第二次如何被識別和處理。
核心判斷：自動化的可靠性不在于保證永遠只觸發(fā)一次，而在于重復觸發(fā)、重試和補跑發(fā)生時，系統(tǒng)仍不會把同一件業(yè)務(wù)辦兩遍。
如需梳理訂單、合同、工單或報銷流程中的業(yè)務(wù)編號、重試策略、狀態(tài)記錄和異常處理，可以聯(lián)系煜企智能，從現(xiàn)有表格與流程運行記錄開始評估。