我让生产环境停机了两个小时

嗯，你看没错，这是真的。

嗯…，我还没被开。

本来，只是普通的一次上线，平时 10 分钟之内就搞定了，今天耗费了两个小时，并且是停机状态，可以定性为事故了。

平时为什么只需要 10 分钟呢？

第一，代码不多；

第二，单机部署；

第三，先打包，再重启服务。

也就是说，10 分钟主要是耗费在启动服务上。

那么，为什么今天耗费了 120+ 分钟呢？

第一，大意了；

第二，心急了；

第三，排错时绕路了。

大意在哪了？

没有把包放到正确的目录就重启服务。执行完打包命令，没有看打包记录，在不知道是否出现了错误的情况，就直接重启了服务。服务启好之后，让测试确认时，才发现代码没有发布成功。

把问题看简单了。在知道了错误 1之后，马上停了服务，删除了原来的包。然后执行 命令，将新打好的包移动到指定目录。正常情况下，启动服务，就完成了。但是…，没错，你猜对了，新的错误出现了， 命令执行失败了。

为什么心急？

晚上 10 点了，除了 PM 和 Test，其他人都走了，因为我犯了错误，导致他俩必须得多留了一会，嗯，你都知道了，一会 == 两小时。其实我也想按时下班，苦笑（就算他们都走了，我还得合完代码才能走）。

你肯定知道，心急了，就不怎么用脑子了，直接凭直觉解决问题，看到 命令执行失败了，就以为是 命令写错了，瞎改一翻，浪费几分钟，没什么卵用，你别笑，没准你也这么干过。

决定不改 命令了，先用 命令看看目录下有没有 war 包，嗯，被你发现了，TMD，没包。

终于知道是打包失败了，那就再执行一次打包命令，看看是什么错呗！错误信息出来了…，原来是message-service对外提供的常量找不到。这时，我又开始凭直觉了，既然需要message-service的常量，那就改一下构建脚本，让message-service先编译，改完再执行。哇，message-service打包时报错，提示：找不到common里合同类型的常量，我去，玩我？

怎么绕路了？

message-service找不到common里的常量，查看源码发现，message-service里使用的常量名是错的，本地代码居然没有报编译错，这时第一反应是没有把最新的common包 到本地，那就 一下试试，结果还是不行，接着把common的版本改了，重新 试了一下，本地message-service报错了，把常量名正确，本地代码不报错了，提交代码，在服务器上构建。

靠，又报错了，找不到swallow里的常量。这回懵逼了，swallow不应该出问题啊，检查maven库，还真是swallow，压根没有下载下来，这时开始怀疑是不是有人修改了maven的配置，真佩服自己居然这么想，服务器，就我一个人有权限操作。

回过神来，继续排查，还把swallow的包手动上传了下，还是不管用，这下可急死我了。

突然想到，会不会又是 jar 包有多个版本，嗯，果然是， 最后把各个模块和service的依赖版本统一了，终于构建成功了。

总结

问题其实就出在message-service的常量名错误上，只是本地查错时用的是开发工具，这和服务器上直接用命令构建有区别，绕了一大圈，解决了个小问题。

不过也有收获，知道自己该加强一下maven的知识了，还有就是目前svn的使用方式得调整了，目前的使用方式不能及时发布上一版本。