容量评估方法论：三种核心手段
容量评估这事儿，说白了就是回答一个问题：系统到底需要多少资源？
我做了这么多年运维，见过太多团队拍脑袋定容量。结果呢？要么资源浪费，要么线上故障。今天我把三种最实用的评估方法掰开揉碎讲清楚。
核心观点：没有一种方法能包打天下。趋势分析、压测、业务预测，三者必须组合使用。
一、基于历史数据的趋势分析
这个方法最直观。你想想看，系统跑了半年，CPU、内存、带宽这些指标肯定有规律可循。
核心思路：把历史数据画成曲线，然后外推。就这么简单。
我个人习惯用 移动平均 + 指数平滑 的组合。为什么？因为原始数据噪声太大，直接看会疯掉。
我的经验：别只看最近一周的数据。至少拉三个月。我遇到过某团队只看两周数据，结果漏掉了月底的批量任务峰值，上线就挂了。
具体怎么做？我一般分三步：
- 数据清洗 - 去掉异常点（比如运维操作导致的毛刺）
- 趋势分解 - 拆成长期趋势 + 周期性波动 + 随机噪声
- 模型拟合 - 选线性回归还是指数回归，看曲线形状
举个例子，这是某电商系统的CPU趋势分析：
# 简单移动平均预测
def moving_average(data, window=7):
return [sum(data[i:i+window])/window for i in range(len(data)-window+1)]
# 指数平滑
def exponential_smoothing(data, alpha=0.3):
result = [data[0]]
for i in range(1, len(data)):
result.append(alpha * data[i] + (1-alpha) * result[-1])
return result
# 使用示例
cpu_usage = [45, 48, 52, 47, 55, 60, 58, ...] # 历史数据
predicted = exponential_smoothing(cpu_usage, alpha=0.3)
print(f"下一周预计CPU峰值: {predicted[-1]:.1f}%")
避坑指南：我曾经吃过一次大亏。某次双十一前，我用线性回归预测流量，结果实际流量是指数级增长。预测值差了3倍！后来我学乖了——先看曲线形状，再选模型。指数增长的业务，别用线性模型。
二、基于压测的容量评估
趋势分析是「看过去」，压测是「测现在」。说白了，就是主动给系统施压，看它到底能扛多少。
我习惯把压测分成三个层次：
| 压测类型 | 目标 | 典型工具 |
|---|---|---|
| 负载测试 | 找到系统最大吞吐量 | JMeter, Locust |
| 压力测试 | 找到系统崩溃点 | wrk, ab |
| 稳定性测试 | 验证长时间运行 | GoReplay, tcpcopy |
关键指标：别只看QPS。我见过太多人压测时只盯着QPS，结果CPU都100%了还在那乐。真正要看的：
- 响应时间 - P99超过500ms就算告警
- 错误率 - 超过1%就要停
- 资源利用率 - CPU、内存、IO、网络
- 拐点 - 响应时间突然飙升的那个点
核心方法：压测不是跑一次就完事。我习惯用「阶梯加压」——从100 QPS开始，每次加50，观察每个阶梯的系统表现。这样能精确找到拐点。
举个例子，某API服务的压测结果：
# 压测结果示例
QPS: 1000 → P99: 45ms, CPU: 30%
QPS: 2000 → P99: 52ms, CPU: 55%
QPS: 3000 → P99: 68ms, CPU: 78% ← 开始拐弯
QPS: 3500 → P99: 120ms, CPU: 92% ← 拐点
QPS: 4000 → P99: 350ms, CPU: 98% ← 不可用
结论：安全容量 = 2500 QPS（留30%余量）
我的习惯：压测结果出来后，我会把安全容量定在拐点的70%左右。为什么？因为线上环境比压测环境复杂得多。网络抖动、慢查询、GC暂停，这些在压测时都模拟不全。
三、基于业务增长的预测模型
这个方法最「虚」，但也最重要。技术指标最终是为业务服务的。
核心逻辑：业务量 → 请求量 → 资源消耗。把这个链条打通，就能从业务增长推导出容量需求。
我一般用这个公式：
所需容量 = 当前容量 × (1 + 业务增长率) × 安全系数
其中：
- 业务增长率 = 用户增长 × 人均请求增长
- 安全系数 = 1.5 ~ 2.0（看业务重要性）
举个例子，某社交APP的容量规划：
| 指标 | 当前值 | 预测值（3个月后） |
|---|---|---|
| DAU | 100万 | 150万（+50%） |
| 人均请求 | 200次/天 | 250次/天（+25%） |
| 总请求量 | 2亿/天 | 3.75亿/天 |
| 所需服务器 | 20台 | 38台（含安全系数1.5） |
避坑指南：我曾经犯过一个错——只考虑用户增长，没考虑产品迭代。有一次产品上线了新功能，人均请求量直接翻倍。容量规划完全失效。后来我学乖了：业务预测一定要和产品、运营团队对齐。他们什么时候上线新功能？什么时候搞活动？这些信息比任何模型都重要。
说到活动，这里有个小技巧。我习惯把活动流量拆成两部分：
- 基础流量 - 日常用户产生的请求
- 活动增量 - 活动带来的额外请求
活动增量又分两种：一种是拉新带来的新用户，一种是老用户的活跃度提升。这两种对容量的影响完全不同。
我的经验：做业务预测时，别只给一个数字。给三个：乐观值、悲观值、最可能值。然后按最可能值准备容量，按乐观值留弹性。这样既不会浪费资源，也不会被打个措手不及。
三种方法怎么选？
说实话，没有银弹。我一般这样组合：
- 日常运维 - 趋势分析为主，压测为辅
- 大促前 - 压测为主，业务预测为辅
- 新产品上线 - 业务预测为主，压测验证
嗯，说白了就是：有历史数据看趋势，没历史数据做压测，有业务规划做预测。三者互相印证，才能做出靠谱的容量评估。
最后说一句：容量评估不是一次性工作。我见过最好的团队，每周都会做一次容量review。数据在变，业务在变，你的评估方法也得跟着变。
公众号:蓝海资料掘金营，微信deep3321