活動檔期流量高峰怎麼準備：流量估算、壓力測試與臨時擴容方案
檔期活動最怕的情況不是沒人來，而是廣告投出去、人真的來了，網站卻在最關鍵的那十分鐘打不開。這種損失是雙重的：當下的訂單沒了，行銷預算白花，還可能在社群上留下一波抱怨。
麻煩的是，平常運作順暢完全不代表尖峰時撐得住。日常流量是分散的，檔期流量是集中的，兩者對系統的壓力性質完全不同。
這篇把活動前的準備工作拆成估算、測試、補強、應變、監看五個階段，讓準備有依據而不是憑感覺。
先估算尖峰，而不是總量
準備工作的第一步是把「會有很多人」換算成可以驗證的數字。要估的不是活動期間的總人數，而是最擁擠的那一分鐘同時有多少人在操作。
可以從幾個方向往回推：
- 從行銷計畫推：電子報與推播發出後的前幾分鐘通常是最高峰，網紅或媒體的曝光則集中在發布後的短時間內。把各管道預計觸及的人數、預估的點擊比例與到達時間攤在同一張時間軸上，就能看出尖峰疊在哪裡。
- 從過去的紀錄推：看去年同檔期或上一次類似活動的分析數據，找出當時的最高同時在線人數，再依這次的推廣力道調整。網站若尚未建立完整的數據追蹤，可以先參考GA4 導入指南把基礎量測補起來。
- 從名額反推：限量商品或限額報名的活動，搶的人數往往遠多於名額，這個差距要一併估進去。
推算示範（以下數字僅為示範假設，不是可引用的行業數值，實際請換成你自家的歷史紀錄）：假設電子報發給一萬名訂閱者，你依過去紀錄假設每十人有一人在發信後十分鐘內進站，那就是一千人分佈在這十分鐘；若其中一半集中在前兩分鐘，尖峰那一分鐘大約要承受兩百多人同時操作。推播與社群貼文各算一遍、疊在同一條時間軸上，最高的那一格就是壓力測試要打的目標。
這一步最常見的錯誤有兩個：只估活動期間的總量、沒換算成尖峰那一分鐘；以及算完就直接把它當成目標值，忘了往上加一段安全係數——估算本身會失準，推廣效果也可能超出預期，目標抓在估算之上才有餘裕。
估算不必精準，但要有一個明確的目標數字，例如「尖峰時每分鐘要能承受多少次結帳」。沒有目標數字，壓力測試就沒有通過的標準，測了也不知道算不算合格。
另外要估的是流量的形狀。同樣的人數，平均分散在一小時內、和全部集中在開賣後三十秒，是完全不同的難度。
壓力測試要看哪些指標
壓力測試就是用工具模擬大量使用者同時操作，觀察系統在什麼程度開始變慢、在什麼程度開始出錯。有幾個重點。
要測真實的流程，不是只測首頁。 首頁通常最容易被快取，壓起來漂亮但沒有參考價值。要測的是活動當天真正會被大量執行的路徑：商品頁、加入購物車、結帳、登入、送出表單。
要看的四個數字：
- 反應時間：頁面或請求要等多久。除了平均值，更要看落後的那一段——平均看起來可以接受，但等最久的那一群人，體感上就是「網站掛了」。
- 每秒能處理的請求數：系統的實際吞吐能力。
- 錯誤率：壓力上升後開始出現失敗的時間點，這通常就是真正的上限。
- 資源使用狀況：處理器、記憶體、資料庫連線數在什麼時候先見底。這個數字會告訴你瓶頸在哪一層。
要找的是轉折點。 壓力測試的目的不是證明「撐得住」，而是找出從哪個量開始崩壞、怎麼崩壞的。把負載逐步往上加，記錄開始變慢與開始出錯的兩個門檻，再和前面估的尖峰數字比較，就知道還差多遠。
測試環境要接近正式環境。 規格差太多的測試結果沒有意義。同時要確認測試流量不會產生真實訂單、不會發送通知、不會污染分析數據。
常見瓶頸出現在哪裡
實務上壓力測試找到的問題，多半集中在這幾個地方：
- 資料庫查詢：最常見的一類。平常資料量少時感覺不到，流量一上來，缺少索引的查詢或在迴圈裡重複查詢的寫法會讓資料庫先倒下。
- 首頁與活動頁沒有快取：每個人進來都重新計算一次相同的內容。平常只是多耗一點資源，尖峰時就是每一位訪客都在對資料庫重問同一個問題。
- 圖片與靜態資源：大量未壓縮的圖片會吃掉頻寬，也拖慢載入。平常這只是慢一點，尖峰時卻可能把出口頻寬整個吃光，連帶把結帳這種不能失敗的流程一起拖下水；日常的優化做法可以看網站速度優化指南。
- 庫存與序號的搶奪：多人同時搶同一批庫存時，鎖定機制設計不當會造成大量等待，甚至超賣。這是電商檔期最容易出事的一環，相關考量可以參考電商網站開發指南。
- 外部服務的限制：金流、簡訊、物流、發票這些串接對象各自有流量限制，你的系統再快也會卡在對方那裡。事前要確認對方的限制與尖峰時的處理方式。
- 後台作業與前台搶資源：報表產生、排程任務如果安排在活動時段執行，會和真實使用者搶同一份資源。
擴容與降級：兩種準備要一起做
擴容是增加資源來承接更多人。雲端服務通常可以在活動前把規格調高、活動後調回來，這是最直接的做法。要注意三件事：不是所有部分都能靠加機器解決（資料庫通常是最難擴的一層）、調整規格本身可能需要重啟、擴容要在活動前完成並驗證，不能等當天才臨時操作。主機形式會決定可用的擴容方式，可以對照網站主機怎麼選。
降級則是在壓力過大時主動關掉非必要的功能，把資源留給最重要的流程。這件事常被忽略，但往往比擴容更有效，因為它不需要等待資源配置。
實務上可以事先準備的降級開關包括：暫時關閉即時庫存顯示改為概略狀態、關掉推薦與熱門排行、把搜尋暫時停用、以預先產生的靜態頁面取代動態活動頁、將非必要的通知改為稍後批次寄送。
關鍵在於這些開關要在活動前就做好並測試過，當天只需要有人下決定去切換，而不是臨時改程式碼上線。同時要先想好排隊機制：真的超過負荷時，讓使用者看到有進度的等待畫面，比讓大家看到錯誤訊息並瘋狂重新整理好得多——重新整理只會讓壓力雪上加霜。
活動當天要監看什麼
當天的目標不是完全不出事，而是出事時能在幾分鐘內知道並反應。事前要準備一個所有人看得到的監看畫面，至少包含：
- 即時同時在線人數與請求量。
- 關鍵流程的反應時間，特別是結帳與登入。
- 錯誤率，以及最常出現的錯誤類型。
- 伺服器與資料庫的資源使用狀況。
- 真實的業務指標：每分鐘成功送出的訂單數。這一項最誠實——技術指標都正常但訂單數突然歸零，代表某個環節壞了而監控沒抓到。
同時要準備好人和流程：誰負責盯、發現異常通知誰、誰有權決定啟動降級、對外的公告由誰發。這些角色要在活動前分配好，不要當天才在群組裡問。
設想一個情境：開賣後幾分鐘訂單數異常偏低，但頁面看起來正常。若有人同時盯著訂單數，可以立刻發現是金流回應變慢，馬上啟動備援方式；若只盯著伺服器的資源使用率，可能會一直以為一切正常，直到客服電話被打爆。
活動結束後要做的事
活動一結束，趁記憶還新鮮時把三件事記下來：
紀錄實際數字。 真實的尖峰是多少、發生在哪一分鐘、和事前估算差多少。這份紀錄是下一檔活動最有價值的依據。
清理臨時措施。 調高的規格要按計畫調回、降級開關要關回正常、臨時放寬的設定要還原。臨時措施忘了收，常常變成日後的資安或成本問題。
把發現的瓶頸排進改善清單。 活動期間靠加資源硬扛過去的部分，本質上的問題還在。趁著剛量過的數據還在手上，安排時間根本處理，下一檔才不必再賭一次。
檔期已經排定、卻不確定現有系統撐不撐得住，這件事愈早看成本愈低。和 NETVANA 聊聊你的專案：軟體服務逐案報價、沒有固定套餐，我們會先問活動規模、推廣管道與現有架構，再判斷該先做一次壓力測試，還是直接補掉已知的瓶頸；各項服務的內容與交付物可以看軟體服務介紹。
延伸閱讀：活動頁上線前的完整確認項目，看網站上線前檢查清單；金流在尖峰時的限制與對帳處理，看台灣金流串接指南；大量訂單湧入後的出貨與狀態回傳，看物流串接完整指南；活動期間也是攻擊的高峰期，看企業網站資安基本功。
