此为历史版本和 IPFS 入口查阅区,回到作品页
阿酷
IPFS 指纹 这是什么

作品指纹

IT办公室的故事 2024-08

阿酷
·
图片源自:https://unsplash.com/

我和我的老板两个人是同一个职称,所以做的工作承担的责任差不多。由于我是从工程院合并过来的,所以工程院的事情,以及博导们的科研项目由我来管理;再加上为软件研发那边提供数据库的服务。他则更多的参与整个学校虚拟环境,数据中心的设备以及校内所有红帽Redhat的事情。

偶尔我们也可以相互代替一下,指导对方手下的职工。他的能力是出现问题网络上各种搜索,总能让他在犄角旮旯的地方找到什么文章解决问题;而我则是在突发事件的时候能够创造性思考,从非常规的角度处理麻烦。

当然我们也不是完全了解对方工作的所有细节,所以事半功倍的事情也会出现。

比如说我有一次在他不在的情况下帮助他对应的一个客户在Cloudflare上面设置DNS记录。这件事情本身很简单,每个人都能在家里弄个私人的CDN。所以我三下五除二手动帮助客户设置完了。后来才知道原来他有一个Ansible的playbook,点击一下就自动完成了。

而在我们需要帮助软件开发组解决上百个DNS域名重定向的时候,他一句话没说。看着我拿出Python,直接写了一个脚本把整个学校网络上的域名改成相对应的新名字。

昨天下午,老板手下的一名职工I需要更新学校管理的自托管Gitlab服务器。但是他正巧有事;我则当仁不让地替他盯着整个过程。

同事I提前做了功课,发现最新版本.8和我们使用的.6并没有什么更新的内容。而.7版本有一些变动。为了保险起见,我们便决定先只升级一个版本。等观察没有问题以后再继续升级。

就这样我和同事I在Teams上一边谈笑风生,一边维护系统。

系统升级本身很轻松,调用一个Ansible的playbook,基本上都是自动完成。然而在升级的最后一步,重新配置参数的时候,系统告诉我们失败了。

我原来在工程院的时候也遇到过这种情况,尤其是在更新SSL Cert的时候。这也是我当年为什么放弃自己管理Gitlab的原因。反正学校都交钱了,为啥不用企业版的Github?只要注意不把敏感数据写在程序库里面就行了。

同事I重新启动了一下Gitlab的服务,发现在没有重新配置参数的情况下,系统还能能够读取旧版本的参数运行。

我在Gitlab的界面上测试了几个页面,感觉没有问题。同事I也得到了同样的答案。

不过为了保险起见,我们还是保留了更新前留下的系统快照。别看我们一直抱怨VMware现在太贵了,但是我们真的还是离不开它。

一晃来到今天下午。我老板突然给我发送私信,问我昨天同事I做了什么?

我把整个系统更新的过程一五一十的向他汇报。他问我们为什么要重新配置参数,这下我们问住了。我不记得当时是系统自动的还是同事手动重新配置的了。

虽然打字看不到对方的心情,不过在字里行间感觉到了他的焦虑。我马上回到我们自己的Gitlab服务器上查看。和昨天一样,我没有遇到任何问题。

就在这时,我突然想起来他曾经跟我说过,在我当年放弃维护自托管Gitlab服务器的时候,他们也遇到过一个很大的麻烦。他们在更新Gitlab版本之后,重新配置参数;导致了LDAP出了问题,所有人都无法登录。

我急忙登出自己的账户,再重新登录。果不其然,LDAP的问题再一次重演。我对老板说,昨天我们留了快照,可以复原。

而他说:“今天早晨,软件开发组那边push了很多的程序。现在复原会有更多的麻烦。”

我觉得这是有点怪我。昨天我应该多检查一些功能才对。

就在这时,只见老板在Teams里面写了大大的一个“Sh!t”。他说如果我们想恢复的话,必须有一个工作的配置参数。而我们昨天最新的参数fail掉了。

感觉事情比想象的还要严重。于是我和他连线,开始一同想办法修理我们的服务器。

这会儿老板的能力体现出来了。不知道他从哪里翻出来一篇博文。里面介绍.7版本里面有一个错别字。需要修改一下参数配置的脚本文档。

老板修改完之后,却不敢运行。他不知道程序里面都写了什么,修改了什么。

我便接手,开始通篇读程序。感觉修改过后的脚本没有什么问题。便和他说,运行吧?

他问:“You sure?”

我回答:“Yes。”

这个对话说了不下五遍。老板决定运行。

不到五秒钟,运行结束。系统恢复正常。大家又能重新登录Gitlab的GUI了。两个人的心终于放下了。

老板咒骂道:“不知道Gitlab谁那个厉害,写出个错别字来。你看.8版本推出的时间和.7不到一个小时。肯定他们自己当时发现问题了,但是没通报出来。”

我说:“难怪.6和.8版本没有发现什么更新的内容。估计就是改那个错别字,在.6里面那个词没错。”

有惊无险,我们可以下班了……

CC BY-NC-ND 4.0 授权