北京
你會不會這樣——給客戶做了一個線上商店，服務器好好的，首頁秒開，監控全程綠燈，直到某天客戶打電話來問：“最近怎么一單都沒有？”
最近在一個 WordPress 工具評測里看到這么一條留言，我把它翻譯成場景版：店主在某次促銷后發現完全沒人下單，自己點進去一看，整個商店頁面不翼而飛。排查下來才發現，WooCommerce 插件不知道什么時候被停用了。在此期間，可用性監控一直報告“200 OK”，首頁運轉得像個勞模，但貨架其實早就空了。
這就是傳統可用性監控的全部盲區。它只追問一件事——“頁面加載了沒？”而在線商店能不能做生意，跟頁面加沒加載完全是兩回事。你把收銀臺的機器通著電，但把收款碼藏起來了，再有人流量也白搭。
我索性把 WooCommerce 商店里最容易出現的“燈亮著、錢不進來”的故障模式梳理了一遍，正好當作一個“業務正常才是真正常”的檢查單。下面這五種情況，發生時網站都會高高興興地返回 200 狀態碼，但生意實際已經停擺：
支付網關卡在測試模式。有人為了調試把 Stripe 或 PayPal 切到沙箱，測完忘了切回來。用戶能走到結賬完成頁，但錢壓根沒動。
更新干掉了結賬頁。插件或主題一更新，結賬模板崩了，可你的監控盯著的首頁一點事兒沒有。
失敗訂單突然暴增。訂單能創建，但在支付環節成片死掉。單看一筆可能沒感覺，合起來就是一個支付通道已經斷了的信號。
服務端訂單流水線掛了。插件沖突導致訂單根本寫不進去，或者永遠停在一個中間狀態。店門口看著漂漂亮亮，后臺的訂單工廠罷工了。
訂單悄無聲息地停了。這是最隱蔽的一種——沒有任何技術意義上的“壞掉”，流水就是枯了。上面四種任何一個都能造成這種結果，或者一場廣告投放突然停掉也會。
發現沒有，所有這些故障都有一個共同點：首頁完好。跟那種聯系表單悄悄停發線索是同一類問題——網站活著，生意死了。
那怎么在客戶打電話之前自己先發現呢？直接設一條“零訂單就告警”的規則，結果一定是每晚都被那種一周只出兩單的店吵醒。所以我們不能用一個絕對數來硬卡，得讓每家店的告警閾值跟它自己的日常表現去比對。
這里有三條用訂單統計數據算出來的便宜信號，配上一個很小的監控腳本就能做到：
失敗訂單激增檢測。把過去 24 小時的失敗訂單占比，跟這家店最近 7 天的常態作比較。條件定成——失敗數至少達到 3 單（統計才有意義），并且 24 小時失敗率超過 7 天平均失敗率的 3 倍。同時滿足兩點就告急：支付網關大概率出問題了。一個天生就有一定失敗率的店（比如貨到付款、風控嚴格的），用這條規則只會在自己的基線之上才觸發，不會亂叫。
訂單干旱檢測。如果過去 24 小時完全零訂單，而這家店過去 14 天每天都平均至少有 3 單，那就得發一個警告：一家平常在出單的店，今天反常地沉默。
拉取訂單總數時講究一點工程細節。別把訂單號碼全拉到內存里數，直接用 WooCommerce 的分頁查詢讀出總數就行。對一天幾百上千單的店，這是跑在大規模場景下必須的講究。
這三條信號背后的邏輯可以挪到任何在線業務里：用自身的歷史表現作為基線，然后設置一個不以絕對數字為準、而以偏離幅度為準的觸發條件。這樣一來，你盯的不再是服務器有沒有活著，而是真正的收銀臺是不是還在收錢。
特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布，本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
