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

哦哦！

(相關(guān)資料圖)

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

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

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

首要記住一個原則：快速恢復(fù)。

時至如今，有一定規(guī)模的公司，后臺服務(wù)狀態(tài)監(jiān)控各方面都做得很完善。日志系統(tǒng)、監(jiān)控系統(tǒng)什么的，一般情況下，異常信息能很快速的展現(xiàn)在開發(fā)者眼前。

因此，趕緊馬不停蹄的根據(jù)現(xiàn)象快速界定問題范圍。然后，找到功能負(fù)責(zé)人，由負(fù)責(zé)人具體處理。畢竟沒有誰比負(fù)責(zé)人更熟悉相關(guān)的業(yè)務(wù)邏輯。當(dāng)然，可能你就是那個負(fù)責(zé)人，自己發(fā)現(xiàn)，自己解決，嘔吐啊！

周知業(yè)務(wù)各個關(guān)聯(lián)方：產(chǎn)品悉知產(chǎn)品狀態(tài)；測試就位協(xié)助問題再現(xiàn)及后續(xù)驗證；上一級負(fù)責(zé)人做好隨時協(xié)調(diào)外部支持資源，溝通應(yīng)對上層（尤為重要啊，不要試圖掩蓋，不聲不響，消弭于無聲是不可能的！）。

確定下是不是因為線上變動引起的問題，比如上線啊，配置變動，數(shù)據(jù)變動啥的。對于研發(fā)流程不甚規(guī)范的公司來說，不測試就上線，隨意變動線上配置，后臺修改線上數(shù)據(jù)庫數(shù)據(jù)等等都是很常見的。

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

這種前提下，還有一種情況是是，因為涉及很多關(guān)聯(lián)方的需求，不能回滾恢復(fù)！天啦擼，不回滾被罵死，回滾被揍死有沒有。腫么辦呢，還能怎么辦，趕緊加補(bǔ)丁，快速驗證快速上線修復(fù)。

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

流量變大，服務(wù)能力不足了：加節(jié)點、加節(jié)點，橫向擴(kuò)展堆機(jī)器。

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

服務(wù)網(wǎng)絡(luò)風(fēng)暴了，抖動了：不是業(yè)務(wù)服務(wù)的問題，找 SRE，拼命催它們。大群拼命 @ 它們。

... ...

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

好吧，一套流程走起來：保留現(xiàn)場，查資源占用，查堆棧信息、查 gc 等等。

jps：

ps aux | grep java

top:

top -Hp 進(jìn)程pid

快捷鍵“R”進(jìn)行排序，可以通過快捷鍵“H”查看幫助信息。

快捷鍵“1” 查看每個cpu使用情況：

jstat -gc 進(jìn)程pid

也可以加額外的參數(shù)循環(huán)輸出：jstat -gc 進(jìn)程pid 間隔時間 輸出次數(shù)

printf "0x%x" 線程pid

jstack 進(jìn)程pid | grep 轉(zhuǎn)化后的線程pid

vmstat：

“r”：運行中；“b”：io block等待。

jinfo 進(jìn)程 pid

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

其實最好的問題解決方法就是避免問題的出現(xiàn)。

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

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