電商活動當天網站掛了：流量暴增的緊急處理與事後升級

電商活動當天網站掛了，先別急著重開主機或連夜搬家。先判斷卡在主機資源還是程式與資料庫，接著關掉非必要功能、把資源留給結帳，撐不住時換上輕量的公告頁，再處理快取與臨時提升規格；網站恢復後，第一件事是確認付款與訂單狀態。活動結束後，用負載測試找出瓶頸，再決定是否從虛擬主機升級到 VPS 或專屬伺服器。

01常見情境：限時搶購、直播導購、週年慶開跑當天網站撐不住

以下是幾種常見情況，均為示意，用來說明不同處境該先看哪一段。

• 保養品牌的整點搶購：一個五人左右的自有品牌團隊，在官網辦限量搶購。開賣後首頁還打得開，按下結帳卻一直轉圈，最後跳出錯誤頁。負責網站的行銷人員最擔心的是客人付了錢，後台卻沒有訂單。先看「現在立刻做的事」那張對照表，判斷是不是結帳與資料庫卡住；網站恢復後，照「確認付款與訂單狀態」逐筆核對。
• 果農的直播導購：一位自己用 WooCommerce 架網店的果農，請網紅在直播中貼出商品連結，幾分鐘內湧進大量手機訪客，整個網站變成空白頁。他最擔心錯過這一波曝光。先看「公告頁與排隊頁」，把首頁換成輕量的靜態公告，寫清楚預計恢復時間與其他下單管道。
• 親子選物店的週年慶：一間由店長兼管網站的選物店，週年慶開跑第一個小時已經連續兩年當機。老闆在想是不是該換主機。先看「事後檢討」，把時間軸與主機紀錄對起來，找出最先撐不住的環節；再看「什麼時候該升級」，決定是改程式、調整排程，還是換主機類型。

02現在立刻做的事：先排除攻擊，再找出卡住的環節

網站撐不住時，建議照這個順序處理，每個動作都記下時間：

1. 確認不是攻擊：流量集中在少數 IP 或國家、訂單卻沒有增加，就改依 DDoS 攻擊的應變步驟處理。
2. 用下表判斷卡在主機資源還是程式與資料庫。
3. 暫停非必要功能與排程。
4. 完全撐不住時換上輕量公告頁。
5. 檢查快取設定，再決定是否臨時提升規格。
6. 恢復後確認付款與訂單狀態。
7. 在官網、社群、LINE 等通路發布同一段說明。

前台打得開，不代表客人能下單。最可靠的方式是自己用手機、在未登入狀態下實際走到付款頁。網站平常就慢的話，檢查順序請看 WordPress 很慢怎麼辦。

03保住結帳：暫停非必要功能、排程與耗資源的頁面

流量超過主機能承受的量時，與其讓所有功能一起變慢，不如主動犧牲次要功能。Google 的網站可靠性工程（SRE）文件把這種做法稱為優雅降級：負載接近上限時，改提供較簡化、運算成本較低的結果，讓系統繼續做有用的事，而不是整個倒下。放到購物網站，就是把資源留給商品頁、購物車與結帳。可以先暫停的項目：

• 站內搜尋與多條件篩選：每次查詢都要動到資料庫，可先隱藏，改在活動頁列出主打商品。
• 推薦商品、即時庫存數字、瀏覽人數這類動態區塊：每一頁都要為它們多做好幾次查詢。
• 排程工作：備份、商品匯入、與 ERP 或倉儲系統的庫存同步、電子報寄送、網站地圖重建，盡量移到活動結束後。備份特別吃磁碟讀寫，不要剛好排在開賣時段。
• 後台的大量作業：匯出訂單、跑銷售報表、批次改價。想看即時業績，就看付款服務的交易後台。
• 活動前一刻才加上的外掛或程式：出錯時間和上線時間吻合就先停用。

運費計算、折價券驗證、發票資料欄位這些和結帳綁在一起的功能不能關。每關掉一項，就重新走一次結帳流程，確定沒有連帶壞掉。

04公告頁與排隊頁：用 503 告訴客人與搜尋引擎「暫時」無法服務

網站已經完全撐不住時，換上一頁說明狀況的公告頁，比讓客人看空白頁好。這一頁要做對兩件事：

• 回應正確的狀態碼。HTTP 規格 RFC 9110 定義，503（Service Unavailable）表示伺服器因暫時過載或排定的維護而無法處理請求，一段時間後可望恢復；伺服器可一併送出 Retry-After 標頭，以日期或秒數表示多久後再試。公告頁若回應 200，搜尋引擎可能把「維護中」當成正式內容。
• 夠輕量。Google 搜尋中心「暫時暫停或停用網站」的說明建議，需要緊急停用一到兩天時，以回應 503 的資訊型錯誤頁取代所有內容；這一頁用靜態 HTML、少用外部資源，Retry-After 填上盡力估計的時間；robots.txt 則不要回應 503，否則會擋住所有檢索。

Google 也說明，網站回應 5xx 時檢索器會暫時放慢檢索，恢復回應 2xx 後再逐步調回；持續回應伺服器錯誤的網址，最後會被移出索引。公告頁只是短期措施，網站恢復後要立刻撤掉。

公告頁要寫清楚：發生了什麼、預計何時恢復、已付款的客人怎麼查詢訂單。排隊頁（虛擬候位室）則讓超過容量的訪客先在外面等候、再依序放行，通常要靠 CDN 或防護服務的功能事先設定並測試，當天才導入多半來不及。

05快取、CDN 與臨時提升規格：哪些當天做得到

快取：首頁、活動頁、商品頁這類每位訪客看到都一樣的頁面，最適合交給頁面快取，讓請求不必執行 PHP、查資料庫。WooCommerce 官方文件要求購物車、我的帳號與結帳頁排除在快取之外，因為它們顯示的是個別客人的資料。已有快取的網站，當天要看快取有沒有真的發揮作用：活動網址帶著廣告追蹤參數，可能被當成不同頁面而各自重算；開賣前一刻清除全站快取，第一波訪客會全部直接打到主機。

CDN：當天才導入要改 DNS，生效需要時間，設定錯誤還可能讓整站連不上。比較實際的做法是縮小活動主圖、拿掉首頁自動播放的影片，直接減少主機要送出的資料量。

臨時提升規格：先確認瓶頸真的在主機資源。CPU、記憶體或執行程序數持續撞頂，加規格才有用；若是某段程式或查詢卡住，加再多資源也只是晚一點倒。虛擬主機能不能當場換到較高方案，要直接問主機商；VPS 調整規格通常較快，但可能需要重新開機，選在流量低的空檔做。不建議當天整站搬家：DNS 生效需要時間，新舊主機之間的訂單也可能對不起來。

06確認付款與訂單狀態：網站恢復後先對帳

網站在結帳途中當掉，常見的後遺症是客人付了錢、網站卻沒有有效訂單，或同一位客人重複下單。原因多半是付款完成後，付款服務回頭通知網站更新訂單時，網站剛好撐不住。以 WooCommerce 為例，官方文件定義的訂單狀態與活動後的處理方式：

要特別留意「保留庫存（分鐘）」設定：時間一到，系統會自動取消仍是「待付款」的訂單並釋出庫存，「保留」狀態的訂單則不受影響。付款通知沒送到時，已付款的訂單可能就這樣被取消，名額又被別人買走。對帳完成前，可以考慮暫時延長這個時間。核對以付款服務的交易紀錄為準，有疑問的單先聯絡客人，不要直接取消或重複出貨。

07事後檢討：找出瓶頸，用負載測試確認撐得住多少

活動結束後，先整理時間軸：幾點開賣、幾點開始變慢、做了哪些處置、何時恢復。向主機商調閱同一時段的 CPU、記憶體、執行程序數、資料庫連線與錯誤紀錄，對照分析工具的同時在線人數與下單時間，找出最先撐不住的環節。

接著用負載測試確認改善後能承受多少。Google 的 SRE 文件建議每個元件都要測到撐不住為止，因為事先不知道哪一個會先碰到上限；流量要同時測逐步增加與瞬間湧入兩種模式，因為快取會讓兩者結果不同；也要看負載退去後，系統能不能自行恢復。整點開賣、直播貼出連結，都是典型的瞬間湧入。要注意：

• 在和正式站同規格的測試環境進行；一定要測正式站時，先和主機商約好時段，否則可能被當成攻擊而封鎖。
• 測試腳本要模擬真實行為：瀏覽活動頁、加入購物車、走到付款前一步，不要只打首頁。
• 不要對正式的付款環境送出測試交易。

容量規劃，是把測出的上限和下一檔活動的預估流量相比，預留足夠餘裕。SRE 文件也提醒，容量規劃能降低出事機率卻無法完全避免，流量超出預期時，仍要靠降級與限流保住核心功能。

08什麼時候該從虛擬主機升級 VPS 或專屬伺服器

虛擬主機是多個網站共用一台伺服器，每個帳號都有資源上限，平常夠用，活動尖峰卻可能在幾分鐘內撞頂。從活動檢討的角度，出現下列情況就值得評估換主機類型：

• 負載測試顯示，就算換到虛擬主機的最高方案，下一檔活動的預估尖峰仍會超過上限。
• 要設定 PHP 執行程序數量、資料庫連線上限，或為購物車與會員頁加裝物件快取伺服器，而這些在共用環境無法調整。
• 活動一年好幾檔，每一檔都要臨時關功能、掛公告頁。
• 網站營收比重高，活動停擺一小時的損失，已經明顯大於換主機類型的費用差距。

VPS 分配獨立的運算資源，可以依活動需求調整規格與伺服器設定；流量長期偏高、資料庫負擔重，或因資安與合規要求需要獨占硬體時，再考慮專屬伺服器。換主機類型也代表要有人照顧系統層的維護，評估時把代管一併算進去。升級不能取代程式與資料庫的改善：檢討出的程式瓶頸先處理，再搬家；搬家排在活動淡季，預留測試與 DNS 切換的時間，不要壓在下一檔活動前幾天。

09下次活動前的檢查清單：依時間點準備

大部分風險要在活動前處理掉，可以照這張表排進行事曆：

大型活動的曝光度高，也可能引來惡意流量。若網站曾經被打過，或活動規模比以往大很多，活動前一個月就要向主機商確認防護的啟用方式與聯絡流程，不要等到當天才問。

10找凱斯騰協助前，先準備這些：活動當機的檢討資料

不論是想檢討這次的當機，還是規劃下一檔活動，先整理好下列資料，判斷會快很多：

• 網站網址、使用的購物系統（例如 WooCommerce、OpenCart）與版本。
• 目前的主機類型與方案（虛擬主機、VPS 或專屬伺服器），以及主機商提供的活動時段資源使用紀錄或事件說明。
• 活動時間軸：開賣時間、開始出錯的時間、看到的錯誤訊息或截圖、做過的處置與恢復時間。
• 當天暫停過哪些功能、公告頁掛了多久，以及對結帳造成的影響。
• 網站分析工具在同一時段的同時在線人數與流量來源。
• 活動前一兩週做過的變更，例如新外掛、改版、加追蹤碼。
• 排程工作清單與執行時間，包括備份、庫存同步、電子報。
• 下一檔活動的日期、預估流量與主打商品數量。

凱斯騰能協助的是主機這一端：依檢討結果評估要不要換主機類型、規劃活動前的主機環境，以及在大型活動期間搭配 DDoS 防護過濾惡意流量。付款服務的設定與帳務核對，仍需由貴公司與付款服務商處理。資料整理好後，可以透過聯絡表單或來信 [email protected]，說明下一檔活動的日期與需求。