峰值估算的第一步是分清這個峰值屬於哪一種形狀，因為不同形狀的倍率推法完全不同。一個提前三個月就知道的年度大促，跟一個賽事進球瞬間的爆量，跟一個產品爆紅後持續數週的高原，估算方法各不一樣——用同一套方法估所有峰值，是估算失準的起點。分好類，才知道這個峰值該用歷史倍率推、還是該按最壞情況預備。

峰值大致分五種形狀：可預期的極端峰值（年度大促、體育決賽，提前數月已知）、事件型的不可預期峰值（賽事進球、突發新聞、KOL 帶貨）、瞬間爆量（搶購型，開賣即爆、幾十分鐘結束）、產品爆紅的持續高原（隨熱度漲跌）、以及結構性位移（外部衝擊讓 baseline 永久上移）。前兩種是本章倍率估算的主要對象，後三種各有專屬的預備方式。

用歷史倍率階梯推可預期峰值

可預期的峰值有歷史資料可依，估算方法是拿一個穩定的 baseline，乘上該事件的歷史倍率。倍率是隨事件等級變化的階梯，不是一個固定數字。一個體育博彩服務的公開案例，以賽季的日常流量為 baseline，季後賽升到 2 到 3 倍、冠軍賽 4 到 5 倍、最高級別的單場賽事（如超級盃）5 到 10 倍——每一級對應不同的準備強度。估算時要先定位「這次事件是哪一級」，才知道套哪一格倍率。

倍率階梯的可信度來自每次事件後的校準。每辦完一次，回頭比對這次的實際峰值跟事前的預測差多少、當時的資源使用率峰值到哪、headroom 是不是留得剛好。這個事後校準（回顧）把下一次的倍率估得更準——沒有校準的倍率階梯，用幾次就會跟真實流量脫節。真正提前的估算通常在事件前約 90 天定案：確認預期的峰值倍數、確認 headroom 比例、確認跨區域與跨可用區的分布，讓容量計畫有時間落地。

事件型峰值按最壞情況預備

事件型的不可預期峰值沒有精確的發生時間，只有「一旦發生會多猛」的量級。一個賽事的進球、一則突發新聞，可以讓流量在幾秒內衝到平均的 10 到 50 倍。這種峰值估算的目標是「來的時候有多大的量級」，並讓系統隨時能承受那個量級——因為它可能在賽事的任何一分鐘發生，估「什麼時候來」沒有意義。

這類峰值的預備常常不能只靠事後擴容，因為爆發是秒級的、而擴容有冷啟動延遲。可行的做法是事前把容量預先拉到能接住那個量級，或搭配預測式的擴容（在賽事的高風險時段提前擴），這牽涉到擴縮的時機判斷，在 規模拐點判斷 展開。這裡要確立的是：事件型峰值的估算目標是量級、不是時間點。

安全係數的數學根據在飽和曲線

峰值估算之外要再加一層安全係數，它有明確的數學根據——對應系統飽和曲線上「knee 以下的 headroom」，不是單純為了保守。一個健康的系統應該運轉在利用率 50% 到 70% 之間，留出的那段 headroom 就是安全係數要覆蓋的：它同時吸收 burst 的瞬間波動、跟峰值估算本身的誤差。自動擴容的目標利用率常設在 60% 到 70%，正是這條曲線推導出的安全位置。

安全係數不能對所有系統套同一個數，因為膝點的位置隨系統類型變。無狀態服務、有鎖競爭的資料庫、吃磁碟 I/O 的佇列，膝點高低不同，有狀態的關鍵系統膝點來得早、要留的 headroom 比無狀態服務厚。飽和曲線的三段區間、排隊理論的量化門檻、以及各類系統膝點的實際位置，在 規模拐點判斷 完整展開；這裡用它來解釋安全係數為什麼存在、為什麼不能一律套同一個數。

從業務指標反推各層峰值

峰值估算不只估總量，成熟的做法是從業務指標往下反推每一層的峰值需求。從用戶感知的端到端延遲目標（例如 p99 500 毫秒）出發，把這個預算拆給路徑上的每一段，各段的延遲配額再配上預期的 RPS、經 Little’s Law 算出各段要準備的並發，並發再翻成實例數、連線池大小、快取容量。這條反推鏈讓峰值估算不停在「總 RPS 是多少」，而是落到每一層的具體規格。

反推過程本身會暴露設計問題。如果某一段算出來的容量超過了它所用元件（例如某個 vendor 服務）的上限，或某段分到的延遲配額短到連跨可用區的網路往返（至少 1 到 2 毫秒）都容不下，代表這個峰值目標在當前架構下達不到，要回頭改架構而不是硬估一個數。

下一步路由