容量预估不足是大促雪崩主因，需从历史数据准确性、资源覆盖全面性、关键路径完整性三维度排查；要分时段分析流量、验证用户行为迁移、检查依赖服务响应漂移；须清点连接池、中间件、内核级等隐性瓶颈；核心链路须拆解压测热点key、下游兜底、日志监控等单点能力。
容量预估不足是大促期间服务雪崩的常见根源——不是系统没做防护，而是压根没料到流量会冲破设计水位。排查要从“历史数据是否被用准”“当前资源是否被看全”“关键路径是否被漏算”三个维度切入，不靠猜测，靠证据链。
回溯真实流量基线，识别预测偏差点
很多团队直接拿“去年峰值×1.5”拍板今年容量，但忽略了业务结构变化。需拆解三类数据：
- 分时段粒度还原：不止看全天峰值，要拉出每5分钟的QPS、TP99、错误率曲线，定位“秒级脉冲”（如00:00整点抢券）是否被平滑掉；
- 用户行为迁移验证：对比去年同活动期新老用户占比、页面跳转路径（如更多人从APP首页直跳秒杀页，绕过广告位缓存），判断CDN/网关/服务层压力分布是否已偏移；
- 依赖服务响应漂移：检查上游调用（如风控、实名认证）的平均耗时和超时率是否比去年上升20%以上——即使自身QPS未超，等待时间拉长也会吃光线程池。
清点全链路资源瓶颈，而非只盯CPU和内存
雪崩常发生在“看不见”的资源上。重点扫描：
- 连接池与线程池饱和度：查数据库连接池活跃数是否持续＞90%，HTTP客户端（如OkHttp）连接池是否频繁创建新连接；
- 中间件水位异常：Redis连接数、Pub/Sub频道积压量、RocketMQ消费者堆积延迟（>10s即危险）；
- 内核级限制：文件句柄（ulimit -n）、TIME_WAIT端口耗尽（netstat -ant | grep TIME_WAIT | wc -l）、本地DNS缓存失效导致解析延迟飙升。
验证核心链路单点容量，拒绝“平均主义”假设
把“下单”当整体压测会掩盖致命短板。必须拆解并单独验证：
- 热点Key穿透能力：模拟10万并发查同一商品ID，观察Redis QPS、后端DB慢查询数量——若缓存击穿未防护，这里就是雪崩起点；
- 下游强依赖兜底时效：关闭支付服务，测下单接口降级响应时间是否仍＜200ms（否则线程池会被拖死）；
- 日志与监控写入吞吐：高并发下ELK或SLS日志采集是否丢数据？监控埋点上报失败是否触发重试风暴？这类“自产流量”常被忽略。
排查结论不能止于“容量不够”，而要明确到“XX服务在YY场景下，ZZ资源（如MySQL连接数）将在第N分钟耗尽”。只有定位到具体资源、具体时间点、具体触发条件，扩容和限流才有靶心。
