用 OBS 生命周期与版本控制，把对象存储成本和误删风险一起管住

对象存储最常见的浪费不是单价贵，而是数据一直在高成本层级里沉睡，同时历史版本又在悄悄计费。本文以华为云 OBS 为例，讲一套可落地的组合：按前缀分层、生命周期自动降级与过期、版本控制加非当前版本清理，以及用桶策略和防误删做兜底。先按访问特征给数据分桶前缀。热数据如用户头像原图近期访问、订单附件近期调用，放在标准存储并保持较短缓存；温数据如上月报表、历史工单附件，30 天后转低频访问存储；冷数据如审计日志、备份快照，90 天后转归档存储，极少读取的合规存档可再转深度归档。分层的前提是前缀清晰，例如 uploads/、reports/、logs/、backups/ 各自独立，否则一条生命周期规则会误伤仍在频繁读取的对象。生命周期规则要写成时间线，而不是一次性清理。示例思路：对象创建后 30 天转为低频访问，90 天转为归档，180 天后对不再有业务价值的临时文件过期删除；对 logs/ 前缀单独设更短的保留期，例如 30 天转低频、90 天过期，避免日志无限增长。制定规则前先在控制台核对该桶的访问统计和存储量分布，确认没有把仍被高频读取的共享文件划入归档，因为归档取回需要时间且可能产生取回费用，频繁取回反而比留在低频层更贵。版本控制是防误删的保险，但保险本身也要设保费上限。开启版本控制后，每次覆盖都会产生一个非当前版本，长期不清理会让存储量成倍增长。合理做法是：对核心业务桶开启版本控制，同时给非当前版本设单独的生命周期，例如非当前版本 30 天后转低频、90 天后过期删除；对临时上传桶则不开启版本控制，改用上传后校验与失败重传来保证正确性。删除操作也要分级：普通删除只产生删除标记，真正需要彻底删除历史版本时，应由两名负责人复核对象键与版本 ID，并先在小范围前缀上验证。最后做上线前检查清单：一是按桶统计当前版本与非当前版本的占比，确认非当前版本规则已生效；二是抽查三个前缀，确认对象确实按预期进入了低频或归档层；三是模拟一次误删与恢复，确认删除标记可以撤销、历史版本可以取回；四是把生命周期与版本策略写进团队文档，注明负责人、保留期和例外审批流程。成本优化不是一次性的清理，而是让每一类数据都有明确的生命周期，这样既能省下沉睡数据的费用，也能在误删时有版本可回。