容量規劃是個資源管理的命題，其目標是解答運行中的系統需要多少容量以及在什麼時候需要這些容量的問題，更簡單的說法就是回答我們需要在什麼時候加多少機器的問題。
容量規劃整體上是一個從上到下，再從下到上的一個過程，先是明確公司整體的目標，而後各個業務域和系統進行拆解，估算出系統的需求，而後再逐步彙總，統計出整個公司對各種機器資源的需求量和到位進度。
一、明確公司或系統核心指標
在沒有明確需求之前，不應該開始容量規劃。
以電商公司爲例，主要的核心指標是日活、下單、支付，直播類app的核心指標可能就是日活、視頻上傳、視頻觀看，共享單車系統的核心指標應該是日活（pv、uv）、下單這兩個，微信的主要指標是日活、個人消息的條數、公衆號文章瀏覽數等。
二、確定容量的約束條件
就是我們在提供這些核心指標的的約束，大體如下。
對於CPU密集型的集羣，我們常常會選擇TPS(每秒處理請求書)作爲集羣的容量指標來衡量集羣的處理能力，而約束條件中則會重點關注CPU的使用率是否率先成爲瓶頸；對於存儲型的集羣，選擇流量(MB/S)作爲容量指標，存儲型的集羣TPS依賴於業務數據大小，所有流量更適合作爲表徵集羣的處理能力，而約束條件最先成爲瓶頸的是網絡流量或者IO。
三、推導出自己系統或業務域的主要指標
我們負責的系統或業務作爲整個公司的一個組成部分，公司核心指標中的一個或者多個必然和我們有關係，因而可以通過公司的核心指標推導出我們的系統或業務的主要指標。
預測容量是一個持續的過程，需要靠數學與直覺來進行精確的預測。比如公司今年的日活是2.5億，我們系統主要服務的調用量是3w/s。而明年公司的日活目標是5億，我們系統主要服務的調用量就是6w/s了，當然在實際的場景中並不完全是線性增長的，這個時候就需要靠自己的直覺了，可以結合自己業務的實際情況乘以一定的係數。
細化到系統的話主要是tps、qps、db數據量、緩存數據量、網絡流量等。
四、計算單系統的需求
根據二和三的具體數據，估算或者經過壓測後得出單系統的具體需求
-
應用服務器
-
在線存儲（關係型數據庫、非關係型數據庫、緩存、文件存儲）
-
離線存儲（數倉、離線計算、實時計算）
-
消息
-
其他的監控、搜索、推薦等
-
下游的依賴
最終產出大致如下的一個表格
|
預算大類
|
系統
|
規格
|
現有資源
|
新增資源
|
一季度
|
二季度
|
三季度
|
四季度
|
需求場景
|
計算邏輯
|
|
應用服務器
|
業務自然增長
|
1wtps/單機200
|
||||||||
|
mysql
|
新項目
|
|||||||||
|
緩存
|
技術改造（提升性能、提升緩存命中率）
|
五、彙總&擠水分
將單個系統的需求彙總後得到整個公司或者大部分的需求，通常情況下每一個系統都會給自己都申請一些資源，以免出現資源不夠的情況，這樣就會總體需求會比較大。對於一些增長幅度比較大或者比較貴的資源，就會出現一個review以及pk的過程，儘量把資源用在刀刃上。這個對於大公司更爲重要，因爲大公司的機器需求是以萬臺爲規模的，涉及到的就是幾億的預算，不得不慎重。
參考資料：
http://blog.csdn.net/wanglha/article/details/39135621
http://blog.csdn.net/hexieshangwang/article/details/49720343