技術的鍋太多，到底該不該你背？

一大早就被微信群炸醒，開發簡訊服務的猿妹子，在公司微信群裡說：

簡訊的生產環境伺服器， CPU 佔用率過高，瘋狂報警，應該是你們昨天上線看門狗導致的（看門狗：守護簡訊服務的監控應用，後續有機會再進行分享）。

沒錯，昨天確實給簡訊服務裝上了看門狗。但是看門狗服務肯定不會有問題（作為程式猿們，潛意識都堅信自己寫的程式碼永無 Bug），主要因為測試環境都沒有此現象。

難道是測試妹子沒測試到位？難道線上簡訊應用自身出現了問題？

生產無小事，小事更不能忽視。迅速開啟電腦，開啟 VPN ，遠端登上簡訊生產伺服器，開始猿外的 2W1H 三板斧診斷之旅。

診斷的內容有點燒腦，請大家坐穩扶好。

1. 病號是誰（WHO）？

猿外拿出控制檯診斷儀器，輸入 top 命令一探究竟，我勒個去，不看不知道一看嚇一跳，PID 為 1878 的病號，CPU 佔用居然 200% 多。

PID 為 1878 的病號到底是誰，難道真是我昨天上線的看門狗 ？

雖然猿外久經職場，但是排查生產問題時，內心還是比較忐忑，畢竟生產無小事。說時遲，那時快，只見猿外一個命令輸入 ps -ef | grep 1878 ，定睛一看，原來是簡訊服務本尊在作祟，心裡一下子平緩了不少。鍋找到了屬主，其實這個時候可以明確告訴簡訊猿妹子：是你們的簡訊服務導致的，這個鍋，猿外不背。但是猿外最喜歡做的不是甩鍋，而是打破砂鍋刨到底。

2. 病號哪裡出了問題（WHERE）？

為什麼 1878 號病人佔用 CPU 會這麼高呢？

只見黑乎乎的控制檯診斷儀器上，猿外熟練的輸入 jstack -l 1878 >> 1878號病歷.log ，於是便得到一份 1878 號病人的病歷詳情單。

到底 1878 號病人的哪個部位出了問題呢？

話沒說完，只見猿外，又在控制檯診斷儀器上，輸入一個 top -Hp 1878 命令，白板黑字，把 1878 號病人的器官資訊全部列了出來。

看到結果，甚是一驚，PID 代號為 8721 的器官佔用 CPU 100% 多。疑惑油然而生，這個 PID 代號 為 8721 的器官是啥，是頭、是眼睛、還是胳膊腿呢？這些器官展示的 PID 列都是暱稱，都這麼善於偽裝，如何揭露它的真面目呢？

還好猿外有高招，藉助照妖鏡演算法，熟練的輸入 printf "%x\n" 8721 ，果真使得代號為 8721 的器官，現了真身，真實身份居然是 2211 的呼吸道，怪不得病號一直氣喘吁吁，上氣不接下氣。

到這一步還無法對症下藥啊，還需要進一步確診 2211 的呼吸道到底出了什麼么蛾子，導致 1878 號病人一直氣喘吁吁，上氣不接下氣？

只見黑乎乎的控制檯診斷儀器上，猿外再次飛一般的在輸入 grep 2211 -A20 1878號病歷.log，診斷結果隨之顯示在診斷儀器上。

曾經背了很多鍋的猿外，看到診斷結果心裡樂了一下，一眼就看出是高併發情況下用了 HashMap 的問題（請猿友們自行尋找谷哥、度娘，就不在此深入展開啦），終於撥開雲霧見青天。

3. 如何對症下藥（ HOW ）？

在猿外行雲流水沒有一絲一毫的拖泥帶水般的神操作下，1878 號病人的診斷也就結束了，這個鍋就徹底被打破了。術業有專攻，猿外就可以鄭重的告訴簡訊猿妹子具體原因，捉得病根，簡訊猿妹子也就可以對症下藥啦。

猿外打破砂鍋的方式你 get 到了沒？猿外自己簡單概括為 2W1H 三板斧：病號是誰、病號哪裡出了問題、對症下藥。

1、病號是誰？（WHO）

• 第一步：採用 top 命令，找出 CPU 佔用最高的病號 PID ；
• 第二步：通過 ps -ef | grep PID 檢視病號對應的真實身份。

2、病號哪裡出了問題？（WHERE）

• 第一步：採用 jstack -l PID >> PID.log 獲取病號的各器官資訊的病歷單；
• 第二步：採用 top -Hp PID 拿到佔用 CPU 最高的器官暱稱 PID ;
• 第三步：採用 printf "%x\n" PID 根據器官暱稱 PID 的拿到器官真實身份 TID ;
• 第四步：採用 grep TID -A20 pid.log 根據 TID 去病歷單中匹配，確定是哪出了問題。

3、捉得病根、便可拿出醫藥箱，對症下藥啦。（HOW）

作為程式猿，工作中難免會遇到不少類似這樣的問題，面對問題，你如果像無頭蒼蠅一樣亂撞，撞得頭破血流依然不知道緣由，在背鍋即將成為現實時，那就不妨試試猿外的 2W1H 三板斧的診斷方式，說不定會幫你快速定位、解決線上問題，畢竟快速的解決生產問題會把損失降到最低。

最後，猿外想說的是：作為程式猿，一定要有程式猿的態度。避免背鍋，拒絕甩鍋，打破砂鍋，從猿友們做起。