背景

在交接的程式碼中做手腳進行刪庫等操作，之前只是網上聽說的段子，沒想到上週還真遇到了，並且親自參與幫忙解決。

事情是這樣的，一老闆接手了一套系統，可能因為雙方在交接時出現了什麼不愉快的事情，對方不提供原始碼，只是把生產環境的伺服器打了一個映象給到對方。

對方拿到映象恢復之後，系統起來怎麼也無法正常處理業務，於是就找到我幫忙看是什麼原因。經過排查，原來交接的人在映象中做了多處手腳，多處刪除核心資料及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包在前一天已經反編譯出來了，也算有了備份。

原本以為程式設計師在程式碼中進行刪庫操作或做一些其他小手腳只是網路上的段子，大多數人出於職業操守或個人品質是不會做的。沒想到這還真遇到了，而且對方為了隱藏刪除操作，還做了一些小偽裝，真的是煞費苦心啊。如果有這樣的能力和心思，用在寫出更優秀的程式碼或系統上或許更好。

當然，不知道他們在交接的過程中到底發生了什麼，竟然用這樣的方式對待昔日合作的夥伴。之所以寫這篇文章，是想讓大家學習如何排查程式碼問題的過程，畢竟用到了不少知識點和技能，但這並不是教大家如何去做手腳。無論怎樣，最起碼的職業操守還是要有的，這點不接受反駁。