1.明確問題
線上問題產生後，先不要慌，冷靜的吟聽問題，如果反饋的問題不明確，最好能和第一反饋人直接溝通。
2.定位問題的思路
熟悉業務、系統架構、實現都能有效的幫助解決問題。
排查線上的問題有一定的技巧和經驗規律。雖然不同的系統排查問題的側重點有所不同，但是在不考慮差異的情況下，一般可以網絡、CPU、內存、磁盤空間四個方面通過排除來定位問題。
3.網絡問題
網絡問題一般來說是比較好排查的。如果張三無法正常訪問，李四、王五都可以正常訪問題，那麼很有可能就是網絡問題（不考慮限流，服務端主動拒絕的情況），這是查詢一下服務端CPU、內存、磁盤空間是否正常，如果是，基本上就可以斷定是網絡問題了。網絡問題一般來說也有三種情況：
- 服務入口帶寬過小，這種情況一般比較少，可以最後排查。
- 運營商限速，例如手機超過套餐流量後會降速，降速後很多APP該問都會超時。
- 運營商之間的壁壘。之前在線上就碰到這種情況，公司拉的是電信的光遷，系統上線後，除北京移動以外的所有地區三大運營商都能正常訪問。解決這類問題最快的解決方案是再拉一根移動的光遷，問題立馬解決。當然要是考慮成本的話可以向運營商反饋，他們也會解決，但是這個週期無法預料。
5.磁盤問題
可通過df命令查詢關聯應用服務器、數據庫磁盤的使用情況。一定要在運行的情況下查看，因爲有的時候一停止，空間就釋放了，如緩存、一些複雜的數據庫查詢等。
df -h
6.CPU
CPU佔用率高：如果是數據庫服務器的CPU佔用率高，基本可以確實是由SQL導致的，可以通過系統表v$sql查看耗時比較長的sql，這裏不就不展開了。這裏主要分析因Java運行導致的情況，推薦使用阿里開源的分析腳本show-busy-java-threads.sh，可將佔用CPU線程高的堆棧打印出來。
7.內存
這裏的內存指的是JVM運行時內存，包括方法區（8之後取消）、堆、虛擬機棧及本地方法棧。
對應的內在溢出情況如下：
方法區內存溢出：Java.lang.OutOfMemoryError:PermGen space， 一般是兩種原因導致，一是 方法區配置過小； 一 是在運行過程中動態加載了過多的類；
棧內存溢出：StackOverflowError， 絕大部份情況是因爲循環或遞歸次數過多導致。
堆內存溢出：OutofMemoryError:Java heap Space，堆內存溢出的情況就比較多了，配置過小，配置不合理，創建了太多對象，創建了大對象等等。
元數據區溢出：OutofMemoryError:MetaSpace，加載的類過多導致，一般是在運行過程中，動態加載的類過多導致，因爲如果是在啓動過程中溢出，服務是無法啓動的，一般在啓動環節就解決了。
GC不給力導致的溢出：java.lang.OutOfMemoryError: GC overhead limit exceeded，花了98%的時間，但是最多回收了不到2%的空間。
用了NIO但是Direct buffer不夠 ：java.lang.OutOfMemoryError: Direct buffer memory ，換ARP直接複製基本上就不存在這種情況了；
操作系統線程限制：java.lang.OutOfMemoryError: unable to create new native thread，一種是數量的限制，創建了大多的線程了； 一種是空間的限制：創建單個線程佔用空間太大了。
9.npgstack環境監控
npgstack可以對集羣或分佈試系統中各個服務應用進行監控，包括CPU、內存、磁盤、IO、負載等參數進行監控，並且可以提供對外的接口，預警服務可以通過這些對外的接口定期檢測服務器的健康情況，對於超過閥值的服務可以觸發一些額外的保護措施，如限流，熔斷等，並可以通過短信或IM向管理員發送預警信息。