寫在前面：
因為公司負責的專案流程鏈路很長，經常需要排查問題定位問題。目前專案是把每個service的方法前後都加上了入參和返回值的列印。接管專案後，總結了一下通過日誌定位問題的經驗，希望以後排查問題能有一些幫助。
第二版：
運單後台排查問題的方法總結：
**邏輯熟悉時：
4.再根據測試/現場人員描述的描述以及自己熟知的業務流程簡單分析一下可能出現的原因；
5.根據問題產生的時機盡量先預期到某個節點的日誌正常情況/異常情況；
6.去相關日誌節點驗證自己猜測。
**邏輯不熟悉時：
4.對於不熟悉的業務邏輯場景，目前是**+關鍵節點日誌資訊梳理當時機械人的業務行為；
5.定位到某個可能產生問題的方法後，檢視方法入參和返回值資訊是否符合預期；
6.若不符合預期繼續分析並向前/向後追溯產生異常資料的原因；
通過現階段運單業務的支援工作，暫得出如下總結：
1.上文1，2，3三點可以通過推動產品/運營/測試人員去優先自主定位問題，並通過業務後台解決問題。以便減少開發人員的支援工作。
2.快速排查問題，定位並解決問題的前置條件是要先熟悉業務的流程。開發人員需提前已知專案正常執行的流程和邏輯。
3.如果開發人員暫不熟悉該部分的業務或者不熟悉**的具體實現細節時，可以通過業務雲端分類別列印的日誌去檢視關鍵節點資訊。
4.寫**時列印日誌要盡可能保證每個關鍵節點都有相應的記錄。要列印該關鍵節點的重點資料。
5.寫**時日誌列印不能過於繁瑣也不能過於簡潔。需要根據業務場景適度列印。
6.可以分析每個問題產生的原因，看是否是由於產品設計或技術實現等原因導致。可以避免下次遇到類似場景出現相同問題。
第一版：運單後台排查問題的方法總結：
再根據測試/現場人員描述的描述以及自己熟知的業務流程簡單分析一下可能出現的原因；
優先確定是否是配置/初始化不正確等原因引起；
配置正確時，檢視問題產生時的日誌：優先檢視關鍵節點日誌資訊->關鍵節點正常->檢視當時有無報錯->有報錯可以定位到具體**；
無報錯/遇到不熟悉的業務流程；一般通過檢視**和列印的日誌推斷問題產生前後時間點機械人的狀態與行為；
最後還無法定位，再在特定節點新增日誌資訊，待復現後再確認。
排查問題思路（一）
問題前提 今天回歸測試用例時，上午回歸用例正常，下午回歸用例98 的用例均報錯，返回空指標異常，伺服器執行正常未宕機。排查思路 1.重跑用例，檢視日誌，因為是錄製的流量，很多資料都是自動mock了，所以無法排查鏈路上是否存在問題。2.重跑全鏈路用例，發現服務基本正常，無問題，排除鏈路上的問題，問題可...
如何使錯誤日誌更加方便排查問題
在程式中打錯誤日誌的主要目標是為更好地排查問題和解決問題提供重要線索和指導。但是在實際中打的錯誤日誌內容和格式變化多樣，錯誤提示上可能殘缺不全 沒有相關背景 不明其義，使得排查解決問題成為非常不方便或者耗時的操作。而實際上，如果程式設計的時候稍加用心，就會減少排查問題的很多無用功。在闡述如何編寫有效...
排查問題 檢視日誌的正確開啟方式
開啟超大日誌檔案，檢視日誌 用分割檔案的命令 split b 200m catalina.out 每個檔案200m 檢視日誌 方式一 tail f aaa.log 實時follow aaa.log n x aaa.log x 最後幾行 xf aaa.log 注 tailf 等同於tail f n 1...