容量 70% 本身不能说明太多：如果每天增长 2%，风险很高；如果半年几乎不变，风险可能并不紧急。巡检应同时记录当前值、趋势、业务影响和处理建议，而不只是给出红黄绿状态。
READING NOTES
本文要点
- 用增长趋势和故障余量判断容量，而不是只看阈值
- 任何时延异常都要同时查副本、硬件、网络和后台任务
- 报告首页只放真正需要决策的风险
01｜将风险分成三档
立即处理表示已经影响冗余或业务；计划处理表示当前可用，但会在可预测时间内越线；持续观察表示暂时无需变更，但要保留趋势。每项风险都写触发条件，不凭感觉定级。
02｜五组信号一起看
从 CloudTower 和集群视图检查容量、副本、性能、硬件和网络。发现存储时延升高时，不要急于下结论，还要继续确认是否存在重建、磁盘错误、上联丢包或业务突发 IO。
| 信号组 | 需要记录 | 常见后续动作 |
|---|---|---|
| 容量 | 逻辑/物理用量、增长率、故障后余量 | 清理、扩容、调整计划与期限 |
| 副本 | 降级对象、重建状态、保护策略 | 先恢复冗余，再处理容量或硬件 |
| 性能 | 时延、IOPS、吞吐、热点虚拟机 | 关联后台任务和业务时间线 |
| 硬件 | 磁盘、内存、电源、风扇、BMC 事件 | 收集日志，安排备件和窗口 |
| 网络 | 上联、丢包、错包、MTU、聚合 | 平台与交换机双向核对 |
03｜报告首页只写三件事
第一，当前最高风险是什么；第二，建议先做什么；第三，不处理会怎样。详细截图、正常项和原始数据放附录。这样负责人打开报告就能决定是否申请扩容或变更，而不是在几十页截图里找重点。
风险：集群物理容量增长过快
证据：当前 71%，近 30 天增长 11%
影响：按当前速度约 7 周进入预警水位
建议：本周确认清理项，2 周内完成扩容评审
责任人：平台 / 业务 / 采购
验证：容量趋势回落或扩容资源上线04｜巡检结果要回到工单
巡检报告发出去不是结束。风险项要进入工单或变更，完成后补验证结果。重复出现的问题转成监控规则或 SOP；采集过程稳定的，再写脚本自动生成基础数据。
FIELD NOTE一份好巡检不是证明系统今天正常，而是让团队更早知道下一个风险在哪里。
SOURCES / 资料核对
相关官方资料
产品功能会随版本和授权变化。下面列出撰写时核对的资料， 实际交付仍以项目版本的兼容矩阵和正式文档为准。