上周跟某金融科技公司的运维负责人在巷子口吃夜宵，他把冰啤酒往塑料桌上顿的时候，我就知道又踩坑了。
大促前一周刚按往年的惯例，把所有核心系统的服务器配额提了30%，采购流程走得顺顺利利，预算一分没超。结果真实流量进来的第一分钟，数据库连接池先崩了。钱花了，锅没躲掉。
别把容量规划当成采购清单
这事没那么玄。很多团队对容量规划的认知，还停留在”算清楚要花多少钱买服务器”的阶段。
怎么算？翻去年的监控报表，找历史最高峰值，随便乘个1.5或者2的系数，对着CPU、内存、磁盘的用量列个采购清单，交差完事。说白了就是把容量规划做成了给采购部的报数题。
但真实的系统根本不是这么运转的。你算的应用服务器CPU峰值，是在数据库响应正常、消息队列没有堆积、缓存命中率稳定在95%以上的前提下测出来的。等你真的把应用层资源堆上去，下游的瓶颈没算进去，所有的冗余都是白搭。就像你家水管装得再粗，水表的流量上限卡在那，开多少龙头都出不了大水。
很多人没意识到，容量规划的核心不是算”系统最多能扛多少流量”，是算”在什么负载阈值下，用户能感知到的业务体验不会掉出及格线”。比如同样是1000QPS的请求量，如果接口响应时间从50ms涨到500ms，用户哪怕能打开页面，也会觉得卡，这种负载就算没把系统打崩，也是不合格的容量水位。
真的，我见过最离谱的一个团队，做容量规划的时候直接翻去年的采购单，在总数上加了50%就报给财务。结果那年业务方向调整，新上的功能要吃GPU算力，原来的CPU服务器根本用不上，空在机房里吃灰吃了两年。
被忽略的隐形成本
做容量规划最容易踩的第二个坑，是只算显性的硬件成本，不算藏在流程里的隐形成本。
比如为了扛那0.1%的极端峰值，你给所有链路都按两倍的冗余配资源，算下来硬件成本是上去了。但平时这些资源空转，光云服务费、机房电费一年下来就是七位数的支出。更麻烦的是，资源给得太足，开发同学根本不会想着优化代码——反正内存够，慢查询就慢查询，内存泄漏就泄漏，等真的到峰值的时候，你就算把资源拉满，代码本身的瓶颈卡在那，根本扛不住流量。
刚才说的那个运维负责人，就是栽在这上面。之前算容量的时候，只盯着应用服务器的CPU使用率，根本没算数据库连接池的承载上限。原来的连接池设的是200个连接，应用层多部署了20个实例，每个实例默认开10个数据库连接，流量刚上来，直接把数据库的最大连接数打满了。DBA半夜从家里爬起来改配置，差点把大促的节奏搞乱。
很多人觉得，冗余留得越足越安全。其实根本不是。很多团队做容量规划的最大浪费，是把所有链路都按最高峰值的冗余标准配，从来没算过哪些环节的冗余是真的能兜住故障，哪些只是给自己买的心理安慰。比如你给前端静态资源的CDN留了10倍的冗余，结果真正的瓶颈在订单系统的交易链路，这部分冗余除了多花钱，没有任何实际价值。
动态调整比静态测算有用
我接触过的团队里，真正把容量规划做顺的，没有一个是靠年初拍个静态数字撑一整年的。
现在的业务变化太快了。上个月刚上了个短视频的内容模块，流量构成跟三个月前纯图文的场景完全不一样，之前按图文业务算出来的容量模型，刚上线就不准了。你拿着去年的老黄历算今年的账，不踩坑才怪。
说白了，真正有效的容量规划，从来不是一份静态的数字报表，是跟着业务流量动态迭代的监控和测试体系。不是等大促前临时拉一次压测，是每个季度对着真实的流量模型做一次全链路压测，把每个环节的拐点找出来——比如CPU到70%的时候，接口响应时间会不会从50ms跳到300ms？消息队列堆积到多少条的时候，下游消费者会出现超过10秒的延迟？这些拐点才是你真正需要留冗余的地方，根本不需要笼统地乘个固定系数。
很多团队花大价钱买了云厂商的弹性伸缩服务，结果根本用不起来。为啥？因为阈值设得太靠后了。等CPU到80%才触发扩容，这时候流量已经把现有实例打满了，新的实例还在启动镜像、加载配置，等真正能接流量的时候，故障已经发生了。这种容量规划，跟没有规划没区别。
那天夜宵快吃完的时候，那个运维负责人说，以前总觉得容量规划是纯技术活，要算得精准到个位数才叫专业。后来才发现，这本质上是个平衡的活——业务要保证体验不崩，财务要控制成本不超，开发要留足够的冗余不背锅，运维要算清楚每个环节的极限在哪。
哪有什么完美的测算公式？
无非是别拿着旧的经验，硬套新的业务而已。