报告要给结论
存储报告常见的失败形态是把采集数据整页贴出来，读者看完仍不知道要不要买盘、要不要优化。有效的报告围绕两个问题组织：容量侧给出趋势与净增预测，说明按当前增长多久需要扩容以及采购与实施需要的提前期；性能侧给出基线、偏离项与热点分布，说明瓶颈在哪个层次、下一步该验证什么。
基本信息
| 报告要素 | 统计周期、数据口径与采样方式、基线与对比、趋势预测、异常项、结论与建议 |
|---|---|
| 口径一致性 | 采样时段、负载模型、统计粒度一旦确定就不随意变更 |
| 容量报告内容 | 总量与已用、增长速率、净增预测、扩容提前期、回收空间 |
| 性能报告内容 | IOPS 与带宽、平均与 P99 延迟、热点卷、偏离基线的项 |
| 受众区分 | 管理层需要结论与预算依据，技术侧需要明细与验证路径 |
| 关联信息 | 同期业务变更与重大事件需附注，否则趋势变化无法解释 |
典型使用场景
- 季度容量汇报与扩容预算申请，需要量化增长与时间点时
- 性能投诉复盘，需要证明瓶颈层次与变化时间点
- 项目验收交付，需要提供性能达标与容量满足要求的证据时
- 容量治理效果验证，展示回收或优化前后的对比时
- 跨团队协作时统一口径，避免各方引用不同数据争论时
固定口径的采集方式
固定口径的采集方式
# 固定时段采集，避免不同报告口径漂移
iostat -x 1 300 > /var/log/report/iostat-$(date +%F).log
# 容量与 inode 一并采集，两者都要纳入预测
df -h > /var/log/report/df-$(date +%F).log
df -i >> /var/log/report/df-$(date +%F).log
# LVM 精简池占用，用于超配与回收分析
lvs -a -o name,lv_size,data_percent > /var/log/report/lvs-$(date +%F).log
# 结论段落里务必写明：口径、对比基线与本次异常项两类报告的核心内容
| 报告 | 核心内容 | 决策用途 |
|---|---|---|
| 容量报告 | 已用、增长率、净增预测、提前期 | 采购排期与预算申请 |
| 性能报告 | 延迟分位、热点卷、偏离基线项 | 优化方向与容量配比调整 |
| 趋势分析 | 多期对比与拐点识别 | 发现隐性退化与突发事件 |
| 异常说明 | 偏离项与其关联变更 | 解释数据波动、避免误判 |
报告的价值随口径稳定性上升：同一个口径连续几期的数据能看出趋势，口径频繁变化的报告只能说明当下，无法支撑预测。
只报平均延迟的性能报告会系统性掩盖长尾问题，业务投诉与报告结论长期对不上，最终导致报告失去可信度。分位数必须与平均值一起给出。