老软件问题种种

一个软件
数据活的一定比应用长，
应用活的可能比维护的人长

有年头的老应用，通常最早的设计者已经不在了。

最初关注点，业务域的约束，以及为什么在这里是这么设计的信息都没有了。通常除了原创者，接手做维护的人，没有有全面的了解，可能也没有主观意愿想让其继续更好的工作下去。

设计是一个讲究权衡的过程，了解的信息越多，越能更好的选择策略。

所以后续的维护者会遇到以下问题范式：

基线问题

正常发布上线会经历三个日常，预发，线上三个环境。我们希望三个环境完全一致。基于linux的软件系统部署时分层为：

• 应用包
• jar包
• 启动脚本
• RPM包
• OS

这就是基线，三个环境中的分层，任何一层在发布上线过程中的不一致都会导致潜在的问题。

随着时间推移，无论是谁在某台机上因为一些原因，动了一下脚本，问题就开始了。 可能在某个环境测试正常的应用，在下个环节就出了莫名其妙的情况。

这也是为什么一定要在组织中推动镜像化，docker形式的集装箱式封装，保证了以上几种层次在各个环境的一致性。杜绝前任跟下任埋坑。

我也曾遇到过日常预发的中间件基线版本跟较高，而线上中间件基线用的是已经找不到的老包，并且与部署系统用的基线仍不一致，这样的应用连无状态扩容都不行。

日志问题

日志是线上系统查问题利器，随着不断遇到问题，工程师倾向于打越来越多的日志。

INFO级的日志过多，线上系统一般会采用WARN级以上的打印级别。为了能看到日志，会有人把日志打到WARN,ERROR级别。

慢慢的，普通的排查日志取代了正常应该显示异常ERROR的日志，填满了正常输出，让初次看的人无从下手。只能靠看Exception，但毕竟不是有Exception就会导致系统业务异常，需要一段时间的观察才有更好的判断。

冲突问题

通常老应用在每次功能增加后，都有可能引入新的jar包。

由于maven的机制，新包会带来更多附带的包，这些问题在编译时并不能发现，只有随着JVM启动，业务线程跑到此处时类加载器才会报出Class Not Found/java.lang.NoClassDefFoundError 等问题。

人们发明了各种工具进行排包，判断，目前仍无法完全确保这种情况的万无一失。比如，还有一种方式通过扫描应用WEB-INF下的lib包名来辅助判断是否有相似jar包。

所以

每个应用都有它的故事，devops应有对以上问题处理的意识。

本文来自微信公众号「麦芽面包」，id「darkjune_think」
转载请注明。长按图片识别二维码关注。
交流Email: [e-mail]