版本升级与迁移解耦

迁移当天顺手把应用从旧版本升到新版本，是常见的冒险操作。两件事叠在一起，出了问题连归因都困难。 为什么不能一起动 迁移本身就带着变量：新硬件、新网络、新环境。再叠一个版本升级，故障发生时要排查的面立刻翻倍——是环境差异引起的，还是新版本引入的？没有答案。运维的基本功之一是控制变量，一次只动一样，问题才定位得准。 迁移时的版本策略 迁移保持版本一致：PHP、MySQL、nginx 不仅大版本一致，PHP 最好小版本也对齐。对齐的成本很低，装包时指定版本号即可；不对齐的代价是各种玄学问题，修起来论小时计。老机上跑什么版本，新机就装什么版本，一个字符都别自作主张。确切版本号用包管理器查：dpkg -l | grep php 或 yum list installed | grep php，输出里的版本号原样抄进新机的安装命令。 升级单独排期 迁移稳定运行两周后再做版本升级，这是惯例节奏。两周里业务在纯迁移的环境上跑过完整周期，可以确认迁移本身没问题。升级时同样留后路：先在测试环境验证，生产切换安排在业务低谷，保留好回滚包，出问题按文档退回去。升级窗口同样选业务低谷，提前一周在内部日历上挂出来，避免和其他变更撞车。 一个例外情况 老环境版本太老、新系统装不出来，比如老系统的软件源已经停止维护，不得不升级时，就把它当作一个独立的迁移项目对待：单独评估兼容性、单独演练、单独准备回退方案，并且在变更记录里写明"本次迁移包含强制升级"这个事实，别事后让人猜。 变更记录的习惯顺便说一句：一行一个动作，带时间戳，写清执行人。迁移和升级的排期怎么定，标准只有一条——出问题时能不能在十分钟内说清是谁的原因。能做到，就是解耦到位。