上周跟三个在互联网公司做运维的老伙计在南京科巷撸串，戴眼镜的阿凯拍着烤串签子骂，上个月刚硬着头皮批了三倍的服务器预算把集群扩上去，这月月初就收到了CPU使用率破90%的告警，老板反过来骂他钱花了连个稳定的服务都保不住。
没人真的会按教科书做容量规划
教科书上的标准流程谁都背得出来，统计过去12个月的资源使用峰值，乘以业务预估的增长率，再留20%到30%的冗余，最后走预算审批就行。
哪有这么简单。
阿凯上次的扩容方案，就是照着这个逻辑做的，他算的是去年同期618的峰值，乘了今年预估的30%用户增长，加了25%的冗余，算出来的资源量刚好把上次批的预算花完。结果呢？今年产品临时在大促前两周上了新的大模型推荐模块，单条请求的GPU资源消耗直接涨了42%，他根本没拿到这个预估数据。更别说运营临时加的分享抽免单活动，带来的裂变流量比预估高了两倍。你要是真敢按最低需求报预算，财务第一个找你谈话。
很多团队的容量规划，本质上就是个凑预算的工具。你要少了，业务高峰期扛不住背锅，要多了，财务说你资源利用率低浪费钱。中间的度，全靠老运维的经验摸。没人敢真的按最低需求报，毕竟谁也想不到下个月产品会突然搞什么幺蛾子。
最容易被漏掉的成本从来不是硬件
阿凯上次踩的另一个坑，是完全没把带宽成本算进容量规划里。他把计算资源、存储资源都留足了冗余，结果大促当天的出口带宽峰值直接打满到运营商给的上限，直接触发了限流，不少用户刷了半天加载不出来活动页面。
后来拉账单才发现，他之前的容量规划里，根本没单独测算过带宽的峰值需求。很多人觉得带宽是跟着服务器走的，服务器多了带宽自然够，哪知道现在的云服务商，带宽是单独计费的，而且峰值计费的价格，比基础带宽贵出三四倍。
太坑了。
还有数据库的连接数、缓存的内存上限、消息队列的堆积阈值，这些全是容易被漏掉的点。你应用层扩了十倍，数据库还是原来的配置，连接池直接被打满，所有请求都排队等连接，慢到用户以为整个网站挂了。
很多人做容量规划的时候，眼睛只盯着看得见的服务器成本，这些藏在链路中间的隐性资源，出问题的时候比服务器不够用还致命。毕竟服务器不够最多是慢，这些中间件卡了，直接就是服务不可用。
动态调整比一次性算准靠谱得多
很多人对容量规划有个误解，觉得就是要提前把所有资源都算准，一次到位管个大半年。
这事没那么玄。
现在的云环境弹性这么好，根本没必要追求一次性算得丝毫不差。阿凯他们团队后来改了做法，不再提前一两个月就把所有资源都买好，而是留一部分固定的基础资源，剩下的全部靠弹性伸缩池托着。
但也不是完全甩给弹性伸缩就行。你得提前摸清楚自己应用的冷启动时间，要是新实例拉起来要三分钟才能接流量，那你等监控告警说CPU到80%了再扩容，黄花菜都凉了。他们后来把弹性伸缩的触发阈值提前到了CPU使用率50%，同时提前在大促前一天把弹性池的最小实例数调到了预估峰值的70%，剩下的30%靠动态扩容补，既不会浪费太多资源，也不会等流量冲上来了才临时抱佛脚。
当然这里面永远有取舍。阈值设高了，资源利用率高，但是容易扛不住突发流量；阈值设低了，成本上去了，但是稳定性好。没有什么最优解，全看你愿意为稳定性多花多少钱。
别觉得容量规划是运维一个部门的事。开发得给新功能的资源消耗做个大概预估，产品得提前说清楚接下来的活动量级，运营也不能临到活动前一天才说要搞个大的裂变。不然就算是干了十年的老运维，也算不准下一秒会冒出来什么需求。