一次典型的搬迁事故值得每个准备上云的团队看一看。某传统企业的内部订单系统从自建机房迁移上云，迁移当晚网站、数据库、文件全部就位，功能验证通过，凌晨收工。第二天上午问题出现：每天早上自动生成的对账单没有产生，客服反馈短信通知全部缺失，报表系统的数据停在迁移时刻。
## 根因分析
排查发现三处被遗漏的依赖。对账单由自建机房里一台独立服务器上的计划任务生成，这台机器不在迁移清单里，因为业务方不知道它的存在。短信通知走的是机房内网的一台短信网关，应用配置里只写了内网地址，迁移后新环境根本连不到。报表系统通过数据库的一个只读账号从旧库抽数，账号权限信息没有文档记录，新环境重建账号时漏掉了它。三处遗漏的共同点：这些依赖不在应用代码里，不在迁移工具能自动发现的范围内，只存在于人的记忆与机房的角落。
## 修复过程
处置按依赖逐项补齐。计划任务在新环境重建，任务脚本从旧机器取证后迁移并补做一次执行，核对产出与历史格式一致。短信网关改用公网短信服务的接口方式，应用配置更新并回溯了漏发时段的通知。只读账号按报表系统的实际用例重建最小权限，报表恢复运行。全程旧机房保持只读可查，为核对差异提供依据。三天后系统完全恢复，迁移正式收尾。
## 复盘要点
这次事故的教训可以提炼成一份盘点清单：应用与数据库之外，专项盘点计划任务、内外网依赖服务、第三方接口凭据、数据库账号矩阵、文件共享路径五类资产。盘点方式以运行时证据为准，进程列表、计划任务列表、防火墙活跃规则、数据库账号权限导出，逐项登记归属与去向。旧环境保留一个只读观察期再下线。搬迁的准备工作量，通常大于搬迁动作本身，这笔时间要提前预算。