# 活動流量一來網站就變慢，升級主機就夠嗎？企業先驗收五項承載能力

- 網址：https://www.edgedeploy.tw/blog/website-peak-traffic-capacity-checklist
- 分類：網站維護與營運
- 發佈日期：2026-09-26
- 更新日期：2026-09-26
- 作者：邊境部署

> 網站平日順暢，不代表促銷、媒體曝光或開放報名時能承受同時湧入的人潮。本文用五項問題檢查流量假設、關鍵流程、相依服務、測試證據與降級方案，協助企業判斷該升級主機、優化瓶頸，還是先調整活動安排。

平日打開網站很順，活動倒數一結束，廣告、社群與簡訊同時把人帶進來，商品頁開始轉圈，報名表送不出去，付款結果也遲遲不回來。廠商若只回答「主機規格已升級」，企業仍不知道這次能承受多少人、哪個步驟會先塞住，以及超過上限時怎麼保住訂單與客戶信任。

這像餐廳為節慶加開座位，卻沒有一起增加點餐、廚房、出餐與收銀能力。門口容納更多客人，不代表整條服務流程都能變快。網站也是如此，首頁檔案、登入、庫存、資料庫、付款與通知各有自己的容量，一個環節塞住，整筆生意就可能停在半路。

## 平日順暢，不能證明尖峰時段撐得住

容量規劃是先估計活動會帶來多少使用者與請求，再確認整套服務能否在可接受時間內完成工作。壓力測試則是在受控條件下模擬不同流量，量出回應時間、錯誤率、完成量與資源使用情況。Google Cloud 的可靠性指引建議把歷史趨勢、季節變化、特殊活動與商業成長都放進預估，並在一般及尖峰負載下重複測試。

真正的商業問題不是伺服器有沒有到百分之百，而是客戶在關鍵時刻能不能完成報名、詢價或付款。若沒有先定義成功門檻，測試跑完只會得到一堆圖表，仍無法判斷能不能上線。

## 用五個問題驗收「活動流量已準備好」

1. **流量假設從哪裡來？** 至少整理過去最高同時使用量、活動名單、廣告排程、開賣時間與預估轉換。把「可能很多人」改成每分鐘進站、登入、送表單或付款的合理範圍，並保留低、中、高三種情境。
2. **測的是哪條生意流程？** 首頁能開不代表訂單能完成。測試應走過活動入口、商品或方案選擇、登入、表單、庫存、付款與通知，標明哪些步驟會寫入資料或呼叫外部服務。
3. **成功與停止門檻是什麼？** 先約定多少請求成功、客戶最多等多久、錯誤率到哪裡必須停止加壓，以及測試是否會建立假訂單、寄信或扣庫存。門檻應對應營運可接受的損失，不只看單一平均速度。
4. **瓶頸證據能否指出環節？** 要同時看網站、應用程式、資料庫、外部介面與第三方額度。只有主機處理器使用率圖，無法證明付款、簡訊或庫存服務沒有先達到上限。
5. **超過容量時如何保住核心交易？** 要事先決定排隊、限制重複送出、暫停次要動畫或推薦內容、分批開放，以及由誰監看與宣布恢復。沒有降級與回復方案，自動擴充也可能在資源到位前先讓客戶遇到錯誤。

## CDN、自動擴充與升級主機各自解決不同問題

內容傳遞網路（CDN）會把可重複使用的圖片、樣式與程式檔案先存到較靠近訪客的位置，這就是快取，能減輕部分原始主機流量。Cloudflare 的文件也說明，會依登入或庫存改變的動態頁面預設不一定會快取；登入、付款與寫入資料的請求仍可能回到原系統。因此「有 CDN」不是整條交易流程的容量證明。

升級單台主機設定快，適合已確認是運算或記憶體不足的瓶頸；但若問題在慢查詢、外部額度或重複送單，只加規格可能增加費用而沒有解決根因。自動擴充能依需求增加資源，優點是平時不必長期支付最高容量，限制是擴充需要時間，而且資料庫與第三方服務未必一起放大。便宜方案可以先保住一條核心流程，但應明確寫出未涵蓋的尖峰、外部服務與待命範圍。

## 今天先做一張活動承載表

先選下一場最重要的活動，記下開始時間、導流管道、預估人數、關鍵流程、成功門檻、第三方服務、目前監測、可接受中斷與負責窗口。請網站、行銷、金流或預約廠商用同一張表回覆，不要各自只保證自己的系統正常。

若尚未具備完整測試環境，可先用小流量逐級增加，觀察哪個步驟先變慢，再決定是否擴大。不要未通知供應商就在正式站大量發送請求，也不要使用真實卡號或客戶個資。Microsoft 的效能測試指引提醒，測試應有可量測目標、接近實際的使用模式與可監測環境；在正式環境測試本身也有造成故障的風險。

## 自行處理的邊界與接洽準備

純內容網站可先整理活動時間、歷史流量與重要頁面，確認快取設定並安排人工監看。若活動涉及限量庫存、會員登入、付款、抽獎、預約名額或多家外部服務，或廠商無法提出測試條件、門檻與瓶頸證據，就值得由網站、雲端與營運人員共同做容量盤點、受控測試及降級演練。

接洽前可準備活動企劃、預估導流、分析工具的歷史尖峰、主機方案、系統與第三方清單、關鍵流程、可用測試帳號、可接受等待時間及事故聯絡人。邊境部署可以協助把這些資料整理成可驗收的負載情境與改善順序；若現有主機和一份分批開放計畫已足夠，也不必先買最昂貴的擴充方案。

## 查證來源

- [Google Cloud：管理工作負載的流量與容量](https://docs.cloud.google.com/architecture/infra-reliability-guide/traffic-load)
- [Google Cloud：大型活動前進行負載測試](https://docs.cloud.google.com/support/docs/peak-events/conduct-load-testing)
- [Microsoft Azure Well-Architected Framework：效能測試策略](https://learn.microsoft.com/en-us/azure/well-architected/performance-efficiency/performance-test)
- [Cloudflare：Cache 與 CDN 的預設行為](https://developers.cloudflare.com/cache/get-started/)