系统升级前要确认的兼容清单

系统升级出事故，多数不是升级本身的问题，而是升级前没核对依赖。列一张清单逐项打勾，能避开大部分坑。 一、依赖版本对不对 应用依赖的语言运行库与系统库，升级后可能没了或换了主版本，Python、PHP、OpenSSL、glibc 都在常见名单里。升级前在测试环境跑： ``` python3 --version ldd --version ldd /usr/local/app/bin/app | grep "not found" ``` ldd 那条能直接列出缺失的动态库，比上线后发现快得多。带扩展的运行环境单独过：php -m 列出已装扩展，新环境逐个确认，缺一个就是一次线上报错。特别是 CentOS 7 这类已停止维护的版本，迁到新大版本时依赖差异最大，值得单独建表逐项核对。 二、内核与模块变没变 大版本升级常换内核。自定义内核模块、特定驱动、较老的监控 agent，都可能在换内核后失效。升级前存一份当前模块列表： ``` lsmod > /root/lsmod-before.txt ``` 容器运行时对内核版本另有要求，升级路径按它的支持表来定。升级后逐项核对加载情况。防火墙若依赖特定 netfilter 模块，规则先在测试机验证一遍。 三、应用先在测试环境跑 生产数据脱敏后导入测试环境，按目标版本完整升级一遍，回归核心功能：登录、下单、支付回调、定时任务。连接串、时区、文件路径这些不起眼的配置最容易出问题。性能也顺带压一轮：内核调度与库函数升级后有变化，核心接口的响应时间对比一遍，心里有底。测试通过的版本组合记录下来，生产照单执行，不临场发挥。 四、退路准备好 升级前做快照或全量备份，是整张清单里最重要的一条。云服务器在控制台打快照只要几分钟，回滚时却省下几小时，这笔账怎么算都划算。升级选业务低峰，提前公告维护窗口，出问题按预案回滚，不现场纠结。 清单的价值在于强制思考。每次升级把这张表过一遍，踩过的坑记进去，它会让下一次升级更省心。