共计 1652 个字符，预计需要花费 5 分钟才能阅读完成。
背景
在交接的代码中做手脚进行删库等操作，之前只是网上据说的段子，没想到上周还真遇到了，并且亲自参加帮忙解决。
事件是这样的，一老板接手了一套零碎，可能因为单方在交接时呈现了什么不欢快的事件，对方不提供源代码，只是把生产环境的服务器打了一个镜像给到对方。
对方拿到镜像复原之后，零碎起来怎么也无奈失常解决业务，于是就找到我帮忙看是什么起因。通过排查，原来交接的人在镜像中做了多处手脚，多处删除外围数据及 jar 包操作。上面来给大家细细剖析排查过程。
排查过程
因为只提供了镜像文件，导致到底启动哪些服务都是问题。好在是 Linux 操作系统，镜像复原之后，通过 history 命令能够查看已经执行了哪些命令，可能找到都须要启动哪些服务。但服务启动之后，业务无奈失常解决，很多业务都处于两头态。
本来零碎是能够失常跑业务的，打个镜像之后再复原就不能够了？这就奇怪了。于是对我的项目（jar 包或 war）文件进行排查，查看它们的批改工夫。
在文件的批改工夫上还真找到了一些问题，发现在打镜像的两个小时前，我的项目中一个多个我的项目底层依赖的 jar 包被批改过，另外还有两个 class 文件被批改过。
于是，就对它们进行了重点排查。首先反编译了那两个被批改过的 class 文件，在代码中找到了可疑的中央。
在两个被批改的类中都有上述代码。最开始没太注意这段代码，但直觉通知我不太对，一个查问业务外面怎么可能呈现删除操作呢？这太不合乎常理了。
于是仔细阅读上述代码，发现上述红框中的代码无论何时执行最终的后果都是 id=1。你是否看进去了？问题就出在三目表达式上，无论 id 是否为 null，id 被赋的值都是 1。看到这里，也感叹对方是用心了。为了暗藏这个目标，后面写了那么多无用的代码。
但只有这个还不是什么问题，毕竟如果只是删除 id 为 1 的值，也只是删除了一条记录，影响范畴应该无限。
紧接着反编译了被批改的 jar 包，顺次去找上述删除办法的底层实现，看到如下代码：
原来后面传递的 id= 1 是为了配合 where 条件语句啊，当 id= 1 被传递进来之后，就造成了 where 1= 1 的条件语句。这个大家在 mybatis 中拼接多条件语句时常常用到。后果就是一旦执行了上述业务逻辑，就会触发删除 T_QUART_DATA 全表数据的操作。
而 T_QUART_DATA 表中是用于存储触发定时工作的表达式，到这里也就明确了，为啥后面的业务跑不起来，全副是两头态了。因为一旦在业务逻辑中触发开关，把定时工作的 cron 表达式全副删除，十多个定时工作全副歇菜，业务也就跑步起来了。
找到了问题的本源，解决起来就不是啥事了，因为没有源代码，略微吃力的是只能把原我的项目整个反编译进去，而后将改批改中央进行了批改。
又起挫折
本认为到此问题曾经解决结束了，没想到第二天又呈现问题了，我的项目又跑不起来了。通过多方排查和定位，感觉还有定时工作再进行暗箱操作。
于是通过 Linux 的 crontab 命令查看是否有定时工作在执行，执行 crontab - e 或 crontab -l，还真看到有三个定时工作在执行。跟踪到定时工作执行的脚本中，而且明火执仗的起名 deleteXXX：
而在具体的脚本中，有如下执行操作：
这下找到为什么我的项目中第二天为啥跑不起来了，原来 Linux 的定时工作将外围依赖包删除了，并且还会去重启服务。
为了搞破坏，真是殚精竭虑啊。还好的是这个 jar 包在前一天曾经反编译进去了，也算有了备份。
小结
本来认为程序员在代码中进行删库操作或做一些其余小手脚只是网络上的段子，大多数人出于职业操守或集体品质是不会做的。没想到这还真遇到了，而且对方为了暗藏删除操作，还做了一些小假装，真的是殚精竭虑啊。如果有这样的能力和心理，用在写出更优良的代码或零碎上或者更好。
当然，不晓得他们在交接的过程中到底产生了什么，居然用这样的形式看待今日单干的搭档。之所以写这篇文章，是想让大家学习如何排查代码问题的过程，毕竟用到了不少知识点和技能，但这并不是教大家如何去做手脚。无论怎样，最起码的职业操守还是要有的，这点不承受反驳。
