【運維】記一次上線前的緊急定位與修復-獻上九條小經驗

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

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

---

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

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