换算的基本链路
业务语言到存储指标之间隔着几步换算。业务量先转成事务或请求数，例如每秒订单数、并发用户数、每小时入库文件数；再结合每个请求触发的读写次数与 IO 大小，得到 IOPS 与带宽需求；再乘以峰值系数得到高峰时段的压力；最后按增长预期与应用效率（如缓存命中率、批量合并程度）做修正。可用性要求则从另一个方向推导：允许的中断时长与数据丢失点对应到冗余等级、副本数量与备份频率。整个换算过程应把假设与数据来源写下来，因为任何一步的假设变化都会显著改变结论，而验收时这些假设就是判断依据。
换算链路与常见系数
| 步骤 | 输入 | 输出 |
|---|---|---|
| 业务量转换 | 每秒事务数、文件数、用户数 | 每秒请求数 |
| IO 特征映射 | 每个事务的读写次数与大小 | IOPS 与带宽需求 |
| 峰值修正 | 忙闲比、峰值系数 | 高峰时段需求 |
| 效率折算 | 缓存命中、批量合并、压缩 | 实际落到存储的压力 |
| 可用性映射 | 允许中断时长与数据丢失点 | 冗余等级与备份策略 |
基本信息
| 数据来源 | 应用日志、数据库统计、主机性能监控与业务侧指标 |
|---|---|
| 关键假设 | 峰值系数、读写比例、平均 IO 大小与缓存命中率 |
| 修正项 | 业务增长、数据保留期与冗余开销 |
| 输出结果 | 容量需求、性能需求与可用性需求的量化指标 |
| 可信度要求 | 每个数字都能追溯到来源或明确标注为假设 |
典型使用场景
- 新系统上线：没有历史数据时按业务模型推算，并预留验证阶段
- 系统迁移：用现状监控数据直接换算，可信度最高
- 性能问题定位：把实测值与推算值对比，找出偏差环节
- 采购需求书编写：以量化指标代替主观描述，便于供应商响应与验收
- 容量与性能复盘：用上线后的真实数据修正当初的假设
峰值系数不能拍脑袋：应按业务的真实忙闲分布取值，例如交互式业务高峰集中在几个小时内，批量任务集中在夜间。把峰值按全天平均摊开会严重低估压力。
换算结果应给出区间而非单点：用悲观、中性、乐观三种假设分别计算，得出需求范围，再按可扩容性决定采购节奏。这样能降低单一假设失准带来的风险。