關于問題查詢的見解

維護現有的軟體是每個工程師日常工作中不可缺少的工作，也是基本的技能之一。那麼當出現故障後，我們該做些啥？怎麼去排查問題？正所謂工欲善其事，必先利其器，針對不同的軟體環境所需要的工具也不盡相同。在出現故障時怎麼才能保持一個清醒的頭腦也至關重要，不過這也來源于自信，來源于平時的積累。

從工作到現在，筆者維護了很多系統，從要求5個9的可靠性的網站系統到現在上萬台離線的hadoop叢集。離線的hadoop叢集故障停機也意味着損失，如停機1小時，則損失為(1/24/365/3)10000(台機器)60000(3年的每台機器的費用)=2.28w元，我們應該盡量降低停機的時間。對于線上應用那肯定是不能停機的，如taobao主站，停機1小時，那則是數百萬的損失，且客戶會流失。

由于阿裡主要的應用是java的應用，筆者接觸較多的也是java應用，将從java方面出發講述一些方法及工具。

這是一個非技術的問題。當故障發生時，怎麼做到不緊張呢。筆者記得剛畢業的第一年，有一次釋出引起線上問題，當時真的非常緊張。目前筆者也沒有好的辦法，多經曆幾次也許會好點，當然如果對系統非常熟悉也會好點。這就要求我們多積累。

基本的一些問題（分類不全）：

功能性問題：産生的一般原因是 環境不一緻，釋出的時候一般就會遇到。如：線上的網絡環境，有的master節點配置了vip，部署結構等導緻的。查詢問題的思路也基本是看是否不一緻引起的。

性能類問題：對于有中心節點，來得最直接的方式是提高master的機器能力，通過jstack找到性能瓶頸點。slave節點是否可以增多機器來解決

跟業務資料有關系的問題：在特定場景下發生的，如：有的使用者在map中處理每行記錄時調用了dns導緻job相當慢，reduce資料發生傾斜。

資料不一緻：業務系統中經常碰見，此類經常需要對比不同資料系統的資料。

有一些問題很直白，基本快速可以查詢。對于一些很難直白知道原因的，最大招數就是debug。但是線上環境不可能或者不能debug，是以，最好還是在測試和開發環境模拟其線上場景，不斷探測直到重制，再查詢原因。

由于，我們經常處理的措施是重新開機系統或者復原系統，那一般當時出問題的場景也就破壞了。為了保留環境，最好有一些監控的系統，能把大部分的資訊保留下來，友善定位問題及重制。一般情況下，一些瞬間的狀态需要自己手工執行，例如:

保留日志，很多系統重新開機後就會沖掉以前的日志。系統中一般會存在很多關鍵的日志，其中出現error日志尤其注意。 linux的日志在 /var/log/messages中。

一般需要三次jstack，看是否有性能瓶頸點，看堆棧 線程數是否正常。

對于記憶體不足，一般會在日志列印相關的記憶體溢出異常。

一般三次sudo netstat –anlp 保留現場

dump堆棧用mat分析

常用的是分析記憶體溢出，特别地，可以用 oql語句，查詢相關的對象，分析其值。

如:

tcpdump相關的包：如：dump 來自host為10.148.184.141 本地網卡bond0 的非8031和非8030的端口的包,