push 成功、網站沒動：自動化最危險的不是失敗，是沒被觸發

先給場景。我們把一批官網改動推上 main，GitHub 顯示收到了。接著輪詢線上版本 22 分鐘，網站一個字都沒變——回應標頭寫著 age: 364253，換算是四天又五小時前的快取。

我們當下的結論是：部署管線壞了。這個結論是錯的。

症狀：三個事實兜不起來

手上有三件事，彼此矛盾：

如果整合斷了，四天前那次不會成功；如果整合沒斷，今天這次不該毫無反應。

一般查部署會去看平台的建置清單，找紅色的失敗或轉圈的排隊。但我們什麼都沒看到——清單裡最後一筆停在四天前。

關鍵在下一步。我們沒有繼續盯著網站看，改去問 GitHub 自己：

# 部署平台每跑一次，都會回報一筆 deployment 事件給 GitHub
gh api "repos/<owner>/<repo>/deployments?per_page=4"

回來的最後一筆是四天前那次。再查今天這顆 commit 的狀態，status 0 筆、check-runs 0 筆。

這才是問題真正的形狀：不是部署失敗了，是部署從來沒有發生。webhook 沒被投遞，而「沒被投遞」這件事在兩邊都不留痕跡——平台沒有失敗紀錄可看，GitHub 也沒有紅叉可查。一片空白，跟管線壞掉長得一模一樣。

寫到這裡的判斷都對。接下來是這次真正的教訓。

認定管線壞掉之後，我們把專案狀態標成紅色，並請使用者去後台排查。二十分鐘後，為了把這件事記錄下來又推了一次 commit——那次 push 兩秒後就觸發部署，42 秒建置完成，全部正常。

管線沒壞。是那一次投遞掉了。而我們推完第二次之後沒有回頭再測，就拿第一次的觀察去下結論。

錯的不是觀察，是推論。觀察到的「零反應」是真的；把零反應解釋成「管線壞掉」則是猜的，而那個猜測當時沒有證據支持——它有的只是「沒有證據」。

失敗會留下紀錄，沒觸發不會。自動化真正該監控的是它有沒有跑，而不只是它跑得對不對。

兩個做法可以直接抄。

第一，找一個每次發版都會變的小東西當探針。 我們用的是 favicon 檔案大小——這批改動剛好換了圖示，舊檔 2178 bytes、新檔 2436 bytes。一行指令就知道線上是哪一版，不必用肉眼比對頁面：

curl -sS -o /dev/null -w "%{size_download}\n" https://<你的網域>/favicon.ico

版本號檔、建置時間戳、資產檔名的雜湊都可以。重點是它必須是機器可讀的一個值，而不是「頁面看起來有沒有不一樣」。

第二，對時間戳，不要對感覺。 把平台上部署的建立時間跟你 push 的時間相減：差幾秒，代表有觸發、只是還在跑；根本沒有那筆紀錄，代表沒觸發。這兩種情況該做的事完全相反——前者是等，後者是重推。

而重推的成本低到不值得猶豫：一個空 commit 就夠。輪詢超過五分鐘沒動靜就再推一次，比花二十分鐘查後台快得多。

你的自動化，失敗時你會知道嗎？沒跑時呢？ 多數人設了失敗通知，沒設「該跑而沒跑」的通知。前者是紅字，後者是一片安靜——而安靜跟正常長得一樣。每天的自動報表停了三天，通常是有人問起才發現。
你有沒有一個機器可讀的探針？ 每次發版、每小時的同步、每天的報表，都該有一個能用一行指令問到的值，告訴你「線上現在是哪一版、資料更新到幾點」。沒有這個值，排查就只能靠肉眼比對。
你的排查是從症狀開始，還是從紀錄開始？ 盯著網站看是從症狀開始，查事件紀錄是從證據開始。這次如果一開始就去查事件紀錄，判斷時間可以從二十二分鐘壓到兩分鐘。

這和我們寫過的 Repository not found 其實是帳號被切走是同一類毛病：錯誤訊息指的地方不是真正的原因。差別在於那次至少還有錯誤訊息，這次連訊息都沒有。

我們自己的官網和客戶的自動化流程現在都掛著這種探針——看看我們做過的案子，多數維運問題不是修得慢，是發現得慢。

你描述現在的流程，我們告訴你哪一段最值得先裝上監控。