摘要：很顯然對于不同規(guī)模，不同功能的系統(tǒng)，這個問題無法一概而論。生產(chǎn)事件上報(bào)客服上報(bào)此類問題往往來自用戶投訴，最重要的就是問題現(xiàn)象的復(fù)現(xiàn)。線上問題處理的核心是快速修復(fù)。以上說的都是問題發(fā)生后的消極應(yīng)對措施。

前言

一線程序員在工作中經(jīng)常需要處理線上的問題或者故障，但工作幾年下來發(fā)現(xiàn)，有些同事其實(shí)并不知道該如何去分析和解決這些問題，毫無章法的猜測和嘗試，雖然在很多時候可以最終解決問題，但往往也會浪費(fèi)大量的時間，時間就是金錢，對線上系統(tǒng)而言甚至是生命。

本文講什么：本文嘗試將本人工作過程中對線上問題的處理經(jīng)驗(yàn)加以總結(jié)精煉，并給出一套相對有規(guī)律的問題定位處理模式，希望能夠在排查問題的過程中可以幫助大家節(jié)省一些時間，盡快找出問題的關(guān)鍵點(diǎn)并修復(fù)。

本文不講什么：1、這不是一篇Linux命令的教程，雖然文章里會提到一些命令，但只會簡單介紹他們的作用和應(yīng)用場景，詳細(xì)使用說明請大家自行g(shù)oogle。2、本文不打算為所有問題尋找解決方案，事實(shí)上下面列出的方法只對大部分Java編寫的web系統(tǒng)比較有意義，一些特別個性化的案例也不再討論范圍之內(nèi)。

了解你的系統(tǒng)

什么樣的現(xiàn)象應(yīng)該列為“系統(tǒng)問題”？某個服務(wù)的QPS達(dá)到1000？對于一般系統(tǒng)或許算是，但是對大型電商網(wǎng)站，或許這只是常態(tài)。

很顯然對于不同規(guī)模，不同功能的系統(tǒng)，這個問題無法一概而論。因此快速發(fā)現(xiàn)問題的前提是深入了解你的系統(tǒng)。

通常情況下，我們可以把系統(tǒng)簡單的劃分為下面三個層次：

系統(tǒng)層

也就是我們的部署軟硬件環(huán)境。通常包含CPU、磁盤、內(nèi)存、網(wǎng)絡(luò)IO等。我們的系統(tǒng)是分布式的，還是單機(jī)應(yīng)用？CPU是幾核的？物理機(jī)還是虛機(jī)？內(nèi)存、磁盤是多大？網(wǎng)卡的規(guī)格？

軟件層

也是我們部署的軟件環(huán)境。負(fù)載均衡服務(wù)器？JDK版本？web服務(wù)器（Tomcat等）以及JVM參數(shù)設(shè)置？數(shù)據(jù)庫、緩存使用的是哪種產(chǎn)品？

應(yīng)用層

也就是我們的系統(tǒng)本身。關(guān)鍵接口的平均響應(yīng)時間（RT）是多少？服務(wù)的QPS是多少？某個接口的并發(fā)數(shù)能承受多少？

以上這些問題你是否能回答出來？這些問題的了解多寡，決定了你對系統(tǒng)的熟悉程度，也在很大程度上決定了你能否及時的發(fā)現(xiàn)問題，甚至在其真正造成影響之前就將問題解決。

現(xiàn)在你或許能回答：某個服務(wù)的QPS達(dá)到1000，究竟算不算是線上問題。

評估問題影響范圍

一個問題究竟影響了多大范圍的用戶？在多大程度上影響用戶的正常使用？如果是集群系統(tǒng)，那么這個問題是全局性的還是只在單臺機(jī)器上出現(xiàn)？不同的問題范圍會直接影響到問題處理的優(yōu)先級，一些極端情況下的個案，甚至可以不急于處理（至少不用過于焦慮）。

問題信息的搜集來源，有如下途徑：

系統(tǒng)、業(yè)務(wù)監(jiān)控報(bào)警

一般稍微上規(guī)模的公司，都會有配套的監(jiān)控系統(tǒng)，通常監(jiān)控系統(tǒng)報(bào)警都意味著問題已經(jīng)影響到系統(tǒng)的正常運(yùn)行了，此時屬于比較嚴(yán)重的生成事故，需要第一時間處理。此類問題由于可以重現(xiàn)，因此比較容易排查。?

關(guān)聯(lián)系統(tǒng)故障追溯

關(guān)聯(lián)系統(tǒng)發(fā)現(xiàn)問題，通過追溯發(fā)現(xiàn)是由本系統(tǒng)的問題引發(fā)的，此時問題的觸發(fā)的往往已經(jīng)比較明確，需要根據(jù)關(guān)聯(lián)系統(tǒng)的故障程度決定問題處理的優(yōu)先級。但此類問題很容易牽扯出隱藏的其他問題（如系統(tǒng)改造時溝通不善造成的適配問題等），緊急修復(fù)后還需要進(jìn)行進(jìn)一步仔細(xì)排查。

生產(chǎn)事件上報(bào)（客服上報(bào)）

此類問題往往來自用戶投訴，最重要的就是問題現(xiàn)象的復(fù)現(xiàn)。

主動發(fā)現(xiàn)

通過線上監(jiān)控，或者日志，主動發(fā)現(xiàn)線上系異常的情況。需要確認(rèn)是否是問題，可能只是偶發(fā)性的系統(tǒng)抖動。

快速恢復(fù)

說回問題本身，一旦確定是系統(tǒng)bug，該如何處理？立即去檢查代碼？且不說線上bug往往不那么容易檢查出來，及時能夠快速定位，修復(fù)又會耗費(fèi)大量時間，這期間不知有多少用戶受到影響。

線上問題處理的核心是快速修復(fù)。有以下兩類處理方案：

1.無法快速定位到問題根源

回滾：當(dāng)最近有新版本上線時，多半推薦這種方案

重啟：CPU高，或者連接數(shù)飆升時，會采取這種方法

擴(kuò)容：線上訪問壓力大，重啟也無法解決時

2.可以定位到問題點(diǎn)的

臨時方案或者功能降級

無論哪種方式，目標(biāo)都是以最快速度恢復(fù)服務(wù)。但這種方式是臨時的，為了徹底解決問題，都需要保留事故現(xiàn)場。基本方式如下：

執(zhí)行top命令，若CPU空閑程度較低：shift+p按CPU使用率倒排，記錄最耗資源的進(jìn)程信息。

執(zhí)行free –m命令，若內(nèi)存使用量高：執(zhí)行top，shift+m按內(nèi)存使用率倒排，記錄最耗資源的進(jìn)程信息。

對嫌疑進(jìn)程執(zhí)行ps xuf | grep java，打印進(jìn)程詳細(xì)信息并記錄。

使用jstack >jstack.log收集線程信息（反復(fù)多取幾次）。

使用jstat–gcutil 查看Old區(qū)占用率，對接近100%的進(jìn)程執(zhí)行jmap > jmap.log保留內(nèi)存信息。

定位與修復(fù)

下圖展示了常規(guī)情況下我們系統(tǒng)故障的原因：

圖1-系統(tǒng)故障原因

?

由此可見，多數(shù)情況下，系統(tǒng)的故障都會反映為系統(tǒng)的一項(xiàng)或者多項(xiàng)指標(biāo)異常。如最初所說，我們可以將整個系統(tǒng)抽象成為幾個模塊，那么對應(yīng)的，每個模塊也有一些工具供我們進(jìn)行問題的分析與定位。

?

圖2-Linux常用工具集

以下是常見的問題排查工具箱：

CPU：top –Hp

系統(tǒng)內(nèi)存：free –m

IO：iostat

磁盤：df –h

網(wǎng)絡(luò)鏈接：netstat

gc：jstat –gcutil

線程：jstack

Java內(nèi)存：jmap

輔助工具：MAT，btrace，jprofile

具體的使用方法不再贅述

方法論

有了基本的系統(tǒng)模塊劃分，以及每個模塊對應(yīng)的分析工具，我們可以嘗試將問題的排查抽象成一個相對固定的流程。大致的思路是：

先逐個模塊排查，確認(rèn)問題現(xiàn)象

再根據(jù)問題現(xiàn)象，定位問題進(jìn)程

進(jìn)一步分析線程以及內(nèi)存情況

最終找到問題的觸發(fā)點(diǎn)。

基本流程如下圖所示：

圖3-逐步排查，鎖定問題進(jìn)程

?

圖4-詳細(xì)分析目標(biāo)進(jìn)程

為故障與失敗做設(shè)計(jì)

隨著系統(tǒng)規(guī)模的逐漸擴(kuò)大，更多的功能被引入，更多的代碼被添加進(jìn)來，從這個角度來看線上的問題幾乎是無可避免的。以上說的都是問題發(fā)生后的消極應(yīng)對措施。事實(shí)上，無論我們的設(shè)計(jì)多么的完善，故障仍然是無法避免的。而且大多數(shù)時候，失敗、故障都會從一個我們無法預(yù)期的角度發(fā)生，令人猝不及防。

因此在系統(tǒng)架構(gòu)時需要設(shè)計(jì)一種機(jī)制，使得失敗、故障發(fā)生時能將系統(tǒng)的損失降到較低，在故障發(fā)生時盡可能維持核心功能的可用性。

1.設(shè)置合理的超時機(jī)制

處理網(wǎng)絡(luò)上第三方依賴時，需要對接口的響應(yīng)時間有一個合理預(yù)期，當(dāng)請求超時時能夠主動斷開連接，避免請求堆積。

本地服務(wù)相互調(diào)用時也需要合理的設(shè)置超時時間。

2.服務(wù)降級

對于無法正常響應(yīng)的應(yīng)用程序應(yīng)對可以自動切換到較低版本的實(shí)現(xiàn)。

對于一些次重要級的接口，可以考慮返回一個系統(tǒng)默認(rèn)值。

3.主動拋棄

對于響應(yīng)過慢的第三方接口，如果非核心調(diào)用，也可以采取直接拋棄的方式。

無論是降級或者拋棄，系統(tǒng)都應(yīng)當(dāng)具備適當(dāng)?shù)闹卦嚈C(jī)制，使得依賴在回復(fù)之后可以自動恢復(fù)正常調(diào)用。

作者簡介

孫思，轉(zhuǎn)轉(zhuǎn)交易系統(tǒng)負(fù)責(zé)人，08年北航計(jì)算機(jī)系虛擬現(xiàn)實(shí)實(shí)驗(yàn)室研究生畢業(yè)。畢業(yè)后入職中國民航信息網(wǎng)絡(luò)股份有限公司（TravelSky），負(fù)責(zé)機(jī)票發(fā)布平臺（EasyFare）的研發(fā)和維護(hù)工作。2010年進(jìn)入互聯(lián)網(wǎng)行業(yè)，先后供職于網(wǎng)易（北京）、搜狐和去哪兒網(wǎng)，參與過網(wǎng)易電商基礎(chǔ)平臺建設(shè)，活動及促銷運(yùn)營平臺的設(shè)計(jì)與實(shí)現(xiàn)；搜狐新聞客戶端的開發(fā)、重構(gòu)，以及去哪兒網(wǎng)旗下當(dāng)?shù)厝水a(chǎn)品的交易、支付系統(tǒng)的升級改造。2016年04月加入轉(zhuǎn)轉(zhuǎn)公司，擔(dān)任中臺技術(shù)部交易系統(tǒng)負(fù)責(zé)人，整體負(fù)責(zé)轉(zhuǎn)轉(zhuǎn)的交易系統(tǒng)、支付中心以及活動促銷運(yùn)營等系統(tǒng)的研發(fā)工作。對大規(guī)模電商平臺、分布式系統(tǒng)的設(shè)計(jì)和實(shí)現(xiàn)有較深入的了解。

軟件開發(fā)技術(shù)群

興趣范圍包括：Java，C/C++，Python，PHP，Ruby，shell等各種語言開發(fā)經(jīng)驗(yàn)交流，各種框架使用，外包項(xiàng)目機(jī)會，學(xué)習(xí)、培訓(xùn)、跳槽等交流

QQ群：26931708

Hadoop源代碼研究群

興趣范圍包括：Hadoop源代碼解讀，改進(jìn)，優(yōu)化，分布式系統(tǒng)場景定制，與Hadoop有關(guān)的各種開源項(xiàng)目，總之就是玩轉(zhuǎn)Hadoop

QQ群：288410967?