睡前必跑的那道指令

每晚闔上筆電之前，我會執行一道指令。它檢查正式環境中的15,000個頁面：每篇部落格文章、每個公司頁面、每份程式化產出的指南、每個語系變體。針對每個頁面，它驗證HTTP狀態碼、測量TTFB、檢查Cloudflare快取狀態，並記錄任何錯誤。完整檢查約需6小時，在我入睡時於背景執行。

我另外還會跑一趟快速關鍵路徑檢查，約2分鐘完成：健康端點、Sitemap、營收頁面、S級公司Hub、市場頁面、程式化內容索引、i18n部落格彙整。這一輪我會盯著看。若有任何失敗，睡前就會著手調查。

例行檢查產出的報告大致如下：

NIGHTCHECK -- 2026-03-27 (morning)
Overnight comprehensive: 16,228/16,602 ok (97.7%)
Avg TTFB: 715ms
S-tier companies: ALL PASS, ALL HIT
Markets: ALL PASS (89-175ms HIT)
i18n blogs: es 95ms HIT | ja 196ms HIT | de 181ms HIT

沒有人要求我這樣做。沒有任何工單規定。沒有哪個衝刺包含「執行nightcheck」。這套流程之所以存在，是因為我在意——當我不在螢幕前時，網站是否依然正常運作。

為什麼每晚都跑

網站每天都在變動。一天之內，我可能部署87個提交：i18n翻譯、爬蟲供應商更新、CRO實驗、效能修復、Logo修正。每個提交都經過獨立測試。但87個提交的組合效應，可能產生任何單一提交都無法暴露的故障。

一批翻譯可能讓部落格Sitemap超過渲染閾值。新的供應商可能引入一個需要14秒才能渲染的公司頁面。快取標頭的變更可能讓Cloudflare停止快取原本很快的路由。一次CSS重構可能在某個語系中破壞模板，其他語系卻不受影響。

nightcheck捕捉的是組合性故障。不是「這個提交是否破壞了什麼」，而是「今天所有變更落地之後，網站整體是否正常運作」。這個區別至關重要，因為組合性故障在CI中是隱形的。每個提交都通過各自的測試。87個提交各自通過測試，並不保證整合後的系統能正常運作。

測量的內容

檢查分為四個層級：

P0基礎設施。 健康端點回傳正常且資料庫已連線。Sitemap回傳有效的XML。Robots.txt和llms.txt存在。RSS feed有效。這些若壞了，網站對搜尋引擎而言等於隱形。

P0營收。 首頁、履歷產生器、分析器、定價頁面皆可載入。這些頁面若壞了，直接損失金錢。履歷產生器歷來是最慢的頁面，WARN閾值設定在5秒。

P1 SEO曝光面。 部落格彙整、支柱型Hub頁面、公司目錄、職缺瀏覽、全部五個程式化內容索引（履歷指南、薪資指南、求職信指南、面試問題、ATS關鍵字）、四個i18n部落格樣本，以及全部20個S級公司Hub。這些頁面驅動自然流量。Google公司頁面出現404就是一起SEO事故。

P2全面檢查。 部落格和公司Sitemap中的每一個URL。這就是那6小時的背景檢查。它捕捉長尾故障：某篇部落格文章因引用格式錯誤而回傳500、某個公司頁面因大型公司資料的N+1查詢而逾時。

每個頁面使用curl搭配真實的User-Agent標頭檢查。裸curl會被Cloudflare擋回403。快取狀態標頭與HTTP狀態碼、TTFB一同擷取。頁面可能回傳200但顯示DYNAMIC，而它本該是HIT——這意味著快取規則設定有誤。TTFB測量的是真實的伺服器端延遲，而非瀏覽器渲染時間。

TTFB趨勢

自2026年3月起我持續執行這項檢查。TTFB趨勢道出了效能的故事：

這條趨勢線記錄了市場頁面的效能歷程：快取清除暴露了問題（14.3秒），邊緣快取掩蓋了它（89-175ms HIT），查詢結構修復解決了根本原因（108ms來源伺服器）。若沒有每晚的趨勢追蹤，我會以為邊緣快取就是解方。TTFB測量數據證明，來源伺服器在重新驗證時渲染依然緩慢，這為查詢重構提供了充分理據。

nightcheck並沒有修復效能問題。它讓效能問題變得可量測，從而變得可修復。

無人看見的價值

nightcheck最珍貴之處，在於它在無人注視時運行。「16,228個頁面在夜間全數通過」不會有Slack通知。沒有儀表板會變綠。報告存在於一個日誌檔案裡，我隔天早上喝咖啡時閱讀。

不搞儀式感，正是重點。nightcheck不是表演性的品質保證，不是站會上的指標。它是一種私人紀律：我睡著的時候，一切是否正常運作？是的話，很好。不是的話，我確切知道什麼壞了、何時壞的。

紀律會複利。每晚的檢查為隔天的比較建立基準。某個特定頁面的TTFB增加50ms就會觸發調查——不是因為50ms對使用者有感，而是因為增加代表某個東西變了。也許新的依賴增加了延遲，也許快取規則過期，也許資料庫查詢隨資料量增長而變慢。每晚的基準讓偏移在釀成問題之前就變得可見。

這是複合脈絡在營運上的實踐。每晚的檢查存入一個數據點。數據點累積成趨勢。趨勢讓任何單次檢查都無法揭示的問題浮出水面。

例行公事即是標準

我可以把nightcheck自動化為cron排程，然後看儀表板就好。我選擇手動執行，因為執行這個動作本身維繫著在意的習慣。當這項檢查變成別人的工作、變成我隨手關掉的通知、變成我不再查看的儀表板，標準就會侵蝕。

標準不是「網站通過自動化檢查」。標準是「我親自驗證了網站在我入睡前正常運作」。差異在於當責。自動化檢查靜默失敗，是自動化的Bug。我跳過手動檢查，是我對自己在意什麼做出的選擇。

我每晚都跑，因為替代方案是信任一切依然正常。沒有驗證的信任是寄望。寄望不是營運策略。

常見問題

完整檢查需要多久？

快速關鍵路徑檢查約需2至3分鐘（36個頁面，含TTFB和快取測量）。全面性Sitemap檢查約需5至7小時（15,000+個頁面）。快速檢查同步執行；全面檢查在背景運行。

為什麼不用正常運作時間監控服務？

正常運作時間監控服務只檢查頁面是否回傳200。nightcheck檢查的是頁面是否以正確的快取狀態、可接受的TTFB，以及預期的內容結構回傳200。一個回傳200但花了14秒、且快取狀態為DYNAMIC的頁面，技術上是正常的，營運上是壞的。

發現問題時怎麼辦？

若失敗出現在營收或基礎設施頁面，我會在睡前調查。對於全面檢查中的失敗，隔天早上檢視日誌，依頁面類型排定優先順序。部落格文章失敗的優先級低於公司Hub失敗。高流量頁面的DYNAMIC快取，優先級高於低流量頁面的TTFB過慢。

這套做法能擴展嗎？

目前規模為15,000個頁面。全面檢查受限於I/O（循序的curl請求），而非運算能力。頁面數量翻倍，執行時間也翻倍。到30,000個頁面時，檢查將需約12小時，仍在一個通宵時段內。超過這個規模，就需要搭配速率限制的平行化檢查。