容量规划是个资源管理的命题，其目标是解答运行中的系统需要多少容量以及在什么时候需要这些容量的问题，更简单的说法就是回答我们需要在什么时候加多少机器的问题。
容量规划整体上是一个从上到下，再从下到上的一个过程，先是明确公司整体的目标，而后各个业务域和系统进行拆解，估算出系统的需求，而后再逐步汇总，统计出整个公司对各种机器资源的需求量和到位进度。
一、明确公司或系统核心指标
在没有明确需求之前，不应该开始容量规划。
以电商公司为例，主要的核心指标是日活、下单、支付，直播类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的过程，尽量把资源用在刀刃上。这个对于大公司更为重要，因为大公司的机器需求是以万台为规模的，涉及到的就是几亿的预算，不得不慎重。