寫服務器程序，今天遇到的詭異問題

今天遇到一個很讓人鬱悶的問題……
因爲需求的一點變動，導致我們需要修改一下服務器端的程序代碼。我們在linux環境下使用boost:asio編寫底層的網絡程序，用python來
處理遊戲邏輯以及對於memcached、mysql等數據存儲系統的操作。我只是負責C++代碼的編寫，C++與python接口之間的調用方式以及
其它的一些操作並不是由我來完成的。我按照需求，把源代碼在自己的機器上修改了一下，其實僅僅是幾行語句的修改，並沒有什麼大的問題。在我的機器上成功
編譯之後，我信心十足的把編譯後的可執行文件拷貝到測試服務器主機上，替換掉了原來的文件。但是，在服務器上運行之後卻發現輸出結果還是修改前版本的老
樣子，我修改之後的程序並沒有生效！於是，懷疑是不是沒有替換掉新版本，但查看了可執行文件信息後，卻發現了我修改後插入的一行特殊字符串，證明絕對是
新編譯版本。有懷疑是否是操作系統在內存當中保留了原來版本的鏡像，於是重新啓動，執行，但仍然毫無效果。使用GDB進行調試，程序在修改行的（就是一
行打印語句）斷點處沒有停止，但卻可以在其後面代碼上安插的斷點處被觸發，而且它後面的打印語句也是可以被打印的！我之前基本上都是在VC下編寫程序，
對於Linux的理解非常有限，近來接觸linux，十足費了一番力氣。對於這種問題，我無法解釋，即使我很確定自己的程序沒有邏輯問題，但是我無法提
供充足的理由來證明這一點。
之後，在沒有任何代碼改的的情況下，我們把所有源代碼都重新的編譯並部署了一下，結果程序卻可以正常的運行了!於是我們懷疑可能是程序部署操作的問題，
但沒有找到真正的原因所在。因爲我實在沒有想通爲什麼舊的可執行文件明明已經被成功被替換了，但還是會被再次調用執行。
與此同時，我們遠程監控發現某服務器當機了！頓時空氣緊張的不得了，老大苦苦的思索問題可能出現的地方，但是因爲代碼量本身就不大，而且已經測試了很長
時間，之前一直沒有問題，一下子出了這樣的異常情況，着實讓人摸不着頭腦。經過一陣緊張之後，我們終於確定了，問題是由於第三方服務異常引起的，並不是
我們自己程序的bug。
在很多時候，我們會使用第三方工具來開發程序，雖然這些工具往往是比較穩定的，基本不會發生什麼問題。但是，倘若由於對第三方工具的薄弱認識而導致一些
錯誤操作，或者本來是合法的操作，但因爲某些方面的細節而導致結果與判斷相違背，或者乾脆是系統方面的bug問題，這些都可能會導致我們在程序測試階段
對於問題的定位失去精準性。況且，如果一個原本平穩運行的程序突然間出現了問題，日誌分析很困難，而其又被部署在了遠程無法調試；或者是機羣內部的某些
問題，這些都會對bug的定位會產生迷惑性。
   總之，上面寫的這些問題都有待於我進行深入的研究與總結，不斷的去積累經驗才能在問題來臨的時候鎮定自若！