沒壓過，就當它會在尖峰垮掉。壓力測試回答兩個容量問題：DB 多滿開始寫入失敗？應用伺服器到幾 QPS 開始超載？ 因為很多元件不會「優雅退化」——過了某個點就是災難式失敗，你得先知道那個點在哪。
🧠 Intuition
TIP
測試通過不能證明系統可靠；但測試失敗可以證明它不可靠。壓力測試就是刻意把系統推過極限，讓「災難點」在受控環境現形，而不是等它在生產尖峰自己爆出來。
- 壓力測試找的是限制：寫入開始失敗的水位、開始超載的 QPS——這些就是容量規劃的輸入。
- 許多元件不會線性退化：負載爬升時看似沒事，越過臨界點卻整個崩掉。平均值看不出這種懸崖，要看它「什麼時候斷」。
- 生產測試有三種面向，容量規劃最相關的是壓力測試；另外還有比對「實際設定 vs 版控意圖」的設定測試，與逐步放量的金絲雀。
- 金絲雀不是真正的測試，是受結構化的使用者驗收——它不會抓到所有 bug，但能在小流量下暴露容量與相容性問題。
⚖️ Tradeoffs
只在生產靠監控抓極限 — 反應太慢
- 監控能發現問題，但反應速度受回報流程的 MTTR 限制；等圖表紅了，使用者已經在痛。
- 尖峰才第一次觸及容量上限，等於拿真實流量當壓力測試——代價是真的當機。
- 適合：完全無法預先壓測的遺留系統；不適合任何你在乎可用度的服務。
事前壓測 + 漸進放量 — 標準做法
- 壓力測試在受控環境找出災難點，容量規劃據此留餘裕、設自動擴縮門檻。
- 金絲雀漸進 rollout（如 0.1% → 1% → 10% → 100%、換不同地理區），讓新版在小流量下先撞到問題。
- 代價：壓測環境要夠像生產才有意義，且大型負載測試耗資源、耗時；要意識到測試成本，別把每次改動都全量壓。
🔑 Takeaways
- 壓力測試的目的是找極限——寫入失敗水位、超載 QPS——因為多數元件到臨界點是懸崖式垮掉，不是緩降。
- 測試失敗證明不可靠、通過不證明可靠；容量決策要靠「它什麼時候斷」而非平均表現。
- 事前壓測給容量規劃輸入，金絲雀漸進放量在小流量下驗證——兩者搭配，別拿生產尖峰當第一次壓測。
No notes yet — jot your takeaways or Q&A here.