容量预留没有一刀切的标准答案，先把日常峰值、瞬时峰值和增长斜率拉出来，再按业务类型套1.3到2.5倍冗余系数，通常就能避免临时抓瞎；低于1.2倍峰值等于裸奔，高于3倍大多属于资源浪费。
先把“容量”拆成四层，别只盯着硬盘
很多人一提容量，脑子里只有磁盘还剩多少G，实际线上出问题，最先爆的往往是内存和带宽,容量规划至少要看四层：
- 计算容量：CPU核数、负载、上下文切换
- 内存容量：available内存、swap使用、OOM风险
- 存储容量：磁盘使用率、IOPS、读写延迟
- 网络容量：带宽峰值、连接数、丢包率
四层中任何一层打满，都会让服务不可用，所以预留多少不能只算磁盘,得按资源类型分别估算。
云服务器预留多少内存合适：内存不够时最先被打爆
内存不足的表现非常典型：操作系统开始频繁换页，swap使用率飙升，数据库连接失败，应用进程被OOM Killer直接杀掉，日常使用中，如果free -h里available长期低于物理内存的10%,基本已经进入危险区。
云服务器预留内存的通用原则是：日常峰值内存使用率不要超过70%，留出30%给系统缓存、日志缓冲和突发请求，比如一台8G内存的云主机，日常稳定跑到5.6G已经接近上限,再往上就该扩容或者加机器。
数据库服务器要更保守一些，InnoDB的buffer pool、连接线程、排序缓冲区都会额外吃内存。数据库内存峰值使用率控制在60%以内更安全，可以用vmstat 1观察si和so两列，如果si持续不为0，说明物理内存已经不够，系统在频繁从swap读数据,这就是临时抓瞎的前兆。
磁盘容量和内存容量不是一回事
磁盘满了不会立刻宕机,但会引发连锁反应：
- 应用写日志失败，进程异常退出
- 数据库写入阻塞，事务大量堆积
- 快照和备份任务失败，数据保护失效
- 日志轮转失效，单个文件无限增长
磁盘容量规划要看两个维度：当前使用量和增长速度。df -h只能告诉你现在用了多少，真正决定要预留多少的是每天、每周的增量，把近30天的磁盘增量画出来，斜率越陡,冗余系数就要越高。
预留多少不能靠感觉：三步倒推法
行业共识认为，容量预留必须先量化业务峰值，而不是按平均值拍脑袋，按平均值预留的后果很直接：一旦流量抖动，资源全部打满,临时抓瞎就来了。
第一步：拉取近30天监控数据，找P95和P99峰值
平均值没有意义，比如夜间流量几乎为零，白天有几个小时高峰，平均值会被拉低，真正该看的是P95和P99，P95代表95%的时间不会超过的峰值，P99代表极端情况下的最高水位，预留容量至少要对齐P99,而不是平均值。
第二步：按资源类型套冗余系数
- CPU：P99使用率不超过60%,无状态服务可放宽到70%
- 内存：P99可用内存不低于30%,数据库可用内存不低于20%
- 存储：P99磁盘使用率不超过75%,日志盘不超过60%
- 带宽：P99带宽峰值乘以1.5倍，大促场景乘以2到3倍
第三步：计算安全容量
安全容量 = P99峰值 × 冗余系数 + 应急余量
应急余量通常保留10%到20%，例如P99带宽峰值是80Mbps，冗余系数1.5，那么安全容量就是80×1.5=120Mbps，再留10Mbps应急余量，最终按130Mbps预留，这个公式比“感觉差不多”可靠得多,因为它每一步都可以用监控数据验证。
电商大促服务器容量规划：活动场景要单独算
日常业务和活动场景的容量需求完全不同，日常峰值的1.5倍冗余，放到秒杀、预售、直播带货里根本不够看，大促期间的流量经常是日常峰值的3到5倍,个别接口甚至能冲到10倍以上。
电商大促服务器容量规划为什么不能只按日常均值算
大促的流量不是均匀分布的，预热、加购、下单、支付、回调，每个环节都有独立峰值，尤其是秒杀开始的几十秒，请求会形成尖锐的突发流量，如果只按日常平均值的2倍预留,前几分钟就会把连接池打满。
电商大促容量规划的正确顺序是：
- 先预估活动期间的PV、UV、下单转化率
- 再按漏斗模型算出每个环节的请求量
- 对秒杀、购物车、订单创建等核心接口做单独压测
- 预留至少日常峰值的2倍资源，同时接入弹性扩容
- 提前压测到目标峰值，记录资源使用率，再微调
这里有一个常见误区：只预留资源，不配置弹性，大促流量回落很快，如果全部按最高峰预留包年包月资源，活动结束后资源大量闲置,成本会很难看。
按量付费和包年包月哪个划算
这个问题没有唯一答案,要看业务的流量形态。
- 长期稳定基线：包年包月更划算，单价低，适合常驻业务
- 短时高峰：按量付费更灵活，活动前扩容，活动后释放
- 混合模式：基线用包年包月，弹性部分用按量付费
实际操作中，可以把日常稳定需要的资源包年，超出日常峰值的部分按量购买，比如日常峰值需要4核8G，就包年买4核8G；大促预估需要12核24G，多出来的8核16G在活动期间按量开通，这样既不会临时抓瞎,也不会长期浪费。
企业存储容量预留多少合理：增长、快照和冗余要一起算
企业级存储的容量规划比个人云盘复杂得多，业务数据只是其中一部分，真正吃掉空间的是快照、备份、日志、临时文件、回收站和RAID损耗。
企业存储容量预留多少合理：不能只算业务数据本身
企业存储通常要考虑以下部分：
- 业务数据库：订单、用户、交易记录等核心数据
- 快照：每隔几小时生成一次，占空间随数据量增长
- 备份：全量备份加增量备份，保留周期越长占用越大
- 日志：应用日志、审计日志、操作日志，增长极快
- 临时文件：导入导出、报表生成、数据清洗产生的中间文件
- RAID冗余：RAID 5或RAID 6会牺牲一到两块盘的容量
如果只按业务数据量预留，快照和备份一开，磁盘很快就吃紧，企业存储容量预留的通用做法是：按当前月增量乘以保留周期，再乘以1.5倍冗余系数，比如每月新增数据100G，快照和备份保留3个月，那么基础需求是300G，再乘1.5倍，最终预留450G，这个1.5倍不是随便拍的，它覆盖了快照临时膨胀、日志增长和意外导入。
每季度重算一次容量，把实际增长率和预估增长率做对比，如果连续两个季度实际增长超过预估，就要上调预留系数,否则下一个季度就可能抓瞎。
北京服务器租用价格与容量：地域延迟和成本不能忽视
地域选择会影响容量策略，很多北方企业会优先考虑北京机房，因为延迟低、网络质量好，但价格也相对更高，同配置的云服务器,北京地域通常比中西部地域贵一档。
北京服务器租用价格与容量如何平衡
在北京机房预留容量，不能完全照搬低成本地域的冗余系数,原因有两个：
- 带宽单价偏高，盲目预留大量带宽成本压力大
- 北京多线BGP网络质量好，适合对延迟敏感的金融、政企和电商核心业务
因此北京地域的容量预留策略应该是：计算和内存按标准系数预留，带宽按实际P99峰值预留，不做过度放大，如果业务主要服务北方用户，延迟收益值得多花一部分成本；如果用户分布全国，可以考虑北京作为核心入口,静态资源和计算任务放到其他地域。
业内专家指出，地域选择不只是看价格，还要看用户访问路径，北京到内蒙古、宁夏的延迟多十几毫秒，对普通网页影响不大，但对交易类接口可能直接影响转化率,容量预留的钱要花在能带来业务价值的地方。
实操：用命令和工具把容量监控起来
光有公式还不够，容量规划需要持续监控，没有监控数据，任何预留都是盲猜,下面这些命令可以直接在生产环境使用：
vmstat 1：查看CPU、内存、swap的实时状态free -h：查看物理内存和swap使用情况df -h：查看各挂载点的磁盘使用率iostat -x 1：查看磁盘IOPS、吞吐和等待时间sar -n DEV 1：查看网络接口的实时流量
把这些命令接入监控系统,设置明确的告警阈值：
- CPU使用率连续5分钟超过80%，触发预警
- 内存可用量低于15%，触发预警
- 磁盘使用率超过85%，触发预警
- 带宽峰值达到预留值的90%，触发预警
以Prometheus为例,内存可用率告警表达式可以写成：
100 - (avg by (instance) (node_memory_MemAvailable_bytes) / avg by (instance) (node_memory_MemTotal_bytes) 100) > 85
这条规则的意思是：当可用内存低于总量的15%，也就是内存使用率超过85%时，触发告警，把阈值设置在实际抓瞎之前,运维才有时间做扩容或降级操作。
容量预留的本质不是一次算完就结束了，而是持续观察、持续调整，每次大促、每次业务上新、每次数据增长，都会改变安全容量的边界，只有把监控、冗余系数和弹性能力绑在一起,才不至于临时抓瞎。
预留到日常峰值的1.5到2倍，设置80%使用率告警，并保留按量扩容的通道，多数临时抓瞎都可以提前化解。
相关问答
容量预留多少才不临时抓瞎？
通用做法是：先看近30天P99峰值，再按资源类型乘以1.3到2.5倍冗余系数，最后加10%到20%应急余量，大促活动直接按日常峰值的2倍起步，同时接入弹性扩容,业务恢复后释放多余资源。
云服务器预留多少内存合适？
日常峰值内存使用率控制在70%以内，数据库服务器控制在60%以内，available内存始终大于物理内存的20%，如果free -h显示available低于10%,应该立即扩容或加机器。
企业存储容量预留多少合理？
按当前月增量乘以备份保留周期，再乘以1.5倍冗余系数，同时把快照、日志、临时文件和RAID损耗一起算进去，每季度重算一次，磁盘使用率日常不应超过75%，日志盘不应超过60%。