上周去南京软件大道见个老同事，刚进园区就碰到以前带过的运维小周蹲在消防通道抽烟，眼睛红得像兔子。
熬了两宿。
上周618大促预热，他们团队的订单系统直接崩了三次，半夜爬起来加了八台物理机，告警声吵得隔壁做生鲜电商的团队都过来敲门问是不是服务器着火了。
你算的根本不是真的业务容量
他说之前做容量规划，全靠上个月的CPU峰值乘个1.5的系数，连产品侧要上的满减活动能拉多少新客、新换的推荐算法要多吃多少内存都没问过。等到流量冲进来的时候，数据库连接池直接打满，接口超时率飙到30%，用户投诉的电话直接打到了老板办公室。
太惨了。
多数人对容量的理解从根上就偏了。盯着监控面板上的CPU、内存、磁盘使用率算余量，觉得资源剩得越多越安全，说白了就是把容量当成了硬件的剩余比例。真正的容量从来不是资源的剩余占比，而是系统能承载的、符合用户体验要求的最大业务请求量。
举个最常见的例子，某团队的订单接口CPU使用率才40%，但P99延迟已经冲到了800毫秒，用户点下单要等快一秒。这时候你再加多少台服务器都没用——瓶颈卡在数据库的行锁上，缓存命中率掉了20个百分点，和CPU剩多少资源半毛钱关系都没有。
很多人算出来的容量和真实承载能力差出两三倍，就是因为只盯着资源指标，没碰过实际的业务链路。你不摸清楚哪个环节是瓶颈，算出来的数全是空中楼阁。
容量规划的时间窗口比你想的长太多
小周说他们之前总觉得容量规划是上线前一周才要做的事。新功能要上了，拉着开发、产品开个半小时的会，拍个大概的用户数，给运维提个资源申请就完事。
说实话，这事没那么简单。
现在企业的IT资源不是你想要就能马上拿到的。公有云的弹性实例虽然快，但要上预留实例降成本的话，提前一两个月都不一定能批下来。私有云的物理机更麻烦，采购流程走下来少则三周多则三个月，要是需要特定型号的GPU，等供应链调货都得等半个月。
太赶了。
我之前帮雨花台区的一个团队做过规划，他们核心交易系统的硬件采购周期是整整三个月。也就是说，他们现在要算的是三个月之后大促时的资源需求，而不是下个月的。这中间还要考虑，业务侧可能要上两个新的营销活动，还要把原来的单体服务拆成微服务，拆分之后的跨服务调用会带来大概20%的额外资源损耗，这些都不是临时抱佛脚能算出来的。
要是你等大促前两周才想起算容量，就算拍脑袋算出了准确的数，资源也未必能及时到位。到时候崩了，锅还是得你背。
留多少冗余才不算浪费
小周说上次出问题之后，团队内部有人提议，以后所有资源都直接按峰值的三倍配，宁可浪费也不能再出故障。
扯什么淡。
我见过最离谱的团队，给内部用的OA系统配了三台8核16G的服务器，平时使用率连5%都不到。问为什么配这么多，说怕员工传附件的时候崩。这不是拿公司的钱开玩笑吗？
容量规划的本质是在稳定性和成本之间找平衡点，而不是追求绝对的安全。冗余比例从来没有统一的标准答案，全看你这个系统崩一次要付出多大的代价。
核心交易系统，崩一次可能损失几百万的营收，留30%到50%的冗余完全正常。甚至你要考虑到极端情况，比如某个可用区整体挂掉的时候，剩下的资源能不能扛住全量的流量。但内部的办公系统，崩了最多让员工摸鱼半小时，留10%的冗余都绰绰有余，真没必要上双活集群。
很多人觉得容量规划是运维团队一个部门的事。不对。开发要知道自己写的代码会吃多少资源，产品要知道自己的活动能带来多少流量，财务要知道每一块钱的资源花出去能带来多少收益。这些信息串不起来，运维算出来的数，和实际跑起来的差出十万八千里，最后背锅的还是干活的人。
上周再碰到小周，他说已经拉了跨部门的固定群，产品、开发、财务每个月都要抽一下午碰一次，把接下来三个月的业务计划摸得门清，再对着资源池算余量。
他说现在再也不蹲消防通道抽烟了。
挺好。