对齐要翻译什么
业务说的是体验，存储说的是指标，两者之间隔着应用、中间件与数据库。对齐的过程就是把一条链路拆开：业务响应时间由哪几段构成，其中哪几段受存储影响，存储侧对应看什么指标、在哪里测。只有把口径、测量点和责任边界写清楚，出现性能争议时才有共同的判断依据，而不是各拿一套数据争论。
基本信息
| 翻译链条 | 业务指标 → 应用处理与调用 → 数据库与中间件 → 存储延迟与吞吐指标 |
|---|---|
| 口径约定 | 分位数与统计窗口、采样时段、聚合方式，必须与业务体验对应的口径一致 |
| 测量点 | 应用侧与存储侧同时采集，差异来源需能解释 |
| 责任边界 | 存储达标但业务不达标时，排查分工与证据要求提前约定 |
| SLA 要素 | 目标值、测量方式、统计周期、上报机制、超出后的处置流程 |
| 常见错位 | 业务关心最慢的那部分请求，而存储报表只给平均值 |
典型使用场景
- 与业务方约定存储服务级别，需要把主观体验变成可测量指标时
- 性能投诉界定责任，需要判断问题落在应用侧还是存储侧时
- 项目验收，需要明确验收口径与测量方法时
- 容量采购申请，需要用业务指标反推存储需求时
- 跨团队协作中统一数据口径，避免引用不同来源争论时
两侧同时取数便于对齐
两侧同时取数便于对齐
# 应用侧：记录关键请求的实际耗时分布（由应用或链路监控提供）
# 存储侧：同一时间窗内采集分位数，便于逐段对齐
iostat -x 1 300 > /tmp/sla-iostat.txt
fio --name=probe --rw=randread --bs=8k --iodepth=16 --runtime=60 \
--percentile_list=50:99:99.9 --direct=1 --filename=/data/probe.bin
# 对齐要点：时间窗一致、口径一致、负载状态一致
# 结论段落写入：哪一段占了多少耗时、责任归属与依据业务表述与存储指标对照
| 业务表述 | 涉及环节 | 对应存储指标 |
|---|---|---|
| 提交要秒级返回 | 数据库提交与日志写入 | 写延迟分位数与 fsync 耗时 |
| 批量任务要按时完成 | 顺序吞吐敏感 | 带宽与持续吞吐能力 |
| 偶尔卡顿不可接受 | 长尾敏感 | P99 与 P99.9 延迟 |
| 并发用户增多后变慢 | 排队相关 | 队列深度、利用率与延迟关系 |
存储达标不等于业务体验达标：应用并发、连接池、锁竞争、代码路径都可能成为瓶颈。SLA 对齐的意义在于能快速判断问题落在哪一段，而不是把责任推给其中一方。
以平均延迟承诺业务体验几乎没有意义：用户体验由最慢的那部分请求决定。SLA 中应明确采用分位数口径，并说明统计窗口与采样方式。