容量规划的 80/20 法则

容量规划是基础设施运维的核心活儿，但 80% 的人做错。本文是我的方法论。

错误姿势 1：按峰值规划

❌ "去年双 11 峰值 10w QPS，今年准备 12w QPS 容量"

问题：
- 峰值 1 小时，剩下 23 小时机器闲置
- 假设业务线性增长，但实际可能跳变
- 没考虑结构性变化（如改了缓存策略）

错误姿势 2：按"经验值"

❌ "1 万用户每秒大概 100 QPS 吧"

问题：每个系统的"经验值"不一样，公司间也不同。

错误姿势 3：堆机器主义

❌ "不够就加机器，先双倍买着"

问题：
- 浪费钱
- 掩盖架构问题
- 加了机器还可能因为锁、单点限制不能 scale

正确姿势：4 步法

Step 1：找业务驱动指标

每个服务有个"业务量 → 资源消耗"的转换关系。先找出来：

API 服务：QPS 与 CPU
DB：DAU 与 IOPS
推送：用户数与连接数
视频：在线观看数与带宽

通过历史数据回归出公式：

CPU_cores = QPS / 1500 + 0.5

Step 2：预测业务量

业务量预测 = 趋势 + 大事件

未来 6 个月 QPS = 当前 × (1 + 月增长率)^6 × 大事件系数

大事件系数：
- 没大事件：1.0
- 季度活动：1.3
- 双 11/618：3-5x

Step 3：算资源需求

把业务量代入 Step 1 的公式：

峰值 QPS = 月均 × 3 (典型电商) 或 × 1.5 (B 端)
所需 CPU = 峰值 QPS / 1500 + 0.5 = ...
所需机器 = CPU / 单机 CPU × 1.3 (留 30% buffer)

Step 4：定 SLO 兜底

CPU 平均 < 50%（双倍冗余）
CPU 峰值 < 80%（应对突发）
内存平均 < 60%
磁盘 < 70%

任何指标接近上限就触发扩容预警。

80/20 法则

容量规划 80% 的价值来自：

找出 top 5 资源消耗大户：精确建模
识别非线性环节：DB、缓存、消息队列经常是瓶颈
量化大事件影响：双 11、营销活动

剩下 20% 价值来自精细化（如按机房、按时段）。新手往往在精细化上花太多时间。

一个真实例子

某社交 App 规划容量：

错误做法："注册用户 1000 万了，机器买 1000 万 / 100 万 × 现有 = 10 倍"

正确做法：
1. 找驱动指标：DAU 而不是注册用户
2. DAU/注册 = 30%，所以 DAU = 300 万
3. DAU 与 QPS 的关系 = 0.3 QPS / DAU
4. 峰值 QPS = 300 × 0.3 × 3（峰值倍数）= 270 万
5. 单机扛 5000 QPS，所以需要 540 台

结果：1000 台变 540 台，省一半成本。

工具

趋势预测：Prophet（Facebook 开源）、ARIMA
资源拟合：Excel 散点图 + 回归足够，复杂的用 sklearn
容量看板：Grafana 自定义 dashboard

几条心得

每季度复盘容量预测准确度：不准就调模型
大版本变更前重新规划：架构变了公式失效
保留 1 个月 buffer：再快的采购也要时间
公有云就开 autoscaling：让云厂商帮你规划

教训：容量规划的目的不是"装满"，是让你永远比业务快一步。