容量规划从来不是提前算好的数
上周在南京的IT运维沙龙，我靠在走廊墙上记笔记，碰到做电商运维的老周蹲在台阶上抽烟，指尖的烟烧到滤嘴都没察觉。他刚为了618大促的容量规划，硬着头皮给团队申请了3倍的服务器资源，结果大促当天流量只到预估的6成，财务追着他要闲置成本的说明，头都大了。
这事儿真的太常见了。几乎每个做过线上系统的人，都在容量规划上踩过坑——要么资源留少了，流量冲上来直接打挂服务；要么资源留多了，大半机器闲置几个月，最后被成本部门追着问责。
别信PPT上的容量公式
很多团队的容量规划流程，说起来特别规范。把过去半年的峰值流量拉出来，乘个2倍的冗余系数，算上未来三个月的业务增长预期，得出一个“完美”的资源需求数，打个申请报告就完事。
说白了，这方法十年前能用。现在真不行。
真实的业务流量从来不是平滑的曲线。你永远不知道哪个节点会突然冒出来一波完全没预料到的流量——可能是某个用户在短视频平台发了条带商品链接的内容，可能是某个政策突然落地，大家扎堆来办业务，甚至可能是系统某个前端的bug，导致无限循环的请求打到后端接口。
我去年跟一个做社区团购的运维团队聊，他们算容量的时候按日常峰值留了1.5倍的冗余，觉得足够应对所有突发情况。结果某天上午，一个小区的团长在群里发了个1000人规模的优惠券链接，两千多用户同时点进直播间，瞬时流量直接冲到日常的7倍，整个集群在10秒内就被打满，连触发降级的机会都没有。最后整个平台卡了20多分钟，团长们的投诉接都接不过来。
公式有用，但不全对。那些印在运维规范里的测算逻辑，算的是“大概率的平均情况”，但线上的所有故障，全是小概率的黑天鹅。更麻烦的是，很多人做容量测算的时候，根本不看真实的资源消耗结构——光盯着CPU使用率，觉得CPU到70%就该加机器，结果加完之后发现，CPU水位是降下来了，但是跨可用区的网络带宽打满了，数据库的存储IO直接卡到读写超时，钱花了，问题一点没解决。
容量规划的核心从来不是“够不够”，是“在可接受的成本下，遇到最坏的情况时，系统能撑到什么程度”。你不可能给所有维度都留10倍的冗余，那成本高到任何公司都扛不住，取舍是必须的。
压测不是走个过场
说到容量验证，很多人第一反应是压测。但我见过的绝大多数压测，本质上都是走个过场。
怎么个走过场法？开发在测试环境把服务部署好，模拟个预估的峰值QPS，跑10分钟，看系统有没有报错，日志有没有异常，得出个“系统可以扛住峰值流量”的结论，就直接上线了。
根本不碰生产环境的真实链路。
之前跟个做金融IT的朋友吃饭，他说他们团队之前上一个新的理财功能，测试环境压测的时候，QPS能稳稳扛到5000，觉得万无一失。结果上线当天，市场利率突然上行，用户挤进来买理财，瞬时QPS刚冲到3000，系统就开始大面积报错。排查了半天才发现，测试环境的网络链路是全内网的，没有跨可用区的延迟，数据库也是单独的测试库，根本没有生产库上那些跑了好几年的定时任务、历史数据带来的资源消耗。测试环境的结果，跟生产环境的真实容量，差了快一半。
很多人怕全链路压测影响线上真实用户，觉得要做流量打标，要隔离压测数据，要搭专门的压测链路，太麻烦。但你算算账，你省了这几个小时的压测准备时间，真出故障的时候，可能要花十几个小时排查，还要赔上用户的信任，哪个代价更大？
账不能这么算。
我见过最扎实的一个团队，根本不做什么提前的精准容量测算。每周固定在业务低峰期，往生产集群里加10%的节点，然后逐步加压，把每个节点的资源水位摸到最准的阈值——哪块资源先到瓶颈，就针对性补哪块，从来不会一次性堆一大堆闲置资源。他们的逻辑很简单，反正业务一直在变，今天算出来的合适容量，可能下个月加个推荐功能，资源消耗直接涨30%，之前的测算全作废。
别把冗余全堆在硬件上
一提容量不够，很多人的第一反应就是加服务器，加带宽，加存储。从来没想过，系统本身的弹性能力，也是容量的一部分。
比如你搭了完善的自动扩缩容机制，能在1分钟内根据实时流量拉起对应的服务实例，那你平时留的冗余量就可以压得很低，不用一开始就把能扛10倍流量的资源全买了放在那闲置。反过来，如果你没有自动扩缩容，就算你留了3倍的硬件冗余，碰到突发流量的时候，流量先打满第一个实例，后面的实例还没来得及接入流量，就已经触发了熔断机制，冗余再多也白搭。
真正的容量冗余，一半是硬件资源，一半是系统的快速响应能力。
之前在沙龙碰到的老周，回去之后花了两周时间调整了自己团队的容量策略。把之前一次性买的3倍冗余服务器退了一半，换成了云服务商的弹性实例——平时只留1.2倍的日常冗余，碰到大促前3天，再根据实时的预约流量动态扩容，大促结束之后立刻把弹性实例释放掉。上个月做平台小促，流量比预估的高了4成，系统稳稳扛住，整体的资源成本还比之前降了60%。他说之前总觉得容量规划就是要算准所有可能的流量，现在才明白，哪有什么百分百的准确，只要系统能跟着流量快速调整，比蹲在办公室算半个月的数有用多了。
其实很多技术决策都是这样。你一开始总想着要做个完美的、算无遗策的方案，把所有变量都考虑到，把所有冗余都留够，最后算出来的数，要么成本高到没人批，要么根本不符合线上的实际情况。
容量规划这事儿，没那么玄。你蹲在监控前面多盯几个月的真实流量，多做几次贴近生产的压测，把系统的弹性能力搭起来，比看十本容量规划的教材都管用。