上次跟做基础架构的老周撸串，他把冰啤酒往桌上一墩，脸皱得像个被抢了糖的小孩。上个月618前刚把核心链路的服务器翻了倍，结果实际流量只到预估的三成，机房电费多烧了二十多万，老板追着问为什么堆了这么多闲置资源。他翻个白眼说，去年同期流量跳涨三倍把系统打挂的阴影还没散，谁敢少买？
你以为的容量规划和实际遇到的根本不是一回事
很多人刚接触这事儿，第一反应是拿历史峰值乘个安全系数，报个采购数就算交差。
错的。
真正的容量规划从来不是对着监控曲线拉直线。你得摸透每个环节的冗余边界——网关层扛到多少QPS会触发限流，数据库连接池打满的时候系统会不会直接雪崩，甚至得算上机房单链路光纤被挖断时，剩下的节点能不能撑住核心交易不垮。
麻烦在于，太多团队把容量规划做成了大促前的突击任务。平时没人盯指标，临到活动前两周才拉会算数字。之前听个做电商的技术负责人说，他们为了赶采购进度，把所有非核心服务的资源砍到了日常最低配，结果大促当天首页推荐直接挂了，用户点进来卡三秒，转化率掉了快四成。事后复盘才发现，推荐服务的容量阈值是按日常浏览时长算的，根本没算大促时用户刷首页的停留时长涨了一倍，请求量直接超了三倍。
算出来的数字永远和真实世界有偏差
别信那些教你套万能公式算容量的教程。
公式是死的，人是活的。
你按去年双11的峰值算今年的数，万一今年突然上了个短视频功能，每个用户进来多刷三个15秒的片段，带宽直接涨两倍，之前算的数直接作废。谁没踩过这种坑？之前采访过一个做直播平台的技术团队，他们算带宽容量的时候，只算了主播推流的固定码率，结果某次搞连麦PK活动，观众端要同时拉两路流的码率，带宽直接冲到预估的2.7倍，当天下午就把当月的流量额度烧完了，平台直接弹了个付费墙，被用户骂了整整三天。
遇到这种事，很多人的第一反应是下次多留一倍冗余。但留多了呢？平峰的时候资源利用率可能连15%都不到，财务每个季度看成本报表都要找你谈话，说你把预算都买了吃灰的机器。
说白了，容量规划的本质从来不是追求绝对不宕机，是在宕机的风险和烧钱的成本之间，找个最舒服的平衡点。你留的冗余刚好够扛住日常的流量波动，够应付大促的临时峰值，又不至于让大部分资源在平峰时闲着，这才叫及格。
最容易被忽略的容量成本从来不是机器钱
很多人算容量账的时候，只算买服务器、付云服务费的显性成本。
错得离谱。
你得算那些看不见的隐形成本。比如为了留冗余多买的一堆机器，平时没人用，占着机房的机位、占着带宽出口、占着运维的巡检精力。之前有个运维跟我吐槽，他们团队三个人要管快两千台服务器，其中快一半是为大促留的冗余，平时没事干就隔三差五出点小毛病，换硬盘、重启服务，光维护这些闲置机器的时间，就占了团队快40%的工作量。
还有更隐蔽的成本。比如你为了省点机器钱，把某个中间件的容量阈值设得特别紧，平时看着资源利用率挺高，结果某次流量稍微涨了点，消息队列直接堵了，订单数据堆了两个小时没处理，客服被用户的退款咨询打爆，财务还要算用户赔付的钱，这账算下来，比多买十台中间件的成本贵多了。
现在很多团队开始做动态容量调整，不是一锤子买卖定个数就完事。平时把非核心服务的资源压到刚好够日常用，大促前一周自动打开弹性扩容的阈值，等大促结束流量回落，再自动把多余的资源收回来。但也别觉得上了弹性伸缩就万事大吉——之前有个团队开了弹性伸缩，结果触发条件设得太灵敏，流量稍微抖一下就批量加机器，加完没十分钟流量掉了，又批量把机器杀掉，来回折腾了一上午，光扩容的手续费就花了小两万，还中断了好几个正在处理的请求。
上次撸串的老周，今年618前没再盲目把机器翻倍。他们拉了过去一整年的流量波动数据，把每个服务的真实容量摸了个透，平时把资源利用率稳在40%左右，大促前三天按预估峰值留了30%的冗余，最后实际流量超了预估的15%，系统稳稳扛住了。这个月算下来，机房成本比去年少了快30%。
他说，以前总觉得容量规划是个算数字的苦差事，现在才明白，这事儿最核心的从来不是算的有多准，是你敢不敢直面那些藏在监控曲线下面的真实细节——别为了怕担风险就堆一堆没用的冗余，也别为了省那点钱把系统逼到悬崖边上。