工作負載對利用率

兩個不同的數字，都是必需的

當團隊只測量兩個基本維度之一時，容量規劃就失敗了。

工作負載: 系統從外部受到的需求。每秒請求數、每分鐘交易數、每秒 MB 數、並發用戶數。工作負載描述世界要求你的東西。

利用率: 系統在服務該需求時的滿載程度。CPU 百分比、已用記憶體、隊列深度、網路頻寬、磁碟 IOPS。利用率描述系統在該需求下感受如何。

單獨的工作負載告訴你會發生什麼，但不告訴你是否能服務它。單獨的利用率告訴你滿載程度，但不告訴你明天應該期望什麼。你需要兩者，並排繪製，以做出容量決策。

容量比率 = 工作負載 / 利用率。如果你在 50% CPU 下每秒服務 1,000 個請求，你的容量比率是每個伺服器 100% CPU 每秒 2,000 個請求。這個轉換因子讓你可以將預測的工作負載轉換為所需的伺服器數。

Allspaw 強調 在正確的粒度測量。每分鐘一個樣本隱藏了 30 秒峰值。每小時一個樣本隱藏了一切。真正的容量工作需要峰值事件的亞分鐘解析度和趨勢的分鐘解析度。任何更粗的解析度都會造成危險的虛假信心。

要監測什麼

你的團隊在新產品推出 (視頻轉碼服務) 上啟動容量測量。你可以選擇最多 8 個指標以亞分鐘解析度追蹤。該服務攝取視頻上傳、對其進行排隊、轉碼為多種格式，& 將輸出寫入物件儲存。

趨勢、季節性、不確定性

每個預測的三層

Allspaw 和 Google SRE 書都認同有用預測的結構: 趨勢、季節性、& 不確定性邊界。忽略任何一個，預測就會變得具有誤導性。

趨勢: 幾個月或幾年內需求的斜率。通常用線性迴歸對短期窗口建模，用指數或分段線性對複合增長建模。趨勢線回答「需求總體上往哪個方向發展?」

季節性: 多個時間尺度的週期性模式。日內 (下午峰值流量)、週內 (週末尖峰)、年度 (黑色星期五、稅季、學年)。乘法季節性隨著趨勢縮放；加法季節性添加常數偏移。

不確定性邊界: 預測圓錐。沒有邊界的預測是猜測。實際預測在中心估計的基礎上發佈明確的上限和下限，通常為 90% 或 95% 信心度。隨著你向未來投影，圓錐擴大。4 週預測可能有 ±10% 邊界；12 個月預測通常有 ±50%。

解耦業務增長和技術需求: 容量規劃預測技術工作負載，但業務團隊預測收入、註冊或活動。容量規劃師的工作是將業務預測轉換為技術需求: 30% 的註冊增長可能意味著 30% 更多的 API 呼叫，但如果新用戶更頻繁地使用系統，它可能意味著 80% 更多，或者如果他們以較低的速率轉換，只有 15% 更多。轉換比率與基礎業務預測一樣重要。

預測假日流量

你的服務為電子商務網站服務。去年的黑色星期五流量是 11 月平均值的 5 倍，持續 12 小時。企業年度增長了 40%。行銷推出預計為黑色星期五流量增加額外 20% 的付費推廣。

知道你的上限

在生產環境發現之前找到上限

預測告訴你會發生什麼。上限測試告訴你系統是否能服務它。Allspaw 將上限測試視為容量規劃的不可商議的輸入: 在你對系統進行受控負載測試之前，你不知道真實容量。

三種上限測試類型:

- 綜合負載測試: 負載生成器 (k6, Locust, JMeter, vegeta) 向分段服務驅動流量。增加負載直到出現問題。破裂點就是上限。最適合隔離服務測試。

- 生產消防演習: 故意在生產中減少容量 (排空伺服器百分比、終止區域) 並觀察剩餘容量如何處理實際流量。測試真正的生產行為，包括意外交互。最高信心但最高風險。

- 影子負載: 在與生產平行運行的目標服務上重放真正的生產流量。捕捉真實工作負載模式 (罕見查詢混合、怪異用戶代理) 而不影響用戶。很好的折中。

餘量是當前負載和上限之間的緩衝。SRE 經驗法則:

- 單區域服務的穩定狀態 50% 餘量 (因此區域失敗不會耗盡倖存區域)

- 多區域服務 N+2 冗餘的 30% 餘量

- 接近已知峰值事件 (黑色星期五、體育決賽) 100% 以上餘量

餘量不是浪費。它是避免在凌晨 3 點叫醒工程師的成本，不在尖峰期間失去客戶，避免當一個區域失敗時級聯故障。財務團隊有時會推動減少餘量；容量工程師必須闡明運行緊密的成本，使對話基於事實而非情感。

設計上限測試

你接手一個沒有記錄的容量上限的服務。目前生產負載是 12 個伺服器上每秒 800 個請求，平均 CPU 35%。行銷公告了預計將流量驅動到峰值 3,000 RPS 的活動，時間為 6 週。

向上、向外或對角線

何時添加電力、添加盒子或兩者

三種核心擴展策略，每種都有不同的成本和可靠性配置檔:

垂直擴展 (向上擴展): 更大的機器。用 32 核伺服器替換 8 核伺服器。最簡單的途徑；適用於直到達到單機限制。單點故障仍然存在。成本非線性增長: 32 核機器通常花費超過 4 倍 8 核機器。

水平擴展 (向外擴展): 更多機器。在負載平衡器後添加伺服器。容量隨著伺服器數量線性擴展。故障模式轉移: 你必須處理分散協調，但單個伺服器故障不再摧毀服務。營運複雜性增加。

對角線擴展 (Allspaw 的術語): 首先向上擴展到舒適的每伺服器大小，然後從那裡向外擴展。結合了大伺服器的較簡單營運與多個伺服器的冗餘。大多數生產服務存在於對角線擴展的領地。

保留與隨選定價: 雲供應商獎勵可預測性。保留容量比隨選便宜 30-60%，但需要 1-3 年的承諾。容量規劃師通常用保留容量鎖定穩定狀態需求，進入隨選以應對峰值。誤判這個拆分可能會浪費金錢 (過度保留) 或暴露預算於驚喜 (在峰值期間保留不足)。

點實例和可搶佔的工作負載: 便宜 60-90% 比隨選，但可在數分鐘的通知內收回。適合批量工作、分析、訓練工作負載或任何為優雅中斷設計的服務。生產面向用戶流量通常避免點。

選擇擴展路徑

你的視頻轉碼服務在 8 個中等大小的雲實例 (每個 8 核) 上運行。你預期接下來 6 個月增長 3 倍。工作負載是 CPU 受限的、可並行化的 (每個視頻)，& 每個視頻轉碼端到端需要 90 秒。保留實例成本為隨選的 50%。點實例成本為隨選的 30%，但可在 2 分鐘的通知內被終止。

容量規劃職業

容量規劃技能薪水好的地方

容量規劃本身很少是工作標題。技能出現在多個角色下:

網站可靠性工程師: 容量規劃是核心 SRE 責任。大多數 SRE 團隊有一或兩個工程師專門從事容量工作，擁有預測模型、上限測試、& 配置自動化。

雲成本 / FinOps 工程師: 一個更新的角色專注於雲支出優化。結合容量規劃與財務建模、合約談判、& 保留實例投資組合管理。在大型雲原生公司薪水非常好，因為雲帳單通常是次於薪資的第二大費用。

效能工程師: 專注於每節點效率和上限測試。工作: 通過分析、優化、& 架構更改從相同硬體提取更多容量。重系統和語言執行時間知識。

容量規劃專家: 在非常大的公司 (Google、Meta、Amazon、Netflix)，專用容量規劃團隊存在。他們擁有整個艦隊的預測模型、大規模談判採購、& 與財務協調多年硬體路線圖。

複合技能: 時間序列分析 (R、Python statsmodels、Prophet)、排隊論 (M/M/1、M/M/c、Little 定律)、至少一個配置管理工具、至少一個雲成本儀表板，& 能力寫一份 CFO 可以理解和行動的預測報告。技術技能讓你進行面試；溝通技能讓你得到預算。

總結

你現在知道什麼

容量規劃是一個持續的紀律，不是年度練習。你已涵蓋:

- 過度配置和不足配置之間的走廊

- 工作負載對利用率作為測量的兩個維度

- 趨勢、季節性、& 不確定性邊界作為每個預測的三層

- 上限測試 (綜合、影子、消防演習) 作為知道真實容量的唯一方式

- 餘量緩衝及為什麼他們不是浪費

- 對角線擴展和保留/隨選/點定價決策

- 這些技能賺取預算權威的職業路徑

兩個想法最重要。用邊界預測，永遠不要用單個點。 & 在生產環境發現之前測量你的上限。 帶著這兩個向前，其餘就順著來。

推薦閱讀: Allspaw 的《容量規劃藝術》(O'Reilly，2017 第二版)、Google SRE 書中的相關章節 (免費在 sre.google/books/)，& Brendan Gregg 的《系統效能》以獲得基礎系統工作。幾何對象伴隨課程更深入地進行視覺結構: Little 定律作為面積、排隊曲線、趨勢斜率、& 餘量信封。