容量规划是算出来的不是拍出来的
2026-11-11 08:16:49
作者：
fawen
上周在机房楼下的便利店碰到老周，他刚蹲在台阶上啃完半个肉包，衬衫袖口还沾着机房地板的灰。前一周他们做的品类专场大促，提前三周按去年同期的峰值算的容量，刚开场17分钟就把网关打满了。他说当时盯着监控面板，手心全是汗，临时拉了三波弹性实例，花的钱比整个季度的运维预算还多出去四倍。这事根本不是他们算错数。是压根没把容量规划当“动态算账”的事，当成了“对着旧报表填数字”的差事。
别把容量规划当采购前置流程
很多公司的容量规划流程，说穿了就是每年年底凑预算的固定动作。运维拉个去年的服务器采购表，在现有数字上随便加个20%-30%的冗余，报给财务批预算，采购完机器上架进机柜，这事就算结项了。说白了，这不是容量规划，是预算凑数。
真正的容量规划，算的从来不是“需要多少台机器”，是每一笔业务请求从入口到落库全链路的资源消耗成本。比如同样1000QPS的商品详情页，一年前的老版本代码，可能要吃掉2核4G的实例才能扛住；上个月前端做了图片懒加载、接口字段裁剪的优化，同样的流量可能1核2G的实例就能接得稳稳的。你要是还按去年的老参数算容量，买多了是白白浪费云资源或者硬件折旧，买少了就是上线即事故。
全链路请求资源消耗监控面板示意图
很多人对容量规划的认知还停留在“算CPU和内存的峰值”，根本没意识到，代码迭代带来的资源消耗变化，比流量增长的影响大得多。我之前见过一个团队，上线了个商品详情的AI摘要功能，没做容量评估就全量推了，结果同样的流量下，应用层的CPU消耗直接涨了2.7倍，原来的实例集群连日常的峰值都扛不住，最后紧急回滚才没出大问题。
别把弹性伸缩当容量规划的替代品
现在云厂商的弹性伸缩功能做的越来越顺，很多团队就开始偷懒，觉得反正流量来了系统能自动扩，平时留个最低配置就行，还能省成本。
麻烦在于，弹性伸缩不是无成本的。从新实例启动，到拉取容器镜像，到注册到服务发现，到把数据库连接池、缓存连接池预热好，整个流程快的话要3分钟，慢的话遇到镜像仓库拥堵、可用区实例库存紧张，10分钟都不一定能正常接流量。要是遇到那种陡增的流量场景——比如直播间刚弹了个无门槛优惠券，每秒涨2000QPS，等弹性组反应过来触发扩容规则，服务已经超时一半用户了。更别说大促节点你所在的可用区可能临时卖完了弹性实例，你想扩都扩不出来。
我之前见过一个团队，把所有流量场景的容量都押在弹性伸缩上，618当天整个可用区的计算资源售罄，他们的核心服务直接宕了两个小时，最后赔的用户代金券，比他们三年买的预留实例总成本还高。
算容量的时候要把“看不见的成本”全列进去
很多人算容量的时候，眼睛只盯着应用服务器的CPU、内存指标，把所有藏在链路里的隐性消耗全漏了。
比如缓存命中率的波动。平时Redis的缓存命中率稳在95%，要是突然遇到恶意爬虫批量抓商品数据，或者前端临时改了商品排序逻辑导致缓存key全失效，命中率掉到70%，那数据库的读压力直接涨了五倍。你之前按95%命中率算的数据库容量，根本扛不住这种波动。
还有日志的磁盘占用。很多团队的服务日志是不设滚动大小、不做定期清理的，跑着跑着磁盘写满了，服务直接抛异常挂掉，这根本不是你算的CPU内存数值能覆盖的风险。
还有跨可用区的流量成本。你为了做容灾，把故障流量切到相邻的可用区，那每GB的跨区流量成本，要是没算进容量的总账里，月底账单出来能给你吓一跳。
跨可用区流量成本拆分账单示意图
我上次看到一个团队的月度云账单，跨可用区的流量费占了整个云成本的40%，他们之前做年度容量规划的时候，连这个费用科目都没列进去。说白了，他们算的只是“买机器的钱”，没算“系统跑起来之后要交的所有过路费”。
很多人觉得容量规划是个一劳永逸的事，报完预算买完机器就再也不用管了。这就离谱。你上个月刚上了个新的搜索推荐功能，每个推荐请求的CPU消耗比之前的简单列表查询高了3倍，你三个月前做的容量测算，哪怕当时算的再准，现在也失效了。还有新的合规要求，比如要求所有用户数据传输全程加密，那网络链路的加密计算消耗、磁盘的加密存储IO消耗，都会比之前高一大截，原来的容量模型根本不适用。
别信那种“所有业务统一按峰值留1.5倍冗余”的万能公式。不同业务的重要性不一样，冗余度根本不能硬套。核心的支付链路，冗余可能要留到2倍，因为一旦挂了就是直接的资金损失和用户信任流失；内部的运营报表系统，哪怕利用率到90%临时挂了，大不了晚两个小时出报表，根本不需要留那么多冗余占着资源。硬套公式的结果，要么是钱花得心疼，要么是事出得突然。
之前碰到过一个创业公司的技术负责人，说他们专门请了个知名的咨询团队做容量规划，花了几十万，拿回来个几百页的报告，最后落地的时候发现，报告里的所有参数都是按通用互联网场景算的，连他们自己的业务代码迭代历史、之前的故障记录都没调研过。最后那报告被扔在共享盘的角落，再也没人打开过。
这事没那么玄。你天天在系统上跑，知道哪个服务的代码上次改完之后CPU涨了多少，知道哪个节点一到周末就因为全量备份占满磁盘IO，知道哪个活动节点的流量是平时的几十倍，比那些隔着几百公里给你算通用模型的专家靠谱多了。
老周后来跟我说，他们现在的容量测算表，每一行都标了对应的代码版本、日常缓存命中率、近三个月的流量波动区间，再也不拿去年的数字今年用了。上个月的小型品类专场，他们提前一周就把冗余补够，当天的资源利用率稳在65%，比之前临时扩容省了快一半的钱。
其实哪有什么复杂的高深算法啊。你别把这事当成给领导交差的报表，当成给自己家的车算油耗、算保养周期、算高速上要留多少刹车距离的事，就不会出大错。
免责声明：市场有风险，选择需谨慎！此文仅供参考，不作买卖依据。如有侵权请联系删除。
文章名称：
容量规划是算出来的不是拍出来的
文章链接：https://m.itcdj.com/news/721.html