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 最後

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

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

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

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※台北網頁設計公司這麼多，該如何挑選?? 網頁設計報價省錢懶人包"嚨底家"

※網頁設計公司推薦更多不同的設計風格，搶佔消費者視覺第一線

※想知道購買電動車哪裡補助最多?台中電動車補助資訊懶人包彙整

※南投搬家費用,距離,噸數怎麼算?達人教你簡易估價知識!

※教你寫出一流的銷售文案?