傳統容量規劃是「蒐集預測 → 設計配置 → 審查簽核 → 部署資源」的四步循環，但它天生脆弱：任何小變動——效率退化、採用提升、交付延遲——都逼整個計畫重來。更好的做法是指定需求，而非指定實作，讓機器把意圖算成配置。
🧠 Intuition
TIP
「意圖式（intent-based）」容量規劃：不寫「cluster X 給我 50 核」，而是寫「每個地理區的需求都被滿足，且具備 N+2 冗餘」。把意圖程式化編碼，需求一變就重新生成新計畫，而不是手動重排試算表。
- 傳統做法的三個痛點：脆弱（任何變動迫使重來）、不精準（用試算表做 bin packing 是 NP-hard，逼人簡化需求）、意圖丟失（到執行端只剩「X 核 in cluster Y」，原始的 why 全沒了）。
- 意圖有不同抽象層級，越高越有價值：純資源請求 → 加入自由度 → 人類可理解的目標（各區需求 + N+2）→ 直接綁可靠度（「5 個 9」）。經驗上跨到「可理解的目標」這階效益最大。
- 產生計畫需要三類前置資料：需求預測（未來趨勢）、效能指標（把需求量翻成資源量與下游依賴量）、優先順序（資源不足時先犧牲誰）。
- 意圖式規劃把優先順序的取捨變得透明、公開、一致——資源不足必然要取捨，但能避免黑箱政治。
⚖️ Tradeoffs
試算表 + 手動 bin packing — 傳統容量規劃
- Bin packing 是 NP-hard，用試算表做既難擴展又易錯，還會逼團隊「簡化需求」以求勉強可解。
- 計畫天生脆弱：服務效率退化、客戶採用超預期、資源交付延遲，任一發生就得整份重算。
- 原始意圖與自由度在傳遞過程中流失，執行端無從判斷哪些是硬需求、哪些可調。
意圖式規劃 — 指定需求交給求解器
- 把依賴、效能模型、需求預測、資源供給與定價餵給求解器（線性／混合整數規劃），自動產出配置計畫，需求變更時重新求解。
- 好處：可擴展、可重現、取捨透明；無法滿足的需求也會被明列出來，而非悄悄被吞掉。
- 代價：要先把服務的依賴與 scaling 模型形式化；起步可用簡單啟發式（近似先於完美），介面抽象好日後再換精確求解器。
🔑 Takeaways
- 傳統四步容量規劃脆弱、不精準、丟失意圖；核心解法是「指定需求，而非實作」。
- 意圖式規劃靠三類資料（需求預測、效能指標、優先順序）自動生成配置，需求一變就重算。
- 抽象層級越高越有價值，做到「可理解的目標 + N+2」這階效益最大，並讓資源取捨透明公開。
No notes yet — jot your takeaways or Q&A here.