然後，順便打包好個人物品，抱著出去就行了！

哦哦！

上線前拜四阿哥，假期前拜佛祖，天靈靈地靈靈！

家人們，這不是危言聳聽。線上無小事，開不得玩笑的啊！

還是那句話，出了問題不要慌，冷靜，保持冷靜。

首要記住一個原則：快速恢復。

時至如今，有一定規模的公司，後臺服務狀態監控各方面都做得很完善。紀錄檔系統、監控系統什麼的，一般情況下，異常資訊能很快速的展現在開發者眼前。

因此，趕緊馬不停蹄的根據現象快速界定問題範圍。然後，找到功能負責人，由負責人具體處理。畢竟沒有誰比負責人更熟悉相關的業務邏輯。當然，可能你就是那個負責人，自己發現，自己解決，嘔吐啊！

周知業務各個關聯方：產品悉知產品狀態；測試就位協助問題再現及後續驗證；上一級負責人做好隨時協調外部支援資源，溝通應對上層（尤為重要啊，不要試圖掩蓋，不聲不響，消弭於無聲是不可能的！）。

確定下是不是因為線上變動引起的問題，比如上線啊，設定變動，資料變動啥的。對於研發流程不甚規範的公司來說，不測試就上線，隨意變動線上設定，後臺修改線上資料庫資料等等都是很常見的。

如果是，那麼立刻做狀態恢復，回滾變動。這樣算是最快速高效解決辦法了。也算是最容易解決的問題。

這種前提下，還有一種情況是是，因為涉及很多關聯方的需求，不能回滾恢復！天啦擼，不回滾被罵死，回滾被揍死有沒有。腫麼辦呢，還能怎麼辦，趕緊加修補程式，快速驗證快速上線修復。

如果不是變動引起的問題，那麼就需要具體問題，具體分析，找問題原因了。

• 流量變大，服務能力不足了：加節點、加節點，橫向擴充套件堆機器。

• 訊息堆積，消費能力不足了：加消費者，加消費者，多張嘴就好了。

• 服務網路風暴了，抖動了：不是業務服務的問題，找 SRE，拼命催它們。大群拼命 @ 它們。

• ... ...

還在不是回聲，是抓耳撓腮，我很無奈啊！

好吧，一套流程走起來：保留現場，查資源佔用，查堆疊資訊、查 gc 等等。

1、找到程序 id

jps：

ps aux | grep java

top:

2、找到執行緒 pid

top -Hp 程序pid

快捷鍵「R」進行排序，可以通過快捷鍵「H」檢視幫助資訊。

快捷鍵「1」 檢視每個cpu使用情況：

3、檢視 gc 情況

jstat -gc 程序pid

也可以加額外的引數迴圈輸出：jstat -gc 程序pid 間隔時間 輸出次數

4、執行緒 pid 轉化為進位制

printf '0x%x' 執行緒pid

5、檢視執行緒堆疊

jstack 程序pid | grep 轉化後的執行緒pid

6、io 情況檢視：

vmstat：

「r」：執行中；「b」：io block等待。

7、檢視 jvm 資訊

jinfo 程序 pid

8、old 區範例查詢：

jmap -histo pid | sort -n -r -k 2 | head -10

其實最好的問題解決方法就是避免問題的出現。

不要去依賴每個人自己的自律性，也不要相信人性。有時候冷酷的規定，制度、流程反而是規避問題的最佳手段。

或許你也聽過，每個看似荒唐的規定背後，都有一段不堪回首的往事。