先定義可接受的服務狀態
壓測開始前，團隊要先回答一個容易被忽略的問題：什麼狀態才算通過？只有每秒請求量並不足以判斷容量。對使用者而言，頁面是否能完成、交易是否重複、資料是否延遲，以及失敗後能否安全重試，往往比伺服器是否仍在線更重要。容量目標應同時包含吞吐量、尾端延遲、錯誤率、佇列等待時間、資料庫鎖定情況與關鍵流程完成率。
接著把預期流量拆成實際工作負載，而不是假設所有請求都相同。登入、搜尋、報表、檔案上傳與訂單寫入，對 CPU、記憶體、網路、快取及資料庫的影響完全不同。若尖峰來自促銷、批次通知或合作夥伴導流，流量通常也不是平滑增加，而可能集中在很短的時間內。
我們通常會先畫出關鍵請求路徑，標示負載平衡器、應用服務、快取、資料庫、訊息佇列、物件儲存及外部 API。這張圖的目的不是製作架構文件，而是找出任何無法隨應用節點一起擴展的共享資源。
讓壓測接近真實流量，而非只追求高數字
有效的容量測試至少要涵蓋基準、逐步升載、突發流量、長時間穩定負載與依賴服務降級。逐步升載用來找出系統從穩定轉為惡化的轉折點；突發測試驗證擴展速度；長時間測試則較容易暴露連線洩漏、記憶體累積、佇列堆積與背景工作互相搶奪資源等問題。
測試環境必須保留與正式環境相近的拓撲、資料規模及設定。若測試資料過於單純，快取命中率會異常漂亮；若只測讀取，則看不到寫入鎖、索引更新與複寫延遲。無法完整複製正式環境時，至少要清楚列出差異，並避免把測試結果直接等比例外推。
- 模擬真實比例：依實際使用情境混合讀取、寫入、登入、搜尋與背景工作。
- 保留思考時間：不要讓每個虛擬使用者無間隔地連續送出不自然的請求。
- 分別測試冷啟動與暖機：空快取、首次部署與大量新節點啟動時，表現可能與穩定狀態不同。
- 從外部產生負載：確認 DNS、CDN、WAF、負載平衡器與網路路徑也在測試範圍內。
- 預先設計停止條件：當錯誤快速增加、資料完整性受威脅或共用依賴接近極限時，應中止測試並保留診斷資料。
配額與硬上限通常比運算資源更早卡住
自動擴展設定完成，不代表容量問題已經解決。應用節點增加後，可能同時耗盡資料庫連線、子網路位址、NAT 連線、負載平衡器並行能力、訊息分割區、檔案描述符或第三方 API 限額。這些限制常分散在不同服務與管理介面中，也不一定會出現在一般 CPU 或記憶體監控裡。
應將限制分成可申請調高的配額、需要重新設計才能突破的架構上限，以及外部供應商控制的合約或速率限制。前者要把審核與生效時間納入上線計畫；後兩者則需要提早準備分流、排隊、快取、降級或非同步處理策略。特別要確認擴展控制器本身是否會因監控延遲、映像檔啟動時間或安全檢查而反應過慢。
- 運算層：可用執行個體、容器排程容量、映像檔下載與節點啟動速度。
- 資料層：連線池、寫入吞吐、鎖競爭、儲存延遲、複寫與備援切換能力。
- 網路層：IP 位址、連線追蹤、出口路徑、頻寬、負載平衡器與防火牆限制。
- 非同步層：佇列深度、消費速度、重試風暴、死信處理與訊息保留空間。
- 外部依賴：身分驗證、金流、通知、ERP、CRM 或其他 SaaS API 的速率與逾時政策。
用證據設定上線閘門與降級方案
測試結果不應只留下「可以承受尖峰」的結論。團隊需要記錄第一個飽和的資源、開始惡化的負載區間、擴展完成所需時間，以及流量下降後系統是否能恢復。監控畫面也要能把使用者症狀對應到後端原因，例如延遲上升究竟來自資料庫鎖定、連線池等待，還是外部 API 逾時。
上線閘門應包含明確的剩餘容量、已確認的配額、告警與值班責任，以及可在短時間內執行的降級開關。關閉非必要報表、延後背景同步、限制昂貴查詢、將寫入送入佇列，通常比臨時擴充一個已經受限的下游服務更有效。每個降級方案都應先測試，否則事故當下才啟用的新路徑，本身也可能成為新的故障來源。
最後，容量驗證不是單次活動。程式版本、查詢方式、資料量、雲端服務設定與外部整合都會改變瓶頸位置。把代表性的壓測納入重大版本與尖峰活動前的檢查流程，才能讓擴展能力成為可重複驗證的工程事實；若系統橫跨雲端、ERP、CRM 與第三方服務，整合團隊也能協助建立共同的容量模型與驗收標準。