内容简介：老软件问题种种
一个软件
数据活的一定比应用长，
应用活的可能比维护的人长
有年头的老应用，通常最早的设计者已经不在了。
最初关注点，业务域的约束，以及为什么在这里是这么设计的信息都没有了。通常除了原创者，接手做维护的人，没有有全面的了解，可能也没有主观意愿想让其继续更好的工作下去。
设计是一个讲究权衡的过程，了解的信息越多，越能更好的选择策略。
所以后续的维护者会遇到以下问题范式：
基线问题
正常发布上线会经历三个日常，预发，线上三个环境。我们希望三个环境完全一致。基于 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: zhukunrong@yeah.net
以上所述就是小编给大家介绍的《老软件问题种种》，希望对大家有所帮助，如果大家有任何疑问请给我留言，小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持！
猜你喜欢:
- 软件复用导致的软件依赖问题 - research!rsc
- 软件中的时间问题
- [译] 虚构问题，低质量软件的根源
- 大多数软件问题归根结底都是组织结构问题
- 5大常见开源软件问题及解决方法
- 要想软件问题少，个人能力要提高
本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。
