巡检照片的存储治理：按月归档与配额告警

原创

节点恒存

发布于 2026-10-16 16:37:36

390

运维做久了都会遇到同一件事：系统里的照片越攒越多，某天磁盘告警一响，才发现三年巡检照片几十万张，把应用服务器硬盘塞满了。我们厂的报修和巡检系统去年就撞上了这堵墙。这篇文章记录那次照片存储治理的全过程。结论先行：照片存储要的不是一次性清理，而是一套自动分桶归档加配额告警的机制，让存储自己管理自己，人只处理告警，不做搬运工。

一、磁盘告警那天

1.1 一次差点酿成的事故

那天下午报修系统突然卡顿，一查磁盘，应用服务器数据盘用到九成七，罪魁是三年的巡检和报修照片，四十几万张，塞满了本地目录。再涨几个点，数据库写日志都要失败，那才是真正的事故。紧急清理了一批明显无用的照片，暂时续命，但谁都清楚，不建立机制，同样的告警一年后还会再响。

1.2 照片为什么会失控

复盘发现失控有三个原因。头一个，拍照是刚需：巡检要拍、报修要拍、维修完成要拍前后对比，一线已经养成了拍照习惯，这本身是好事。第二个，没人删照片：照片是工单附件，工单是业务记录，谁都不敢拍板删，只能让它躺在盘里，一躺就是几年，谁上任谁接着供着。第三个，全存一处：四十几万张照片全在应用服务器本地盘，没有分层没有归档，热数据冷数据挤一个屋，高速存储的钱花在常年没人看的老照片上，贵的地方放错了东西。

1.3 治理目标定三条

目标定得克制：一线拍照习惯不动，业务记录不删；存储自动分层，冷照片自动挪走；磁盘用量有水位告警，提前预警而不是事后救火；另外动作要轻，一线只管拍照，治理对他们必须是透明的，多一个步骤就多一分推行阻力。克制的目标很重要，治理方案一旦要求改变一线习惯或者删除业务数据，推行的阻力会大到让方案流产。

二、归档机制设计

2.1 冷热分层的分界线

照片的使用规律很清晰：工单创建后的头一个月，照片会被反复查看，对账、验收、争议核对都发生在这个窗口；一个月之后，查看频次断崖式下跌；三个月以上的照片，一年也点不开几次。据此定分层：三十天内热照片留在本地盘，保证查看速度；三十天以上转温，挪到独立的存储服务；一年以上转冷，压缩后进归档区。分层的意义是让贵的高速存储只服务真正被访问的数据。

2.2 按月分桶的目录结构

归档不是把冷照片倒进一个大池子，而是按月分桶：

archive/
  2026-07/
    repair/     报修照片
    patrol/     巡检照片
  2026-08/
    repair/
    patrol/

按月分桶的好处是删留决策有清晰的边界：政策要求工单附件保留两年，到期整桶处理，不用在几十万张照片里逐张筛选。桶内再按业务类型分目录，报修和巡检各自独立，排查问题时直达。目录结构的本质是给未来的自己留检索的路，结构乱了，归档就只是换了个地方堆放，将来想按时间清理或者按类型检索，都得重新人工梳理一遍。

2.3 自动归档任务

归档用每日定时任务执行，核心逻辑几十行：

function archivePhotos():
  cutoff = now() - 30 days
  batch = query "SELECT id, path, biz_type, created_at FROM photo
                 WHERE archived = 0 AND created_at < cutoff LIMIT 500"
  for p in batch:
    target = "archive/" + monthOf(p.created_at) + "/" + p.biz_type
    moveObject(p.path, target)
    update photo set archived = 1, path = target where id = p.id
  if batch.size == 500: scheduleNext(10 min)   # 还有存量，稍后继续

两个细节。每次只搬五百张，搬完歇口气，避免归档任务把存储和数据库拖出高峰压力；工单表的照片字段记的是逻辑路径，搬家后只改路径记录，业务代码零改动，查看时网关自动按新路径取。这套任务跑了半年，没有一次影响白天高峰期的系统使用，归档任务还自带失败重试，个别文件搬移被占用时跳过下轮再补，不卡死不丢件。

2.4 压缩与缩略图

冷归档前统一做两件事：原图压缩到合理画质，照片是取证用的，不是办影展，压缩后体积普遍缩到三成；同时保留一张小缩略图，工单列表页只加载缩略图，点开才看大图。就这两个动作，归档区总体积省了一多半，列表页加载速度也快了一截，存储治理顺手把前端体验也治了，一线点开工单列表，缩略图秒开，再也不用等着一张张原图慢慢爬出来。

三、配额与告警

3.1 三道水位线

告警按三道水位设计：七成，提示级，通知运维群，确认增长速度是否异常；八成五，警告级，通知到人并要求给出处置计划；九成五，严重级，通知部门负责人，自动暂停归档写入之外的临时文件写入，保住系统运行底线。水位线的关键是梯度和提前量，七成就开始行动，永远不让九成五真的到来。

3.2 按桶配额而不只看总量

总量告警之外，每个业务桶单独设配额：巡检照片每月上限、报修照片每月上限分开算。分桶配额能在头一时间发现异常增长源——某条产线的点检相机出问题每小时拍几百张，总量告警要月底才看出来，分桶配额当天就亮黄灯。告警要能回答一个问题：是谁在涨。答不出这个问题的告警，只是噪音，定位不到源头的水位告警，运维看完也只能干着急。

3.3 一次真实的告警处置

机制上线后触发过一次警告级告警：某月巡检照片量翻倍。按桶定位到一条新产线，到场一看，新装的巡检点位光线暗，点检员拍一张看不清就连拍多张，单点照片量是别处的五倍。处置很轻：给该点位补了照明，拍照提示里加了光照不足的提醒，次月照片量回落。没有这次分桶告警，这个五倍异常会安静地吃掉存储，直到下一次九成七的告警把人吓一跳。

四、治理后的状态

治理后本地盘占用稳定在三成以下，归档区按月增长、可预期可预算，年度存储成本头一回能提前算出来。工单照片的查看体验没有变化，一线甚至没感知到归档的存在——最好的治理就是无感。另外意外收获是备份提速：备份窗口从七小时缩到三小时，因为热数据区小了，备份只盯热区加增量，冷归档区按桶做一次性全备，每月只动新增桶。

五、总结

照片存储治理的框架就三句话：冷热分层，让快存储服务热数据；按月分桶，给未来的删留和检索留好边界；梯度告警，让增长异常自己冒头。技术实现加起来不过百来行脚本，真正的功课是摸清自己业务的数据访问规律——三十天是冷热线，两年是保留线，这些数字每家不一样，照抄别人的参数不如看自己的访问日志。存储问题和设备保养一样，平时不治，爆时救火，代价从来不对称，平时的百来行脚本，抵得上事发时的通宵救火。