IT办公室的故事 2024-08

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

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