壓測理論的角色是讓「加機器能不能解決」這個問題從直覺變成可推導。沒有理論基礎時、容量決策容易陷入「跑壓測 → 看數字 → 加機器」的盲試循環；有理論之後、可以從「現在的延遲 / 吞吐 / 並發量」反推「瓶頸在哪個資源、加什麼有效」。

本章是 9.2-9.12 的共同基礎。後續章節的 workload modeling、saturation discovery、capacity planning、SLO 都會回引本章的數學工具。讀者可以把這章當作「容量規劃的最小詞彙表」、其他章節是這些詞彙的應用情境。

本章不深入推導公式、聚焦在 工程意義。讀完之後讀者能回答：為什麼系統在 80% utilization 就該擴、為什麼加機器會邊際效益遞減、為什麼 sub-ms 延遲需求會反推架構選擇。

Little’s Law：穩態系統的最小數學工具

Little’s Law 用一條等式 L = λW 把三個變數綁在一起：L 是系統內平均並發數、λ 是請求到達率、W 是請求平均逗留時間。這個關係在 穩態（流量已穩定、不在 warmup 階段）必然成立、不需要假設特定分布或服務模式。

工程上最有價值的用法是「反推」。給定預期 RPS λ = 1000 跟 SLO latency 上限 W = 200ms、能算出系統最大穩態並發 L = 1000 × 0.2 = 200。這個 200 直接對應「connection pool size」「thread pool size」「async worker count」這類容量參數 — 訂得比 200 小、系統撐不住預期流量；訂得比 200 大太多、資源浪費。

反向也成立。當 connection pool 卡死在某個 size L、latency budget W 已訂、能算出可支撐的 RPS。這個算法在 capacity planning 階段比 ramp-up 壓測更快、可以先用 Little’s Law 篩掉明顯撐不住的配置、再用壓測驗證剩下的候選。

對應案例：Coinbase sub-ms 把 W 訂在 sub-millisecond、所有架構選擇都從這個 W 反推；Tubi ML p99 < 10ms 從 W 反推 feature lookup 必須 cache hit 路徑、不能回到持久 store。

詳見 Little’s Law 卡片。

Queueing Theory：為什麼 80% 利用率就是 knee

排隊論（M/M/c 模型）解釋了一個常見直覺：「系統在 50% utilization 看似還很閒、80% 就該擴、90% 已經太晚」。這個直覺不是經驗法則、是 數學必然。

M/M/c 系統的平均 queue length 跟 utilization 之間是非線性關係。當 utilization 從 50% 漲到 70%、queue length 約增加 2-3 倍；從 70% 漲到 90%、queue length 增加 10 倍以上。latency 跟 queue length 成正比（Little’s Law 又出現）、所以 latency 也呈現同樣的指數成長。

工程意義：健康系統運轉在 50-70% utilization、超過 80% 就接近 knee、超過 90% 進入不可預測區。「為什麼明明還沒滿就 saturate」的答案就在這條曲線。autoscaler 的 target metric 通常訂在 60-70%、是 queueing theory 推導出的安全邊界、不是工程師憑感覺。

多 server 模型（M/M/c）比單 server（M/M/1）有顯著容量優勢：c 個 server 的有效容量遠超 1 個 server 容量 × c。這也解釋了為什麼水平擴容（多開幾個 instance）通常比垂直擴容（單機加 CPU）划算 — 不只是規模、是 queue 行為的本質差異。

對應案例：GR8 Tech 25ms p95 把 p95 維持在 25ms 同時撐 54K TPS、靠的是 永遠不讓系統進入 knee、AI 預測讓擴容窗口縮短到 reaction time 內。

Universal Scalability Law：擴容會邊際失效

USL（Neil Gunther 提出）的公式 throughput(N) = N / (1 + α(N-1) + βN(N-1)) 解釋了「為什麼加機器到某個點之後 throughput 反而下降」。兩個常數 α 跟 β 描述系統的擴展限制：

• α 是必須序列化的部分（Amdahl’s Law 的對應）。distributed lock、coordinator、單一 leader DB 都是 α 來源。α 越大、線性擴容越早 plateau。
• β 是節點間互相通訊的成本（crosstalk）。cache invalidation broadcast、consensus quorum、cross-region replication 都是 β。β 比 α 更危險、會讓 throughput 在 N 大到某點後 反向下降。

工程上 α 比較好處理 — 把序列化部分拆細、用 partition 切分、用 sharded coordinator。β 比較難 — 通訊本質就需要協調、降低 β 通常要重新設計分散式協議（例如 Spanner 用 TrueTime 把跨節點交易的協調成本降低）。

對應案例：Spanner 線性擴展到 10 億 req/sec — TrueTime API 讓跨地區交易的 β 降到可接受、達成傳統 OLTP 做不到的線性；Coinbase RAFT consensus — RAFT 的 quorum 通訊讓 β 不可降、所以 選擇不橫向擴、改用 z1d + Cluster Placement Group 榨單機。

詳見 USL 卡片。

Saturation Curve：linear → knee → cliff

實際系統的 latency vs throughput 曲線分三段。第一段是 linear region — utilization 低、latency 平穩、加流量幾乎不影響 latency。第二段是 knee — utilization 接近 80%、latency 開始指數成長、再加流量會明顯變慢。第三段是 cliff — 系統進入不穩定區、latency 不可預測、可能 timeout、可能 cascade failure。

容量規劃的關鍵概念是 knee point = 設計容量上限。健康系統運轉在 knee 以下 50-70%、留出 headroom 應付 burst 跟 forecast 誤差。沒有量過 knee 的系統等於「不知道距離崩潰多遠」 — 平日看起來穩、實際隨時可能因為一個小 spike 進入 cliff。

不同 system 的 knee 位置差異很大。stateless service 通常 knee 在 80% CPU；DB 因為 lock contention、knee 可能在 60% utilization；broker / queue 因為 disk I/O bottleneck、knee 可能在 50%。容量規劃時不能一概而論、必須個別量測。

每次重大改動後必須 re-test knee。新增功能、改 ORM、升級 library、調 GC tuning、改 cache 策略 — 任何一個都可能讓 knee 往不好的方向移。

對應案例：Tixcraft DynamoDB IOPS 20 → 135K — partition 設計均勻時 saturation point 可以推到極遠（6750x 擴展）；Amazon Ads 9000 萬 RPS — 線性擴展靠 partition key 均勻、不靠 vendor 神話。

詳見 Saturation Point 卡片。

反推：從業務 KPI 到系統參數

理論工具的真正價值在「反推」 — 不是先設計系統再量測 saturate 多少、是 先訂業務目標再反推系統參數。這層思維把容量規劃從 reactive（撐到撐不住才擴）變成 proactive（按業務需求預先配置）。

反推流程通常從 latency budget 開始（詳見 9.12 SLO 與 Performance Budget）：

1. 從 user-perceived end-to-end latency（例如 p99 500ms）開始
2. 拆到每個 stage（網路、CDN、application、cache、DB、第三方）的 latency 配額
3. 配額決定每個 stage 的設計選擇 — DB 配 50ms → 不能跨 region、application 配 100ms → 不能多層 microservice hop
4. 配額 + 預期 RPS → Little’s Law 算每個 stage 的並發
5. 並發 → 每個 stage 的容量需求 → 實例數 / connection pool size / cache size

反推失敗的常見徵兆：算出來的某個 stage 容量超過 vendor 提供的上限（例如「需要 50 萬 DynamoDB RCU」可能超過單一 table partition 上限）、或某個 stage latency 配額過短（例如 cross-AZ 網路至少 1-2ms、配 0.5ms 不可能達成）。這時要回頭調整 SLO 或重新設計架構。

詳見 Latency Budget 卡片。

案例對照

下一步路由

• 下游：9.2 Workload Modeling（把模型量化成 production traffic）
• 下游：9.4 Saturation Discovery（實測 knee point）
• 跨章節：9.12 SLO 與 Performance Budget（latency budget 拆解）

既建知識卡片

• Little’s Law
• Universal Scalability Law
• Saturation Point
• Latency Budget
• Tail Latency

Workload modeling 的角色是讓壓測結果有意義。如果壓測模型跟 production traffic shape 不一致、壓測通過不代表 production 撐得住。這一層的工作不是「製造大量請求」、而是「製造跟 production 一樣形狀的請求」。

跟 9.1 壓測理論 的關係：9.1 提供推導工具、9.2 把工具的輸入（流量參數）量化。沒有 workload model、Little’s Law 的 λ 跟 W 都是猜。

本章的核心問題：production traffic 不是「N RPS」這麼簡單。它有時間分布、地理分布、操作分布、cohort 分布、burst pattern。每個維度都會影響系統行為。一個只測「總 RPS」的壓測通過了、production 還是可能因為某個 cohort 集中或某個 burst pattern 出事。

Traffic shape 的五個維度

Production traffic shape 至少要量五個維度才算 model 完整。

平均吞吐 vs 峰值：peak/avg ratio 是工程意義最大的單一指標。1.5x 的 peak/avg 代表流量相對平緩、容量規劃可以接近 average peak；3-5x 的 peak/avg 代表 bursty 流量、必須按 peak 規劃、平日大幅 over-provision。對應案例：ASOS Black Friday 24h 1.67 億 / 峰值 3500 RPS 峰均比約 1.81x 屬於相對溫和；Tixcraft 5 分鐘賣完 是另一極端。

時間分布：日內（早晚通勤）、週內（週末活躍）、月內（月初發薪）、季內（節慶）、年內（活動）。不同尺度的週期都要記錄、用於 forecast 跟 pre-scaling 決策。

用戶分布：geographic（哪個 region 多）、device（mobile vs desktop）、tier（free / paid / VIP）。同樣 RPS、不同分布可能造成完全不同系統行為 — VIP 用戶可能跑更複雜 query、mobile 用戶可能更多 retry、跨 region 用戶可能更多 cross-zone latency。

操作分布：read vs write 比、不同 endpoint 的 mix。一個系統 90% read 跟 50% read 的容量設計完全不同 — read-heavy 可以 cache、write-heavy 必須關注 storage IOPS。

Cohort 與 burst pattern：同一秒的請求不一定均勻 — bursty arrival 比 Poisson arrival 對系統更殘酷。突發 burst 來源：promo 推播、KOL 推廣、新片發布、新聞事件。

對應案例：GR8 Tech 賽事高潮 burst — 賽事「進球瞬間」 burst 比平均流量高 10-50 倍；Disney+ 新片發布 — 同片瞬間集中、cohort 高度集中。

從 production log 抽 workload model

實務上 workload model 不能憑空寫、要從 production data 抽。流程通常分四步：

第一步：data 蒐集。從 access log、APM trace、metric 系統取得 production traffic 樣本。要 sampling（不是全量）、避免影響 production；要包含 至少一個完整 weekly cycle（含週末、含峰谷）；要按 endpoint / per-tenant 分組。

第二步：分組統計。對每組（per endpoint、per tier、per region）計算 percentile（p50 / p95 / p99）、arrival pattern（Poisson、bursty、scheduled）、payload size 分布。輸出是「workload profile」 — 比單一數字更接近 reality。

第三步：序列重播。複製一段 production traffic 的時間序列、保留 inter-arrival timing（不只是 RPS 平均、是 每秒幾個）。這層讓 burst 在壓測重現、不只是「平均壓力均勻分布」。

第四步：脫敏處理。PII（user_id、phone、address）必須匿名化或替換 — 否則壓測環境變成 PII 洩漏點。常見做法：hash + salt + 確保結果 cardinality 跟 production 一致。

production log 通常缺寫入 payload（log 只記 metadata、不記 request body）、要從 application metric 或 schema sample 補。schema sample 用「distinct value 抽樣」、不是「random」 — 確保壓測涵蓋常見 value pattern。

Synthetic load vs production replay

兩種主要壓測方式各有取捨。

Synthetic load：手寫腳本、明確控制每個請求的 shape。優點是好複現、可以針對特定情境設計（例如「測登入失敗 retry」）；缺點是容易脫離 production reality、寫腳本的人會無意識套用自己的偏見。

Production traffic replay：用 GoReplay、Istio mirror、AWS VPC Traffic Mirroring 等工具把 production traffic 複製到測試環境。優點是 最貼近真實、自動帶上 burst 跟 cohort；缺點是消耗 production 下游資源（要算進容量規劃）、PII / 合規處理複雜、replay 環境的下游 mock 不容易做。

混合模式：常態壓測用 synthetic（cheap、可控）、release candidate 驗證用 production replay（真實）、debug 特定 incident 用 特定時段 的 replay。三種工具在不同階段用、不是二選一。

對應案例：FanDuel 雙峰需要兩個 workload model 並行 — 直播 model（CDN heavy、長 session）跟投注 model（低延遲、burst at goal）必須分開壓測、不能合成一個。

詳見 Workload Model 卡片 跟 Shadow Traffic 卡片。

模型驗證：怎麼知道模型像 production

寫了 workload model 之後、怎麼驗證它真的「像 production」？方法是 跑壓測 同時 對比 production metrics。

驗證指標包含：throughput pattern（總 RPS、各 endpoint mix）、latency 分布（p50 / p95 / p99 對比）、resource utilization（CPU / memory / network 行為）、error rate 與 retry pattern。

兩個可能的偏差結果：

• 模型撐不住但 production 撐得住 → 模型太苛刻、可能高估了流量或操作複雜度。usually fine、調整模型參數即可。
• 模型撐得住但 production 撐不住 → 模型不足、漏了某個維度。dangerous、需要回到 data 蒐集階段找漏掉的 pattern。

對應案例：Zoom 30x COVID surge — 之前的 workload model 完全不能用、必須 reset baseline 重新從 post-COVID 流量抽 model；Tixcraft 10K t2.micro 壓測 — 用實際售票場景重播驗證、不是 synthetic 數字。

模型維護：定期 review

Workload model 不是一次抽完就永久有效。業務變化會讓模型過時、過時的模型導出的容量規劃會失準。

需要 re-抽 model 的訊號：

• 新功能上線改變 user journey（例如新增 video upload、user 行為變寫多）
• 新市場進入改變 cohort 分布（例如進入印度市場、mobile share 大幅增加）
• 行銷活動改變 burst pattern（例如新增 push notification、burst 集中度上升）
• 用戶習慣轉變（例如 work-from-home 讓週末跟平日流量比變化）

維護節奏建議每季 review 一次、重大產品改動立即 re-抽。每次 re-抽要 跟前一版對比、量化變化幅度、決定哪些容量計畫要重新評估。

案例對照

下一步路由

• 上游：9.1 壓測理論
• 下游：9.3 壓測工具選型（用什麼工具實作 model）
• 下游：9.4 Saturation Discovery（用 model 跑 ramp-up）
• 跨模組：04 可觀測性模組（production log 來源）

既建知識卡片

• Workload Model
• Shadow Traffic
• Growth Curve
• Peak Forecast

壓測工具選型的核心不是「哪個工具最強」、是「哪個工具最貼合本團隊的 workload model 表達能力跟 CI 整合需求」。沒有絕對最好的工具、只有最匹配當前場景的工具。

跟 9.2 Workload Modeling 的關係：9.2 定義 workload 長什麼樣、9.3 找能複製這個樣子的工具。工具選對、壓測結果可信；工具選錯、壓測結果誤導。

本章不是工具教學、是 選型維度 + 主流工具的 適用情境。讀者讀完後能回答「我現在這個 workload 該用哪個工具」、而不是「哪個工具最快」。

六個選型維度

選工具時要按六個維度評估、不能只看「能不能跑 HTTP GET」。

腳本表達能力：能不能寫複雜 user journey（登入 → 瀏覽 → 加購物車 → 結帳）、不只是單一 HTTP request。複雜系統的壓測通常是 user journey 級別、單一 endpoint 壓測只能找絕對極限、找不到 cross-endpoint contention。

協議支援：HTTP / WebSocket / gRPC / TCP / 自家二進位協議。WebSocket 跟 gRPC 是現代後端常見、傳統工具（JMeter、wrk）可能要 plugin 補。

規模能力：單機可以發多少 RPS、能不能分散式擴容。本機 wrk 可發 10K-50K RPS；分散式 Locust 可發 1M+ RPS。決定因素：CPU 效率、async I/O 模型、是否單機 bound。

CI 整合：能不能在 PR 上跑 lightweight perf check、結果能不能機器可讀（JSON / Prometheus exposition）、能不能跟 baseline diff。沒有 CI 整合的工具只能做「事件型壓測」、無法做 continuous perf governance。

結果分析：原生 dashboard（k6 Cloud、Gatling Enterprise）/ Prometheus + Grafana 整合 / 純文字輸出。要看結果分發、團隊成員能不能輕鬆查詢歷史。

學習曲線：腳本語言（JavaScript / Scala / Python / Go）、團隊熟悉度。工具好但團隊不會用、會變成 1-2 個工程師的孤島技能、流失時整套廢掉。

主流開源工具對照

k6 是過去 5 年崛起的綜合首選。JavaScript 腳本（前端工程師也能寫）、原生 dashboard、Prometheus exposition、CI 友善。Grafana 收購後生態加速。缺點：複雜 stateful 場景（DB connection pool 共享）需要繞 workaround。

JMeter 是企業常見的 incumbent。協議支援廣（含 LDAP、JDBC、JMS）、有 GUI 編輯器。缺點：腳本是 XML、版本控制困難；GUI 主要用來生成腳本、實際跑壓測還是要 headless。已經在用的團隊建議繼續、新團隊不必特意選它。

Gatling 高 throughput 純 async、性能優秀、報表精美。缺點：Scala / Kotlin DSL 學習曲線陡、新版本（11+）改了 DSL 不向後相容。

Locust 是 Python 生態的選擇、特別適合複雜業務邏輯（用 Python 寫 user journey 自然）。分散式部署原生支援。缺點：Python 單線程 throughput 受限、要靠分散式擴容。

Vegeta 跟 wrk 是「quick check」工具、用於單一 endpoint 的極限測試。不適合複雜場景、適合 saturation discovery 第一輪「找這個服務的天花板」。

Production traffic replay 工具

當需要複製 真實 production traffic 的壓測場景時、需要另一類工具。

GoReplay 是最常用的開源 traffic replay 工具。在 production server 上 tcpdump-based 捕獲 HTTP traffic、可以 store 到 file 或 stream 到 staging 環境。優點：開源、無 vendor lock-in；缺點：HTTP only、加密流量要拿到 key 才能用。

Service mesh shadow（Istio / Linkerd mirror）：mesh 層 mirror traffic 到 staging service。優點：mesh 已部署的話 zero infra cost、加密 traffic 也能 mirror。缺點：需要 service mesh 已落地。

AWS VPC Traffic Mirroring：底層網路層 mirror、application 完全無感。優點：最低 invasion；缺點：AWS only、加密 traffic 要另外處理。

Diffy（Twitter / X 開源、已 deprecated 但概念仍有效）：dual-write 同時打到舊 / 新版本、比對結果。適合驗證「新版本是否邏輯正確」、不是純壓測。

對應案例：Tixcraft 10K t2.micro 壓測 — 用分散式 EC2 跑 synthetic load 模擬 100K 同時搶票；SeatGeek Virtual Waiting Room — token 配發邏輯通常用 dual-write 驗證新舊版本一致。

雲端 managed 壓測服務

當不想養 load test infrastructure、想 ad-hoc 跑大規模壓測時、用 managed service。

AWS Distributed Load Testing：CloudFormation 起 Fargate cluster 跑 JMeter 或 Taurus、報表寫到 S3。優點：一鍵部署、Fargate 計費；缺點：JMeter-based、不是現代 k6 風格。

Grafana k6 Cloud：託管 k6、跨地理 distributed 壓測（從多個 region 同時發流量）。優點：地理分散原生、跟 Grafana 整合無縫；缺點：vendor cost。

Azure Load Testing：Azure 原生、整合 Application Insights。優點：Azure 用戶無縫；缺點：相對較新、生態還在補。

GCP 沒有 first-party managed load testing：要靠 Marketplace 方案或自管 Locust on GKE。

工具選型決策樹

落地時的快速決策：

• 想快速驗證單一 API 極限 → wrk / Vegeta
• 想寫複雜 user journey + CI 整合 + JavaScript 團隊 → k6（新項目首選）
• 企業已有 JMeter 流程、不想換 → JMeter（接受 XML / GUI 複雜度）
• 大規模分散式 + Python 生態 → Locust
• 報表給管理層看、Scala 團隊 → Gatling
• 想複製真實 production traffic → GoReplay 或 service mesh shadow
• 想 ad-hoc 雲端大規模壓測 → 對應雲商的 managed load test

常見反模式

• 只測單一 API、不測 user journey：找不到 cross-endpoint contention、找不到 session state 累積
• 壓測機跟被測機在同一網段：網路延遲被低估、p99 比 production 樂觀
• 壓測時 throttle 自己的工具：結果不是被測系統的極限、是工具自己的極限
• 結果報表只看平均：tail latency 看不到、p99 退化被掩蓋
• 壓測環境跟 production hardware 不一致：CPU 型號、network、disk IOPS 差很大、結果不可外推
• 沒驗證 model：跑了壓測但沒對比 production metrics、不知道 model 是否貼近 reality

案例對照

下一步路由

• 上游：9.2 Workload Modeling
• 下游：9.4 Saturation Discovery（用工具找 knee）
• 下游：9.9 Improvement Loop（CI 整合）
• 跨模組：06.1 CI Pipeline（壓測在 CI 的位置）

既建知識卡片

• Load Test
• Workload Model
• Shadow Traffic
• Saturation Point

Saturation discovery 的責任是把「系統能撐多少」這個問題變成可量化答案。沒有 saturation 量測時、容量規劃只能猜；有 saturation 量測之後、能說「在當前配置下、p99 < 100ms 的條件下、能撐 X RPS、headroom Y%」。

跟 9.1 壓測理論 的關係：9.1 預測 saturation curve 的形狀（linear → knee → cliff）、9.4 用實測找出 本服務 的曲線具體位置。理論告訴我們 knee 存在、實測告訴我們它在哪裡。

本章不深入工具操作（9.3 處理工具）、聚焦在 方法論 — 怎麼設計 ramp-up、怎麼判斷 knee、怎麼把結果文件化讓後續決策可用。

Saturation 的精確定義

容量規劃裡 saturation 不是「系統當機」、是「系統 進入 latency 指數成長區」。這個區分很重要 — 系統 看起來 還在跑、其實已經不可預測。

技術上 saturation 對應 queueing theory 的 knee point：utilization 超過某個臨界（M/M/c 通常 70-80%）、平均 queue length 從線性轉成指數成長。latency 是 queue length 的線性函數、所以也跟著指數成長。

實務上把 saturation 分三段：

• linear region（utilization < 50%）：latency 平穩、加流量幾乎不影響
• knee region（utilization 50-80%）：latency 開始上升、但還可接受
• cliff region（utilization > 80%）：latency 不可預測、可能 timeout / cascade failure

健康系統運轉在 linear 後半段或 knee 前段（utilization 50-70%）、留出 headroom 應付 burst。autoscaler 的 target metric 通常訂在 60-70%、是這條曲線推導出的安全位置。

Ramp-up 測試方法

要找出 saturation 點、必須跑 ramp-up 測試 — 不能固定一個壓力值。

單點壓測的問題：跑「2000 RPS 連續 10 分鐘」、看 latency 100ms、結論「能撐 2000 RPS」 — 但不知道 1500 跟 2500 RPS 是什麼樣。可能 1500 也是 100ms（離 knee 還很遠）、可能 2500 直接崩（已經在 cliff）。

Ramp-up 流程：從基線開始、按倍數加壓（1x / 2x / 4x / 8x …）。每個壓力 level 維持 5-10 分鐘、觀察 latency / throughput / resource utilization 的穩態（不是 transient）。紀錄每個 level 的 percentile 分布。

Knee 出現的訊號：

• throughput 從線性成長轉成 sub-linear（加壓但 throughput 不再等比成長）
• latency p50 還算穩、但 p99 / p999 開始飆
• resource saturation queue 開始堆積（不只 utilization 上升）
• error rate 仍接近 0（cliff 才會 error 飆）

Cliff 出現的訊號：throughput 開始下降（加壓反而越來越慢）、latency p99 變成 timeout、error rate 飆升、retry storm 出現。

對應案例：Tixcraft 用 10K t2.micro 壓測 找 DynamoDB 從 20 IOPS 到 135K 的擴展曲線、知道 knee 在哪。

Resource saturation 的六個維度

每次 ramp-up 都要同時觀察六個維度的 resource saturation、找出哪個 先 saturate。

CPU：utilization 100% 不一定 等於 saturation。要看 load average 跟 run queue。utilization 80% 但 run queue 不斷增長 → 已 saturate；utilization 100% 但 run queue 空 → 還能撐（單純 CPU bound）。

Memory：not OOM 即可？不夠。GC pause（Java、Go）、swap（Linux）、cache eviction 都是隱性 saturation。記憶體不直接 OOM 但 GC 飆 → 已影響 tail latency。

Disk I/O：要看三個維度：throughput（MB/s）、IOPS（operations/sec）、queue depth。雲端 SSD 通常先 IOPS bound、不是 throughput；本機 NVMe 可能先 throughput bound。

Network：bandwidth（Gbps）、packets per second、connection count。雲端 instance 通常有 PPS limit、超過會 silent drop、不是顯式錯誤。

Connection pool：DB / cache / external API 的連線數。這是 最常見的隱性 bottleneck。pool size 訂 100、實際在用 95 → utilization 看似還好、其實已經 saturate（剩下的 request 在等 connection）。

External API quota：第三方 rate limit（Stripe、Twilio、Slack API）。這個維度的 saturation 看不到 本系統 的訊號、要看 對方 API 的 429 error rate。

對應案例：Lemino RDB connection limit — connection 是 RDB 的 saturation 點、CPU 跟 RAM 都還沒到。

詳見 USE Method 卡片。

Hot partition 的隱性 saturation

對分散式 KV / OLTP（DynamoDB、Cosmos DB、Bigtable、Cassandra）、saturation 還有另一個維度：hot partition。

名義容量 = 每 partition 上限 × partition 數量。partition key 分布不均 → 名義容量達不到。整體 utilization 看起來 20% → 系統還能撐？不一定。最熱 partition 已經 100%、其他 partition 0%、整體平均才 20%、但加流量會打在最熱 partition、立即 throttle。

識別 hot partition 的訊號：

• throughput 上不去、但 average resource utilization 低
• 某些 key 的 request latency 飆、其他 key 正常
• DynamoDB throttling event 出現（即使 capacity 還沒滿）

處理方法：

• composite key（event_id + user_id_hash）
• write sharding（event_id + random_suffix）
• time-bucket（event_id + minute）
• 用 cache 吸收 hot key（DAX、ElastiCache）

對應案例：Amazon Ads 9000 萬 RPS — partition 設計均勻時可以撐 sustained 高吞吐；Tixcraft 售票 — 同一場演唱會（event_id）天然容易 hot、必須用 composite key 分散。

Long-tail latency 的 saturation

p50 / p95 / p99 / p999 在 saturate 時表現可能完全不同。

p50（中位數）對 GC pause、retry storm、tail latency 不敏感 — 大部分 request 沒事、p50 看不到。 p99（百分之 1）對 connection contention 開始敏感、能早期看到 saturation。 p999（千分之 1）對 GC stop-the-world、leader election、retry storm 敏感、是長尾的最強訊號。

純看 average / p50 會誤判 saturation 還沒到。SLO 通常訂 p99（讓 99% 用戶體驗良好）、internal critical 系統可訂 p99.9（5 個 9 的可用性對應 5 個 9 的 latency 期待）。

對應案例：Tubi p99 < 10ms — ML 系統的 user-perceived latency 是 最後完成的 inference、p50 快沒用；Coinbase sub-ms — RAFT 系統的 p999 通常比 p99 高一個量級。

詳見 Tail Latency 卡片。

Saturation 文件化：容量地圖

Saturation discovery 跑完之後、產出 容量地圖 — 不是一個數字、是一張表。

容量地圖至少要回答：

• 在 X 配置下（instance count、type、network）
• SLO 條件 Y 下（p99 < N ms、error rate < M%）
• 能撐 Z RPS（含分解到不同 endpoint）
• knee 在哪（什麼條件下進入 cliff）
• 第一個 saturate 的 resource 是什麼

紀錄 測試時間 跟 軟硬體版本：硬體 / 軟體版本變動後、saturation 點可能位移、舊地圖不能套用。

加入 release gate：每次重大改動後 re-test、確認 knee 沒往不好的方向移。這層自動化跟 9.9 Improvement Loop 對接。

案例對照

下一步路由

• 上游：9.1 壓測理論 / 9.3 壓測工具選型
• 下游：9.5 瓶頸定位流程（找到 knee 之後、定位是哪個 resource）
• 下游：9.6 容量規劃模型（用 knee 算 headroom）
• 跨模組：04 可觀測性模組（量測訊號）

既建知識卡片

• Saturation Point
• USE Method
• Tail Latency
• Hot Partition

瓶頸定位的責任是回答「為什麼擴 app 沒用」這類問題。當 9.4 Saturation Discovery 找到 knee point 之後、下一步是知道 哪個 resource 先 saturate。沒有定位、容量規劃只能 全部翻倍；有定位、可以 精準加在瓶頸層。

跟其他章節的關係：跟 9.4 是姊妹章（9.4 找出 knee、9.5 定位 knee 的成因）、跟 9.8 效能可觀測性 互補（9.8 訊號治理、9.5 用訊號做定位）。

本章不深入工具操作、聚焦在 方法論 — 怎麼按層次定位、怎麼避免常見誤判、怎麼區分可分散 vs 不可分散瓶頸。

USE method：resource-oriented 觀察

Brendan Gregg 的 USE method 提供逐層定位的最小框架：對每個資源、量三個維度。

Utilization：資源使用率 0-100%。CPU 70%、memory 60%、disk 40% 這類數字。 Saturation：資源排隊量（queue depth）。CPU run queue length、memory swap rate、disk I/O wait queue、connection pool wait count。 Errors：資源層錯誤。CPU page fault、memory OOM、disk I/O error、network packet drop、connection refused。

對每個資源（CPU / RAM / disk / network / DB connection / cache connection / file descriptor）逐一檢查。第一個出現 saturation 上升的資源是 bottleneck、不是 utilization 最高的那個。

USE 跟 RED method（rate / errors / duration）互補：USE 看「哪個資源頂不住」、RED 看「哪個 endpoint 表現變差」。容量規劃通常先用 USE 找瓶頸、再用 RED 看影響面。

詳見 USE Method 卡片。

逐層定位流程

從 application 層往下查、按依賴鏈逐層檢查。多數 bottleneck 在 application 跟 DB 兩層、但不能跳過其他層 — 偶爾真的在意外位置。

1. 應用層（application）：

• thread / coroutine pool 使用率：是否已飽和
• event loop lag（Node.js、async runtime）：> 50ms 是警訊
• GC pause 頻率與時長：影響 p99 / p999
• request queue（accept queue、application internal queue）

2. DB 層：

• connection pool 使用率（最常見隱性 bottleneck）
• slow query frequency
• replication lag
• lock contention（row lock、table lock）
• transaction queue depth

定位到 DB 層瓶頸時、優先檢查 1.13 應用層查詢反模式 清單 — 多數 DB 層瓶頸的根因是「應用程式發給 DB 的 query 寫法」、不是 DB 規格不夠。N+1 query 放大 connection 占用、long-running transaction 放大 lock contention、缺索引讓 slow query frequency 升高、SELECT * 放大 transaction queue。這層判讀走完、再考慮 DB 規格升級或加 replica。

3. Cache 層：

• hit rate（突然下降是訊號）
• eviction rate
• connection 飽和（cache pool 也會耗盡）
• memory utilization

4. Broker / queue 層：

• consumer lag（最重要的單一指標）
• queue depth
• dead-letter rate
• broker connection count

5. 外部 API / 第三方 quota：

• rate limit 觸發頻率
• retry storm（自家 retry 把對方 quota 打爆）
• circuit breaker trip
• timeout rate

6. 網路層：

• bandwidth utilization
• packets per second（PPS limit）
• socket count（file descriptor limit）
• 跨 region / 跨 AZ latency

7. DNS / load balancer：

• DNS resolution latency
• LB connection establishment time
• TLS handshake duration
• backend health check failure

對應案例：Lemino RDB connection limit 是隱性 bottleneck、CPU / RAM 都還行；Tixcraft 付款層獨立 — 把高頻搶票流量跟低頻付款流量分離、避免一層拖累另一層。

Profile 工具鏈

USE 找出哪一層 saturate 之後、profile 工具找出 該層的哪段 code 拖累。

Continuous profiling：Datadog Continuous Profiler、Pyroscope（開源 + Grafana 整合）、Parca（CNCF）、GCP Cloud Profiler、Azure Application Insights Profiler、AWS CodeGuru Profiler。production 持續取樣 CPU / heap / lock、overhead 通常 < 1%。

Distributed tracing：OpenTelemetry、Jaeger、Tempo、AWS X-Ray、GCP Cloud Trace、Azure Application Insights。記錄 request 在每個 service / 每個 stage 花了多少時間、找跨服務的 latency 累積。

Flame graph：profile 結果視覺化的標準。從寬度可以看到「哪段 code 佔 CPU 最多」。學會看 flame graph 是 SRE 的基本功。

Profile diff：壓測 baseline 跟 release candidate 比 stack 差異。看 相對變化 而非絕對值。詳見 Profile Diff 卡片。

對應案例：Netflix Aurora storage / compute 分離 — DB 統一後 application profile 變單純、退化來源更容易識別。

詳見 Continuous Profiling 卡片。

跨層依賴鏈

瓶頸不一定在 本服務、可能在 下游服務。這層判斷常被忽略。

第三方 API quota 是常見隱性瓶頸。Twilio SMS、Stripe API、Slack webhook、Sendgrid email、Google Maps API 都有 rate limit。自家服務看起來健康、實際是 對方 throttle、自家 retry 再讓對方更慢。

跨 region / 跨 zone 網路延遲 是累積的。一個 user request 經過 5 個 service、每個 service 跨 AZ 一次、累積 10-20ms cross-AZ latency。看起來每個 service 都很快、但 end-to-end 慢。

Downstream cache 也是依賴。app 看起來健康、但其實是 cache 在擋；cache 突然 cold start（restart、eviction storm）、application 直接被打爆。

對應案例：PayPay 行動支付 — DynamoDB 寫入可以撐 3K msg/sec、但 APNs / FCM 一天的 quota 有限、推送下游才是瓶頸。

可分散 vs 不可分散瓶頸

定位完瓶頸後、要判斷它 可不可以橫向擴。這個判斷決定能不能用「加機器」解決。

可分散瓶頸：

• stateless app server → 加機器有用
• partitioned KV / OLTP（partition key 均勻時）→ 加 partition 有用
• read replica（read-heavy workload）→ 加 replica 有用
• worker pool → 加 worker 有用

不可分散瓶頸：

• consensus DB（RAFT / Paxos）→ 加節點不一定快（quorum overhead）
• single leader DB（master 寫）→ 必須垂直擴
• 中央 coordinator → 必須拆解或垂直擴
• 共享 cache（hot key）→ 必須改 partition key 或加 local cache

判斷不可分散的關鍵是「協調成本」。一個操作必須 跟所有 / 多數節點協調 才能完成、就不可水平擴。

對應案例：Coinbase RAFT consensus — consensus 不可水平擴、所以 選擇不擴、改用單機極致；Spanner TrueTime — TrueTime 把協調成本 amortize 到 hardware（GPS + 原子鐘）、讓 OLTP 可水平擴。

常見定位陷阱

看單一指標就下結論：CPU 100% 不一定是 bottleneck（可能 saturation queue 空）；CPU 50% 不一定健康（可能 saturation queue 已滿）。always 看 USE 三個維度。

平均看 OK、p99 看不出來：average latency 50ms 看起來健康、p99 500ms 已經出事。用 percentile、不用 average。

Observer effect：profile / tracing 本身有 overhead、量測會輕微影響系統。critical path 上的 instrumentation 要 sampled 不要 100%。

跨 release 比較 baseline 沒對齊：上週的 baseline 對應 v1.2、這週的 candidate 對應 v1.3、但 v1.2 跟 v1.3 之間還有 schema migration / hardware 變化、baseline 已經漂移。重新建 baseline 再 diff。

案例對照

下一步路由

• 上游：9.4 Saturation Discovery
• 下游：9.6 容量規劃模型（針對 bottleneck 規劃）
• 下游：9.9 Improvement Loop（用 profile diff 改進）
• 下游：1.13 應用層查詢反模式與 Query 預算（DB 層 bottleneck 多半在 query 寫法）
• 跨模組：04 可觀測性模組 / 05 部署平台模組

既建知識卡片

• USE Method
• RED Method
• Continuous Profiling
• Profile Diff
• Universal Scalability Law

容量規劃的責任是把「未來 N 個月可能多大」翻成「現在該訂多少 capacity」。這層工作不純靠歷史外推、要結合業務 forecast、事件型成長、頂部風險 buffer。

跟 9.4 Saturation Discovery 的關係：9.4 提供「當前配置能撐多少」、9.6 用這個數字加上 forecast 推「該規劃多少」。沒有 9.4 的 baseline、9.6 只是猜；沒有 9.6 的 forecast、9.4 的 baseline 只是 snapshot。

跟 9.13 擴展軸 的關係：9.13 先決定「沿哪條軸擴」（垂直 / 水平 / Y 軸拆服務 / Z 軸 partition），9.6 才能算出「該擴多少」。同樣是「處理 10 倍流量」、選垂直擴展要算單機規格上限、選水平擴展要算協調成本跟連線池放大、選 Y 軸拆服務要算跨服務 latency budget — 三條軸的容量公式參數完全不同。沒先做 9.13、9.6 的數字會落到錯誤的擴展軸上。

本章是「規劃決策」的章節、不是執行手冊。讀完後讀者能回答：peak 怎麼預測、headroom 訂多少、autoscaler 怎麼配、不可水平擴的服務怎麼處理。

容量公式三項

容量規劃的核心公式可以濃縮成三項相乘：容量 = 預期峰值 × (1 + headroom) / 可擴容速度。每一項都需要獨立分析：

預期峰值（peak forecast）：歷史 baseline × 預期成長 × 事件因子。三項中最影響整體準度。詳見 Peak Forecast 卡片。

Headroom budget：通常 30-50%、為了應付異常 burst + AZ 故障 + forecast 誤差。不同工作負載 headroom 不同。詳見 Headroom Budget 卡片。

可擴容速度（reactive vs predictive）：autoscaler 反應時間 vs 流量上升速度。如果流量上升比 autoscaler 快、必須 提前 pre-scale、不能等 reactive 反應。

這個公式的另一個寫法是「容量 = peak × 安全係數」、安全係數 = (1 + headroom) / 可擴容速度。預測準 + 擴容快 → 安全係數小、容量緊湊；預測差 + 擴容慢 → 安全係數大、成本高。

Peak forecast 方法

Forecast 方法分三層、按業務型態選用。

歷史線性外推：拿過去 N 個月的趨勢、按斜率外推到下 N 個月。適合 sustained growth（B2B SaaS 月增 X%）；不適合 event peak（年度活動）跟 surge（產品爆紅）。

季節性分解（STL：Seasonal-Trend decomposition using Loess）：把長期趨勢、週期成分、殘差分開預測。適合電商（雙 11 / Black Friday）、串流（IPL / Super Bowl）、零售（聖誕節）。需要 至少兩個完整 cycle 的歷史資料。

業務 ML 模型：結合 marketing pipeline（廣告投入）、新用戶獲取（acquisition rate）、留存率、產品變化等多 feature。最精準但成本高、需要 ML team。

最常見錯誤是「拿去年同期 × (1 + 預期成長 %)」：忽略產品改動 + 行銷投入變化 + 外部事件。Prime Day 2025 vs 2024 不只是 +30% — 是 AI shopping assistant 上線、是 ad spend 變化、是新國家上線。

對應案例：Prime Day 年增率 +30% ~ +77% — 連 Amazon 自家每年成長都不能線性外推；Disney+ 新片發布 — 事件型 forecast、按過去新片 metric 預估。

Forecast 必須有 誤差範圍、不能單一數字。給上下界（最壞 / 預期 / 最好）、容量規劃才能用 worst-case 訂 baseline。

Headroom budget 設計

Headroom 不是 over-provisioning 浪費、是容量規劃的安全邊界。常見比例 30-50%、按 saturation 行為跟工作負載敏感度調整。

為什麼是 30-50% 而不是 10%：

• forecast 誤差：預測準度通常 ±20-30%
• burst pattern：瞬間 spike 超過 average peak、需要短時間吸收
• AZ / region failover：一個 AZ 掛、剩下兩個要承擔全部（多 33% 容量）
• 系統老化 / drift：軟硬體升級後 saturation 點可能位移

不同工作負載不同 headroom：

• stateless service：30%（autoscaler 反應快、headroom 可以薄）
• DB：50%（不易擴容、要備援足夠空間）
• broker / queue：60%（consumer 落後恢復時要瞬間吃下積壓）
• consensus DB：80%+（完全不能 reactive 擴）

headroom 太低 → 出事：peak 期間進 cliff、用戶體驗變差。 headroom 太高 → 浪費錢：平日成本拉高、CFO 質疑。

對應案例：GR8 Tech AI 預測 — 預測準了可以降 headroom 比例；預測不準必須拉高 headroom 補回安全邊界。

Growth curve 形狀分類

不同 growth curve 形狀對應不同 forecast 方法跟 review 節奏。

Linear growth：用戶月增 X%。B2B SaaS 最常見。forecast 線性外推、每季 review、headroom 可以薄（成長可預測）。

Step growth：每次行銷 / 活動跳一階、之間 plateau。需要 event tier 規劃、每個事件單獨 forecast、headroom 跟 event 強度連動。

Exponential growth：早期初創、病毒擴散。forecast 容易低估、傳統線性外推會大幅低估；headroom 必須拉到 100%+、不能省。

S-curve growth：成熟產品、會 saturate。Forecast 初期像 exponential、中期 plateau、晚期 mature。需要識別 inflection point、過了就調 forecast 方法。

Cyclical：電商季節性。每年 Black Friday / Cyber Monday / Christmas / Chinese New Year 都重複、forecast 用 STL 季節性分解。

對應案例：Zoom 30x COVID — step growth、外部衝擊讓 baseline 永久上移；Pokemon GO 50x surge — exponential（早期）+ 之後 S-curve；ASOS Black Friday — cyclical。

詳見 Growth Curve 卡片。

Autoscaling sizing

訂好 capacity 之後、要設計 autoscaler 把這個容量 動態使用。

min / max / target metric 三個參數：

• min 太低 → cold start 風險（流量上來時還在 boot）
• min 太高 → 平日浪費
• max 太低 → 限流（peak 時 autoscaler 不能再擴）
• max 太高 → 月底炸帳單（autoscaler 不受控、過 peak 不會主動降）
• target 太高 → autoscale 啟動太晚、進 knee 才反應
• target 太低 → autoscale 太敏感、頻繁 scale up / down 浪費

Predictive vs reactive：

• predictive scaling：根據歷史 pattern 或 ML 模型提前擴
• reactive scaling：根據當下指標擴
• 兩者組合最穩：predictive 處理已知 pattern、reactive 處理 unexpected burst

Scheduled vs metric-based：

• scheduled scaling：時段觸發（年度活動、daily peak）
• metric-based：根據 utilization / queue depth 觸發
• 三層組合（scheduled + predictive + reactive）最穩

不同層的 autoscaler 各自設計：

• EC2 Auto Scaling Group：infrastructure 層
• Kubernetes HPA / VPA：pod 層
• Karpenter：node 層
• DynamoDB auto-scaling：DB capacity 層
• CloudFront：CDN 層

對應案例：Tixcraft 30 分鐘擴 130 倍 — 6 台 → 800 台靠 ASG + AMI prebuild + ELB warmup；Prime Day predictive — pre-scaling 30-77% 年增率提前算進容量。

不可水平擴容服務的容量規劃

部分服務不能用「加機器」解決容量問題。這類服務的容量規劃有獨立邏輯。

典型不可水平擴：

• consensus DB（RAFT / Paxos）：節點數量是 consensus 一部分、不能臨時增減
• single leader DB（PostgreSQL primary、MySQL master）：寫只有一個 leader
• 中央 coordinator：必須拆解才可擴

容量公式變成：單機極限 × headroom、沒有 elastic 救援。 設計重點：

• 預先 provision 到能撐 peak、不依賴 reactive 擴
• 垂直擴容（更大 instance）為主、不是橫向
• 留更高 headroom（80%+）、出事沒有第二招

對應案例：Coinbase pre-provision — RAFT 限制下完全 pre-provision、不 autoscale；Spanner 節點即容量單位 — 雖然全球可擴、但每個 region 內節點數要預先規劃。

跨地理 / 跨 region 容量規劃

跨 region 服務不能用 全球總量 平攤、每個 region 獨立規劃。

為什麼不能聚合：

• 用戶在哪、流量就在哪、不會自動 spread
• 跨 region 切流量有延遲（DNS TTL、用戶習慣）、不能即時 rebalance
• 資料駐留合規可能強制各 region 獨立

規劃方法：

• 每個 region 抽各自的 workload model
• 各自跑 saturation discovery
• 各自訂 headroom（區域峰值 + 區域 AZ failover）
• 跨 region failover plan：哪個 region 掛了、流量去哪、目標 region 要留多少 headroom 接

對應案例：Standard Chartered 7 個受監管市場 — 跨市場獨立容量規劃；Genesys 15 region — 15 主 region + 5 衛星 region 各自規劃；Mercado Libre 18 國 — 每國獨立 cycle。

案例對照

下一步路由

• 上游：9.2 Workload Modeling / 9.4 Saturation Discovery
• 上游：9.13 擴展軸與 Stateless 前提（先選軸再算數量、不可水平擴容服務的判讀基底）
• 下游：9.7 成本邊界與 efficiency（容量翻成成本）
• 下游：9.11 高峰事件準備
• 跨模組：05 部署平台模組 autoscaler 實作

既建知識卡片

• Peak Forecast
• Headroom Budget
• Growth Curve
• Predictive Scaling
• Scheduled Scaling

成本工程的責任是讓容量決策有經濟邊界。沒有成本意識時、容量規劃會「保險起見全部擴」、最終帳單炸裂；有成本意識之後、能 在每一個容量決策點 把「多保險」跟「多省錢」一起評估。

跟 9.6 容量規劃模型 的關係：9.6 算「該訂多少容量」、9.7 算「這樣訂值不值得」。兩者必須一起做、不能先決定容量再算成本。

本章從 cost per request 這個 unit economics 開始、推到 cost curve、TCO、降級成本、人力成本工程化、FinOps 整合。讀完後讀者能回答「容量設計的成本邊界在哪、什麼時候該降級而非擴容」。

Cost per request 模型

雲端帳單從月度視角看是黑箱、從 cost per request 視角看可拆解。

基本公式：月帳單總額 / 月總 RPS = cost per request。但這只是平均、不同 endpoint 成本差很大。 分 stage 拆解：app compute + DB read + DB write + cache + network egress + 第三方 API。每個 stage 自己有 unit cost。 分 endpoint 拆解：登入請求可能 $0.0001、結帳請求可能 $0.001（10x 差距）。原因：結帳走更多 stage、可能跨 region、可能呼叫第三方支付。

對齊業務 metric：

• cost per active user：總成本 / MAU
• cost per transaction：總成本 / 完成的訂單數
• cost per ML inference：總成本 / inference 次數

業務 metric 級別的 cost 才能跟收入對比、才能算 unit economics。

對應案例：Zomato 50% 成本下降 — 算出每筆計費事件的 cost per request 後、發現 TiDB over-provision 拖累、遷移 DynamoDB 後減半；Netflix Aurora 28% 成本降 — DB consolidation 把多套 DB 的 cost 統一到 Aurora、Aurora 自己的 cost per request 更便宜。

詳見 Cost Per Request 卡片。

Cost curve 形狀

不同 pricing 模式的 cost curve 形狀不同、組合起來才能最佳化。

On-demand（pay-per-use）：流量上升、成本同步上升。線性 cost curve。優點：彈性、不用承諾；缺點：單位成本最貴。 Reserved instances（RI）/ Savings Plans：承諾 1-3 年用量、單位成本降 30-60%。階梯 cost curve。優點：便宜；缺點：承諾期內如果用量低、浪費。 Spot instances：用 cloud 閒置 capacity、單位成本降 70-90%。可被中斷。優點：最便宜；缺點：可能突然被收回。

最佳組合通常是「Reserved baseline + On-demand spike + Spot batch」：

• Reserved 覆蓋 baseline 容量（永遠用得到）
• On-demand 處理 peak 跟 unpredicted burst
• Spot 跑 batch 工作（不在 critical path、可被中斷）

對應案例：Riot Games 年省 1000 萬 — 從自管 Mesos 遷到 EKS、降的不只是 instance cost、是 cluster 管理人力 + ops 簡化；Capcom 30% 成本下降 — DynamoDB + EKS 取代自管、釋放 DBA 人力。

Over-provisioning vs under-provisioning 取捨

容量決策的核心經濟學問題：訂多大容量才是最划算？

Over-provisioning 成本：每月多付 $X 雲端費。這個數字直接看帳單。 Under-provisioning 成本：sigma 機率 × downtime × revenue per minute。這個數字更難算 — 需要 historical incident rate + downtime impact analysis。

兩個成本平衡點 = 經濟最佳 headroom。但實務上 under-provisioning 成本不容易量化、保守做法是把 sigma 機率拉高（用 worst-case 估）、headroom 訂寬一點。

Critical workload（金融、醫療、付款）：under-provisioning 成本極高（合約違約 + 客戶流失 + 法規）、寧可 over-provisioning 30-50%。 Non-critical workload（內部工具、分析、batch）：under-provisioning 成本低、可以更貼近 minimum capacity。

對應案例：Zomato TiDB 必須 over-provision — 為了應付 spike、TiDB 必須長期 over-provision；DynamoDB on-demand 不必、pay-per-use 自然處理。

降級的成本邊界

「降級 vs 擴容」是常見容量決策、但常被當成「技術問題」而非「成本問題」。

降級不是免費：

• 流失轉換：UI 顯示「系統忙碌」、用戶可能放棄
• 客訴成本：客服處理客訴的 OpEx
• 品牌損失：社群媒體負面評論、口碑下降
• 合約違約：B2B 客戶可能基於 SLA 求償

算「降級 vs 擴容」哪個成本低：

• 擴容成本：peak 時段多付的 cloud 費用
• 降級成本：上述四項合計
• 哪邊低就選哪邊

降級觸發條件通常按負載門檻 / 成本門檻 / SLA 觸發：

• 負載門檻：utilization > 85% → 啟動降級
• 成本門檻：本月雲端費已超預算 X% → 啟動降級
• SLA 觸發：error budget 快用完 → 啟動降級保 SLA

對應案例：Pokemon GO 50x surge — surge 期間無法等比擴容、必須降級保住核心遊戲機制、犧牲附加功能。

人力成本工程化

雲端帳單是顯性成本、但 人力成本 是常被忽略的隱性容量成本。

自建 vs managed 的人力成本對比：

• 自建 Kafka / PostgreSQL / Redis：需要 DBA / SRE 持續維護 + 升級 + 故障處理
• Managed 服務（MSK、Aurora、ElastiCache）：vendor 負責 patch、backup、failover
• 差距通常 3-10 倍 人力成本

DBA / SRE / network engineer 都是隱性容量成本：

• 一個資深 DBA 在美國年薪 $200K+、台灣 NTD 200-400 萬
• 工程師時間是有上限的、自管系統佔的時間就是 無法投入產品開發 的機會成本

「90% 工程工時下降」是管理 ROI 的關鍵：重點是把工程資源從 維持 轉移到 建構、不是拿來吹噓技術。這條自建 vs managed 的人力成本對比、是 0.22 能力級買 vs 建 裡「計費隨規模成長、自建 TCO 出現交叉點」那條 tripwire 的算法側 — 選型方向在 0.22 判、成本量化在這裡做。

對應案例：Spotify Kafka → Pub/Sub — 不是因為 Pub/Sub 便宜、是因為 Spotify 規模下自管 Kafka 的人力成本不划算；Lemino 90% 工程工時降 — managed 路線讓電信商級新串流服務只用 5-10 個工程師 launch；Capcom DBA 釋放 — 把 DBA 時間從 patching 轉到遊戲品質。

FinOps 跟容量規劃的整合

FinOps 是 財務跟工程的協作框架、把成本決策從事後對帳變成事前規劃。

Showback / chargeback：把雲端成本攤到團隊 / 服務 / feature。每個團隊看得到自己的成本、自然開始 optimize。chargeback（實際扣預算）比 showback（純展示）更有效但組織複雜度高。

每月 cost review 變成容量 review 的一部分：

• 對比預算 vs 實際
• 找出 top 5 cost driver
• 對比上月趨勢、看是否有 anomaly
• 跟 capacity team 一起討論 right-sizing

Spot diversification：spot 中斷風險可以靠 多 instance type 跟多 AZ 分散。例如：spot pool 同時包含 m5.large + m5a.large + m5n.large、各 AZ 都有、單一 type pool 撤回時其他 type 還在。

Right-sizing：定期 review instance type 是否最適。常見浪費：訂太大 instance（CPU / RAM 用 30%）、過時 instance generation（用 c5 沒升到 c7）、reserved 過剩。

反模式

容量成本的常見錯誤模式：

Autoscaling max 設無限大：流量爆衝時 autoscaler 跟著爆衝、月底帳單炸裂。max 必須訂、是 financial circuit breaker。

全部用 on-demand、沒談 reserved / savings plan：cloud spending > $10K/月 已經值得跟雲商 talk discount、savings plan 通常 30-60% off。

沒成本 monitoring、直到帳單來才知道：要建 daily cost dashboard、anomaly 即時 alert、不要等月帳單。

降級用人工觸發、出事時來不及：降級邏輯要 自動化、按 metric 觸發、不是 oncall 工程師看到 dashboard 才下指令。

忘了人力成本：算 build vs buy 只算 cloud 費、忘了 SRE / DBA 時間、結果發現「省的 cloud 費 < 多花的人力」。

案例對照

下一步路由

• 上游：9.6 容量規劃模型
• 下游：9.8 效能可觀測性（cost attribution）
• 跨模組：04.14 cost attribution

既建知識卡片

• Cost Per Request
• Headroom Budget

效能可觀測性的責任是讓容量決策有訊號基礎。沒有適當訊號時、就算有壓測結果跟容量計畫、也看不到「現在實際距離 saturation 多遠」、無法做即時調整。

跟 9.4 Saturation Discovery 的關係：9.4 找到 saturation 點、9.8 定義持續監控這個點的訊號跟 dashboard。跟 04 可觀測性模組 是 sibling — 04 處理通用觀測、9.8 處理 容量規劃用 的觀測。

本章不重複 04 的訊號治理基礎、聚焦在 容量 / 效能 / 成本三條觀測線怎麼整合。讀完後讀者能設計一個「容量 dashboard」、回答「現在距離 saturation 還有多遠、什麼時候該擴」。

USE method 在 production 持續監控

USE method 不只是壓測時用、production 也要持續監控。

對每個資源（CPU / RAM / disk / network / DB connection / cache pool / file descriptor）量三個維度：

• Utilization（使用率 0-100%）：直觀但會誤判
• Saturation（queue depth）：早期警訊
• Errors（資源層錯誤）：已經出事的訊號

為什麼不能只看 utilization：

• CPU 100% 但 run queue 空 → 還能撐（單純 CPU bound）
• CPU 80% 但 run queue 不斷增長 → 已 saturate（saturation 比 utilization 領先）

Saturation metric 是 capacity warning 的最早訊號：

• queue depth（每個 queue / pool）
• connection pool 使用率（最常見隱性 bottleneck）
• thread pool / coroutine count
• event loop lag（Node.js、async runtime）
• GC pause time / frequency
• cache hit rate / eviction rate
• replication lag

Dashboard 設計：每個關鍵資源獨立 panel、同時顯示 utilization 跟 saturation。alert 在 saturation 起飛 時觸發、不是 utilization 滿。

對應案例：Lemino connection limit — connection saturation 是 RDB 的真正 bottleneck、不是 CPU；Zomato latency 降 90% — 從 TiDB 換到 DynamoDB、saturation 行為完全不同、observability 也要跟著改。

RED method：請求層的容量訊號

RED method 跟 USE 互補、從請求層看容量。

• Rate：requests per second（每個 service / endpoint）
• Errors：error rate
• Duration：latency distribution（histogram、不是單一 percentile）

Duration 比 Errors 早：duration p99 飆通常先於 error rate 上升、是 saturation 的早期警訊。

每個 endpoint 都要有 RED：不能只看全站 average、要分 endpoint。登入 endpoint 跟結帳 endpoint 的 saturation 行為不同、混在一起看不到 issue。

Histogram 是必須、不是 nice-to-have：

• 只記 p99 → 看不到 p999、看不到 distribution shape
• 記 histogram → 可以隨時算任何 percentile、可以做 long-tail 分析
• Prometheus histogram、OpenMetrics histogram 是現代標準

對應案例：GR8 Tech 25ms p95 — p95 是業務 KPI、不是技術指標、每個 endpoint 都有獨立 SLO。

p50 / p95 / p99 / p999 的取捨

不同 percentile 反映不同問題、選錯 percentile 會錯失 issue。

• p50（中位數）：整體狀況、感覺正常的指標、對長尾不敏感
• p95：日常 user-perceived experience、大多數用戶感受到的延遲
• p99：minority but critical 用戶體驗、SLO 常訂在這
• p999：極端長尾、受 GC pause / leader election / retry storm 影響、internal critical 系統訂在這

業務 SLO 通常訂 p99：「99% 用戶 request < 500ms」是常見承諾、合約 SLA 也通常基於 p99。 Internal critical 系統訂 p99.9：金融交易、即時配對、客服 SaaS（5 個 9 可用性對應 5 個 9 latency 期待）。

紀錄分布、不只紀錄 percentile：

• gauge p99 → 看不到 distribution shape、看不到 multimodal 分布
• histogram → 可以重新計算任何 percentile、可以對比 distribution、可以找 anomaly

對應案例：Tubi p99 < 10ms — ML inference 在 p99 才能控制用戶體驗、p50 沒意義；Coinbase sub-ms — 必須關注 p999、RAFT 系統長尾顯著。

詳見 Tail Latency 卡片。

Cost dashboard

成本訊號跟容量訊號要 並列顯示、不要分開看。

Per-service / per-endpoint cost attribution：

• 每個 service 自己的雲端成本
• 拆到每個 endpoint
• 跟 RPS / latency 並列、看「成本上升是因為流量還是低效」

Cost per request 的時序變化：

• 突然上升通常是 退化 訊號（新版本沒效率）
• 緩慢上升通常是 規模 訊號（用戶增加但 efficiency 沒變）

成本異常告警（vs 容量異常告警）：

• 容量告警：utilization > X% → 擴容
• 成本告警：cost spike > X% → review
• 兩者可能同時觸發（autoscaler 擴容也擴 cost）、要區分

跟業務 metric 對齊：cost per active user、cost per transaction、cost per ML inference。業務 metric 級別的 cost 才能 review unit economics。

對應案例：Lyft 100+ 微服務各自 cost — 微服務粒度的 cost attribution、找出哪個 service 過貴；對應 04.14 cost attribution。

Continuous profiling

Continuous profiling 是現代效能 observability 的關鍵環節 — production 持續取 profile（CPU / heap / lock）、隨時可以做 diff 跟 root cause。

工具生態：

• Datadog Continuous Profiler、Pyroscope（開源 + Grafana 整合）、Parca（CNCF）
• GCP Cloud Profiler、Azure Application Insights Profiler、AWS CodeGuru Profiler
• Overhead 通常 < 1% CPU、放心開在 production

跟 distributed tracing 整合：trace → span → profile。一個 slow request 點下去、能看到對應 span、再下去看 profile。

Profile diff 是 release gate 的核心訊號：每次 deploy 後自動對比 baseline、退化幅度過門檻 trigger alert。詳見 9.9 Improvement Loop 跟 Profile Diff 卡片。

對應案例：Netflix 多 DB 統一後 profile 變單純 — DB 統一 → application 層 profile 噪音降低 → 退化定位更快。

Cardinality cost governance

效能 observability 的成本經常爆炸、源頭通常是 high cardinality metric。

高 cardinality 來源：

• per-user metric（user_id label）
• per-request metric（request_id label）
• per-trace metric（trace_id label）

為什麼會爆：Prometheus 等 metric system 為每個 label 組合存獨立 time series、cardinality = 所有 label value 的笛卡爾積。100 萬 user × 100 endpoint × 10 region = 10 億 time series、儲存爆炸。

對策：

• high cardinality 資訊放 log / trace、不放 metric
• metric label 限制在 low-cardinality 維度（service、endpoint、region、status）
• 真的需要 high-cardinality 分析、用 sampled trace + log query

對應 04.10 cardinality cost governance、跟 Metric Cardinality 卡片。

訊號跟 SLO 對接

最後一層整合：每個 saturation metric 都要對應一個 SLO threshold、訊號驅動行動。

訊號 → 行動鏈：

• saturation metric 超 threshold → trigger alert
• alert 觸發 → trigger autoscaler / runbook / oncall
• 持續超 threshold → trigger error budget burn alert
• error budget 用完 → trigger release freeze

Alert 不要太敏感：

• false positive 浪費 oncall、長期會 alert fatigue（Alert Fatigue 卡片）
• 用 multi-window multi-burn-rate alert（Google SRE 推薦）
• 用 symptom-based alert（業務影響）而非 cause-based alert（單一資源）

跟 9.12 SLO 與 Performance Budget 直接對接。

案例對照

下一步路由

• 上游：9.4 Saturation Discovery / 9.5 瓶頸定位流程
• 下游：9.12 SLO 與 Performance Budget
• 跨模組：04 可觀測性模組（基礎訊號）

既建知識卡片

• USE Method
• RED Method
• Tail Latency
• Continuous Profiling
• Cost Per Request

Improvement loop 的責任是把效能優化從「事件型 hotfix」變成「持續改進的工程流程」。沒有 loop 時、效能問題靠 oncall 觸發、改了又改、改完又退化；有 loop 之後、每次 release 都通過 perf gate、退化在發布前就攔住。

跟 06.13 perf regression gate 的關係：06.13 是 release gate 的一個環節、9.9 是這個 gate 背後的完整工程閉環。06.13 處理「進 gate 後怎麼判斷」、9.9 處理「進 gate 前怎麼產生比較資料」。

本章聚焦在 閉環設計 — 怎麼建 baseline、怎麼跑 re-test、怎麼用 profile diff、怎麼整合 CI。讀完後讀者能設計一個 perf improvement workflow、不是只有 ad-hoc 壓測。

Loop 五個階段

完整的 improvement loop 包含五個階段、缺一不可：

1. Baseline 建立：壓測 + profile 取得「當前正常」snapshot。 2. 變更 + re-test：每次 release candidate 跑壓測、跟 baseline diff。 3. Profile diff：用 flame graph diff 定位退化原因。 4. Fix：rollback 或修正 code path。 5. Update baseline：通過後更新 baseline、進下個 cycle。

少了 baseline → re-test 沒有比較對象、看絕對數字會錯判。 少了 profile diff → 退化定位靠猜、修錯方向。 少了 update baseline → 永遠跟 old baseline 比、退化累積看不出來。 少了 fix → 退化通過 gate、production 出事。

Baseline 設計

Baseline 不是「歷史最佳」、是「最低可接受效能」。

設計原則：

• 不只一個 baseline、按 workload model 訂多個（不同 endpoint、不同 user tier 各自 baseline）
• baseline 必須可重複：固定 seed、固定資料集、固定環境、固定壓測參數
• 定期 review：硬體 / 軟體升級會讓 baseline 該往好的方向走、不更新就是裝盲

儲存策略：

• baseline as artifact：存進 release artifact、隨 release 帶走
• baseline as code：用 Pulumi / Terraform / dedicated config 管理、可 version control
• baseline as service：dedicated service 管 baseline、提供 query API

Drift 監控：baseline 每月對比上月、看趨勢是否往好方向。drift 超門檻 → re-baseline 並 review 原因。

Profile diff

退化定位的關鍵工具是 profile diff — 對比兩次 profile 找 hottest 變化。

工具實作：

• Brendan Gregg 的 differential flame graph：開源、需要手動 generate
• Pyroscope diff：UI 直接對比兩個時間段
• Datadog Continuous Profiler diff：跟 deployment marker 整合
• Parca compare：CNCF 標準
• AWS CodeGuru Profiler：自動偵測 CPU / memory anti-pattern

正確使用方法：

• 在 相同負載 + 相同硬體 + 相同 sampling rate 下取兩次 profile
• 比較 相對變化、不是絕對 CPU%
• 看 wider stack（不只看 leaf function）找 systemic regression

Profile diff 結果通常需要工程師判讀：「多花 20% CPU 但 throughput 多 50%」可能是好變化、不能純自動化判斷退化是否可接受。

對應案例：Netflix Aurora 統一 — DB 層統一後 profile diff 噪音降低、退化來源更容易識別。

Regression gate 整合 CI

效能改進閉環必須整合到 CI、不能只在 release 前一次性跑。

Multi-tier 壓測策略：

• 每個 PR：跑 lightweight perf test（單 endpoint、5 分鐘）、合併前比 baseline
• 主分支 nightly：跑 medium perf test（多 endpoint、30 分鐘）
• Release candidate：跑 complete perf test（完整 workload model、數小時）

Gate 觸發條件：

• p99 退化 > X%（例如 10%）
• 吞吐降 > Y%（例如 5%）
• error rate 升 > Z%
• cost per request 升 > W%

Gate 通過 / 不通過的後果：

• 通過：自動 promote 到下個 stage（staging / canary / production）
• 不通過：block release、自動 notify owner、附 profile diff link

Gate 太敏感的反模式：

• 每天 false positive、最後沒人看（alert fatigue）
• false positive 來源：壓測環境噪音、baseline drift 未更新、業務變化
• 對策：multi-window detection（變化必須持續 N 個 sample）、配合 manual override（資深工程師判斷異常正常）

對應案例：06.13 perf regression gate 的實作建議。

Canary perf check

Canary perf check 是 release 階段的另一道 perf gate。跟 regression gate（pre-release）對應、是 production 階段的監控。

Canary 階段除了看 error rate、也看：

• latency p99 / p999（最先看到的 regression 訊號）
• throughput（是否處理變慢）
• resource utilization（CPU / RAM / connection 變化）
• cost per request（是否更貴）

Canary 流量 vs control 流量比較：

• 同樣流量同樣時段、不同版本的差才有意義
• 不能拿 canary 跟 historical baseline 比（外部變數太多）
• abort condition：canary p99 比 control 退化 > X%

漸進放大策略：1% → 5% → 25% → 50% → 100%、每階段觀察足夠時間（至少 15 分鐘看 long-tail）。

對應案例：Prime Day FIS 8x chaos — canary 模式跟 chaos test 並行、確保新版本在故障場景也撐得住。

Pre-release 改進迴圈頻率

不同層級的 review 在不同節奏：

• 每日 PR 級 perf check：lightweight、單 endpoint、5 分鐘
• 每週 release candidate 完整壓測：完整 workload model、數小時
• 每月 baseline review + drift 評估：對比歷史趨勢、決定是否 re-baseline
• 每季容量地圖 review：跟 9.6 容量規劃模型 連動

頻率不夠 → 退化累積看不到；頻率太高 → 工程資源吃緊。按團隊規模跟 release 節奏調整。

退化的常見來源

知道退化怎麼來、才能設計對應的 detection：

• 新功能引入 N+1 query：ORM lazy loading、loop 內 query。看 DB call count 變化
• ORM 沒下 index、cache miss 飆升：看 slow query 跟 cache hit rate
• 第三方 library upgrade 帶來 overhead：新版本可能多了 telemetry / validation。看 profile diff
• GC tuning 變動：JVM / Go GC config 調整造成 pause time 變化。看 p999
• container resource limit 變動：Kubernetes limit 改、限制更嚴造成 throttling。看 CPU throttling event

反模式

• 只在 release 前一次性壓測：退化已累積數月、找不出原因
• baseline 不更新：永遠跟舊版本比、低估目前狀態
• 改了又改、改完忘記更新 baseline：下次 release 又跟過時 baseline 比、迴圈失效
• 缺 profile diff、退化原因靠猜：修錯方向、退化還在
• gate 訊號跟業務無關：技術指標退化但業務 metric 沒事、被當 false positive

案例對照

下一步路由

• 上游：9.4 Saturation Discovery / 9.5 瓶頸定位
• 下游：9.10 Production-Side 驗證
• 跨模組：06.13 perf regression gate / 06.8 release gate

既建知識卡片

• Profile Diff
• Continuous Profiling
• Canary Perf Check

Production-side 驗證的責任是回答「staging 過了 production 一定過嗎」。多數 staging 環境的硬體 / 流量 / 資料 / 第三方依賴都跟 production 不一樣、staging 通過不代表 production 安全。本章處理「在 production 安全驗證新配置」的工程做法。

跟 06.20 experiment safety boundary 的關係：06.20 走「故障注入」的安全邊界（chaos）、9.10 走「正常負載」的 production 驗證（perf）。兩者方法論類似、目標完全不同。chaos test 是「主動破壞看會不會出事」、production perf validation 是「真實流量看新版本能不能跑」。

本章四個工具（shadow traffic、dark launch、canary、production-like load test）按 blast radius 從小到大排列、每個適合不同驗證場景。

Shadow traffic

Shadow traffic 是 blast radius 最小的工具：複製 production traffic 到新版本、但 不把結果返回用戶。

運作機制：

• 用戶看到的還是舊版本回應、體驗不變
• 新版本只是「並行跑、看會不會崩」
• 新版本的結果可以跟舊版本對比、找出邏輯差異
• 對下游的寫入要 特別處理：要麼寫入 sandbox、要麼 dry-run（純驗證 query plan、不真寫）

工具實作：

• GoReplay：tcpdump-based 開源、適合 HTTP
• Service mesh shadow（Istio、Linkerd mirror）：mesh 層 mirror、零 application invasion
• AWS VPC Traffic Mirroring：底層網路層、加密 traffic 要另處理
• Diffy（已 deprecated 但概念有效）：dual-write 對比結果

適合場景：架構大改、想驗證 是否能撐 production traffic 但不能影響用戶。例如「DB 從 PostgreSQL 換 Aurora、想看新 DB 在真實 query pattern 下穩不穩」。

注意事項：

• shadow traffic 也消耗 production 下游資源（DB read、API call）— 必須算進容量
• 加密 / PII 資料需要處理
• shadow 通常跑 1-7 天看 long-tail、不是 30 分鐘就下結論

對應案例：Tixcraft 10K t2.micro 壓測 — pre-event 壓測但走 staging；real shadow 則是 production-traffic-driven 而非合成。

Dark launch

Dark launch 介於 shadow 跟 canary 之間：程式碼上線、走 production traffic、但 UI 入口暫不開放。

跟 shadow 的差別：

• Shadow：traffic 複製、新版本 不寫入真實狀態
• Dark launch：真實寫入 production、但用戶看不到 UI

運作機制：

• 後端 code 部署到 production
• 用 feature flag 控制 UI 暴露
• 從內部 API、cron job、employee-only access 觸發新功能
• 真正寫入 production DB / cache / queue
• 用戶看不到 UI 入口、無感

Exit criteria：

• 跑足夠時間（通常 1-2 週）
• 內部使用沒有 critical issue
• metric 在預期範圍

適合場景：新功能後端風險高、想 production-validate 再開放給用戶。 不適合：純 UI 改動（沒有後端風險、直接 canary）。

對應案例：SeatGeek Virtual Waiting Room 從第三方換到自建、必然有 dark launch 階段驗證 token 配發機制、再正式 cutover。

Canary

Canary 是 production-side 驗證最常用工具：小比例流量導到新版本、跟舊版本對比。

運作機制：

• 小比例（1% / 5% / 10%）流量導到新版本
• 大部分流量（99% / 95% / 90%）走舊版本
• 比較 perf / error / business metric
• 通過 → 漸進放大；不通過 → 自動 rollback

漸進放大策略：1% → 5% → 25% → 50% → 100%、每階段觀察足夠時間（至少 15 分鐘看 long-tail）。

自動 rollback 條件：

• error rate canary 比 control 高 X%（例如 50%）
• p99 latency canary 比 control 退化 X%（例如 10%）
• business metric（conversion rate）canary 比 control 低 X%

Canary perf check 跟一般 canary 的差異：

• 一般 canary：看 error rate 為主
• Canary perf check：看 latency / throughput / cost、退化通常早於 error rate

比較的對象是 control（同時跑的舊版本）、不是 baseline：同樣流量同樣時段才能對比、不能拿 canary 跟昨天 baseline 比（外部變數太多）。

對應案例：Prime Day pre-event 驗證 / FanDuel canary across 20 州 — 按 region 漸進放大、控制 blast radius。

Production-like load test

當需要驗證 peak 場景 但 production 平日流量達不到時、在 production 跑額外的 synthetic load。

為什麼要在 production 跑：

• staging 環境的硬體 / 網路 / 第三方依賴跟 production 不同
• staging 沒有 production 級資料量、cache hit pattern 不一樣
• 只有 production 才能驗證真實 peak

風險高、必須有安全邊界：

• blast radius 限制（用 dedicated test endpoint、限制影響範圍）
• abort condition（什麼訊號觸發停止）
• rollback path（rollback 流程跟時間）
• 通訊（相關 oncall 通知、避免誤判 incident）

通常用在：

• Pre-event 壓測（Black Friday、Super Bowl、IPL 決賽 前一週）
• 重大架構變更後驗證
• 容量規劃 review（每年 / 每季）

跟 06.20 experiment safety boundary 同等嚴格的安全要求：production 壓測本質是 controlled experiment、必須有 game day-level 的計畫跟人員。

對應案例：Prime Day FIS 8x chaos — 把 chaos test 跟 load test 結合、production-like 驗證；Tixcraft 10K t2.micro 壓測 — pre-event 大規模壓測模擬實際售票場景。

A/B test 與 perf 對齊

Product A/B test（測試新功能對 conversion 的影響）同時也是 perf A/B test。

為什麼要對齊：

• 新 feature 可能帶來 perf 退化（多 query、多 component、額外 logic）
• 純看 conversion lift 會誤判：「conversion 上升、所以 OK」可能掩蓋「但 p99 上升 30%」
• A/B 同時看 conversion 跟 perf 兩個 metric

Guardrails：

• 業務 metric 改善 + perf 退化 → 工程判斷是否值得（trade-off review）
• 業務 metric 沒改善 + perf 退化 → 直接 reject
• 業務 metric 改善 + perf 改善 → 直接 ship
• 業務 metric 退化 → 不論 perf 怎樣、reject

對應 06.20 experiment safety boundary 的 experiment guardrails。

Pre-event readiness check（game day）

大事件前跑「全系統 production-like 壓測」、是 production-side 驗證的整合演練。

跟 9.11 高峰事件準備 直接對接 — game day 是 readiness 流程的一個 stage。

Shopify game day、Stripe game day 是業界範本（06 cases 有完整案例）。

安全邊界設計

任何 production-side 驗證都要有清楚的安全邊界、不能臨機應變。

Blast radius：

• 影響哪些用戶（X% 流量、特定 cohort、特定 region）
• 影響哪些 service（受 perf 影響的下游）
• 影響哪些 metric（哪些 business metric 可能變化）

Abort condition：

• 什麼訊號觸發停止（error rate > X%、latency > Y ms、特定 alert 觸發）
• 由誰觸發（自動 vs oncall 手動）
• 觸發後多久內必須完成 abort（< 60 秒）

Rollback path：

• rollback 流程是什麼（feature flag、deployment rollback、traffic shift）
• rollback 需要多久（target < 5 分鐘）
• rollback 是否需要 data 處理（已寫入的資料怎麼處理）

通訊：

• 啟動驗證前 notify 哪些 channel
• 期間 oncall 待命
• 結束後 retro

反模式

• Canary 比例太大（50% 起跳）：出事影響大、blast radius 失控
• 沒 control group：不知道 baseline、看絕對數字會誤判
• Canary 跑太短時間（< 15 分鐘）：看不到 long-tail、看不到 user pattern shift
• 沒 abort condition：人工監控失誤就出事、不可預測
• shadow traffic 寫入真實狀態：可能造成 double charge、duplicate notification
• production load test 沒 notify 相關團隊：被當成 incident、誤觸 escalation

案例對照

下一步路由

• 上游：9.9 Improvement Loop
• 下游：9.11 高峰事件準備
• 跨模組：06.20 experiment safety boundary / 06.4 chaos testing

既建知識卡片

• Shadow Traffic
• Dark Launch
• Canary Perf Check

單機 Middleware 實作

Rate limit middleware 在 HTTP handler 之前攔截請求。每個 request 過一次 limiter，通過就進入 handler，超限就回 429。

Go 實作

Go 標準生態的 golang.org/x/time/rate 提供 token bucket 的 rate.Limiter。

 1import "golang.org/x/time/rate"
 2
 3// 全域 limiter：每秒 100 個 request、burst 上限 200
 4var globalLimiter = rate.NewLimiter(100, 200)
 5
 6func rateLimitMiddleware(next http.Handler) http.Handler {
 7    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
 8        if !globalLimiter.Allow() {
 9            w.Header().Set("Retry-After", "1")
10            http.Error(w, "Too Many Requests", http.StatusTooManyRequests)
11            return
12        }
13        next.ServeHTTP(w, r)
14    })
15}

Per-client 限速

全域 limiter 對所有 client 共用一個配額。Per-client 限速讓每個 client（by API key、IP、或 tenant ID）有各自的配額。

 1var clients sync.Map // map[string]*rate.Limiter
 2
 3func getClientLimiter(clientID string) *rate.Limiter {
 4    if limiter, ok := clients.Load(clientID); ok {
 5        return limiter.(*rate.Limiter)
 6    }
 7    limiter := rate.NewLimiter(10, 20) // 每 client 每秒 10 個
 8    clients.Store(clientID, limiter)
 9    return limiter
10}

Per-client limiter 用 sync.Map 存、首次出現的 client 自動建立 limiter。長期運行的服務需要定期清理不再活躍的 client limiter（用 goroutine + ticker 掃描最後使用時間）。

回應格式

超限時的 HTTP response 需要帶足夠資訊讓 client 做正確的重試決策。

1HTTP/1.1 429 Too Many Requests
2Retry-After: 1
3X-RateLimit-Limit: 100
4X-RateLimit-Remaining: 0
5X-RateLimit-Reset: 1719014400

Retry-After 告訴 client 等多久再試（秒數或 HTTP date）。X-RateLimit-* headers 不是 RFC 標準但被廣泛使用（GitHub API、Stripe API 都用），讓 client 在被限速前就知道剩餘配額。

分散式限速（Redis-backed）

單機 limiter 的計數存在 process 記憶體中。多個 server instance 各自有獨立的 limiter，client 的請求被 load balancer 分配到不同 instance 時，每個 instance 只看到部分請求 — 全域限速失效。

Redis 做共用的計數儲存，所有 instance 查同一個 counter。

Sliding Window Counter

用 Redis 的 INCR + EXPIRE 實作 sliding window counter。

 1-- Redis Lua script（原子操作）
 2local key = KEYS[1]
 3local limit = tonumber(ARGV[1])
 4local window = tonumber(ARGV[2])
 5
 6local current = redis.call('INCR', key)
 7if current == 1 then
 8    redis.call('EXPIRE', key, window)
 9end
10
11if current > limit then
12    return 0  -- 超限
13end
14return 1      -- 通過

Key 的設計：ratelimit:{client_id}:{endpoint}:{window_start}。Window start 用當前時間截斷到秒或分鐘（如 1719014400），每個窗口一個 key，EXPIRE 自動清理過期窗口。

現成套件

自己寫 Lua script 適合學習，production 用現成套件更可靠：

配額設計

差異化配額

不同的 endpoint 和 client 有不同的配額需求。搜尋 API 比列表 API 消耗更多計算資源，應該有更低的速率上限。

配額溢出的處理

超限時的處理策略依業務需求決定：

Reject（429）：直接拒絕。最簡單，適合 API 服務。Client 收到 429 後按 Retry-After 重試。

Queue（排隊等）：超限的請求進入等待隊列，按順序處理。適合不能丟棄的操作（付款確認、訂單建立）。代價是 client 端等待時間增加。

Degrade（降級回應）：超限時回傳簡化版的回應（cached 結果、摘要而非完整資料）。適合讀取操作。

和 Monitoring 的整合

Rate limit 的命中事件應該記入監控系統，讓團隊知道哪些 client 在撞限速、哪些 endpoint 的配額是否合理。

1// Rate limit hit 時送 metric 事件
2monitor.Metric("ratelimit.hit", map[string]any{
3    "client_id": clientID,
4    "endpoint":  r.URL.Path,
5    "limit":     100,
6    "window":    "1m",
7})

Dashboard 視圖：rate limit hit 的時間趨勢 + 按 client 和 endpoint 分群。Hit 數持續上升代表配額設太低（正常使用被限速）或某個 client 在濫用。

下一步路由

• Rate limit 的概念基礎 → DevOps 流量管控 — Rate Limiting
• 背壓機制（被動的流量控制）→ DevOps 背壓機制
• Rate limit 知識卡 → Rate Limit
• 監控系統中的 ingestion 限速 → Monitoring Ingestion Scaling

高峰事件準備的責任是把「事件臨頭才動手」變成「事前數週流程化準備」。沒有 readiness 流程時、年度活動靠 oncall 撐、出事率高；有流程之後、活動成「routine event」、工程資源穩定釋放。

本章 是 9.10 Production-Side 驗證 跟 9.6 容量規劃模型 在「事件型場景」的應用組合、不重新建立方法論。要看具體方法回到那兩章、本章聚焦在 流程整合。

讀完後讀者能設計一個 T-90 → T-0 的事件準備時程、回答「Black Friday 該怎麼準備、Super Bowl 該怎麼準備、新片發布該怎麼準備」。

事件分類：五種負載形狀

不同事件對應不同準備強度、第一步要分類。

可預期極端峰值：年度活動、預售、賽事決賽。提前數月已知時間、業務影響大。例：Prime Day、Black Friday、Super Bowl、IPL 決賽。 事件型不可預期峰值：賽事高潮、突發新聞、KOL 推廣。時間或大小不完全可預測。例：賽事進球瞬間、KOL 帶貨、突發新聞引發的流量。 Flash-sale 瞬間爆量：售票開賣、報名活動、限量搶購。t=0 瞬間爆量、5-30 分鐘結束。例：演唱會售票、限量商品搶購、報名截止前最後一小時。 產品爆紅 surge：新 app 紅、病毒擴散。完全不可預期、流量會隨熱度消退。例：Pokemon GO、ChatGPT 爆紅初期、TikTok challenge。 結構性 surge：COVID 類外部衝擊、永久 baseline 上移。不會回到舊水準。例：COVID 期間遠距工作工具、烏俄戰爭期間能源類 app。

對應案例：9.C1 / 9.C13 / 9.C21 / 9.C27 / 9.C29（predictable）/ 9.C2 / 9.C4 / 9.C7 / 9.C28（event）/ 9.C15 / 9.C16 / 9.C17（flash-sale）/ 9.C8 / 9.C18（surge）。

T-90 → T-0 準備時程

可預期極端峰值的完整準備時程：

T-90 天：流量 forecast + 容量計畫敲定。確認預期峰值倍數、確認 headroom 比例、確認跨 region / AZ 分布。產出 容量計畫文件。

T-30 天：基礎設施 quota 申請。雲端 instance limit、connection pool、API rate limit、DynamoDB throughput、Lambda concurrency 都要 提前申請、不能事件當天才發現 quota 不夠。AWS Infrastructure Event Management（IEM）等服務在這階段啟動。

T-14 天：第一輪 production-like 壓測。驗證容量計畫是否真的能撐預期峰值、找出第一輪 bottleneck。

T-7 天：完整 game day 演練。注入故障場景（DB failure、AZ outage、第三方 quota 耗盡）、驗證降級、failover、rollback 流程。修正最後問題、更新 runbook。

T-2 天：pre-scaling 開始。CDN cache pre-warm、Lambda provisioned concurrency 啟動、autoscaler scheduled 開始、DB capacity 預先 scale up。避免事件當天還在 boot。

T-0 day：watch room 待命、runbook 開機可執行。所有相關 oncall 跨團隊聯合 channel、dashboard 集中、escalation path 清楚。

T+7 天：retro。對比預測 vs 實際、紀錄 incident 跟 near-miss、列下個事件要改的事。寫進 06 cases 或本模組 cases。

Pre-scaling 策略

T-2 階段的 pre-scaling 是「不依賴 autoscaler 反應」的容量保險。

Pre-scaling 涵蓋層次：

• ELB warm-up：請 AWS 預先 warm up ELB，避免流量上來時 ELB 自身需要時間擴容
• Lambda provisioned concurrency：預先 boot 一定數量 instance、避免 cold start
• DynamoDB / Cosmos DB capacity：scheduled 提前 scale up
• EC2 ASG：min instances 提前拉高
• CDN cache pre-warm：重要 URL 提前 invalidate / pre-populate
• DB connection pool：應用層提前 warm up connection
• Cache warmup：把 hot key 提前 populate 進 cache

Pre-warm window 通常 30 分鐘到 2 小時、取決於：

• Instance boot time（VM-based 慢、container 快）
• Cache warmup 時間（cold cache 命中率低、要時間 populate）
• Connection pool 預熱（DB connection establish 有 latency）

CDN Pre-warm 操作細節

CDN pre-warm 在 T-2 階段是 high-impact 操作、但跟其他 pre-scaling 的特性不同。具體做法：

• 找出活動會大量被讀取的 URL 清單：商品頁、活動 landing page、新 release 內容
• 在每個 CDN edge POP 觸發 cache populate：可以用 vendor warmup API（Cloudflare Argo、Fastly Image Optimizer pre-fetch、Akamai NetStorage push），或從多個 region 發 synthetic request 強制 edge 拉取
• 驗證 hit ratio 已升高：用 vendor dashboard 觀察 cache_status=HIT 比例、確認 pre-warm 生效
• 預估 origin 流量曲線：pre-warm 完成後、活動開始時 edge miss 流量應該大幅降低、origin 容量規劃可以對應放鬆

跟其他 pre-scaling 不同的是 CDN pre-warm 沒有「容量上限」這個概念 — edge cache 是被動填的、warm 完就是 warm、不像 EC2 / Lambda 那樣需要 reserve 容量。風險不在「填不夠」、在「填錯」（key 不對、TTL 設錯讓 pre-warm 立刻過期）。詳見 5.9 邊緣分發 的 purge 與 cacheable 判讀。

事件結束後也要 scheduled scale down：autoscaler 通常 scale up 快、scale down 慢、長期 over-provision 浪費錢。

對應案例：Tixcraft 30 分鐘擴 130 倍 — pre-scaling + Auto Scaling Group + AMI prebuild + ELB warmup 組合；Prime Day pre-scaling — predictive scaling + scheduled scaling 兩種組合。

詳見 Predictive Scaling 卡片 跟 Scheduled Scaling 卡片。

Watch room 設計

T-0 當天的指揮中心、跨團隊聯合 channel。

人員配置：

• 跨團隊聯合 channel：app / infra / network / SRE / business / customer support
• 24/7 輪班（國際事件可能跨 24 小時）
• 明確 incident commander（08.7 incident command roles）

Dashboard 集中：

• 流量 dashboard：總 RPS、按 region 拆分、按 endpoint 拆分
• 延遲 dashboard：p50 / p95 / p99 即時、按 service 拆分
• 錯誤 dashboard：error rate、按 endpoint、按 status code
• 成本 dashboard：當前 hourly cost、預估全天 cost
• 業務 dashboard：訂單數、轉換率、收入

Runbook 隨手可用：常見問題 → 對應動作的明確指引。不要事件當下還在 wiki 找資料。

Escalation path：什麼狀況找誰、多久升級。寫成決策樹、不要靠人記。對應 08.7 incident command roles。

對應 Game Day 卡片。

Vendor 緊急支援

戰略事件可以申請 vendor 工程師待命、是「人力 backup」。

AWS Infrastructure Event Management（IEM）：年度重大事件可以申請、提供 pre-scaling 與專屬監控通道。 GCP Customer Reliability Engineering（CRE）：戰略客戶的 24/7 工程支援、能即時為客戶補容量。 Azure Premier Support + CSAM：對等服務。

注意：這類服務通常綁定 enterprise 等級合約、不是所有客戶都能用。設計事件準備時要假設「沒有 vendor 救援」、vendor 是 bonus 而非 primary plan。

對應案例：GR8 Tech World Cup IEM — AWS Infrastructure Event Management 在 2022 FIFA World Cup 期間支援；Pokemon GO CRE — GCP CRE 即時補容量、撐過 50x surge。

Game day 演練

T-7 階段的核心活動、把 readiness 從計畫變實戰。

演練場景：

• 模擬「事件當天 worst case」
• 注入故障：DB primary failure、AZ outage、第三方 quota 達標、network partition
• 演練降級：哪些功能關閉、用戶看到什麼
• 演練 failover：流量切到備援
• 演練 rollback：發現新版本問題、能不能快速回退

Game day 學習目標：

• runbook 不夠詳細 → 補
• 訊號不夠 → 加 metric / alert
• 人員不夠 → 排班補
• 工具不夠 → 工程補

對應 06 cases Shopify game day — Shopify game day 是業界範本、值得直接參考。

Event tier 分級

不同事件規模對應不同準備強度、不能一律照 T-90 流程跑。

Regular event（每週 promo、small feature launch）：

• scheduled scaling 即可
• 無 dedicated watch room
• 對應 06.8 release gate 的常規 release

Major event（季度行銷、新功能發布）：

• pre-scaling + watch room
• 簡化版 T-14 → T-0 流程
• 跨 team coordination

Critical event（年度大促、Super Bowl、IPL）：

• 完整 T-90 流程
• vendor IEM + game day
• 24/7 watch room
• C-level visibility

對應案例：FanDuel regular game → playoff → Super Bowl 三 tier — NFL 賽季 baseline → playoffs 升 2-3x → championship 升 4-5x → Super Bowl 升 5-10x、每 tier 對應不同準備強度。

事後 retro

T+7 retro 是讓 readiness 持續改進的關鍵。

Retro 必答的問題：

• 流量 forecast 跟實際差多少？（forecast 改進方向）
• 容量 utilization 峰值多少？（headroom 是否合適）
• 有沒有 incident 跟 near-miss？（runbook 更新方向）
• 下個事件要改的事是什麼？

Retro 產出：

• forecast 改進建議（給 9.6）
• 新 runbook 或 runbook 更新
• 新 monitoring / alert
• 新工程任務（補容量、補工具）

對應 08.13 post-incident review — retro 不只用在 incident、event readiness 也需要。

案例對照

下一步路由

• 上游：9.6 容量規劃模型 / 9.10 Production-Side 驗證
• 上游：9.13 擴展軸（pre-scaling 前要分辨可不可水平擴展）
• 跨模組：5.9 邊緣分發與靜態資源（CDN pre-warm / origin protection 是 T-2 核心）
• 跨模組：06.20 experiment safety boundary / 08 事故處理模組

既建知識卡片

• Predictive Scaling
• Scheduled Scaling
• Game Day
• Peak Forecast
• Headroom Budget

SLO 與 performance budget 的責任是讓容量決策有「可衡量的目標 + 可審查的代價」。沒有 SLO 時、容量規劃容易變「越大越好」、沒邊界；有 SLO + budget 之後、所有決策都能回答「是否在 budget 內」、「超出 budget 該怎麼辦」。

跟 06.6 SLO 與 Error Budget 的關係：06.6 處理「可靠性 SLO」（用 error budget 凍結 release）、9.12 處理「效能 SLO」（用 performance budget 約束容量）。兩者用同一套方法論、目標不同。讀者可以把本章當作 06.6 的 效能對應 章節。

本章覆蓋 SLI/SLO/SLA 分層、latency budget 分解、performance budget vs error budget、SLO 等級的成本含義、多 SLO 對齊、SLO drift 維護。讀完後讀者能設計一套完整的 SLO + budget 系統、把容量決策跟 SLO 對接。

SLI / SLO / SLA 三層分清

三個名詞常被混用、實際是三個不同層的概念。

SLI（Service Level Indicator）：客觀量測值。p99 latency、availability、throughput、error rate 都是 SLI。 SLO（Service Level Objective）：團隊內部目標。「99.95% 用戶請求 < 500ms」這類具體承諾。 SLA（Service Level Agreement）：對外合約承諾。達不到要退款、違約金、信用補償。

SLO 比 SLA 嚴 — 給內部 buffer。SLA 訂 99.9%、SLO 訂 99.95% — 萬一 SLO 沒達到、SLA 還沒違約、有反應時間。

容量規劃針對 SLO、不是 SLA：SLA 是「最低不能跌破」、SLO 才是「日常目標」。用 SLA 做容量規劃會經常 violate SLA、給用戶 / 客戶不好體驗。

詳見 SLI / SLO 卡片。

Latency budget 分解

Latency budget 是把 SLO 翻成可分解工程目標的關鍵工具。

從 end-to-end latency 開始：

• 用戶感受到的 latency：DNS resolution + TLS handshake + CDN + load balancer + application + cache + DB + serialization + network back
• SLO 訂在 user-perceived：例如「p99 end-to-end < 500ms」

拆到每個 stage 的 budget：

• DNS：5ms（assume cached）
• TLS handshake：50ms（first request）
• CDN：20ms
• Load balancer：5ms
• Application：100ms
• Cache lookup：5ms（hit）/ 100ms（miss）
• DB query：30ms
• Serialization：10ms
• Network return：15ms
• 總和：240ms（cache hit）/ 335ms（miss）

每個 stage 的 budget 必須 跟 SLO 對齊：

• 每個 stage 加總 = SLO 上限
• 任何 stage 超 budget → 該 stage 必須改善（不是其他 stage 來補）
• 每個 stage 必須有 current measurement — 不能訂了沒量

Cross-region call 自帶不可壓縮 latency：

• 同 AZ：< 1ms
• 跨 AZ：1-2ms
• 跨 region 同 continent：20-30ms
• 跨 continent：100-200ms
• SLO 訂 50ms 但服務要跨 region 設計 → 不可能達成

任何新增 stage 都會吃 budget：middleware、sidecar、interceptor、API gateway 都會增加 latency。設計時要明確認知這層代價。

對應案例：Coinbase sub-ms — sub-millisecond 反推所有架構選擇（Cluster Placement Group 壓網路、z1d 壓 CPU、RAFT 壓共識）；Tubi p99 < 10ms — ML inference 多 stage 各自分配 budget。

Performance budget

Performance budget 跟 error budget 是 姊妹概念 — 用同一套方法論處理可靠性 vs 效能。

Error budget（06.6）：

• 每月有允許的 unavailability 額度
• 例如 SLO 99.95% → error budget = 0.05% × 30 days = 21.6 分鐘 / 月
• 額度用完 → freeze new release、focus on reliability

Performance budget（本章）：

• 每月有允許的 latency 退化額度
• 例如「p99 允許比 baseline 高 10ms 連續 X 分鐘」、用 burn rate alert
• 額度用完 → freeze new feature release、focus on perf

兩個 budget 並列、不衝突：

• 一個燒一個健康 → 部分 freeze（freeze 對應的那條）
• 兩個都健康 → 全速 release
• 兩個都燒 → 全面 freeze、deep review

Burn rate alert 比 threshold alert 好：

• threshold：p99 > 500ms 就 alert → false positive 多
• burn rate：過去 1 小時 budget burn rate > 14.4x 就 alert（Google SRE 推薦）→ 對應「再這樣下去 budget 5 分鐘內燒光」

對應案例：Coinbase 延遲就是收入 — 沒 performance budget 等於沒 release control；FanDuel 多 SLO — 直播 vs 投注不同 budget。

SLO 等級的成本含義

不同 SLO 等級對應不同容量成本、選 SLO 就是選成本。

每多一個 9、容量成本指數成長：

• 99 → 99.9：成本 +30-50%
• 99.9 → 99.99：成本 +50-100%
• 99.99 → 99.999：成本 +200-500%

選 SLO 不是 marketing 決策、是工程經濟決策：選太高、燒錢；選太低、用戶不滿。要算 每個 9 對應的業務價值、是否值得對應的容量投資。

對應案例：Amazon Ads 99.999% — 廣告計費 1 分鐘斷線損失幾百萬美金、5 個 9 是真實營收邊界；Genesys 99.999% — B2B 客服 SaaS、客戶停線 = 客戶失去用戶信任、5 個 9 是合約義務。

多 SLO 對齊

同一系統不同工作負載可以有不同 SLO、按業務重要性分級。

設計原則：

• 按「業務重要性 × 用戶感知」分級
• 同一個 endpoint 不同情境可能有不同 SLO（例如登入 vs 結帳）
• 多 SLO 必須有 優先順序、衝突時知道犧牲哪個

範例：

衝突處理：當 capacity 不夠時、優先保 結帳 而非 推薦、即使技術上推薦比較好擴容。

對應案例：FanDuel 直播秒級 SLO vs 投注毫秒級 SLO、同一個 user 同一場 NFL Super Bowl、兩個服務必須分開部署、各自 SLO。

SLO 演進：baseline drift

SLO 不是訂了就不動 — 業務變化要重新校準。

SLO drift 來源：

• Structural surge：COVID 類外部衝擊讓 baseline 永久上移
• Product change：新 feature 改變用戶 journey
• Architectural improvement：DB 換型、cache 加強、CDN 擴點
• User behavior：mobile share 上升、跨 region 比例變化

Drift 不是 anomaly、是 新常態。

Review 節奏：

• 每季 review SLO：拉過去 90 天 SLI 分布、看是否需要調整
• 重大產品改動立即 review
• Drift 確認後要更新：alert threshold、autoscaler trigger、performance budget 額度、容量規劃 baseline

對應案例：Zoom 30x COVID — 30 倍成長後 baseline 永久上移、SLO threshold 跟著重新校準、不能套用 COVID 前的標準。

SLO 跟容量規劃對接

回到本章開頭的論點 — SLO 是容量決策的目標。

容量公式：能撐多少 RPS @ SLO 條件。 規劃時用「SLO-constrained capacity」、不是「max capacity」：

• max capacity：絕對極限、進 cliff
• SLO-constrained capacity：知道在 SLO 條件下能撐多少
• 兩者差 30-50%（headroom）

9.4 saturation 找 knee 是技術指標、9.6 容量規劃用 SLO-constrained knee：

• saturation 在 utilization 80% 時開始
• 但 SLO 可能要求 utilization 60% 以下
• 容量規劃用 60% 而非 80%

跟 9.7 成本工程 對接：

• 每多一個 9 多花多少錢
• 業務需要這個 9 嗎
• 不需要的話降 SLO 省成本

SLO 跟 performance budget 一起用

最後的整合 — error budget + performance budget 一起治理 release 節奏。

Error budget 控制 變更節奏：

• error budget 健康 → release 可以快
• error budget 燒光 → freeze release

Performance budget 控制 容量決策：

• performance budget 健康 → 新 feature 可以引入 perf cost
• performance budget 燒光 → freeze new feature

兩個 budget 並列：

• 都健康 → 全速 release + 新 feature
• error 健康 + perf 燒 → release 但只接 perf-neutral 變更
• error 燒 + perf 健康 → 暫停 release、修可靠性
• 都燒 → 全面 freeze、deep review

對應 06.6 SLO 跟 06.8 release gate。

案例對照

下一步路由

• 上游：9.1 壓測理論（latency budget 反推）
• 上游：9.4 Saturation Discovery（SLO-constrained capacity）
• 跨模組：06.6 SLO 與 Error Budget 政策（可靠性 SLO）
• 跨模組：04.16 SLI / SLO 訊號（量測層）

既建知識卡片

• SLI / SLO
• Latency Budget
• Performance Budget
• SLO Baseline Drift
• Error Budget

兩個軸的責任差異

垂直擴展指把單一機器換成更高規格（更多 CPU / 記憶體 / IOPS），水平擴展指增加機器數量。同樣是「加資源」，兩者面對的工程問題完全不同。

讀者要從「程式假設」這欄反推自己的選項。如果服務本身是 stateful（資料庫、cache、session store），水平擴展需要設計 partitioning 或 replication；如果是 stateless API server，水平擴展幾乎可以無腦複製。把這個前提搞錯，就會用水平擴展的策略去動 stateful 服務、然後撞牆。

第三軸：拆功能 / 拆 partition（AKF Scale Cube Y / Z 軸）

兩個軸的對比把擴展簡化成 capacity scaling 的雙軸、但 AKF Scale Cube 模型提了第三軸：

• X 軸（複製 / 水平擴展）：本表 scale-out 即此軸、適合 stateless 服務
• Y 軸（functional decomposition）：沿業務邊界拆服務、跟 10.1 服務拆分 對應、適合處理「不同功能的擴展需求差距大」
• Z 軸（data partition / sharding）：沿資料拆 partition、適合處理「stateful 服務超出單機容量」

實務系統常同時動兩到三軸：API 走 X 軸水平、按業務拆 Y 軸（user service / order service / payment service）、user service 內部再用 user ID hash 做 Z 軸 sharding。本章焦點在 X 軸、但讀者規劃容量時要記住 Y / Z 軸是同時可用的工具。

Stateless 是水平擴展的前提

Stateless 的核心定義是「處理一個請求不依賴前一個請求留下的本機狀態」。Session、本機快取、檔案系統暫存都會破壞 stateless 假設。

很多人以為自己的服務是 stateless、但一上水平擴展就出事，原因常常在這張表的某一行。判讀方式：把單一機器停掉、重新分配流量到其他機器，使用者體驗是否完全無感？如果有任何「重新登入」「上傳消失」「資料看不到」的情境，就有 stateful 殘留。

這張表覆蓋顯式狀態。隱式狀態（implicit state）是另一類常被忽略的破壞 stateless 因素：

• In-flight request state：HTTP/2 stream、gRPC bidirectional stream — 跨多個請求保持的連線級狀態
• TLS session resumption：session ticket 跟 session ID cache 跨連線、若不集中存會降低重連性能
• Rate limiter state：per-user token bucket、滑動視窗 — 看似無狀態的 middleware 其實在記每個 user 的計數
• 連線預熱（connection warm-up）：HTTP/2 / gRPC 連線建立成本高、機器接到流量後需要時間熱起來

這類「看似 stateless 但有 implicit state」是水平擴展撞牆的常見主因。處理方式是把隱式狀態抽到外部 store（rate limit 用 Redis、TLS session 用共用 cache）或設計連線級 sticky。

Auto Scaling 的操作模型

水平擴展通常搭配 auto scaling — 根據訊號自動加減機器數量。常見的擴展訊號跟對應的判讀重點：

設定 auto scaling 的判讀順序：先選訊號（CPU vs RPS vs queue depth），再設閾值（避免過早觸發或過晚觸發），最後加 cool-down（避免反覆擴縮造成抖動）。三步驟有一步沒做好就會撞牆。

Auto scaling 不是萬靈丹。三類問題它無法解決：擴展速度跟不上（冷啟動時間視 stack 範圍 5-300 秒、流量尖峰若集中在秒級就來不及）、預測式流量（黑五、新片上線、活動）、stateful 服務（資料庫不能用 auto scaling 加 primary）。這三類要分別用 predictive scaling、scheduled scaling 跟 partitioning 處理。

垂直擴展的天花板

垂直擴展看起來簡單但有兩道牆。

第一道是物理上限。雲端機型的最大規格是有限的：以 2025 年公開資料為例、AWS 的 u 系列 instance（如 u7i-12tb、u-24tb1.metal）可達 24 TiB 記憶體級別、vCPU 數量視 SKU 而異；GCP / Azure 也有對應的 memory-optimized 系列、但具體上限隨年份更新。要查最新規格走 vendor 官方文件、不要拿這裡數字當決策依據。對 stateful workload（例如 OLTP 主節點）真實天花板通常出現在 32-64 vCPU 級別、是 lock contention / context switch / memory bandwidth 等架構因素而非規格上限。

第二道是成本曲線。雲端機型的價格不是線性的、越高階的機型每單位資源越貴。以 AWS general-purpose 機型（m 系列）為例、4 vCPU → 8 vCPU 約 ×1.8、8 → 16 約 ×1.9（接近線性）、但到 48 vCPU 以上會明顯偏離線性外推、特別是 memory-optimized（r 系列）跟 high-memory（x 系列）的高階規格溢價更陡。具體曲線依機型 family 跟雲廠商而異 — 走 vendor calculator 算實際 workload 的成本曲線比抓單一倍數可靠。垂直擴展到一定規模、就算物理上撐得住、財務上也會比水平擴展貴。

對 stateful 服務（特別是主資料庫），垂直擴展常常是第一選擇，因為水平擴展需要重新設計 partitioning。但要清楚兩道牆會在什麼時候撞上：基於目前流量增長率，預估垂直擴展能撐多久？多久之後必須改成水平擴展？這個答案要在「還沒撞牆時」就準備好，不是等到下一次撞牆才開始討論。

水平擴展的隱性成本

水平擴展看起來彈性、但有它自己的代價。

協調成本：多臺機器要處理「誰是 leader、誰來執行排程、誰來處理同一筆訂單」這類問題。consensus protocol 跟 distributed lock（含 leader election、Raft / Paxos 演算法）都會引入新的故障模式跟 latency 代價。

連線池放大：100 臺機器、每臺對資料庫開 10 個連線，等於對 DB 開 1000 個連線。DB 連線是有限資源，水平擴展應用層的同時要評估資料層連線壓力。常見緩解：connection pooler（PgBouncer）、serverless DB（DynamoDB）、讀寫分離。

狀態同步成本：cache、session、配置這些「跨機器需要一致」的狀態，要靠外部 store 或 broadcast 機制同步。同步延遲跟頻率會反過來影響服務行為。

Cold start：新機器啟動到接流量需要時間（image pull、init container、warm-up）。auto scaling 觸發跟流量到達之間的延遲就是這段。冷啟動長的服務（JVM、需要載入大量資料的服務）要預留更多 buffer。

Debug 變難：請求散落在多臺機器，排查問題需要 log 聚合、trace context。沒有這些基礎設施，水平擴展只會把「一臺機器壞」的問題變成「不知道哪一臺機器壞」的問題。

混合策略

純垂直或純水平在實際系統中都罕見。常見的混合模式：

• 小規模垂直、大規模水平：早期單機就能撐，先用較大規格降低運維複雜度；流量上來後再轉水平，把每臺機器規格降回中等。
• stateless 水平、stateful 垂直：API server 水平擴展、資料庫主節點垂直擴展、加 read replica 做讀路徑水平擴展。
• 熱資料水平 sharding、冷資料保持單庫：把熱表用 partition key 拆到多個 shard，冷表保留在主庫不動。
• 核心服務垂直保底、邊緣服務水平彈性：核心交易服務用更大規格降低事故風險，前端、推薦等服務走 auto scaling。

選混合策略時，要明確標記每個服務在哪個軸上、極限在哪、下一步轉換點在什麼條件下觸發。沒有這張對照表，混合策略容易變成「每個服務都是特例」、最後沒人記得當初為什麼這樣設計。

判讀訊號

常見誤區

把「加機器」當作所有效能問題的萬靈丹。如果瓶頸在演算法、SQL query、序列化、locks，加機器只會讓問題變得更貴。先用 9.5 瓶頸定位流程 確定瓶頸位置，再決定擴展軸。

把 auto scaling 當成「設定完就不用管」。auto scaling 是 reactive 策略，它無法處理可預期的尖峰（活動、新片上線、節日）。預期型流量要用 scheduled / predictive scaling 提前準備。

把 stateless 當成「沒有狀態就好」。WebSocket、long-polling、上傳、檔案處理這類服務天然 stateful、強行水平擴展會出事。要分辨「業務本質 stateful」跟「實作偷懶 stateful」，前者用 partitioning 處理、後者用重構移除。

定位邊界

本章專注「擴展軸的選擇與前提」。當問題進入具體量化（要加多少臺機器？headroom 多少？），交給 9.6 容量規劃模型；進入瓶頸定位（瓶頸在哪一層？），交給 9.5 瓶頸定位流程；進入服務拆分（要不要先把 stateful 部分拆出來再水平擴展？），交給 10.1 服務拆分與邊界判讀。

案例回寫

擴展軸選擇可用以下案例回寫。每個案例對應的軸不同，引用時要先辨識案例的主要壓力來源，再對照本章相應段落。

• 9.C18 Zoom：COVID 30 倍突發 — 案例主軸是「stateless API 層水平擴展、stateful 資料層改用 DynamoDB 移除單點」，直接對應本章「stateless 是水平擴展的前提」段。是本批最貼近 scaling axis 主題的案例。
• 9.C12 Riot Games：246 個 EKS cluster 的多遊戲多地區治理 — 案例展示水平擴展到極端規模後，協調成本（cluster 治理、版本一致性）變成新的瓶頸；對照本章「水平擴展的隱性成本 / 協調成本」段。
• 9.C19 Capcom：DynamoDB + EKS 上的遊戲後端 — 案例主軸是 KV 業務語意、不是 scaling axis 取捨；但可反向追問「stateful 玩家狀態為何適合 KV vs RDB」、對照本章「stateless 是水平擴展的前提」段中的「狀態類型 vs 緩解方向」表。
• 9.C23 Netflix：把關聯式 DB 統一到 Aurora — 案例主軸是「DB 種類整併」、不直接對應 scale-up vs scale-out；但 Aurora 在 single-primary 規格選擇上隱含了「先垂直、再考慮分散」的策略，可作為「垂直擴展天花板」段的對照組。

Zomato 跟 Netflix 不在這份案例清單裡的原因要先講清楚：擴展軸的真實示範案例在後端教材中相對稀缺、09 模組多數案例的主軸落在 vendor 或容量規劃。Zoom 是這四個案例中最貼近教科書 — stateless API 水平 + stateful 改用 DynamoDB 的組合直接示範本章核心。Riot Games 揭示水平到極端規模後協調成本翻轉成新瓶頸。Capcom 跟 Netflix Aurora 不直接示範擴展軸取捨、但用反向追問「為什麼選 KV / 為什麼 single-primary 仍是 default」能把它們的決策放回擴展軸框架。

跨模組路由

1. 與 9.1 壓測理論與系統行為 的交接：USL 跟 Little’s Law 在理論上推導水平擴展的曲線、本章解釋這道牆在運維現場長什麼樣。
2. 與 9.6 容量規劃 的交接：擴展軸選定後，容量規劃決定具體數字。
3. 與 10.1 服務拆分 的交接：水平擴展常常是服務拆分的觸發點，反之亦然。
4. 與 01 database high-concurrency-access 的交接：資料層水平擴展（sharding、replica）的具體機制。

下一步路由

規模成長路線下一站 → 1.13 應用層查詢反模式與 Query 預算：選定擴展軸後、在加機器前先用反模式清單收回單機可撐住的容量。

其他延伸方向：

• 容量計算與 headroom 模型 → 9.6 容量規劃模型
• 擴展前的瓶頸定位 → 9.5 瓶頸定位流程
• 服務拆分如何配合水平擴展 → 10.1 服務拆分與邊界判讀

連線池放大的物理本質

PostgreSQL / MySQL 每個連線都會在 DB server 端配一個 backend process / thread。Backend 佔 5-15 MB 記憶體、context switch 也有成本。當應用層連線數超過 DB 機器能負擔的數量，會出現三類問題：

• 記憶體吃光：500 個 backend × 10 MB = 5 GB、再加 shared buffer、可能直接 OOM
• Context switch 抖動：上百個 backend 競爭 CPU、上下文切換 overhead 變成主要消耗
• 連線建立失敗：超過 max_connections 後、新請求拿不到連線、即使現有連線多數 idle

問題的根因不是「連線多」、是「連線生命週期跟使用率不對齊」。應用層 connection pool 通常維持「每臺機器 N 個常駐連線、避免每個 request 重新建連」、但 100 臺機器各自 keep 10 個常駐就是 1000 個 idle 連線。

解法的方向不是「砍應用層連線數」（會讓 connection acquisition 變慢、影響 latency）、是「在 DB 跟應用層之間放一層 multiplexer」— 把多個應用層連線複用到少數 DB 連線上。這層中介就是 connection pooler。

Connection Pooler 三大選項

PgBouncer — 三種 pooling 模式決定一切

PgBouncer 的核心參數是 pool_mode：

• Session mode：應用層 client 拿到的連線、跟 DB backend 1:1 綁定、整個 session 結束才釋放。其實沒做 multiplexing、只是 connection caching。
• Transaction mode：每個 transaction 結束、應用層 client 的連線釋放回 pool、下個 transaction 再分配 DB backend。multiplexing 比較強、但不支援 transaction-scoped state（如 SET LOCAL、prepared statement、temporary table）。
• Statement mode：每個 statement 結束就釋放、最強 multiplexing 但不支援 transaction。極少用、只在純 stateless query workload 適用。

Transaction mode 是多數場景的 default。但要注意：應用層的 ORM / driver 可能默認用 prepared statement、跟 transaction mode 衝突。PostgreSQL 14+ 的 protocol-level prepared statement 才相容、JDBC / asyncpg 等需要特別配置。

AWS RDS Proxy — managed 換掉運維

RDS Proxy 是 PgBouncer / ProxySQL 同類功能的 managed 版本：AWS 負責部署、HA、failover、IAM 整合。應用層連到 RDS Proxy endpoint、Proxy 在背後維持跟 RDS / Aurora 的連線池。

特點：

• 連線 share 模式類似 transaction mode：自動 detect 連線是否在 transaction、空閒時釋放
• IAM auth 整合：應用層用 IAM token、不用維護 DB password
• Failover 加速：DB failover 時 Proxy 維持應用層連線不斷、background 重連 new primary。Failover 期間應用層感受最小化。
• 計價：per vCPU-hour、Aurora 約 $0.015/vCPU-hr、RDS 約 $0.02/vCPU-hr — 加在 RDS 計價上面

不適用場景：很多 read-only / analytics workload 不需要 connection pooler、純讀 replica 直接連通常更便宜。RDS Proxy 是給「寫入混合」「連線抖動嚴重」這類場景。

ProxySQL — MySQL 規則型 routing

ProxySQL 是 MySQL 生態的 connection pooler、但比 PgBouncer 更全功能：

• Query routing rules：可以按 query pattern 把 query 導去不同 backend（讀路徑去 replica、寫路徑去 primary、特定 query 強制 cache）
• Connection multiplexing：類似 PgBouncer transaction mode
• Query rewriting：可以攔截 query 改寫（debug / 漸進遷移 schema）
• Auto failover：監控 backend 健康、自動切流

ProxySQL 的代價是學習曲線跟運維成本 — 規則設計需要對 query pattern 跟 DB topology 有掌控、設錯規則會把 query 導去錯誤 backend、debug 困難。

選型對照

實務選型的關鍵變數是「DB 廠商 / managed 程度 / 規模 / 預算」：

不裝 pooler 的判讀

Connection pooler 不是必要 — 在以下情境可以暫時不裝：

• 應用層機器數 < 10：對 DB 連線總數壓力小、deferred 安裝 pooler 沒問題
• 每臺機器連線數 < 5：應用層 connection pool 已經很省、再加 pooler 改善有限
• DB 機器規格大、max_connections 充裕：高階 RDS instance 可開到 5000-10000 連線、有 buffer 之前不必加 pooler
• Workload 全是長 transaction：transaction mode pooler 在這種 workload 跟 session mode 沒差、收益低

該裝 pooler 的訊號是相反：應用層機器數 ≥ 20、每臺連線數 ≥ 10、max_connections 使用率 ≥ 70%、或 P99 connection wait time 升高。

判讀訊號

常見誤區

把 connection pooler 當「N+1 解藥」。Pooler 解的是「連線數放大」、不是「query 數量過多」。N+1 query 在裝完 pooler 後仍然慢、只是 DB 不會因為連線爆掉而當機。兩個是正交問題、各自要解。

把 RDS Proxy 當「免費功能」。Proxy 的計價跟 RDS / Aurora 本體疊加、高 connection volume 場景 Proxy 成本可能可觀。要算實際的 cost-per-request、不是預設「managed 一定值得」。

把 transaction mode 配置當「裝完就好」。Prepared statement / SET LOCAL / temporary table 都會跟 transaction mode 衝突、ORM 預設行為要 audit 過、不然會在 production 出現難 debug 的「query 隨機失敗」。

定位邊界

本章專注「連線池放大的解法」。當問題進入擴展軸選擇（要垂直 vs 水平？stateful 前提？）、回 9.13 擴展軸；進入 DB 本身的容量規劃（要多大規格 instance？要不要 read replica？）、進 9.6 容量規劃；進入 application-level connection 設計（per-request pool / persistent pool）、進 1.1 高併發 SQL。

案例回寫

09 案例庫多數案例規模到 connection pool 已是 secondary concern、但兩個案例有對應參考：

• 9.C18 Zoom：COVID 30 倍突發 — Zoom 把 stateful 資料層改用 DynamoDB、繞過 SQL connection pool 問題（KV 沒有 backend process 概念）。對照本章可問：若 Zoom 保留 SQL、connection pool 怎麼設計才撐得住 30 倍突發？
• 9.C39 DoorDash：CockroachDB 多主寫入 — DoorDash 從 Aurora single-primary 換成 CockroachDB 多主、connection pool 設計從「集中在 primary」變成「分散在多 node」。對照本章可問：CockroachDB 是否仍需要 connection pooler？

跨模組路由

1. 與 9.13 擴展軸 的交接：9.13 提出隱性成本、本章給具體解法。
2. 與 1.1 高併發 SQL 讀寫邊界 的交接：1.1 講應用層 connection pool 設計、本章補 DB 端 pooler 中介層。
3. 與 01 vendors 的交接：各 DB vendor 的內建 pooler 能力詳見 vendor deep article。
4. 與 9.6 容量規劃 的交接：pooler 加上後、DB 容量規劃的單位從「連線數」變成「DB backend 數 + Pooler vCPU」。

下一步路由

要看擴展軸選擇的完整 framing、回 9.13 擴展軸與 Stateless 前提。要看 DB-side 高併發處理、進 1.1 高併發 SQL 讀寫邊界。要看具體 vendor 的 pooler 文件、進對應 vendor deep article。