容量预测必须基于90天关键路径增量数据的时间序列斜率拟合，而非当前df使用率；需排除reserved blocks、deleted文件等干扰，绑定具体指标与触发条件，并用UTC时区处理时间序列。
容量预测必须基于历史增长趋势，不能只看当前使用率
很多运维人员看到 df -h 显示根分区用了 75%，就以为还有 3 个月缓冲期——这是最典型的误判。真实风险取决于业务写入速度：日志轮转频率、数据库归档节奏、用户上传量是否随活动爆发式增长。必须提取至少 90 天的 /var/log、/var/lib/mysql、/data/uploads 等关键路径的每日增量数据，用时间序列方式拟合斜率。
实操建议：
- 用
find /var/log -type f -mtime -1 -print0 | du -ch --files0-from=- | tail -n1统计单日日志增量（注意排除压缩归档） - 对 MySQL，优先监控
information_schema.TABLES.DATA_LENGTH + information_schema.TABLES.INDEX_LENGTH按表聚合的周环比变化 - 避免直接用
du -sh /，它包含缓存、未释放句柄等临时占用，会干扰趋势判断
df 命令输出的 “Available” 不等于真正可用空间
df 显示的 Available 列默认保留 5% 的 reserved blocks（ext4 默认），且不计入已被删除但进程仍打开的文件（lsof +L1 可查）。当业务进程持续写入大文件后异常退出，这类“幽灵占用”可能高达几十 GB，而 df 完全不体现。
实操建议：
- 检查 reserved blocks 占比：
tune2fs -l /dev/sda1 | grep "Reserved block count"，生产环境可酌情调低至 1%（tune2fs -m 1 /dev/sda1） - 确认是否有未释放大文件：
lsof +L1 | awk '$7 ~ /[0-9]+[G|M]/ {print $0}' - 对比
df和du -sh /* 2>/dev/null | sort -hr差值 >5GB 时，必须排查 inode 泄漏或 deleted 文件
业务增长说明文档必须绑定具体指标和触发条件
“预计 Q3 用户量增长 30%” 这类模糊描述无法驱动容量动作。必须明确：该增长体现在哪个目录？对应磁盘 IO 增幅多少？是否触发自动扩容？例如：“支付订单量每增加 1 万/日，/data/pg_xlog 日增 1.2GB，当连续 3 天日增 >2.5GB 时，触发 RDS 存储扩容流程”。
实操建议：
- 每个业务线提供三类基线值：日均写入量（GB）、峰值 IOPS（次/秒）、单次事务平均写入大小（KB）
- 在监控系统（如 Zabbix/Prometheus）中为上述指标设置阶梯告警：
disk_write_bytes_total{mountpoint="/data"} > 50e9（日写入超 50GB） - 禁止在文档中出现“视情况而定”“后续评估”等无约束表述；所有增长预估需附带验证方法（如压测报告编号或灰度集群数据）
Python 脚本做趋势预测要避开 datetime 库的时区陷阱
用 pandas 读取日志分析结果时，若原始时间戳无时区信息（如 2024-06-01 00:00:00），pd.to_datetime() 默认按本地时区解析，跨夏令时或服务器时区不一致时会导致日期错位，拟合直线斜率失真。
实操建议：
- 强制指定 UTC 时区：
pd.to_datetime(df['date'], utc=True) - 用
scipy.stats.linregress()替代sklearn.linear_model.LinearRegression，前者对小样本（ - 必须校验 R² 值：
r_value**2 时拒绝预测，改用人工标注拐点（如大促前一周）
import pandas as pd from scipy import statsdf = pd.read_csv('disk_growth.csv') df['date'] = pd.to_datetime(df['date'], utc=True) slope, intercept, r_value, p_value, std_err = stats.linregress( df['date'].astype('int64') // 109, # 转为 Unix 时间戳秒级 df['used_gb'] ) if r_value2 > 0.8: days_to_full = (df['total_gb'].iloc[0] - df['used_gb'].iloc[-1]) / slope
实际执行时，最容易被忽略的是业务侧提供的“增长说明”往往未经存储层验证——比如前端说“上传功能上线”，但没说明默认保存 30 天还是永久，也没提缩略图是否额外占用 3 倍空间。这类信息差必须在容量评审会上当场对齐，不能依赖事后补救。
