1 簡介

本文介紹了作者所在團隊在某次上線前測試發現問題、定位問題並修復上線的過程，最後給出幾點經驗總結，希望對大家有用。

2 過程

（1）今天需要上線，但昨晚才合併了所有分支，時間很緊迫。不幸的是，打包測試後發現有一個Springboot應用（模組R）啟動失敗，但程序沒有死，一直在輸出報錯日誌。

（2）Google了相關的報錯日誌，並沒有找到相關資訊。查看了模組R的程式碼變更，並沒有什麼改動，以為是環境問題；部署到其它環境後，發現問題依舊存在，而且這個問題從未出現過，基本排除環境問題，問題還是出在程式碼上。

（3）啟動模組R上一個版本（現生產環境）的程式碼，正常啟動。所以問題還是出現模組R的改動上。

（4）對比模組R的釋出包的新版本與生產版本的差異，發現第三方依賴包都一致，但自己專案的依賴包不同。

（5）想到一個有效的辦法，依次用生產版本替換掉自己專案的包，最終定位了問題出在通用模組D上。

（6）檢視模組D的程式碼變更記錄，改動比較大，比較難發現是哪裡的改動造成的。

（7）重新看日誌。為何要重看呢？並不是心血來潮，主要是想找關聯。既然已經知道了問題在哪個模組程式碼上，通過檢視日誌與該模組可能相關的資訊，或許能找到蛛絲馬跡。

（8）果然！！！重新檢視日誌發現，模組R啟動時，報了一個其它錯誤ErrorA，但被後面不斷重複出現的錯誤ErrorB刷掉了，所以一開始並沒有注意到它。通過該報錯，與模組D的程式碼改動對比。終於定位出了問題！

（9）建立hotfix分支，修改程式碼提交，重新merge，打包，測試通過，部署生產！！！

因為部署上線是有特定的時間視窗的，如果錯過了時間，就要下次再上線，還好及時定位，及時解決！

3 經驗總結

（1）不要放過任何日誌，特別是報錯的日誌，日誌是極其有用的。不要只看最後面的報錯，也不要只看最前面的報錯，任何報錯都可能提供新的方向和線索。如果日誌資訊不夠，可以嘗試開啟debug模式，會有大量的日誌資訊，當然也要求你有足夠強的過濾和整理資訊的能力。

（2）提取有用日誌，可以用grep、tail、less等linux命令。

（3）元件化、模組化很重要，能快速縮小問題範圍。能通過只回退某個模組實現部分功能先上線。

（4）善用對比工具，如diff命令，BeyondCompare軟體等。

（5）善用程式碼變更記錄，這是版本控制給我們帶來的好處，可以方便我們對比程式碼改動了什麼，什麼時候改的，能加速問題定位；也能及時回退程式碼。

（6）上線前要做充分的測試。這次問題的出現專案流程上的原因在於沒有進行充分的測試。（1）寫程式碼的人修改了通用模組，卻沒有測試依賴它的其它模組的功能會不會受影響，而只測試了自己那一部分；（2）合併程式碼後，沒有足夠的時間來進行測試。部署前一天，才合併了程式碼打包測試。所以時間非常緊迫，在短時間要定位問題並解決，容易造成壓力。

（7）要有獨立的測試環境。這個是導致方向性錯誤的原因，經過是這樣的：A同學打包了自己的分支，這時剛好B同學稍晚一點也打包了分支，而打包的環境只有一個，B同學的包覆蓋了A同學的包。所以在A部署的時候，實際用了B同學的程式碼打的包，導致啟動失敗。所以一直以為是A同學程式碼的問題，這個方向性的錯誤浪費了很多時間。應該要讓每個分支可以同時打包，但不會覆蓋。

（8）不要先入為主。不要過早認定某個模組就是有問題的，請參考上一條。

（9）團隊作戰，分工合作。整個過程全靠團隊一起協作才能快速定位並解決；打造一個開放包容、溝通順暢的團隊是多麼的重要。

If You Want to Go Fast, Go Alone. If You Want to Go Far, Go Together.

4 最後

運維和問題定位的知識很多，也非常重要，需要持續學習。本文僅講述了本次過程用到的方法。更多的知識以後慢慢再介紹...

歡迎關注公眾號<南瓜慢說>，將持續為你更新...

多讀書，多分享；多寫作，多整理