为什么指标要写细
存储采购失败的典型形态不是设备不能用，而是「交付的与预期的不是同一件事」。裸容量与可用容量、峰值与稳态、控制器冗余与链路冗余，这些概念在买卖双方的语境里含义并不一致。把指标写成可验证的形式，是减少争议最有效的手段：容量要写明配置某冗余级别后的可用容量与文件系统可见容量；性能要写明 IO 大小、读写比例、并发与要求的时延分位，而不是一个 IOPS 数字；可用性要写明允许的切换时间与演练方式；扩容要写明按什么单位扩展、单次扩展增加多少能力、是否需要停机。
需要写清的指标项
| 类别 | 应写明的要素 |
|---|---|
| 容量 | 裸容量、配置后可用容量、文件系统可见容量与预留比例 |
| 性能 | IO 大小、读写与顺序随机比例、并发、稳态吞吐与高位分位时延 |
| 可用性 | 冗余部件清单、单点故障范围、切换时间与演练要求 |
| 扩展 | 扩容单位、单次扩展幅度、是否需要停机、上限 |
| 运维 | 监控能力、告警项、固件升级方式与责任划分 |
| 服务 | 响应时限、备件方式、现场支持范围与年限 |
基本信息
| 容量口径 | 以可用容量为交付与验收依据，明确扣减项 |
|---|---|
| 性能口径 | 以业务时延目标内的稳态表现为准，而非峰值 |
| 验证方式 | 约定测试脚本、数据集规模与测试时长，双方确认 |
| 扩容预留 | 预先确认后续扩容所需部件与周期 |
| 生命周期 | 明确支持年限与固件更新策略 |
典型使用场景
- 需求书编写：把业务指标转成采购可响应的条目
- 方案比价：统一口径后比较不同方案的等价能力，而不是比较标称参数
- 验收测试：按约定脚本执行并留存记录，作为付款与整改依据
- 扩容谈判：在初次采购时锁定后续扩容的接口、部件与价格机制
- 生命周期管理：约定备件与支持年限，避免设备过保后无支持
性能指标最好附带测试方法：同一句话在不同脚本下测出的结果可能差出数倍。把脚本、数据集与测试时长写进附件，是避免验收争议最实用的做法。
扩容条款常被忽略：部分方案在初次配置时价格优惠，后续扩容必须整套更换或按高价购买。采购阶段应询问扩容的颗粒度与上限，并写入合同。