「奇怪」問題解決思路整理

2022-06-17 15:18:09 字數 1054 閱讀 2467

處理過各種各樣的「奇怪」問題,當然一般的問題,也不會找我處理

雖然每個問題最終產生的原因有各種各樣,但還是有些套路可以整理的

可以從以下幾個方面入手:

準確描述問題現象,很重要。以下幾個點可以捋一下:

1. 現象能否重現?在什麼條件可以出現?重現頻率 分 極少出現,偶爾出現,頻繁出現,100%出現

2. 出現現象的環境:包括硬體,系統,外接裝置,程式以及各種庫的版本

3. 跟操作步驟是否有關?

如果現象可以「重現」的,往往是比較好解決的。難度係數與解決率均跟「重現頻率」有很大關係

因此,重點關心「重現頻率」

其次,出現問題後,我們應該怎麼辦?

這個是技術活,一般人還做不了。

從第一段裡,可以得出一些「猜測」,這樣也可以縮小解決問題的範圍

1. windows vs除錯功能還是非常強大的,網上方法也很多

2.linux,主要還是依賴gdb了,這個也非常強大

注意:往往這些第三方是定位不到具體點,只是能夠提供一種相對比較準確的位置。比如說,可以通過gdb檢視,執行緒,執行緒如果一直在增加,也會導致問題。至少你可以看到哪個執行緒在不斷建立。對,一般只能到這一步。

有了,這一步,再去分析「相關」**,這樣比較準確一些

經常遇到的現象:我們通過第三方跟蹤過去,發現出現問題的地方是乙個庫(非開源)的某乙個函式。。

此時也就不能很好定位問題了,但也有點思路了。至少,我們呼叫這些介面存在一定問題。

最後,萬變不離其宗的還是**。(前提是程式出現問題)

這個需要一定經驗積累。

這裡也會存在一點悖論:

1. **本身不存在問題,即無論老化單元測試,單元耐壓測試都沒有問題。但出現問題的確也是這個模組。

比如說:我們發現第三方庫存在問題,第三方庫的開發者比如像微軟這樣的角色,你都沒有辦法。需要花費很大精力去「證明」

其實,有些問題,真的很難可以「證明」的。因為出現次數本來就不多

其實,很多事情,會出現扯皮的事情,往往最終會妥協,或不了了之

回過頭看,寧可「自己的**」有問題,也比「其他」模組有問題來得好解決。扯皮的事情,很傷神,很吃力不討好的。

「奇怪」問題解決思路整理

處理過各種各樣的 奇怪 問題,當然一般的問題,也不會找我處理 雖然每個問題最終產生的原因有各種各樣,但還是有些套路可以整理的 可以從以下幾個方面入手 準確描述問題現象,很重要。以下幾個點可以捋一下 1.現象能否重現?在什麼條件可以出現?重現頻率 分 極少出現,偶爾出現,頻繁出現,100 出現 2.出...

Mysql問題解決思路

資料庫層面 一 檢查問題常用工具 1 msyqladmin mysql客戶端,可進行管理操作 2 mysqlshow 功能強大的檢視shell命令 3 show session global variables 檢視資料庫引數資訊 4 show session global status 檢視資料庫...

快取擊穿問題解決思路

後端分布式快取是 服務端經常用到的一種技術,在讀多寫少的業務場景中,通過使用快取可以有效地支撐高併發的訪問量,對後端的資料庫等資料來源做到很好地保護。現在市面上有很多分布式快取,比如redis memcached以及阿里的tair等,不管我們使用的哪種快取產品,基本上都會遇到快取擊穿 快取失效以及熱...