扩容最常见的错误，是等到告警响了才动手——那时能选的窗口往往只剩周末凌晨。真正省事的做法是把容量当成一条曲线来管：先知道它每个月涨多少，才能提前三周安排动作，而不是被动救火。
一、先算三个数：水位、速度、余量
容量评估不需要复杂模型，把三个数写进台账就够用：当前水位、月均增长速度、按当前速度还剩多少周。第三个数是关键——它把技术指标翻译成了决策语言。
- 当前水位：分区分开看（系统、数据、日志、备份各不相同）
- 增长速度：取最近 90 天的数据做线性拟合，别用单月数据
- 剩余周数：把"还剩 40GB"换成"还能撑 6 周"，优先级立刻清楚
一条经验
增长从来不是匀速的。旺季、审计期、新系统上线都会把斜率抬起来，所以评估时给增长速度留 30% 的余量，比事后解释为什么算错了轻松得多。
二、按资源类型分别判断
不同资源的扩容触发点完全不同，混在一起谈容易漏项。下面这张表可以直接抄进台账，把"触发线"改成你们自己的标准。
| 资源类型 | 先看什么 | 扩容触发线 | 首选动作 |
|---|---|---|---|
| 磁盘容量 | 分区水位与增长斜率 | 数据分区超 75% | 加盘扩卷或归档冷数据 |
| inode | 文件数量与小文件占比 | 使用率超 80% | 清理缓存、归档小文件 |
| 内存 | 驻留内存与 swap 活跃度 | 常态超 80% 或频繁 swap | 加内存，先查内存泄漏 |
| CPU | 负载 1/5/15 分钟值 | 持续高于核数的 70% | 先优化，再考虑加核 |
| 连接与端口 | 并发会话数、TIME_WAIT | 接近上限的 80% | 调参数或做分流 |
三、动手之前先确认四件事
- 备份可用：不是"有备份"，而是最近一次恢复演练成功过
- 窗口明确：谁在用、几点停、停多久、谁批准
- 兼容性确认：硬盘型号、固件版本、阵列卡在不在兼容列表里
- 变更留痕：变更单、操作步骤、回退方案，缺一项就不要开工
四、实施窗口怎么选
选窗口的原则是"业务低谷"，而不是"人少的时段"。下午三点办公室里人不多，但业务系统正在跑日结；凌晨两点没人加班，恰恰可能撞上批处理任务。
- 避开批处理、备份、对账等定时任务时段
- 预留回退时间：计划停 1 小时，就申请 2 小时窗口
- 知会到使用部门，不能只通知 IT 内部
五、扩容之后要验证什么
- 容量确实生效：文件系统、卷组、阵列层面都对
- 系统日志无新增告警，服务进程与端口正常
- 性能回到基线：响应时间、IO 等待、内存命中率
- 台账同步更新：容量、增长斜率、下一次评估时间
最后一句：扩容完成不等于结束。把这次的变化写进台账，下一次评估才有参照；否则半年后又是"感觉快满了"，重新从零开始判断。
#容量管理#服务器扩容#运维台账#变更管理
