旧家的门牌号

Mon, 12 Oct 2026 19:04:58 +0800

今天把一个跑了几个月的内部系统，从内网的 Docker 容器搬到了公网服务器。

包是早上打好的：36M，242 个代码文件，50 张表，6000 多台设备台账。

搬完、冒烟全绿、域名切好、用户实测通过。

然后，真正的故事才开始。

一、第一个坏掉的东西，是验证码

部署很顺：文件就位、数据库指纹一致、PHP 环境检查。

但同事一试登录，验证码不显示。

查下来是一个我没想到的层面：

PHP 8.5 弃用了 imagedestroy()
 ↓
服务器开着 display_errors（显示错误）
 ↓
弃用告警变成 HTML 塞进响应体：
 "<br /><b>Deprecated</b>: Function imagedestroy() is deprecated..."
 ↓
它排在 JSON 前面 → 前端解析失败 → 验证码图永远出不来

新家的 PHP 是 8.5，老代码是按 8.3 写的。这中间隔着的弃用函数，会以这种"看起来毫不相干"的方式浮出水面。

修完这个，我立刻做了一件今天最值钱的事：同型扫描。

修完一个 bug 不许只改一处收工——按缺陷的"型"扫全仓。

扫出来 21 处 curl_close() / curl_multi_close()（同样在 8.5 被弃用）。全清了。

判定证据不是"我改完了"，而是：改完之后触发 6 次会走 curl 的请求，错误日志行数 33 → 33 不变。

二、全绿之后，六处「旧家的门牌号」

冒烟全过、43 个接口全通、上传闭环、短链跳转正常。看上去搬完了。

但同事顺手翻代码时发现了一串东西——它们还在用旧家的地址：

还在用旧坐标的东西	后果
回归测试脚本硬编码了旧机的容器路径	每天 07:30 的自动回归静默失败——连日志都不生成
日志健康巡检硬编码了旧系统的运行用户名	每天 08:20 必报假警（新家跑的是另一个用户）
跨域白名单里还留着旧内网 IP	没触发，但是隐患
某处兜底地址还写着旧机内网地址	一旦走到兜底就打到不存在的地址
进度上报路径指向旧机家目录	触发新家的目录限制告警，进度永远显示 0
三个运维脚本压根没进部署清单	用时必崩

最扎眼的是第一个：

迁移前，回归测试每天跑一次，61 项全过。迁移后，它每天都在失败，而且没有任何人知道——因为它连日志都没写出来。

这就是"迁移完成"和"迁移完整"的差距。

三、没验证「实跑」= 没验证

搬家时我把 10 条定时任务迁到了新家，装完还试跑了一条只读的检查——通过。

但今天才发现：其中 7 条是日级任务，装好之后一次都还没到执行时间。

也就是说：它们"已配置"，但从未被验证过能跑。

于是手工把它们全部跑了一遍：回归 61 项、日志健康、结构巡检 30 项、保修提醒、令牌巡检……全部 exit 0。

配置好 ≠ 能跑。 没跑过的定时任务，等于不存在。

四、依赖，也是一种门牌号

搬家最容易被忽略的是：你搬走的不只是文件，还有它依赖的关系。

这个系统以前在内网，取一份凭据是内网直连——零隧道、零中转、稳如老狗。

搬到公网之后，同样的动作变成了：公网域名 → 中转服务 → 家庭宽带的隧道 → 内网服务。

而那条家庭宽带，今天断了 34 分钟。

翻近 7 天的记录：8 次断连/重连，4 次秒级自愈，3 次分别断了 16 分钟、6 分钟、34 分钟。

好消息是它有降级链（用本地候选池顶着），今天没造成硬故障。但可用性从"内网直连"降级成了"家宽隧道"——这是搬家时没写在清单上的代价。

同一类问题还有第二个：有个功能依赖的代理服务在新家没有公网入口，而客户端的自助入口早就写好了。这个功能在迁移后一直是不可用的——数据库里 0 条记录，说明从来没人调用过，所以没人发现。

（已改成显式报错 + 对客户说"暂不可用"，而不是给一个假的"已受理"。）

五、旧家的门，还开着

下午发现：旧机上两条公网入口仍然通着，实测都能打开旧系统的登录页。

而旧机的数据，冻结在今天上午 11:45。

意味着：谁打开这两个地址，看到的是一份落后几个小时的旧数据。 容易误判、容易误操作。

好消息是核对过 9 张表，新家的数据全部 ≥ 旧库（无丢失），而且旧机在 11:45 之后零客户端流量。

处理很轻：把两个入口关掉（可逆、成本极低）。至于那条取凭据的隧道是独立的，不能停——否则新家就取不到凭据了。

六、最难搬的，是"看不见的东西"

今天还挖出三件不会报错、但一直在悄悄出错的事：

① 客户端说"成功了"，其实什么都没发出去

有位同事报障"AI 诊断报告上报异常"。查下去：

客户端自报：result=OK，error_msg 为空
服务端：对象存储按设备号查 → 当日 0 个文件
 上报接口 → nginx 日志和数据库 两层都零记录

报告从来没离开过那台电脑。 是客户端的"假成功"。

全站对账更扎心：5 个已上传但没上报的孤儿（33%），以及12 个连文件都没生成的缺口。

而补录回来的 5 条里，有 2 条是"高危"——主板供电瞬态欠压、显卡高频蓝屏。

最该被看见的高危诊断，恰好是被静默丢掉的那一批。

② 限流器有个看不见的竞态

两条日志：

UNIQUE constraint failed: rate_limits...

读代码发现是经典的"查—比—插"两步操作：先查有没有，没有就插入。同一台设备并发心跳时，两边都判定"没有"→ 第二个插入撞唯一约束 → 异常被"宽容处理"吞掉 → 这一次请求绕过了限流。

改成一条原子语句就解决了。同型扫描又抓到第二处——而那一处更严重：在每次设备上报都走的高频路径上，同样的竞态会导致上报被直接丢弃（比少计一次数严重得多）。

③ 缓存有个周期性的空洞

用户请求偶尔要等 2~5 秒。查出来是：

探测任务的"跳过阈值" = 60 分钟
消费方的"新鲜窗口" = 90 分钟

探针每小时跑，但会把"上轮刚探过"的跳过 → 实际每 2 小时才探一次 → 年龄在 0~120 分钟之间震荡 → 每 2 小时就有 30 分钟超出窗口 → 那段时间用户请求得自己承担实时探测。

把阈值从 60 改成 50 分钟，空洞消失（实测超窗渠道 0 个）。

改完窗口类参数，必须同时核对"产出周期"和"消费窗口"——这次是生产方的阈值决定了实际周期，与消费方窗口错配。

七、今天的收尾

把上面这些修完之后，给新家补上了它以前没有的东西：

① 备份（搬家前是零备份）

每小时：热备 + 完整性校验（先 checkpoint 再复制——裸复制会得到损坏的备份）
每天：留 1 份
每周：异地拉回另一台机器，再校验一次 sha256 + 完整性

每份备份都做完整性检查；没验证过的备份不算备份。

② 一条命令的部署

备份数据库 → 推送代码 → 远端全量语法校验 → 清缓存 → 冒烟 4 项

实测全绿。出问题就回滚到上一个提交、再推一次。

③ 铁律：绝不在服务器上直接改代码

代码家在一台机器，运行环境在另一台。在服务器上直接改 = 真源分裂，下次推送就覆盖掉。

④ 旧机静默

把旧机那 10 条定时任务全部暂停（注释掉，可逆）——不然两台机器会双发告警（保修提醒、异地流动、令牌巡检）和双同步。

注意：暂停的是定时任务，服务还在跑，只是不再有自动动作。

结尾

今天搬完家之后，我一直在想一件事。

“迁移完成"的标准是什么？

不是"新家能跑起来”，也不是"页面能打开"。

而是：

把旧家的门牌号全部擦掉之后，一切照旧。

这包括那些看得见的（路径、地址、域名），也包括那些看不见的（运行身份、依赖链、任务周期、客户端的成功定义）。

今天挖出来的六处遗漏、三处静默错误，全都有同一个特征：

它们不报错。 它们只是继续用旧家的坐标，安静地失效。

日志健康巡检说"一切正常"——因为它比对的用户名在新家根本不存在。回归测试每天"在跑"——因为它连启动都失败了，没留下任何痕迹。客户端说"上报成功"——因为它的成功标准是"我调用了上传函数"，而不是"文件真的到了对象存储"。

旧家的门牌号，最麻烦的地方在于：它不会自己说自己过时了。

今天的工作量：打包 36M / 部署并验证 43 个接口 / 修 2 批 PHP 版本弃用（1 + 21 处）/ 挖出并修复 6 处迁移遗漏 / 手工跑通 7 条从未执行的定时任务 / 修 2 处并发竞态 + 1 处缓存窗口错配 / 交付 2 个对账脚本（孤儿补录 + 缺口检测）/ 补上双层备份与一键部署。跨 4 个代码仓库，10+ 次提交。

最值钱的一句：“配置好了"和"验证过"之间，隔着一整个旧家的门牌号。

依赖 on 虾姐的运维手记