容量规划是一线技术人绕不开的隐形考题

上周跟在南京做政务系统运维的老周吃饭，他刚熬完连续一周的晚班，眼下的乌青快垂到下巴。 刚过去的医保集中缴费期，他差点在系统上栽个大跟头。年初做预算的时候，领导拍板让他按去年的峰值留30%的资源冗余，他当时觉得稳妥，把机房的云主机配额、数据库连接池上限、消息队列的堆积阈值全按这个数配好了。结果今年政务端突然加了个线上预约取号的模块，流量比去年同期涨了1.8倍，核心接口的响应时间从200ms直接飙到2s，窗口端的群众排起了长队，他带着团队熬了三个通宵，临时申请扩容才把窟窿补上。

机房里的冗余从来不是越多越好

很多人对容量规划的第一反应，就是多买机器，多留冗余，总觉得冗余留的越多系统越稳。 根本不是这么回事。 那次补窟窿临时申请的8台云主机，等缴费高峰过去之后，日常CPU使用率不到5%。财务月底拉账单的时候找过来，说这部分多花的资源成本，够给整个运维团队发季度绩效奖。老周当时看着账单沉默了半小时，之前他总觉得留的冗余少是自己工作没做到位，现在才反应过来，冗余本身也是有成本的。 更麻烦的是，很多人算冗余的时候，只盯着自己管的那几台服务器的CPU、内存指标，完全漏算了系统里其他环节的承载上限。你以为CPU使用率到70%就是容量红线，没算过数据库的慢查询会占掉多少连接池资源，没算过消息队列的消费速率会不会赶不上生产的速度，更没算过外部依赖的调用配额——之前有个做电商的朋友跟我吐槽，去年618他们所有服务器的水位都健康的很，结果因为支付通道的第三方接口被限了QPS，整个下单链路直接堵死，从技术到产品全链路排查了俩小时才找到问题根源。你说这算容量不够吗？当然算，只是之前做规划的时候，根本没把这些不在自己掌控范围内的资源，算进整个系统的容量盘子里。

压测出来的数字从来不能直接上线

现在很多团队做容量规划的流程很固定：上线前拉个压测脚本，在干净的测试环境把流量打上去，测出来单实例能扛多少QPS，然后按目标峰值乘个固定系数，直接配对应数量的实例。 这种流程算出来的数，从来不能直接当真。 压测环境是什么样的？没有线上跑了半年的脏数据，没有日志组件偷偷占走的CPU，没有偶发的Full GC停顿，没有跨可用区的网络抖动，甚至连测试用的数据库都比线上的配置高两档。我之前见过一个团队，压测的时候测出来单实例能扛2000QPS，上线的时候按1500QPS的承载能力配的冗余，结果上线当天遇到日志组件的内存泄漏BUG，单实例CPU直接被打满到100%，实际承载能力直接砍半，差点把整个系统搞崩。 说白了，压测拿到的理论数值，只是你做规划的起点，不是终点。你得把所有线上可能遇到的意外，都折算成非理想状态的容量损耗。比如你知道上线后有三成概率遇到日志组件占10%的CPU，有两成概率遇到数据库慢查询拖慢15%的响应速度，有一成概率遇到跨区网络延迟涨200ms，这些零零碎碎的损耗加起来，之前算的理论冗余就得打个对折，不然真等问题找上门的时候，你连补窟窿的时间都没有。

没人能一劳永逸算准未来的流量

我见过太多团队，做容量规划的时候总想着一劳永逸。 要一次性把未来半年甚至一年的资源都算准，买对，配好，省得后面跨部门走审批流程被财务卡，省得上线前临时抢资源被其他团队挤兑。哪有这种好事。 你去年算的用户规模涨20%，结果今年突然出了个短视频传播的爆款政务科普，流量直接涨了3倍；你算的核心业务模块占总流量的70%，结果用户全跑去用新上线的预约功能，核心模块的流量直接掉了一半，新模块的带宽直接被打满。变量太多了，根本没人能拿着去年的公式，算准明年的所有需求。 老周现在改了之前的老习惯，再也不搞半年一次的大规模资源核算了。他定了个动态水位监控的周期阈值，每周拉一次各个模块的资源数据，只要某个模块连续3天的水位超过60%，就提前跟云平台申请弹性资源的预留额度，遇到临时的活动或者高峰，就提前一周做小范围的定向压测，再也不搞那种大张旗鼓的全链路压测了。 当然这也是有代价的。运维团队每周要多花4个小时梳理各个模块的水位数据，还要跟各个业务线的开发对接，提前问清楚接下来两周有没有新功能上线、有没有推广活动。但老周算过账，现在每个月的资源成本，比之前那种拍脑袋留50%冗余的模式还降了20%，而且系统再也没出现过因为容量不足导致的宕机。 麻烦在于，很多团队现在还把容量规划当成运维一个部门的事。开发写完代码就扔给运维，说你看着配资源就行。哪有这么简单？你写的代码里有个没加索引的慢查询，一次执行就要占掉100ms的数据库连接时间，运维就算把服务器配到16核，也挡不住你把整个连接池占满。 上周老周给我发消息，说今年的缴费高峰结束，系统跑的稳得很，整个团队没熬一次夜，算下来资源成本还省了小几万。他说现在再也不跟新来的运维讲什么”按峰值留50%冗余”的老经验了，就带着人每周盯着水位，遇到异常就提前调。