业务高峰前的容量检查清单

清单放在最前面，方便直接抄走：资源水位、依赖服务、降级预案、值班安排，四块各过一遍，大促前的准备基本就齐了。 一、资源水位 提前一周开始看监控的历史峰值。CPU 和内存的日常峰值除以总容量，余量不足三成就该扩容；内存重点看可用量而不是总量，free -m 输出里的 available 才是真正能用的部分，缓存占用的内存不算危险，应用占用的才要盯。磁盘用 df -h 确认剩余超过 20%，别让促销当天的日志把盘写满；带宽拿去年峰值乘以预估增长率，对比实际购买值，不够就临时升配。云服务器升配大多支持在线操作，提前两天完成并留一天观察，不要卡在开始前一小时才动。 二、依赖服务 主服务扛得住，从属服务掉链子照样出事。逐项确认：数据库 max_connections 的当前用量离峰值还有多少余量；Redis 的 used_memory 离 maxmemory 多远；第三方接口的调用限额、超时和重试参数。凡是依赖外部接口，都要假设它会慢——超时设短一点、重试设少一点，别让一个外部接口拖住整条请求链。 三、降级预案 高峰期核心链路只有一条：能浏览、能下单、能支付。评价、推荐、统计这类非核心功能，准备好开关，出问题直接关掉；开关做成配置项，改一行就生效，比临时改代码发版快得多。再准备一个静态兜底页，数据库顶不住时先让用户看到东西。预案要真的演练过一次，只写在纸上的预案等于没有。 四、值班安排 告警阈值提前收紧，值班表写清联系人和升级路径，什么情况找谁、多久没人响应就升级。回滚和开关的操作步骤写成文档，值班的人照着能执行，不依赖"问一下写代码的同事"。 有条件就压测一轮，ab -n 5000 -c 200 http://127.0.0.1/ 这类简单压测也能暴露明显短板。准备大促和准备考试是一个道理，清单过完一遍，心里就有数了。