巡检要做的事
存储故障大多有前兆：错误计数缓慢增长、路径偶尔切换、延迟基线悄悄上移。巡检就是把这些前兆固定地采集下来，形成可对比的时间序列。因此巡检的核心不是现场看几眼状态灯，而是按清单采集指标、与上次结果对比、把变化点转成待办事项，并留档可追溯。
基本信息
| 巡检范围 | 硬件与告警、盘与介质错误计数、冗余与路径状态、性能基线、容量、错误日志、配置与版本、备份可用性 |
|---|---|
| 频率分层 | 日巡只看变化快的项，周巡覆盖趋势项，月巡做完整版 |
| 执行方式 | 脚本自动采集为主，人工复核异常项与物理环境 |
| 核心方法 | 与上次结果和设计基线对比，而不是与固定阈值单点比较 |
| 输出物 | 采集归档、变化清单、待办与责任人、处置结论 |
| 闭环要求 | 上次发现问题必须有跟踪结论，未闭环项本轮继续列出 |
典型使用场景
- 月度例行巡检，需要一份可交付的完整状态报告时
- 重大变更后做专项巡检，确认系统回到稳态时
- 接手新系统前做健康摸底，建立第一份基线时
- 审计或迎检，需要证明巡检制度实际在执行时
- 长期无人管理的环境，用一次完整巡检发现积压风险时
一份可落地的采集清单
一份可落地的采集清单
# 统一归档目录，文件名带日期，方便逐期对比
D=/var/log/storage-inspect/$(date +%F); mkdir -p $D
# 阵列与盘状态
storcli /c0 show all > $D/array.txt
smartctl -A /dev/sdb > $D/sdb-smart.txt
# 冗余与路径
multipath -ll > $D/multipath.txt
cat /proc/mdstat > $D/mdstat.txt
# 容量与性能快照
df -h > $D/df.txt; df -i > $D/df-inode.txt
iostat -x 1 5 > $D/iostat.txt
# 严重日志
journalctl -p err --since '7 days ago' > $D/errlog.txt巡检项与判据
| 巡检项 | 判据 | 异常处置入口 |
|---|---|---|
| 盘与介质计数 | 与上期对比，是否新增增长 | 介质扫描与预防性更换评估 |
| 冗余与路径 | 路径数、状态是否与设计一致 | 路径故障排查 |
| 性能基线 | 是否持续偏离历史区间 | 瓶颈分层排查 |
| 容量与 inode | 增长速率与剩余可用期 | 容量治理与阈值调整 |
| 配置与版本 | 是否与台账基线一致 | 配置备份与变更管理 |
巡检清单要按频率分层，否则一张几十项的清单很难长期执行。日巡只留变化快的三到五项，剩下的放到周巡与月巡，才能持续下来。
巡检本身也消耗存储资源：全盘扫描类项目要安排在业务低峰，并避免与重建、扩容、备份窗口重叠，否则巡检会成为新的风险来源。