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

在昨晚的投产中，一个小 BUG 投产修复居然处理了超过 3 小时，我。。。

这里先说一下背景，我带的其中一个项目有个小 BUG 需要投产修复，这个小 BUG 就是某一类客户不能在系统界面上修改密码，一旦修改就提示“该用户没有密码修改的权限”。经过开发人员排查，刚好这一类客户的修改密码代码有点漏洞，没有正确关联上权限导致的，实际上开发人员只花了不到 1 小时就修复 BUG 并测试完成。所以当晚投产预计 18 点到 19 点便可完成，心里还美滋滋地终于不用半夜回家了，结果。。。

到底整个投产过程发生什么错误了？

实际上，整个投产过程都没发生任何操作性错误，操作步骤都是严格按照操作文档进行的，结果到执行关键的一步，替换 JAR 包并重启服务后，服务直接报错并关闭，让人淬不及防。这时，无论是多么重要的系统出现故障，首先查看服务日志，排查故障原因。

通过查看服务日志，结果发现报错信息是提示数据库无法连接。怎么就发生数据库无法连接的呢？第一个想法就是可能数据库服务挂掉了导致连接不上数据库的，先从故障原因直接排查，尝试快速找出原因。结果后台连接数据库服务是正常的，把数据库服务异常这个可能性给排除了。既然不是数据库的原因，又会是什么原因呢？

既然不能快速找出原因，就不要期望天下掉馅饼了，去仔细排查投产内容，真正把问题解决。这时我们把 JAR 解压，通过排查代码找出涉及数据库连接的地方。皇天不负有心人，经过接近半个小时的排查，最终发现代码是引用一个 application.yml 里面登记的数据库连接信息来进行连接的。打开 application.yml 文件一看，数据库的连接 IP 居然填错了，把 32 填成了 63，最后导致服务无法连接数据库而启动失败。看到这样的结果，真是让人哭笑不得。

代码引用的配置信息，如果是读取配置文件的内容，而非连接到统一配置中心获取，一定要养成每次投产前检查配置文件的信息是否与生产一致的习惯。就这样一个小坑，就耗了我们 1 个小时的时间了。什么，前文说的是耗了 3 个小时来处理的？那么剩余的两个小时到底耗在什么地方呢？且听下回分解。

一分钟总结：

• 无论是多么重要的系统出现故障，首先查看服务日志，排查故障原因；

• 先从故障原因直接排查，尝试快速找出原因；

• 既然不能快速找出原因，就不要期望天下掉馅饼了，去仔细排查投产内容，真正把问题解决；

• 代码引用的配置信息，如果是读取配置文件的内容，而非连接到统一配置中心获取，一定要养成每次投产前检查配置文件的信息是否与生产一致的习惯。