
演示跑不过夜:一次仿真环境卡死后,我们把 preflight 挪到了 CI
上个月给一个团队交付了一个仿真环境的自动化脚本,交付前最后一轮演示跑批,凌晨两点半挂了。日志只有一行超时,环境直接锁死,第二天早上我们对着屏幕重装了一整套依赖。复盘时大家很沉默,因为这个问题其实「早就预防过」——runbook 里写着的。
深度内容,技术探索,设计思考

上个月给一个团队交付了一个仿真环境的自动化脚本,交付前最后一轮演示跑批,凌晨两点半挂了。日志只有一行超时,环境直接锁死,第二天早上我们对着屏幕重装了一整套依赖。复盘时大家很沉默,因为这个问题其实「早就预防过」——runbook 里写着的。

上个月我们给业务侧上线一套内容异常检测,第一周就撞上老毛病:模型很「热」,异常件的分高分全捞出来,人工复核队列三天堆了三千多条。业务侧的结论只有一句:「这么多误报我们没法看,先别用了。」

上个月我们在一条识别链路里花了一整周排查「模型在特定品类上变差」。最后定位到的根因和模型评分本身关系不大——是上游一条时间窗口滑移的链路事件,把检测任务的可用数据拖长了,再叠加一个只有部分团队知道的错峰运行改动,导致高价值样本的比对窗口整体向后滑了一段。

上个月给一个内部团队做意图分类服务的性能排查。区域监控显示 P99 延迟从 310ms 悄悄涨到 740ms,持续了大约三天才被人报警。模型没变、GPU 没变、prompt 模板也没动——第一反应是去找基础设施团队,查了一下午也没找到离群点。最后真正的原因出在请求网关层:一个上线时没有任何监控覆盖的限流中间件,把聊天后

上个月二点档的发布任务,同一个 bug 报了三次。第一次,脚本自建自清理;第二次,它把异常吞掉变成空结果;第三次,它自己探测自己写的文件,探测结果反过来又变成重试条件,空转了四十分钟。直到我们把"判断该不该重试"从执行进程里搬出去,这种活锁才停下来。记录一下。

上次给客户的演示排在下午三点,早上的例行巡检里,我把主后端从 A 池切到了 B 池,想趁没流量试一次真正的故障切换。结果切换脚本在健康检查这一步卡了 38 分钟,差点把演示拖成事故。这篇把当时的排查记录和后来落地的三条规则写下来,都是我们自己踩过的。

上个月我们把线上推理从云 API 切到了本地 router,流量数字很体面:P95 延迟从 1400ms 掉到 220ms,月底账单省了大概七成。我们是按计划切完、观察一周、报告结果的。

上周把我们本地推理集群接到生产的最后一周,CI 全绿、监控全绿、fallback 链路演练也"成功"了。结果第一次真挡住上游流量的那天,恢复动作的第一步就卡住了——我们按故障预案滚动重启"不健康的节点",排出来的一台其实是最健康的那台。

上个月,我们把团队的本地推理路由从内网上的旧节点迁到了各工作站的本地端口。听上去只是改几个地址,实际踩坑踩了整整五天。记录一下,给同样在做这件事的同行参考。