本地推理集群怎么租到"假健康"：停机演练里踩的三个坑

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

问题不在重启脚本，在于我们给"健康"这个词定了两套标准，两套标准在平常时候都对，在故障时候互相打架。

坑一：两种健康判断，两套真相

我们当时有两层判断：

- **探测层**：定时打 /health，返回 200 就算活。

- **负载层**：按队列深度和排队耗时标记节点"过载"。

停机演练时，路由器把过载节点从调度池里摘了。第二天排查日志发现摘的那批节点，探测层视角全是绿的，负载层视角全是红的。两边都没错，但恢复手册写的是"重启探测失败的节点"，按这个步骤操作，重启的就是负载最高、但还活着的那台。

后来把约定写死在应急预案里：**调度摘除用负载层指标，重启动作用进程级探测，两者不共用"不健康"这个标签**。现在恢复手册第一页就贴这个对照表。看起来是文档活，其实是把两套判定层解耦的活，省一次凌晨四点的误重启。

坑二：fallback 演练"成功"，是因为演练里根本没有真流量

我们的路由器配置是：主路由 127.0.0.1:4000，fallback 走云端。演练方式是把主路由进程 kill 掉，再发几个测试请求——全走了 fallback，演练通过。

但生产上第一次真故障时我们发现，超时的那批请求根本到不了 fallback 决策点：它们在客户端到主路由的连接层就卡死了，TCP 建连成功、write 成功、read 超时，客户端的 retry 逻辑直接原地重试三次。fallback 只在"请求成功到达路由器且被拒绝"时才生效。

补的修法：客户端超时从 30 秒砍到 8 秒，加一个连接池的空闲超时；路由器侧增加"队列超过阈值主动返回 503"，让请求在到达 fallback 决策点之前就先失败，而不是悬挂在队列里。这次演练的教训不是 router 配错了，而是**演练流量和生产流量的失败点不在同一层**，只对演练覆盖的那一层做了验证。

坑三：同一个 IP 同时当路由器和资产源

另一个细节：本地路由器进程同时托管了静态封面图的 HTTP 端点。路由器重载配置的时候，去拉新文章封面的任务同时被中断，文章发布流程报"封面 404"，排查了快四十分钟才发现是端口同一个进程。

拆法很简单：静态文件挪到独立端口，路由器的 image 端点只管 image。一小时的故障时间换了一条规矩：**一个端口只承担一种故障域**，任何"顺便"挂上去的东西都要单独列故障预案。

收尾

这三件事单看都不复杂，共同点是：健康判定、失败路径、故障域，三样东西在"系统活着"的时候互相掩盖，系统出问题时才会显形。演练的价值不是给绿勾，是把这三套标准各自写清楚、并且确认它们描述的是同一次故障。

现在每次停机演练，检查单第一项不是"服务恢复了"，是"我们用的健康标签是不是同一套"。