IT办公室的故事 2022-13

Words
922
Reading
5 min
Listen
Play
4y


[图片源自:https://www.pexels.com/]

休假的时候千万别热心做工作上面的事情。好好休息开开心心,整个身心放松,根本回不到上班时候的状态。

本来打算整个独立日假期什么都不做,好好的休息一下。

不过有一个网络应用开发的项目一直是我一个人支持;今年夏天所有系统升级包括这个项目所在的虚拟机,所以我还是决定在我的假期中抽几个小时把他升级完就完事了。

7月4号这一周想找人帮忙也不是很容易。

Ubuntu,NGiNX外加MairaDB,暑期升级多少个了,应该不会出什么问题。顶多就是浪费点时间我和屏幕大眼瞪小眼看着CLI界面一个多小时。

为了保险起见,我还是备份了整个虚拟机,还存了一份整个数据库的数据。

本来还想架一个新的虚拟机,以便如果升级不成功,系统坏了,马上从Gitlab上面下代码恢复数据库需要一点时间;结果发现我上一次架的备用虚拟机没有用,也没删除。正好后端和前端的框架都一样,这个准备的时间都省了。

看来今天真的能很快完事,回到我的假期中……

相信大家看故事这么铺垫都知道后面会出事。没错!

不到一个小时,整个系统升级完毕,从新启动Web Service登录研发的程序没有问题之后,我就下线了。

结果没到半小时,客户打电话来和我反应他们的用户在平台上建立新实习工作机会的时候系统报错。

我重新上网,连到数据中心中。发现虚拟机上面的记录并没有显示什么错误信息。犹豫为了保证系统的功效,数据库除了报错没有保存其他运行记录。

一般数据库的信息都是在开发环境中读来修复错误的,正式系统中不用。所以我觉得是这里有问题。

现在开发环境下运行一下,结果没有发生客户报告的错误。脑子里面立马想到是不是开发环境中的数据库系统版本和正式的不一样?

mariadb --version

果然不出所料,正式系统的版本比开发环境的新。

唉!本来想的一个小时完事,继续我的假期的愿望不能实现了。好在改程序不难,而且只是一处出现问题,几分钟的事情。不过客户的服务协议上面明文写着:所有更新的代码都要先经过他们的测试环境才能推到正式系统中。

等他们测试不定得几个小时呢。

没办法,只能忽悠他们,说这个错误能够瘫痪整个系统,请一定让我用hotfix得形式直接发到正式环境中以免出现更大的问题。

客户同意了,把新代码传到Gitlab上自动更新产品服务器的程序。

说一千,道一万;虽然事情不大,但是一定还是要记住老话,休假的时候千万别热心做工作的事情。不顺序,准出事……