Silent Failure

靜默失敗指的是：一個排程任務實質上已經沒有在正常運作（可能是重試用盡後放棄、可能是資料來源本身就有問題），但從系統外部觀察，完全看不出任何異狀——沒有錯誤訊息、排程照常在設定時間觸發、介面上沒有任何紅字或警告。這是 fallback instruction（備援指示）要防範的核心情境：如果重試策略用盡後，系統沒有明確通知人，只是安靜地停在那裡，就會產生靜默失敗。這跟一般理解的「任務失敗」不同——多數人想像的失敗是有明顯訊號的（跳出錯誤視窗、收到失敗通知），靜默失敗恰恰相反，它的危險之處就在於沒有訊號，你必須主動去查才會發現，而多數人不會沒事就去查一個「看起來在正常運作」的系統。

這個現象會發生，是因為「系統看起來在跑」跟「系統真的完成了該做的事」是兩件不同的事，但多數人日常判斷系統健不健康，用的是前者的訊號——排程按時觸發、介面沒有紅字，就直覺認為沒問題。這個直覺在多數情況下是對的，但在重試用盡卻沒有配套通知機制的情況下會失靈，因為觸發跟失敗可以同時發生：系統確實在設定時間醒過來、確實嘗試執行、確實失敗了三次、也確實照著設計放棄了——這整套流程完全正常運作，只是最終結果是「什麼都沒完成」，而這個結果沒有任何管道被傳達出去。靜默失敗因此不是系統設計上的漏洞，反而經常是系統「完全按照設計運作」的結果——問題出在設計本身沒有把「失敗後要通知」這件事考慮進去。

實務上有兩種偵測靜默失敗的做法。第一種是設計時就預防：確保每個排程任務都搭配 fallback instruction，重試用盡或判定不該重試時，一定要有明確、人看得到的動作，而不是任其安靜停止——這是從源頭杜絕靜默失敗的方式，比事後偵測更根本。第二種是主動巡檢：定期（例如每週）檢查關鍵排程任務最後一次成功執行的時間，如果某個任務「最後成功時間」比預期的執行週期還久，就代表它可能已經靜默失敗一段時間了，這個檢查本身也可以是另一個排程任務，形成「用排程監控排程」的結構。兩種做法搭配使用最完整：第一種降低靜默失敗發生的機率，第二種則是在第一種萬一沒設計好的情況下，提供一道最後的安全網。

對你來說，靜默失敗真正的風險不在「任務失敗」這件事本身，是在「失敗到被發現」之間那段時間，因為系統看起來正常，你不會主動去懷疑它，這段時間裡累積的損害（資料連續好幾天沒更新、報表用的是好幾週前的舊資料）會一直增加，直到有人偶然發現不對勁。真正該建立的習慣是：任何你設計的排程任務，動筆時就該假設「這個任務有一天會失敗」，並問自己「失敗的時候，我會怎麼知道」——如果答案是「我不會知道，除非我剛好去查」，這就是一個潛在的靜默失敗風險點，需要補上明確的通知機制。要留意的是：靜默失敗一旦真的發生，事後追查的成本通常遠高於當初設計通知機制的成本，因為你不只要修好任務本身，還要往回追查這段沉默期間到底累積了多少錯誤資料，這個追查過程本身可能比原本的任務複雜得多。