唤醒沉睡数据：媒体运营智能测试掘金引擎

　　告警响的那一刻，我正把泡面叉子插进最后一块蛋里——没吃完，汤还浮着油花，手机就震得像要从裤兜里跳出去。不是主站告警，是媒体运营后台那套「智能测试掘金引擎」自己崩出来的三级告警，标红带感叹号，标题写着：「沉睡数据唤醒失败：索引熔断，样本池失联」。我第一反应是点掉——谁还没见过假阳？去年十二月那会儿，连监控面板都集体抽风过三回，其中一回还是因为机房空调调太低，服务器结露触发湿度传感器误报。

　　可这次弹窗底下多了一行小字：「连续五次唤醒尝试均未命中有效特征向量」。我盯着那句看了三秒，手指悬在鼠标上没动。我原以为又是开发改了上游schema没同步文档，结果切到ES集群看health，发现三台机器里有两台yellow，yellow就yellow吧，但其中一个节点的disk watermark卡在94%——不是磁盘真满了，是它把/tmp/.cache/mediascan这个临时目录当data path挂了。谁干的？没人认。运维群里@了三次，开发老张回了个「？？」，十分钟后补一句「你们清下缓存就行」，然后去接他儿子视频电话去了——我亲眼看见他头像右下角那个绿色小圆点亮了三分钟才灭。

　　反正我也没清。手欠点开「掘金引擎」控制台的debug面板，发现它根本没在跑全量唤醒，只在反复轮询一个叫「legacy_media_v2017」的冷备库表。这表早该归档三年了，但没人动，因为迁移脚本里写了句注释：「下游报表依赖此表timestamp字段做同比基线（实为虚构）」。呵，基线。上周我问DBA要不要drop，他说「等Q3审计完再说」；前天我又问，他正蹲机房门口啃煎饼果子，油渍抹在工牌上，头也不抬：「你先别动，我怕它哪天突然被哪个PPT引用了。」

　　窗外天快亮了，蓝灰色，泛着那种凌晨四点特有的、洗不干净的灰。我翻出去年十二月的变更日志，就一条相关记录：「掘金引擎v3.2上线，启用‘优胜劣汰’数据唤醒策略」。策略说明文档写得漂亮：「动态淘汰低活跃度、低标签置信度、高特征熵的数据簇，保留高转化路径样本」。听起来像人话，对吧？可它没说，「淘汰」的底层操作是——往冷备库里扔DELETE语句，但删之前，会先读一遍所有字段校验一致性；而legacy_media_v2017这张表，自2017年停更后，timestamp字段全是'0000-00-00 00:00:00'，类型却是datetime not null。引擎一读就panic，panic之后不重试，不降级，直接把自己挂进crashloop。这才是它站得住的地方：优胜劣汰——不是数据优胜劣汰，是代码活着的和死着的，一起被淘汰。

　　火大是真火大。但火大之前，我先开了个新终端，把那三台机器的systemctl status media-scan- 全截图发到群里，附言：「各位看看，哪个服务状态是active (exited)？ exited不是退出，是它启动完立刻自杀，连log都没来得及刷半行。」没人应。老王倒是在旁边工位哼了声：「我昨儿备份的时候顺手rm -rf了backup/2023Q4/，就剩个空目录……」他边说边关掉屏幕右下角的《甄嬛传》第十集——他值班爱看这个，音量调得比告警还小。我其实也该备份的。但我没备。我原以为那套「智能引擎」不过是加了层AI皮的crontab，顶多吐几条错日志，不至于牵扯主链路。结果它在凌晨三点十七分，用一条select count() from legacy_media_v2017 把整个media-ops-api的连接池给占满。连接池满不是问题，问题是它占满后，API服务拒绝新建连接，却还在收健康检查心跳——于是k8s认为它活得好好的，照常转发流量。我们眼睁睁看着503暴涨，而liveness probe显示绿色。

　　我老婆昨晚微信问我「饺子馅剁好了吗」，我没回。她今早发了个图：冰箱里三个冻饺子排成一列，最边上那只裂了口，露出一点韭菜。她没骂我，就拍了张照，连表情包都没配。这事跟我爸也有关系——他上周住院，查出来肾结石，碎石当天我在机房改helm chart，他说「没事，医生说我这病老辈人都有，喝点醋就行」。我信了，真去超市买了瓶恒顺香醋，结果回家发现我妈早兑好了四百毫升温水，就搁厨房窗台上晾着，醋味混着隔壁装修的电钻声，飘得满楼道都是。

　　所以你看，这事根本不是什么「沉睡数据唤醒」，就是一堆没人碰、不敢删、又舍不得关的旧东西，在某个阈值被踩穿的瞬间，齐齐翻身咬你一口。开发说「这叫灰度验证」，DBA说「这叫历史包袱」，老板说「这叫数据资产沉淀」。我反正是认了。掘金引擎的代码我扒过两次，核心逻辑其实就三十行python：一个while True，里面嵌着try-except，except里只有一句logging.error('woke up nothing')，然后continue。它连error level都懒得分级，就扔这么一句，像甩锅一样甩进syslog。没有重试，没有退避，没有熔断开关，没有配置项。但它赢了——因为它足够简单，简单到连崩溃都崩得特别稳。而我们呢？我们给它配Prometheus告警，配ELK日志轮转，配ansible批量启停，配了六套SOP，最后发现它根本不吃那一套。它只吃一行shell：echo "DROP TABLE legacy_media_v2017;" | mysql -uroot -pXXX media_ops —— 这行命令，我至今没敢敲。毕竟谁说得准，下个月OKR里会不会蹦出一句「激活存量历史数据价值」？

文章配图，仅供参考

　　今天下午补个动作：给media-ops-api加个/healthz 的超时硬限，三秒不返回就杀。另外，泡面盒子我扔了，但没扔盖子——盖子扣在键盘右上角，正好压住那个总在闪的「紧急回滚」按钮。它上次被按，是前年春节，当时我们回滚到v2.8，结果发现v2.8连OAuth2回调地址都没配SSL。算了，这事本来能避免。我早该在十二月就把它从crontab里踢出去。或者，至少，把泡面吃完再碰键盘。

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!