容量规划是业务增长、资源消耗与系统韧性的动态平衡；需规避低估突发负载、隐性消耗、冷启动放大及OOM、磁盘写满、连接打满等连锁故障风险，须以历史P95+趋势外推、多级水位告警、定期压测和保底资源预留实现持续校准。
容量规划不是简单估算“够不够用”，而是对业务增长、资源消耗、系统韧性三者的动态平衡。做得不好，轻则性能抖动、扩容频繁，重则服务中断、数据丢失。
常见陷阱：低估真实负载与弹性需求
很多团队按当前峰值流量乘以1.5倍就定下服务器配置，却忽略了几个关键变量：
- 业务突发性：促销、报表生成、定时任务集中触发时，CPU和内存可能瞬间冲高200%以上
- 隐性资源消耗：日志写入、监控采集、JVM元空间、数据库连接池等常被忽略，长期运行后持续占用内存
- 冷启动放大效应：云环境或容器重启后，首次请求需加载类、初始化缓存、建立连接，瞬时资源需求远超常态
安全隐患：资源过载引发的连锁故障
容量不足不只是慢，更会诱发安全边界失效：
- 内存耗尽触发OOM Killer，随机终止进程（如数据库主进程），导致数据不一致
- 磁盘写满使日志无法落盘，掩盖真实异常；同时可能阻塞应用写操作，引发线程堆积和雪崩
- 连接数打满后，新请求被拒绝或排队超时，攻击者可借此发起慢速DoS（如Slowloris），低成本压垮服务
避坑实操指南：从静态预估转向动态观测
真正可靠的容量规划，必须嵌入可观测性闭环：
- 以“历史P95+趋势外推”代替“当前峰值×系数”：至少采集30天核心指标（QPS、延迟、错误率、CPU/内存/磁盘使用率），识别周期性与突增规律
- 设置多级水位告警：70%预警（准备扩容）、85%严重（触发预案）、95%紧急（自动限流或降级）
- 定期做容量压测：模拟2–3倍日常峰值，验证瓶颈点（是CPU？IO？网络？锁竞争？），并记录各组件响应曲线
- 为关键路径预留“保底资源”：例如数据库连接池保留10%固定连接专供健康检查与运维命令，避免完全失联
不复杂但容易忽略——容量规划不是上线前的一次填表，而是贯穿生命周期的持续校准。
