依赖服务清单：迁移最容易漏的

迁移清单上最容易漏的，不是数据库，也不是静态文件，而是那些平时看不见的依赖服务。它们平时无感，一断就是真金白银的损失。 定时任务最容易漏 crontab 里的任务不随网站文件走，逐个账号导出才能看全： crontab -l -u www > cron_www.txt cat /etc/cron.d/* > cron_system.txt 漏掉一条数据汇总任务，可能几天后对账才发现。新机上用 crontab -u www cron_www.txt 导入，导完再用 crontab -l -u www 确认一遍，一条都不能少。用 systemd timer 的任务也别漏：systemctl list-timers --all 列出来逐条记，它不在 crontab 里。导入后等一个执行周期再确认：有每天凌晨跑的任务，第二天早上看它的输出文件有没有生成。 回调地址在别人后台 支付异步通知、物流订阅推送、第三方登录的回调，都注册在对应平台的后台里。域名换了或者接入方式变了，要逐家登录后台修改。漏改的表现很隐蔽：下单正常，支付结果却收不到，订单一直停在待支付。排查方法是盯新机的访问日志，看回调请求到底有没有进来。日志搜索给个例子：grep 'notify' /var/log/nginx/access.log | tail，支付异步回调的路径大多带这个词。 白名单卡的是源 IP 短信接口、对象存储、风控服务，不少平台按源 IP 限制调用方。新服务器的 IP 不在白名单里，调用直接被拒，这类故障切换当晚就会爆发，属于必查项。切换前把要改的白名单列成表：服务名称、后台入口、要改的项目，当天逐项打钩。还有个容易踩的坑：网卡上绑的是内网 IP，出方向走的是 NAT 后的公网出口 IP，第三方后台要填的是后者，在服务器上 curl ifconfig.me 查到的才算数。 还有一类是反向依赖：有合作方限制了只接受来自老机 IP 的请求，或者你这边防火墙只放行了老机的出站目标，这些规则要同步更新，联络对方要留提前量。 依赖服务的特点是藏得深。代码里 grep 一遍回调地址和接口域名，比事后对账省心得多；迁移完成后再盯一周日志，确认没有依赖掉队。