排程任務半夜掛了沒人知道？給 cron 加一層可觀測性

自動化最怕的不是失敗，而是靜默失敗。一個每天凌晨 2 點跑的備份任務，如果連續一週都掛了，你發現的那天，才是要出大事的那天。這一講怎麼用最少的成本，給 cron 任務加一層掛了會叫的可觀測性。

第一層：退出碼不等於健康

很多人以為命令跑完 echo ok 就算監控了。問題在於：命令成功退出但沒有產出結果，是 cron 世界最陰險的失敗。比如腳本跑完了，但因為上游 API 變更，一筆資料都沒寫進去——exit code 是 0，日誌裡也沒有報錯，只有結果數量是 0。

所以每一條任務都要給自己定義業務級成功條件：寫庫任務檢查受影響列數，發布任務 GET 回讀確認狀態，備份任務核對產物檔案大小和時間戳。把成功從 exit code 升級為業務斷言，是 cron 可觀測性的第一塊基石。

第二層：心跳比告警更便宜

與其等任務失敗再告警（任務本身沒跑、機器當機、cron 守護行程死了，都輪不到你的告警邏輯），不如反過來：讓任務成功後上報一個心跳。用 dead man's switch（死人開關）的思路——健康監控服務每隔 N 小時沒收到 ping，就說明任務沒活著，主動發通知。GitHub Actions 有第三方託管方案，自託管的話一個小 HTTP 端點加一條 cron 掃描就夠用。

心跳要點：任務結尾加一行 curl 或腳本呼叫；逾時閾值設成排程週期乘以 2 加緩衝；上報內容帶上任務名、日期、關鍵產出計數，排查時不用登機器就能定位。

第三層：留一份人類可讀的執行檔案

機器告警之外，每次執行往固定位置追加一行摘要：時間、任務、狀態、耗時、產出數。檔案比資料庫更適合半夜排查——tail 一眼看穿最近七天的規律。哪天耗時突然翻倍、產出突然減半，趨勢肉眼可見，往往比閾值告警更早發現問題。

上線前的自我檢查清單

給新 cron 任務過一遍這四問：失敗時誰會知道？會不會靜默成功？重試會不會造成重複副作用（寫庫要先查重複、發布要冪等）？日誌能不能在 30 秒內定位到出錯那一步？四問都有答案，任務才配得上無人值守四個字。

自動化的尊嚴不在於它平常跑得多順，而在於它掛掉的那一刻，有人——或者至少有個行程——在替你著急。