一个系统小 BUG 修复投产居然花了 3 个小时来处理（下）

接上回，耗了接近 1 个小时，终于发现了数据库服务连接失败的元凶，是 JAR 包里的配置文件 application.yml 的数据库连接 IP 填错了。由于问题不大，所以直接在现场做了紧急修复。修改配置文件倒是简单，关键是如何把已经解包的内容重新打包呢？

要重新打成 JAR 包，首先要把内容压缩成 zip 包，再重命名为.jar 文件。由于包的内容是由 3 个目录组成的，所以要使用 zip –r 命令进行压缩。使用上述操作打成新的 JAR 包后，就更新原有的 JAR 包并重启服务。这时，以为问题就能解决了，这次投产就可以结束了，结果。。。还是我们太天真了。

此时服务启动仍然失败，通过排查服务日志，发现是缺少文件导致的。明明有好好对所有文件进行打包，怎么就缺少文件了？不信邪的我们，重新把整个流程都操作了一遍，甚至把原来错误的 JAR 包重新解压，修改配置文件，再打包成 JAR 包，都还是不行。折腾了快 1 个小时，问题仍未解决。没办法了，把调整后的 JAR 包跟调整前的 JAR 包进行对比，排查文件缺失的原因。结果一对比发现，新的 JAR 包是 67M，原来的 JAR 包是 76M，很明显容量都对不上。接着我们就把两个 JAR 包都解包并进行对比，结果发现两边的文件都是一样的，包括文件大小都是一样的，那为什么打成 JAR 包后大小就不一样的呢？

这时开发人员就有点崩溃了，希望把包拿到本地重新修改打包后，再重新上传堡垒机。（我司的投产目前都是使用堡垒机打开命令窗口处理的，如果涉及文件传输，必须要联系运维室的同事说明理由，有时候甚至要上报领导决策）现在的情况是我们私自在现场修改投产包，如果要重新上传堡垒机的话难以跟运维室的同事解释，所以我就跟开发人员说：这事情先不要急，你到开发环境模拟一下场景，看看怎样才能把 JAR 包打成功，然后开发人员就到开发环境探索去了。不小片刻，开发人员回来并且兴奋地说：我成功了！

接下来，我饶有兴趣看着他是怎样重新打包的，结果他并没有重新打包，而是使用 zip –m 命令把修改后的配置文件更新到原来的 JAR 包。更新完成后，再比对新 JAR 包和原来 JAR 包的大小，发现都是 76M，说明第一步更新 JAR 包内容基本成功了。接着再进行服务重启，发现这次启动终于没有报错退出了。最后再排查服务日期，观察了近 3 分钟，也没有错误日志反馈出来，说明这次的 JAR 包终于更新成功了，真的是一波三折啊。

由于总共有 4 个节点需要更新，所以把剩余的节点都更新并且验证完成后，时间悄悄地已过去 3 个小时了。。。在回家的路上，我跟开发人员说：明天我们要把这次投产出现的问题记录到 checklist 上，以后投产前必须按照 checklist 的检查项进行排查。

一分钟总结：

• 若更新后的文件出现错误，可把更新前与更新后的文件做对比，通过发掘差异来排查错误的原因；

• 在投产过程卡住的时候，千万不要把生产环境当作开发环境不断调试，可以先去开发环境探索方法；

• 投产过程中出现的问题建议总结为检查项加入到 checklist 中，防止下次再犯。