自動化最可怕的不是壞掉，是停了一個半月我都沒發現

九月中的某一天，我才發現一個每週自動產出摘要的排程，從七月底就被停用了。

一個半月。中間沒有錯誤訊息，沒有通知，我也完全沒注意到少了什麼。因為「停用」不算出錯，他就只是安安靜靜地不跑了。

那時候我才意識到一件有點不舒服的事：我花了很多力氣讓自動化會動，卻幾乎沒花力氣讓他停下來的時候會出聲。

回頭盤點，五次都是同一種壞法

我把最近自己專案裡出過的狀況翻出來，至少有五次是同一個模式：東西壞了，但看得到的訊號全是綠的。

1. 前陣子網站上 24 條站內連結壞了整整一週，驗證腳本每次都回報全部通過
2. 每週產出摘要的排程，七月底被停用，九月中才發現
3. 一個工具站的意見回饋表單，背後要寫入的資料庫函式根本不存在，使用者看到送出成功，錯誤紀錄是 0 筆，好幾個月的回饋都沒存到
4. 筆電上的排程，因為系統預設用電池時不執行，沒插電那幾輪直接被跳過
5. 批次生圖腳本把「額度用完」誤判成「這張圖有問題」，整批跳過，最後還回報說不是額度問題

這五件事沒有一件是程式當掉。當掉還好處理，他會噴錯、會停在那裡。麻煩的是這種：每一步都照設定在走，每個回報都說沒事，只有結果是空的。

我後來整理出三條原則，再加一個每週的巡檢。

第一條：從結果驗，不是從有沒有跑驗

回饋表單那件事最典型。

使用者按下送出，畫面說成功。錯誤紀錄是 0 筆，因為負責記錄錯誤的那支函式，跟負責存回饋的是同一批不存在的函式，而記錄錯誤的程式為了不拖慢網站，本來就設計成自己失敗也不吭聲。

整條路上會說實話的只剩一個地方：那張資料表裡，到底有沒有新資料。

生圖腳本也一樣。腳本跑完了、有回報、回報看起來很合理，但真正該看的是資料夾裡多了幾張圖，而那一批是整批被跳過的。

所以我現在對每一條自動化都先問：這件事做成功之後，世界上會多出什麼東西? 一筆資料、一個檔案、一封寄出去的信。然後去數那個東西，不是去看執行紀錄。

還有一個我以前完全反過來的直覺：錯誤紀錄 0 筆，是最該起疑的數字。 一個有人在用的表單，幾個月零錯誤，比較可能的解釋不是他很完美，是記錄的那條路也斷了。

第二條：檢查別跟被檢查的東西共用同一個假設

24 條連結那件事，問題不只是連結壞，是驗證腳本一直說全部通過。

後來查出來，文章裡的連結是照我以為的網址規則寫的，驗證腳本也是照同一套規則去組網址、去比對。網站實際的路徑跟我以為的差了一個字母（單數跟複數），但兩邊錯得一模一樣，所以驗證永遠會過。

等於拿自己的假設，去驗自己的假設。

生圖腳本也是這個結構。判斷「是不是額度問題」的那段邏輯就是寫錯的那段，所以他一邊誤判，一邊很有自信地說不是額度問題。錯的診斷比沒有診斷更麻煩，他會把你帶往錯的方向。

我後來的原則是：檢查要去問真正的那一方。 連結對不對，直接打線上網址看回不回正常頁面，不要自己再組一次。資料有沒有存，直接去數資料表，不要相信寫入那段程式自己的回報。

這跟我之前寫的 AI 流程的人工檢查點 是同一件事的另一面。那篇講人要在哪一步看，這篇講機器的檢查不能跟被檢查的東西串通好。

第三條：每個排程都要有「該發生卻沒發生」的提醒

摘要排程被停用、筆電沒插電被跳過，這兩件事有一個共同點：根本沒有東西在執行，所以也不會有東西報錯。

一般監控是出事時叫你，這種狀況要反過來，在「該有動靜卻沒有」的時候叫你。

筆電那件事，微軟的官方文件寫得很清楚：Windows 工作排程器新建的工作，預設就勾著只在使用 AC 電源時才啟動（英文介面是 Start the task only if the computer is on AC power），錯過排定時間就補跑的選項預設則是關的。照預設走，沒插電那一輪就直接跳過，不補跑也不吭聲。用筆電跑排程的人，值得現在打開「條件」跟「設定」兩個分頁看一眼。

工具上，我覺得最省事的是 Uptime Kuma 的 Push 監控。一般監控是他主動去敲你的網站，Push 反過來：他給你一串專屬網址，排程跑完去敲一下，超過你設定的 Heartbeat Interval 還沒收到，他就把監控標成 Down 並發通知。每週跑的排程，時間窗就設得比一週稍長。

這裡有個細節跟第一條連在一起：敲那個網址的動作，要放在驗完結果之後，不是放在腳本最後一行。 先確認真的多了圖、多了資料，再回報「我還活著」。不然只是把「有沒有跑」換個地方再驗一次。

通知要推到手機，我會選 ntfy。Uptime Kuma 的通知管道裡就有 ntfy，腳本自己要發通知也只要一行 curl 送到你訂閱的主題。

另外，Uptime Kuma 最好放在跟被監控的東西不同的機器上，不然那台一起掛掉時，負責叫你的人也一起睡了。

每週五分鐘巡檢

上面三條是讓系統自己會叫。但一定還有我沒想到的壞法，所以我覺得還要補一層：每週五分鐘，用眼睛看一次。清單壓得很短：

1. 每個排程最近一次「產出」是什麼時候，看的是結果的時間，不是執行的時間
2. 該有資料進來的表，這週的筆數是不是 0
3. 錯誤紀錄如果連續幾週都是 0，就故意弄出一筆錯，確認記得到
4. 監控本身還活著嗎，上一次真的發出通知是什麼時候

每週會更新的對外頁面，可以丟進 changedetection.io，頁面一更新他就會通知你。巡檢時看這週有沒有收到那則通知，沒收到就是該去查了。

清單一定要短，五分鐘看不完的巡檢，一個月後就不會有人做。

最後

這幾次之後，我對「沒消息」的態度整個變了。以前沒消息就是好消息，現在沒消息是一個需要確認的狀態。

自動化省下來的時間是真的，但他也把「發現出事」從每天順手看到，變成需要刻意設計的事。沒設計好，省下來的時間會在某一天連本帶利還回去。

不是自動化不可靠，是我把安靜當成了沒事。

更多 AI 工具跟工作流程的整理，我放在 AI101。

常見問題