然後，順便打包好個人物品，抱着出去就行了！
哦哦！
上線前拜四阿哥，假期前拜佛祖，天靈靈地靈靈！
家人們，這不是危言聳聽。線上無小事，開不得玩笑的啊！
一、快速恢復
還是那句話，出了問題不要慌，冷靜，保持冷靜。
首要記住一個原則：快速恢復。
時至如今，有一定規模的公司，後臺服務狀態監控各方面都做得很完善。日誌系統、監控系統什麼的，一般情況下，異常信息能很快速的展現在開發者眼前。
因此，趕緊馬不停蹄的根據現象快速界定問題範圍。然後，找到功能負責人，由負責人具體處理。畢竟沒有誰比負責人更熟悉相關的業務邏輯。當然，可能你就是那個負責人，自己發現，自己解決，嘔吐啊！
周知業務各個關聯方：產品悉知產品狀態；測試就位協助問題再現及後續驗證；上一級負責人做好隨時協調外部支持資源，溝通應對上層（尤爲重要啊，不要試圖掩蓋，不聲不響，消弭於無聲是不可能的！）。
確定下是不是因爲線上變動引起的問題，比如上線啊，配置變動，數據變動啥的。對於研發流程不甚規範的公司來說，不測試就上線，隨意變動線上配置，後臺修改線上數據庫數據等等都是很常見的。
如果是，那麼立刻做狀態恢復，回滾變動。這樣算是最快速高效解決辦法了。也算是最容易解決的問題。
這種前提下，還有一種情況是是，因爲涉及很多關聯方的需求，不能回滾恢復！天啦擼，不回滾被罵死，回滾被揍死有沒有。腫麼辦呢，還能怎麼辦，趕緊加補丁，快速驗證快速上線修復。
如果不是變動引起的問題，那麼就需要具體問題，具體分析，找問題原因了。
-
流量變大，服務能力不足了：加節點、加節點，橫向擴展堆機器。
-
消息堆積，消費能力不足了：加消費者，加消費者，多張嘴就好了。
-
服務網絡風暴了，抖動了：不是業務服務的問題，找 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
三、關於研發流程
其實最好的問題解決方法就是避免問題的出現。
不要去依賴每個人自己的自律性，也不要相信人性。有時候冷酷的規定，制度、流程反而是規避問題的最佳手段。
或許你也聽過，每個看似荒唐的規定背後，都有一段不堪回首的往事。
