容量规划从来不是凑资源的算术题

上周跟一个做运维的朋友吃夜宵，他攥着半串烤筋，说上周刚为了大促扩容多买了两百台云主机，结果流量只到预估的三分之一，月底财务找上门，问这多出来的三十万预算花哪了。他说当时拍脑袋按往年峰值乘了个1.5的安全系数，谁知道今年新上的转化路径比往年短了一半，用户根本没走原来的入口。

别把容量规划当采购清单

很多人对容量规划的认知，还停留在列采购清单的阶段。CPU要多少核，内存要多少G，存储要多少TB，把数字报给采购部门，就算完成了全部工作。说白了，这就是最表面的活。麻烦在于，资源买早了是沉没成本，买晚了是线上事故。

之前见过一个团队，每次大促前就按历史最高值打满配置，结果连续三次流量不及预期，闲置的服务器占了整个机房近两成的机位，最后下架的时候光数据迁移就花了两周。容量规划的核心从来不是“要多少资源”，而是“在什么时间点、用多少成本、换多少可承载的服务能力”。

没人天生会算这笔账。

很多团队踩的第一个坑，就是把所有历史峰值都当有效参考。

去年有个做内容社区的技术负责人跟我吐槽，他们之前算视频流的容量，把三年前某次热点事件带来的10倍流量峰值算进了基线，结果每次按这个基线留的冗余，够扛三次同等规模的热点，平摊下来每GB视频的存储成本比同行高了近40%。等反应过来的时候，多花的钱够搭两套新的冷存储集群。

那些藏在指标后面的隐性成本

大家算容量的时候，往往只看得见CPU、内存、存储这些明面上的资源，很容易漏掉那些藏在指标缝隙里的隐性消耗。

之前有团队算容量的时候，只算了计算资源的成本，没算跨可用区流量的费用，等系统跑起来才发现，每次数据同步的跨区流量费，比计算资源本身还贵30%。还有集群规模上来之后，调度系统本身的资源 overhead——当集群规模到几千台的时候，光调度本身消耗的资源就占总资源的8%到12%，这些如果不算进容量基线，最后实际能用来跑业务的资源，比预估的少了快十分之一。所有没被计入基线的隐性消耗，最后都会变成线上的意外。

很多人说，那我把所有指标都拉满不就完了？

不对。

容量规划最有意思的地方，就是永远没有“最优解”，只有“可接受的取舍”。

你要留足够的冗余扛突发流量，就要接受闲置资源的成本；你要把资源利用率打满压成本，就要接受流量突增时可能的响应延迟。没人能两边都占。

之前见过一个团队，为了把资源利用率从40%提到70%，把所有非核心业务的弹性阈值调得特别高，结果某次用户上传高峰，核心业务和非核心业务抢CPU，核心接口的响应时间从200ms涨到了2s，整整抖了四十分钟。事后复盘的时候，负责人说，当时只盯着利用率的数字好看，忘了不同业务的优先级根本不一样。

别等系统告警了才开始算容量

不少团队的容量规划是完全被动的。磁盘满了加硬盘，CPU到80%告警了加机器，带宽跑满了买流量包。这种被动应对的代价是什么？是每次扩容都要付出比提前规划高得多的成本。比如云厂商的临时按需扩容，比包月包年的预留实例价格贵近一倍；紧急采购的物理服务器，从下单到上架要走三周流程，这三周里如果真的来了流量峰值，根本扛不住。

真正靠谱的容量规划，从来不是对着当前的监控数字算，是往前看三到六个月的业务变化。比如产品下个月要上新的直播功能，直播的带宽消耗是原来图文场景的10倍，那你不能等功能上线了才开始算需要多少带宽，要在功能做预发布测试的时候，就把对应的容量模型搭好。很多人觉得容量规划是架构师一个人的事，其实不是。做产品的要提前说清楚未来半年的功能迭代节奏，做运维的要把历史的真实流量峰值——去掉那些偶发的、不可复制的热点——整理成稳定的基线，做财务的要把不同冗余比例对应的成本算清楚，凑到一起，才是一份能用的容量规划。

说实话，这事没那么玄。

不需要你拿什么复杂的数学模型去算，也不需要你做多么宏大的架构设计。

很多时候就是把那些拍脑袋的数字，换成有依据的估算。比如之前那个因为大促多买了两百台服务器的朋友，后来把容量模型改成了分场景的：日常流量占多少，大促基础流量占多少，热点突发留多少冗余，每个比例对应的成本是多少，算完之后，今年的大促扩容规模比去年少了60%，结果流量峰值刚到他预留的冗余线，资源利用率刚好到70%，财务那边也没再找他麻烦。

我之前见过不少团队，把容量规划当成每年要交的一份文档，写完就存在共享文件夹里再也没人看。其实不是的。这东西是要跟着业务一起变的。

你今天算好的容量基线，可能下个月因为一个新的功能就完全不适用了。

但只要你开始不拍脑袋，就已经比大部分人强了。