用 OBS 生命周期规则配合 CBR，把冷数据成本压下来：一次账单复盘

一、先把账单拆开看

很多团队看到 OBS 账单上涨，第一反应是「容量涨了」，但真正拉高费用的往往不是容量本身，而是三件事叠加：标准存储里长期不访问的历史对象、频繁的 LIST 与 GET 请求、以及为「保险」而全量保留的备份副本。把账单按存储类别、请求类型、流量方向三个维度拆开，通常能立刻看到一块明显的沉淀数据。

二、判定冷数据

判断标准不要凭感觉，用访问日志说话：连续 30 天没有 GET 请求、且对象大小分布以归档类文件为主的前缀，基本可以判定为冷数据。建议先在测试桶上跑一轮统计，再决定分层阈值，避免把仍在被业务读取的对象误转成低频访问。

三、生命周期规则怎么配

• 第 0 天：对象写入标准存储，保证在线业务读性能。
• 第 30 天：转入低频访问存储，适合「偶尔读一次」的报表与日志。
• 第 90 天：转入归档存储，读取需要先恢复，适合合规留存。
• 第 365 天：过期删除，或用深度归档承接长周期留存。

规则按前缀匹配，一个桶可以挂多条规则。要点是每条规则只做一件事，命名里带上前缀和天数，出问题时能一眼定位是哪条规则在生效。

四、备份侧不要全量堆副本

CBR 的价值在于恢复点，不在于副本数量。按业务分级设置保留策略：核心库保留 30 天每日备份加每月全量，普通业务保留 7 天，测试环境保留 3 天即可。备份策略与生命周期规则要分开评估——备份产生的对象同样会进桶，同样受生命周期影响，两者叠加才决定最终成本。

五、落地后的观察指标

配置完成后至少观察两周：标准存储容量是否按预期下降、归档恢复请求是否在可接受时间内完成、以及恢复演练是否真的能拉起业务。成本优化的前提是恢复能力没有被削弱，这一点必须用一次真实恢复演练来验证，而不是看控制台的绿色对勾。

六、几个容易踩的坑

一是把生命周期规则直接挂到生产桶而不做灰度，转档后才发现某个离线任务仍在读归档对象；二是忽略请求费用，低频访问的取回费用在访问量突增时会反超存储节省；三是备份策略与生命周期规则互相打架，导致备份对象被提前删除。规避方式统一：先在测试桶验证，再按前缀小范围放开，最后全量。