問題場景

當流量逼近上限時，技術瓶頸與協作瓶頸會同時出現。若只有容量模型，沒有分層值班，恢復節奏仍會失控。

決策機制

可觀測訊號

下一步路由

把容量假設寫進 6.22，再把交接規則對齊 8.2。

問題場景

大型社交平台的流量增長是漸進的，但容量不足是突然的。超過 saturation point 後 latency 會非線性惡化，從可接受的排隊延遲快速轉成級聯超時。若靠一次性壓測做容量規劃，規劃結論會隨時間漂移：流量結構改變、功能上線帶進新 workload、依賴服務的回應時間波動，都會讓上一次壓測的 saturation point 不再準確。

LinkedIn 的做法是把壓測自動化並跑在定期排程中，讓容量預測的輸入持續更新。壓測結果直接餵給 forecasting 模型，forecasting 輸出接到 headroom alert，headroom alert 觸發擴容 review。這條鏈路讓容量決策從「每季做一次人工判斷」變成「每週自動更新、異常時才需要人介入」。

決策機制

Automated load test 用 production traffic replay 而非固定 scenario，讓壓測的 workload model 跟真實流量保持同步。Traffic forecasting 結合歷史流量趨勢與產品 launch 日曆，把可預期的流量事件（功能上線、促銷、季節性增長）納入預測。Headroom alert 在 forecast peak / capacity ceiling 比值超過 70-80% 時觸發，讓團隊在容量耗盡前有足夠反應窗口。

可觀測訊號

常見陷阱

自動化壓測最常見的失真來源是 workload model 僵化。若自動化跑的是建立時的固定 scenario 而非持續更新的 traffic replay，時間一長模型就跟 production 脫鉤。脫鉤的訊號是壓測結果與 production 同時段的 latency distribution 開始偏離 — p50 / p95 / p99 的比率差異超過 20% 時，模型已需要校準。

另一個陷阱是把 forecast 當成精確預測。Forecasting 的價值在於提早觸發 review，讓團隊有時間做擴容決策。若團隊把 forecast 當成精確數字做自動擴容，預測偏差會直接變成過度擴容或擴容不足。forecast 輸出應該驅動人工 review，而非直接觸發資源變更。

下一步路由

先把壓測結果接到 6.2 load testing 的 workload model 校準流程，再用 headroom ratio 餵給 6.9 容量與成本邊界 做容量預算。forecast 準確度的追蹤連到 6.13 performance regression gate 的 baseline 校準。

引用源

• Eliminating toil with fully automated load testing
• （背景脈絡）Taming Database Replication Latency by Capacity Planning