一个企业站的跨机房迁移:链路、数据与暗礁

企业官网在一台家用 NAS 上跑了很久,八月中旬一次系统更新顺手动掉了图形库的依赖,整站报错;后续一轮安全加固做完,服务干脆停摆。修复还是迁移?评估的结论是:修复要动别人留下的半成品加固配置,迁移到已在运行的香港容器环境反而路径更短。拍板:直接搬。

迁移前的三件套

第一件,环境重建。源站是PHP应用,目标环境没有现成的运行时,就自建了一个应用镜像,把扩展一次配齐:图形库连同三种图像格式的支持(站点的验证码与缩略图靠它——当年压垮源站的正是图形库的依赖被系统更新连坐)、数据库驱动、压缩包扩展、字节码缓存。每一项扩展都对应站点的一个具体功能,配齐的标准不是“能启动”,是“全功能可用”。新环境里第一次就配到位,比上线后再补扩展少一轮事故。

第二件,数据搬迁。数据库的迁移没有走文件复制:把数据目录拷成副本,起一个跳过权限的临时实例,在里面做一致性导出,再导入目标库。家用 NAS 的文件系统有个暗礁要特别提防:它的复制会产生与源文件相同的“伪副本”,看着拷完了其实什么都没拷——跨机搬数据一律走打包管道,不信文件系统的快捷方式。

第三件,链路规划。目标入口是香港机的边缘代理,应用跑在容器里,两者之间用内网穿透隧道衔接。隧道这层的坑此前踩过很多,这次按既有清单走,详见后文审计一节。

最大的暗礁:两份数据库配置

站点迁过去后第一次访问就挂死。追查过程走了一条经典路径:从应用日志到进程跟踪,一路跟到数据库连接那一行,发现它连的是内网网段的一个地址——那是 NAS 里的地址,在新机房自然不通。

诡异的是,项目里明明有一份写着本机地址的配置。真相是:这套程序支持配置覆盖,同目录下还有另一份配置文件,把主机地址整个覆盖掉了。两个月前有人为了在 NAS 上排障改了那份覆盖文件,改完忘了删,它就一直沉睡在部署包里。

修法很简单,删掉覆盖文件、指向本机。但教训值钱:配置的真相以运行时生效的那一份为准。同目录多份配置的程序,迁移前必须做一次“配置清单审计”,列出所有生效路径,逐份核对。

隧道层的配置清单

香港入口与容器应用之间靠内网穿透隧道衔接,这层的坑此前积累了完整清单,迁移时照单排雷,无一踩中。罗列出来给同路人:穿透配置的全局参数必须写在所有代理定义之前,追加到文件尾会变成最后一个代理的字段,启动直接报错退出;客户端服务的重启要看进程列表而非回显,曾有看门狗与手工各拉一个进程并存抢配置,标准清理姿势是按名字全杀、删运行文件、重启、确认进程数归一;判一条隧道死活必须逐跳端到端实测——入口地址、中间端口监听、每个域名带对头部逐个探,抽样推断等于赌博,我们曾因抽样误判把一条活隧道打成中断,十七分钟后才恢复。

迁移当天还做了一次端口面审计:两条旧隧道的服务端口长期对公网敞开,访客带对域名头就能绕过边缘直达内部内容。处置是收敛端口放行,并外网复测确认——穿透链路的边缘校验设计,第一步永远是枚举所有能到达后端的网络路径。

配置清单审计的做法

“两份配置”的坑之后,我们把迁移前的配置审计固化为四步。第一步,枚举:把程序框架的配置加载顺序搞清楚——默认配置、主配置、覆盖文件,谁加载谁、谁覆盖谁,画成一张图;第二步,全量搜索:在源站目录里按数据库地址、主机名、路径等关键词全量搜索,列出所有包含这些关键词的文件——不靠记忆数文件,靠搜索兜底;第三步,判定生效:对每个候选配置,确认它在加载链里是否真的生效(生效的那个才是真相);第四步,运行时验证:迁移完成后用进程跟踪看应用实际连接了哪个地址,与清单对账。

这次事故里,第一步和第二步但凡做了一步,那个指向内网的覆盖文件就会在迁移前现形。四步审计的全程不过二十分钟,而跳过它的代价是迁移当天的整站挂死加半天的排查——清单类工作的性价比,永远高得不成比例。

验收:港口到港口

迁移的验收不能只看首页开不开。我们的清单是:首页、栏目页、详情页、搜索、后台登录、表单提交,六条路径各走一遍;伪静态规则在容器环境重验;数据库连上后内容条数与源库对账;证书链完整、跳转关系与源站一致;最后做一轮全站页面抽样,比对标题与正文字节数。

全绿之后,老 NAS 上的站点目录原样保留(不启用,避免两边打架),源库导出留档。整个迁移从动手到验收,一个下午。

沉淀

这次迁移没有高深技术,价值全在清单化:环境重建有镜像清单、数据搬迁有管道流程、链路有端口审计、配置有覆盖审计、验收有六路径对账。迁移这类活,准备工作决定成败,执行只是把清单划勾。而清单的每一行,都是某次真实事故的坟头。