计算机视觉网站扩容难？三步实现存储零冗余
|
凌晨三点二十，机房空调嗡嗡响得像台老拖拉机，我蹲在B区第三排冷通道里，手电光晃着NAS柜背面——那块贴了三年的蓝胶布又翘起来了，边缘发黄，粘灰。旁边监控屏右下角还留着上个月贴的“U12温度告警线已手动屏蔽”字条，字是小陈写的，他女儿发烧请假三天，走前没撕。 事情是从二十号下午开始的。我原以为只是日常扩容：给CV网站新挂两台GPU节点，加个对象存储桶，顺手把训练数据集镜像过去。结果一执行rsync -av --delete，/data/vision目录底下直接报Input/output error——不是磁盘坏，是inodes用尽。查了下，四万八千个软链接，全指向同一个/srv/images-raw/yyyy-mm-dd/下的重复文件，而那个路径早在六月十七号就被我删过一次。可没人动过清理脚本，它还在 cron 里跑，每小时自动生成新软链。谁干的？我查日志查到天亮，最后发现是实习生小吴上周改了GitLab CI配置，把软链生成逻辑从“覆盖”写成“追加”，还压根没提PR。他今早微信回我：“哥，我以为那个变量叫append_mode……” 二十一号中午，CDN回源爆了。不是带宽满，是回源请求里83%都命中了404——但Nginx access_log里明明记着200。我抓包一看，上游OSS返回的ETag根本对不上。再翻ossutil ls -d /bucket/cv/ —— 三百七十个同名但MD5不同的图片，全是不同版本模型输出的推理截图，命名规则一样，后缀带了个无意义的_v2、_v3、_backup_20260618。没有去重策略，只有自动备份脚本在凌晨两点定时cp -r。我骂了一句，顺手删了/_backup_目录，五分钟后，监控报警跳红：/usr/local/share/cv-models/weights/ 下某个checkpoint文件md5校验失败。不是丢了，是被同步脚本抄没了——它把备份里的旧checkpoint当“最新”推过去了。现在三个节点权重不一致，连 infer.py run 都出错码137。 二十二号早上八点，老板在运维大群里甩了张图：用户投诉截图，说上传一张人像照片，页面返回“已检测127次相似特征，建议换图”。客服在后台工单系统里标红写着：“用户上传失败，但前端显示成功。”我盯着这条工单看了四十来分钟，泡面汤在桌角凉透，浮一层油花。突然想起来，上周五测试环境升级过OpenVINO runtime，把--enable-caching改成--disable-cache，但线上没同步。结果所有特征提取都在内存算，缓存层崩了，上传路径误判成重复检测。我切到生产库查t_upload_records表，status=‘success’的记录有两千一百三十四条，但S3实际只写了九百零七张。剩下那一千多条，压根没落盘。我敲kill -9 pid of uploader-service的时候，手有点抖。窗外开始下雨，雨点打在机房玻璃上，像有人用指甲在刮。 其实真不是技术卡点。我们用的MinIO集群早就启了versioning和object locking，Nginx反代也配了cache_bypass $arg_nocache，连证书续签都用certbot hook脚本自动reload了OpenResty。难的是“谁说了算”。上周例会，研发总监拍板说“先上再优化”，DBA老周当场摔了保温杯：“你们的‘先上’，就是把所有临时表建在/tmpfs上？”他杯子底朝天，茶渍一圈一圈往外晕。我那天没说话，只低头看手机——小儿子视频通话弹出来，镜头晃着，他举着乐高城堡喊：“爸爸你看！这个塔楼比上次高！”我点头，没关麦，背景音里传来另一台服务器告警声，低频，持续，跟心跳似的。 最瘆人的是二十三号零点。我们手动把旧存储切走一半流量，新对象存储开始承接。一切正常。凌晨一点，值班室门被推开，是刚值完夜班的小王，黑眼圈深得能养金鱼，拎着半瓶冰啤酒：“张工，你猜我刚才巡检发现啥？”他凑近，酒气混着汗味，“U12柜顶那只温感探头，自检灯灭了两周了。但监控系统里一直报‘normal’——因为上个月运维平台升级，新API默认返回200，就算传感器离线也照常刷状态。”我没接话。他就站在那儿喝完最后一口，罐子捏扁扔进废纸篓，咔嚓一声。我忽然想起去年搬家，搬家公司把三台DELL R730的导轨螺丝弄丢两套，最后用订书钉硬卡住电源模块运到新机房——没炸，也没重启，就那么扛了一年多。
文章配图，仅供参考 这次没宕机，没丢数据主库，没被人挂马。就只是——每天多长两百G无效文件，每月多跑三千次重复校验，每次扩容都要人工扫一遍/data/vision//output_/的垃圾快照。我说“优胜劣汰”不是指机器，是人。比如小吴的脚本没被合并前，老周的备份检查脚本早就报过三次inodes超限，但他改完就commit push，没人review；比如每次CDN配置变更，都是前端同学直接改阿里云控制台，连个审批流都没有，更别说和我们同步Header白名单。优胜的永远是“快”，劣汰的永远是“多问一句”。所以“零冗余”根本不是技术目标，是逼着所有人，在软链生成之前、在备份触发之前、在CDN回源之前，多点一次ls -i，多看一眼ETag，多试一次curl -I。这事儿谁做？反正不是厂商。他们昨天发了个“智能去重SDK”白皮书，PDF第17页写着：“需配合业务方定义唯一性标识逻辑”。翻译过来就是：锅，还是你背。明天先把告警阈值调了——inodes剩5%就发电话告警，不许再走企业微信。另外，抽空把U12柜顶那只温感探头拆下来，换个带蜂鸣器的。就这。 （编辑：站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
