排障

数据"消失"的时候，先看它是被删了，还是根本没写进去 TVL 看板某天开始是空的。不是加载慢，是图表直接报错，一张干干净净的空白。 这天把这块看板修回来。 一块空的图页面 pages/1_tvl_rank.py 里的 Plotly 柱状图，x 轴取的是 protocol 字段： 1px.bar(x='protocol') 它读到的是一个空列，于是图表报错、数据全丢。 前端报错看着像渲染问题，但真正的疑点应该往后推一步：数据是什么时候没的？是同步进来的数据本来就空，还是本来有、后来被写没了？ 根因：往一个不存在的列里写查下来，问题在写入端，而且比想象中更基础。 tvl_rank 表原本就没有 protocol 列。而 save_tvl_rank 在做 INSERT 的时候，把协议名写进了这个不存在的列——结果数据全丢。 同时，页面又反过来用 px.bar(x='protocol') 去引用这个空列，于是一起报错。 这条链子很典型：写入端写了个不存在的目标，读取端读了个空的结果，两头各自沉默，直到图表上什么都看不见，才被人发现。中 ...

一个数字离谱到没人信的时候，问题多半不在那个数字上 新做的 12 号页跑完之后，v1.16.4 的 BUY 数量是 15254。而同一时间，11 号页里真实成交只有两百多笔。 差了将近两个数量级。这天做的事就是把这个数字修回来。 一张对不上的表：11 页 215，12 页 15254起因很朴素：11 号页显示"买的币很少"，12 号页却显示买了 15254 次。策略筛选出要买的币本来应该非常少，两个页面却给出了完全不同的结论。 这里先要分清两个页面在干什么。11 号页读的是 sim_trades，真实跑出来的成交；12 号页是反事实回测，用历史数据按每个版本的规则重放一遍。回测的意义在于"把历史数据和样本重新过一遍，快速筛出最近真正赚钱的策略，顺带看出优化方向"——它能跑出的笔数本来就该和实盘一个量级，绝不该多出几十倍。 15254 这个数字本身就在喊"我不对"。 根因一：combo 的 max() 被避雷策略钻了空子第一层根因在 engine.py 的 score_combo()。 原来的写法是用 max() 取 4 个子 ...

系统在跑，日志在滚，但一笔交易都没发生 这是做交易系统时最让人心慌的一种故障：**它不是崩了，它是"活着但不动"**。 v1.8 部署上去两个小时，0 BUY、0 SELL。进程在，决策在写，就是不下单。 四层诊断：把"不动"拆开面对这种情况，最容易犯的错是直接去怀疑策略——是不是阈值太高了？是不是信号太差了？然后开始降阈值。 但那天没有先动手改参数，而是先做了一次分层排查。因为"0 BUY"这件事，可能在四个完全不同的地方断掉： 层 卡住的表现 1. 策略层 headless 跑出来的 want 比例过低 2. 风控层 策略想买，但被 _risk_check_buy 拒了 3. 仓位层 想买，有额度，但拿不到仓位 4. 持久化层 链路断了，数据根本没进来 排查结果： 第 1 层——健康。 headless 跑 sol + bsc + base 共 120 个 token，**111 个 want=True，通过率 92.5%**。策略评分没有任何问题。 第 2 层——有问题，但只说明一件事。 那 ...

如果你发现自己在打补丁，先退一步：上游修了吗 那天要解决的毛病很小——小到可以忍，但每次都在提醒你它的存在。 那个一闪而过的黑窗口现象是：每执行一次终端命令，屏幕上就闪一下黑色的 cmd 窗口。 它不影响结果，命令照跑，输出也正常。但一天下来闪几百次，人会烦。更要命的是它给人一种"这东西没做干净"的感觉。 查下来是本地装的 Hermes 0.14.0（v2026.5.16，2026-05-18 发布）的一个已知 bug：Windows 上每次调用终端都会弹一个控制台窗口。 先查上游，再动手改第一反应当然是"把弹窗的地方关掉"——找到 Popen 的调用点，加个 Windows 专用的隐藏标志就行。 但我先多做了一步：去看看上游有没有修。 结果很干脆：这个 bug 在 0.15.0（v2026.5.28）里已经修了，做法是加了一个 windows_hide_flags() 的辅助函数。而当时 PyPI 上最新是 0.15.2（v2026.5.29.2）——本地落后了整整两个补丁版本。 那正确的修法就只有一条： 1pip install --upg ...

内网部署的坑，一半出在CDN，一半出在localhost。 今天从早到晚都在和工厂的UI报表较劲。本来以为只是把现有的外网版本改个数据库地址打包丢到内网服务器就完事，结果前后修了三四个问题，每个问题都精准踩在内网环境特有的盲区上。 一、需求：把UI打包进内网，配置全部指向10.103.x.x早上接到的活儿很明确：UI报表要放到内网，整体打包成一个文件夹，数据库从原先的地址切到内网MySQL，服务器发布到10.103.54.6的8765端口，视频流地址也换成了内网FLV源。 数据库信息当时直接给了一串：10.103.50.147:3306，库名m3_ai_data，表work_load_0521，表结构不变。账号密码我直接写进了factory_api_server.py，这里就不贴明文了，反正后端连库用的配置全部改好。视频流地址是http://10.103.65.30:8080/live?port=1935&app=live&stream=M3_5643，后面要集成到前端播放器里。 第一版打包很快出炉，factory_dashboard_deploy文件夹一共7个文件： ...

数据频率一换，累计算法不换，报表就是 100% 假象。 今天这一天基本都耗在 factory_api_server.py 和前端报表上。数据库从旧表 work_load 切到新表 work_load_0521，本来以为只是换个连接串，结果时间字段从时段变成每 10 秒一条快照，利用率算法也跟着塌了，改到第三轮才把口径理顺。 一、新表 work_load_0521：TIME 是单点快照，不是 START/END拿到的新库配置很直接：100.64.0.2:3306，表名 work_load_0521，每 10 秒记录一次人员及工时。字段里 TIME 代表记录时间，worker_num 是人数，workload 是总工时，area 和 main_area 保持原意。 跟旧表 work_load 放一起，差异一眼就能看出来： 维度 旧表 work_load 新表 work_load_0521 时间 START_TIME / END_TIME TIME（快照单点） 工时 WORKTIME（秒） 无此字段，WORKLOAD 为累计值 频率 不定时 10 秒一 ...

在岗人数不是“最后一条记录的 worker_num”，而是“当前时刻还没有结束的那条记录”。 今天这台看板连续出两个问题：先是在岗人数全部显示成 1，查了半天发现 SQL 少了对时段的判断；修完没过多久，服务自己又退掉了。一天基本就在改查询和重启服务之间来回。 一、看板起来了，但依赖是补装的先把看板重新拉起来，浏览器打开 http://localhost:8765/ 就能访问，PID 59140，端口 8765，自动连接 MySQL 实时数据，地址是 100.64.0.2:3306，30 秒自动刷新一次。 这里有个小插曲：新会话的 venv 被重置了，Python 依赖全丢。所以先把 flask、flask-cors、pymysql 补装完，服务才正常起来。当时没太在意，后面这个“会话重置”又出来刷了一次存在感。 二、在岗人数全为1：一眼就是时序问题看板刚跑起来，就收到反馈：在岗人数逻辑不对，所有工位在岗人数都为 1，数据库里 worker_num 变成 0 也不显示 0。 我去翻查询，问题出在第 71-78 行： 1WHERE (AREA, START_TIME) IN (SELEC ...

这天最关键的判断：改了后端代码不重启 Flask，页面永远还是旧数据。 上午接到的需求是把一张静态的 factory_dashboard_dark.html 塞进真实数据库里的产线工时数据，还要动态实时刷新。最后折腾到傍晚，主要精力没花在写 SQL 上，全花在“我以为改了就应该生效”上了。 一、从一张静态 HTML 到一个 Flask API 服务原始素材很明确：数据库在 100.64.0.2:3306，账号 ***（空密码，内网测试库），库名 m3_ai_data，表 work_load，字段有开始时间、结束时间、worker_num 人数、worktime 工时、workload 总工时。area 字段里五个工位代码分别是 SCBX（上层布线）、SCZZ（上次组装，素材里是打字笔误，我直接按原文记录）、DCZZBX（底层组装布线）、GJQ（工具区）、ZCZZ（中层组装），总区域 main_area 的 TST1 代表 M3 手工流水线。 浏览器本身不能直连 MySQL，所以当天定下的架构就是两文件方案： factory_api_server.py：Flask 本地服务，端口 87 ...