昨天開始替自動化流程加上 Log 和監控之後，至少我終於知道流程什麼時候壞掉，也可以看出問題發生在哪一個步驟，但很快又碰到下一個很實際的情況，知道它壞掉之後，接下來呢？

如果每一次失敗都還是要我打開系統、找到那次執行紀錄，再自己按一次重新執行，那整套流程其實還是需要人一直照顧。

所以今天我開始把「失敗之後要怎麼辦」也放進自動化流程裡。

很多錯誤其實只是暫時的

以前看到 Workflow 執行失敗，我第一個反應通常都是程式是不是寫錯了，但實際跑久一點之後會發現，很多失敗其實跟流程邏輯沒有太大關係。

例如 API 剛好 Timeout、第三方服務暫時連不上、網路不穩，或者服務回了一個暫時性的 Server Error，這些問題過幾秒再執行一次，很可能就會直接恢復正常。

如果這種錯誤每次都通知我，其實很快就會遇到昨天提過的問題，通知越來越多，最後我開始懶得看，真正重要的錯誤反而被埋在裡面。

所以第一個加入的機制很單純，就是 Retry。

Retry 也不能一直按

一開始看到 Retry 很容易會想，只要失敗就重新執行，失敗三次就再跑三次，但真的放進 Workflow 之後才發現，這件事情也需要限制。

假設今天失敗的是讀取資料，重新執行通常沒有太大問題，但如果這個步驟是寄信、建立訂單、寫入資料庫或發出通知，直接 Retry 就可能讓同一件事情被做兩次。

所以現在我會先把流程裡的動作分開來看，哪些步驟可以安全重試，哪些步驟在重試以前必須先確認前一次到底有沒有成功。

像讀 API、抓資料這類動作通常比較適合自動 Retry，涉及寫入或對外行動的步驟就要小心得多，至少要有唯一識別碼、狀態紀錄或重複執行保護，否則原本只是想讓流程更穩定，最後反而可能製造更多問題。

幾次失敗之後才需要找我

加入 Retry 之後，我也重新調整了通知條件。

第一次遇到 Timeout 時，系統可以自己等一下再試，第二次失敗再繼續記錄，真的連續幾次都沒有恢復，才把錯誤資訊整理起來通知我。

通知內容也不能只有一句「Workflow failed」，至少要讓我知道是哪一個流程、哪個步驟、什麼時間失敗、已經重試幾次，以及最後收到什麼錯誤訊息。

這樣我收到通知時才是真的需要處理，而不是每次有一點小波動就被叫回去看系統。

做到這裡，我才發現自動化穩不穩定，其實跟流程成功時做了多少事情沒有直接關係，真正跑久之後，更常遇到的是各種失敗、Timeout、資料缺漏和第三方服務突然沒有回應。

前幾天我一直在想怎麼讓 Workflow 自己把事情做完，現在開始補的是它出錯之後怎麼自己恢復。

如果連 Retry 都救不回來，下一步就不能只是繼續重試了，明天我想來處理另一個問題，一個步驟真的完全失敗時，要怎麼避免整條自動化跟著一起停掉。