容量規劃為何關鍵#

容量規劃（capacity planning）是評估硬體與軟體要多少容量才能滿足應用需求的過程。在 SRE 與 SDLC 視角，它還涵蓋每位工程師的時間與工作量。

「規劃做得好等於戰役打贏一半。」這句話用在 SDLC 上格外貼切——尤其敏捷團隊必須能快速回應客戶需求變化。

三種容量類型#

• 軟硬體容量：定義伺服器數量、CPU、記憶體、所選軟體等硬體與軟體規格
• 人力容量：估算每團隊投入時數與所需技能
• 產品容量：預測客戶需求趨勢，確保有資源支撐新功能；同時要求產品設計具備未來可移植性

長短期容量規劃#

組織通常把容量規劃拆成兩種視角：

• 長期容量規劃：高階規劃未來可能的系統演進與團隊擴張，產品容量屬此類
• 短期容量規劃：定義短期里程碑，盤點系統與團隊容量；軟硬體與人力容量屬此類，每個 SDLC 階段都應做

Agile 的 Program Increment（PI）週期通常 8 ～ 12 週。每個 PI 開始時都需重新做短期容量規劃。

容量與成本的連動#

容量規劃與成本管理密不可分：

• 招募具備正確技能的人員 → 人力成本
• 採購伺服器與授權軟體 → 基礎設施成本
• 評估辦公空間、筆電等周邊資源 → 營運成本
• 評估開源替代品可能省下的授權費用

組織通常設置獨立的技術評估團隊，從工作量、工具、基礎設施、辦公地點、設備等全方位評估成本。

三種容量規劃策略#

雖然源自製造業，這些策略也可套用到軟體開發：

• 滯後策略（Lag strategy）：等需求成長後才追加容量

  • 預先準備完成專案所需容量，加上一點緩衝預算
  • 適用於需求增長有固定時程、波動有限的場景，如銀行投資產品上線
  • 缺點：需求暴增時補容會有時間落差

• 領先策略（Lead strategy）：依歷史資料與研究預先擴充

  • 在初期就上多餘人力與基礎設施
  • 適用於需求劇烈變動的零售類應用
  • 風險：若預測落空，多買的資源會浪費

• 配對策略（Match strategy）：滯後 + 領先的折衷

  • 持續分析當下與短期未來需求並動態調整
  • 多在 SDLC 各階段檢視趨勢、視情況提早擴充

成本管理的最佳實踐#

• 預留容量（Capacity reserve）：保留緩衝以應對未來需求；用不上時可挪到其他專案
• 開發策略：
  • 程式碼框架要易於水平與垂直擴充、可整合新框架
  • 雲端原生時代要寫雲端不可知（cloud-agnostic）程式，方便未來搬遷
• 成本管理：
  • 從詳細設計開始考量何處可使用開源軟體
  • 不用的伺服器與工具要降規或退訂；可重新分配給其他專案
  • 評估虛擬辦公模式以降低實體成本
• 人力管理：把 SRE 團隊的多元技能視為彈性資源
  • 50% 時間在運維，50% 在開發
  • 流量暴增時開發者可協助 SRE，反之亦然
• 可觀測性（Observability）：建立準確的告警，把警示數據轉化為歷史趨勢，協助未來容量預測

容量規劃不是一次性決策，而是持續的迭代。建立「告警 → 數據 → 預測」的閉環，才能讓容量規劃跟上業務節奏。