最近工作中的乙個問題，耗時乙個月之久終於調查完畢且順利解決，頓時感慨萬千。耗時之久和預期解決時間和環境搭建以及日誌不合理等等有關，當然這個並非此文的重點。
之所以在很久以後的今天又開始寫文，主要是這個問題調查的過程值得銘記。具體情況如下文述。
一、問題發現過程
資料告警服務提示相關分析結果缺失，經初步調查，發現分析服務在呼叫對應的nlp演算法服務時出現大量failed，遂檢視演算法日誌，確實存在錯誤資訊。
二、問題調查和解決
1.定位問題
1) 反饋給演算法相關開發同學：他們認為可能是該演算法遇到了長文字資料（超過3000字），由於分析時間超長，導致後續演算法請求時出現阻塞而導致failed。
2) 根據開發的反饋，開始定位是否存在這樣的長文字資料：通過分析日誌和資料庫查詢確認後，並沒有分析長文字資料，且出現異常時的文字資料均為短文本（小於200）。
3) 深入調查：該演算法部署了多個節點，出現異常時，多個節點均出現了異常，因此可能是演算法本身遇到了某個瓶頸問題。經確認，該演算法使用了同一臺gpu伺服器上的tf-serveing服務。
4) 確認gpu伺服器是否發生了異常情況：經確認，該伺服器進行過vip漂移操作。
5) 問題是否可以復現：測試環境中，對gpu伺服器進行vip漂移操作，發現錯誤現象出現，問題可復現。
因此，問題的起因是gpu伺服器進行了vip漂移操作，導致演算法出現異常。
3.解決問題
1）根據調查的原因，修復方法是：sever端在進行vip漂移完成前，儘量減少演算法的請求次數，因此我們對該演算法進行了超時重試次數的設定和請求間隔的設定（可配置）。
2）演算法修復後經測試，問題解決。
三、總結
1）合理且重要的日誌輸出對於問題的定位和調查非常重要
2）涉及http請求的問題調查時，服務端抓包有必要
3）linux 的errno113問題並不一定是設定了防火牆導致的
備註：（一）vip環境：用來給k8s做三節點高可用，被k8s的kubeproxy的ipvs方式**到具體pod，四層**，tcp協議（nat模式）
（二）linux errono命令
由Typedef引發的問題
由typedef 引發的問題 自 用來宣告乙個別名，typedef 後面的語法，是乙個宣告。本來筆者以為這裡不會產生什麼誤解的，但結果卻出乎意料，產生誤解的人不在少數。罪魁禍首又是那些害人的教材。在這些教材中介紹 typedef 的時候通常會寫出如下形式 typedef int para 這種形式跟...
由const引發的版本控制問題
最近，對專案的庫做了一次公升級，程式一切正常。但是，有次開啟 oracle 發現資料不對，表中還是沒有公升級之前的老資料。於是，對所有庫做了一次徹底檢查，硬是沒找出 bug。心裡想，先放著吧，說不定就來靈感了呢！幾天後，我偶然把專案全部 compiler 一次，資料竟然正常了。怪，怪了。難道是常量的...
由object不能比較引發的問題
這是乙個小問題，請看下面的 using system using system.collections.generic using system.linq using system.text namespace sample 我們假設有兩個變數，其實它們是int，但程式用object來接收它們。然後...