暴露出来的问题：
服务器上的python版本突然变更，由原来的python3.9变更成3.11
为什么会多出3.11？ ---不太知道，还在找原因
引起的问题：
因为3.11版本下没有安装依赖包，所以导致在jenkins上跑的python脚本报错
处理问题：
step1： 将python3指向的python3.11的软连接删除（成功）
删除后，which python发现，python3为/usr/bin/目录下的python3.8
计划：将指向3.8的软连接删除，再创建指向3.9的软连接
但是遇到问题，/usr/bin/目录下的python3.8不是软连接，而是一个可执行文件
而/usr/local/bin/下存在指向python3.9的软连接python3
此处为什么会用/usr/bin/下的3.8，而不是用/usr/local/bin/下的3.9？
可以使用 echo $PATH 查看环境变量，得到 /usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin，环境变量生效条件是会在前面的目录去找可执行文件，如果存在，则不会继续查找，所以，会先用/usr/bin/下的3.8
为什么会多出3.8
继续排查原因，发现问题原因 是因为安装了CLT
解决方法：
- 卸载CLT（不现实，因为需要使用）
- 变更环境变量顺序（需要注意，不要影响到其他可执行文件的使用）
step2： 变更环境变量顺序
vim ~/.bash_profile (建议对环境变量文件进行备份)
source ~/.bash_profile (环境变量生效)
服务器上验证，python3指向了python3.9
step3 重启jenkins
这里也遇到了问题，重启的时候，竟然需要解锁jenkins，正常来讲，只有在首次安装配置jenkins的时候才需要解锁。
（当时不清楚，如果重新解锁的话， 会不会导致之前所有的jenkins配置和数据都会丢失，所以不敢轻易重新解锁）
继续排查原因，发现是因为重启jenkins的时候用的是root用户，而之前一直用的是qa用户，所以只需要使用root用户停掉jenkins的服务，再用qa用户重新启动即可 参考
step4 再次执行python脚本
讲道理，应该可以正常运行了，因为服务器上现在python3默认的是3.9了
又遇到了问题！！jenkins中调用的环境变量和服务器的环境变量不一致
可以在shell中增加
printenv用来在控制台输出，jenkins执行脚本时使用的环境变量
step5 强制jenkins使用期望顺序的环境变量
在jenkins全局配置->环境变量中增加PATH，值填写为期望的顺序
这样在jenkins中执行python脚本时，就按照指定的python版本调用了
step6 但是这样也会有问题 。 有一些其他使用jenkins的构建内容，会因为环境变量的改变而构建失败
最终改成这样就可以了
