資訊專欄INFORMATION COLUMN
摘要：很顯然對于不同規(guī)模，不同功能的系統(tǒng)，這個問題無法一概而論。生產(chǎn)事件上報客服上報此類問題往往來自用戶投訴，最重要的就是問題現(xiàn)象的復現(xiàn)。線上問題處理的核心是快速修復。以上說的都是問題發(fā)生后的消極應對措施。
前言
一線程序員在工作中經(jīng)常需要處理線上的問題或者故障，但工作幾年下來發(fā)現(xiàn)，有些同事其實并不知道該如何去分析和解決這些問題，毫無章法的猜測和嘗試，雖然在很多時候可以最終解決問題，但往往也會浪費大量的時間，時間就是金錢，對線上系統(tǒng)而言甚至是生命。
本文講什么：本文嘗試將本人工作過程中對線上問題的處理經(jīng)驗加以總結精煉，并給出一套相對有規(guī)律的問題定位處理模式，希望能夠在排查問題的過程中可以幫助大家節(jié)省一些時間，盡快找出問題的關鍵點并修復。
本文不講什么：1、這不是一篇Linux命令的教程，雖然文章里會提到一些命令，但只會簡單介紹他們的作用和應用場景，詳細使用說明請大家自行google。2、本文不打算為所有問題尋找解決方案，事實上下面列出的方法只對大部分Java編寫的web系統(tǒng)比較有意義，一些特別個性化的案例也不再討論范圍之內。
了解你的系統(tǒng)
什么樣的現(xiàn)象應該列為“系統(tǒng)問題”？某個服務的QPS達到1000？對于一般系統(tǒng)或許算是，但是對大型電商網(wǎng)站，或許這只是常態(tài)。
很顯然對于不同規(guī)模，不同功能的系統(tǒng)，這個問題無法一概而論。因此快速發(fā)現(xiàn)問題的前提是深入了解你的系統(tǒng)。
通常情況下，我們可以把系統(tǒng)簡單的劃分為下面三個層次：
系統(tǒng)層
也就是我們的部署軟硬件環(huán)境。通常包含CPU、磁盤、內存、網(wǎng)絡IO等。我們的系統(tǒng)是分布式的，還是單機應用？CPU是幾核的？物理機還是虛機？內存、磁盤是多大？網(wǎng)卡的規(guī)格？
軟件層
也是我們部署的軟件環(huán)境。負載均衡服務器？JDK版本？web服務器（Tomcat等）以及JVM參數(shù)設置？數(shù)據(jù)庫、緩存使用的是哪種產(chǎn)品？
應用層
也就是我們的系統(tǒng)本身。關鍵接口的平均響應時間（RT）是多少？服務的QPS是多少？某個接口的并發(fā)數(shù)能承受多少？
以上這些問題你是否能回答出來？這些問題的了解多寡，決定了你對系統(tǒng)的熟悉程度，也在很大程度上決定了你能否及時的發(fā)現(xiàn)問題，甚至在其真正造成影響之前就將問題解決。
現(xiàn)在你或許能回答：某個服務的QPS達到1000，究竟算不算是線上問題。
評估問題影響范圍
一個問題究竟影響了多大范圍的用戶？在多大程度上影響用戶的正常使用？如果是集群系統(tǒng)，那么這個問題是全局性的還是只在單臺機器上出現(xiàn)？不同的問題范圍會直接影響到問題處理的優(yōu)先級，一些極端情況下的個案，甚至可以不急于處理（至少不用過于焦慮）。
問題信息的搜集來源，有如下途徑：
系統(tǒng)、業(yè)務監(jiān)控報警
一般稍微上規(guī)模的公司，都會有配套的監(jiān)控系統(tǒng)，通常監(jiān)控系統(tǒng)報警都意味著問題已經(jīng)影響到系統(tǒng)的正常運行了，此時屬于比較嚴重的生成事故，需要第一時間處理。此類問題由于可以重現(xiàn)，因此比較容易排查。?
關聯(lián)系統(tǒng)故障追溯
關聯(lián)系統(tǒng)發(fā)現(xiàn)問題，通過追溯發(fā)現(xiàn)是由本系統(tǒng)的問題引發(fā)的，此時問題的觸發(fā)的往往已經(jīng)比較明確，需要根據(jù)關聯(lián)系統(tǒng)的故障程度決定問題處理的優(yōu)先級。但此類問題很容易牽扯出隱藏的其他問題（如系統(tǒng)改造時溝通不善造成的適配問題等），緊急修復后還需要進行進一步仔細排查。
生產(chǎn)事件上報（客服上報）
此類問題往往來自用戶投訴，最重要的就是問題現(xiàn)象的復現(xiàn)。
主動發(fā)現(xiàn)
通過線上監(jiān)控，或者日志，主動發(fā)現(xiàn)線上系異常的情況。需要確認是否是問題，可能只是偶發(fā)性的系統(tǒng)抖動。
快速恢復
說回問題本身，一旦確定是系統(tǒng)bug，該如何處理？立即去檢查代碼？且不說線上bug往往不那么容易檢查出來，及時能夠快速定位，修復又會耗費大量時間，這期間不知有多少用戶受到影響。
線上問題處理的核心是快速修復。有以下兩類處理方案：
1.無法快速定位到問題根源
回滾：當最近有新版本上線時，多半推薦這種方案
重啟：CPU高，或者連接數(shù)飆升時，會采取這種方法
擴容：線上訪問壓力大，重啟也無法解決時
2.可以定位到問題點的
臨時方案或者功能降級
無論哪種方式，目標都是以最快速度恢復服務。但這種方式是臨時的，為了徹底解決問題，都需要保留事故現(xiàn)場。基本方式如下：
執(zhí)行top命令，若CPU空閑程度較低：shift+p按CPU使用率倒排，記錄最耗資源的進程信息。
執(zhí)行free –m命令，若內存使用量高：執(zhí)行top，shift+m按內存使用率倒排，記錄最耗資源的進程信息。
對嫌疑進程執(zhí)行ps xuf | grep java，打印進程詳細信息并記錄。
使用jstack
使用jstat–gcutil
定位與修復
下圖展示了常規(guī)情況下我們系統(tǒng)故障的原因：
圖1-系統(tǒng)故障原因
?
由此可見，多數(shù)情況下，系統(tǒng)的故障都會反映為系統(tǒng)的一項或者多項指標異常。如最初所說，我們可以將整個系統(tǒng)抽象成為幾個模塊，那么對應的，每個模塊也有一些工具供我們進行問題的分析與定位。
?
圖2-Linux常用工具集
以下是常見的問題排查工具箱：
CPU：top –Hp
系統(tǒng)內存：free –m
IO：iostat
磁盤：df –h
網(wǎng)絡鏈接：netstat
gc：jstat –gcutil
線程：jstack
Java內存：jmap
輔助工具：MAT，btrace，jprofile
具體的使用方法不再贅述
方法論
有了基本的系統(tǒng)模塊劃分，以及每個模塊對應的分析工具，我們可以嘗試將問題的排查抽象成一個相對固定的流程。大致的思路是：
先逐個模塊排查，確認問題現(xiàn)象
再根據(jù)問題現(xiàn)象，定位問題進程
進一步分析線程以及內存情況
最終找到問題的觸發(fā)點。
基本流程如下圖所示：
圖3-逐步排查，鎖定問題進程
?
圖4-詳細分析目標進程
為故障與失敗做設計
隨著系統(tǒng)規(guī)模的逐漸擴大，更多的功能被引入，更多的代碼被添加進來，從這個角度來看線上的問題幾乎是無可避免的。以上說的都是問題發(fā)生后的消極應對措施。事實上，無論我們的設計多么的完善，故障仍然是無法避免的。而且大多數(shù)時候，失敗、故障都會從一個我們無法預期的角度發(fā)生，令人猝不及防。
因此在系統(tǒng)架構時需要設計一種機制，使得失敗、故障發(fā)生時能將系統(tǒng)的損失降到較低，在故障發(fā)生時盡可能維持核心功能的可用性。
1.設置合理的超時機制
處理網(wǎng)絡上第三方依賴時，需要對接口的響應時間有一個合理預期，當請求超時時能夠主動斷開連接，避免請求堆積。
本地服務相互調用時也需要合理的設置超時時間。
2.服務降級
對于無法正常響應的應用程序應對可以自動切換到較低版本的實現(xiàn)。
對于一些次重要級的接口，可以考慮返回一個系統(tǒng)默認值。
3.主動拋棄
對于響應過慢的第三方接口，如果非核心調用，也可以采取直接拋棄的方式。
無論是降級或者拋棄，系統(tǒng)都應當具備適當?shù)闹卦嚈C制，使得依賴在回復之后可以自動恢復正常調用。
作者簡介
孫思，轉轉交易系統(tǒng)負責人，08年北航計算機系虛擬現(xiàn)實實驗室研究生畢業(yè)。畢業(yè)后入職中國民航信息網(wǎng)絡股份有限公司（TravelSky），負責機票發(fā)布平臺（EasyFare）的研發(fā)和維護工作。2010年進入互聯(lián)網(wǎng)行業(yè)，先后供職于網(wǎng)易（北京）、搜狐和去哪兒網(wǎng)，參與過網(wǎng)易電商基礎平臺建設，活動及促銷運營平臺的設計與實現(xiàn)；搜狐新聞客戶端的開發(fā)、重構，以及去哪兒網(wǎng)旗下當?shù)厝水a(chǎn)品的交易、支付系統(tǒng)的升級改造。2016年04月加入轉轉公司，擔任中臺技術部交易系統(tǒng)負責人，整體負責轉轉的交易系統(tǒng)、支付中心以及活動促銷運營等系統(tǒng)的研發(fā)工作。對大規(guī)模電商平臺、分布式系統(tǒng)的設計和實現(xiàn)有較深入的了解。
歡迎加入本站公開興趣群軟件開發(fā)技術群
興趣范圍包括：Java，C/C++，Python，PHP，Ruby，shell等各種語言開發(fā)經(jīng)驗交流，各種框架使用，外包項目機會，學習、培訓、跳槽等交流
QQ群：26931708
Hadoop源代碼研究群
興趣范圍包括：Hadoop源代碼解讀，改進，優(yōu)化，分布式系統(tǒng)場景定制，與Hadoop有關的各種開源項目，總之就是玩轉Hadoop
QQ群：288410967?
文章版權歸作者所有，未經(jīng)允許請勿轉載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉載請注明本文地址：http://systransis.cn/yun/3963.html
摘要：一直以來，前端的線上問題很難定位，因為它發(fā)生于用戶的一系列操作之后。當然，這些問題并非不能克服，讓我們來一起看看如何去定位線上的問題吧。地址參考一步一步搭建前端監(jiān)控系統(tǒng)錯誤監(jiān)控篇一步一步搭建前端監(jiān)控系統(tǒng)接口請求異常監(jiān)控篇 摘要： 記錄用戶行為，排查線上BUG。 作者：一步一個腳印一個坑 原文：如何定位前端線上問題（如何排查前端生產(chǎn)問題） Fundebug經(jīng)授權轉載，版權歸原作者所...
摘要：摘要徒手寫錯誤監(jiān)控。為什么用定時器呢，因為在單頁應用中，路由的切換和地址欄的變化是無法被監(jiān)控的，我確實沒有想到特別好的辦法來監(jiān)控，所以用了這種方式，如果有人有更好的辦法，請給我留言，謝謝。 摘要： 徒手寫JS錯誤監(jiān)控。 作者：一步一個腳印一個坑 原文：搭建前端監(jiān)控系統(tǒng)（二）JS錯誤監(jiān)控篇 Fundebug經(jīng)授權轉載，版權歸原作者所有。 背景：市面上的監(jiān)控系統(tǒng)有很多，大多收費，對于...
摘要：問題分析隨著回滾版本的放量，主端崩潰逐漸回歸正常，進一步坐實了新版本存在問題。內容非常多但都是重復的，看起來進程沒有啟動，導致連接端一直在進行重連。背景公司的主打產(chǎn)品是一款跨平臺的 App，我的部門負責為它提供底層的 sdk 用于數(shù)據(jù)傳輸，我負責的是 Adnroid 端的 sdk 開發(fā)。sdk 并不直接加載在 App 主進程，而是隔離在一個多帶帶進程中，然后兩個進程通過 tcp 連接進行通信...
摘要：摘要通過記錄用戶行為，快速復現(xiàn)場景。這是搭建前端監(jiān)控系統(tǒng)的第二章，主要是介紹如何統(tǒng)計報錯，跟著我一步步做，你也能搭建出一個屬于自己的前端監(jiān)控系統(tǒng)。 摘要： 通過記錄用戶行為，快速復現(xiàn)BUG場景。 作者：一步一個腳印一個坑 原文：搭建前端監(jiān)控系統(tǒng)（備選）用戶行為統(tǒng)計和監(jiān)控篇（如何快速定位線上問題） Fundebug經(jīng)授權轉載，版權歸原作者所有。 一步一步搭建前端監(jiān)控系統(tǒng)系列博客： ...
摘要：主要介紹了美團智能支付業(yè)務在穩(wěn)定性方向遇到的挑戰(zhàn)，并重點介紹在穩(wěn)定性測試中的一些方法與實踐。其中，智能支付作為新擴展的業(yè)務場景，去年也成為了美團增速最快的業(yè)務之一。 本文根據(jù)美團高級測試開發(fā)工程師勛偉在美團第43期技術沙龍美團金融千萬級交易系統(tǒng)質量保障之路的演講整理而成。主要介紹了美團智能支付業(yè)務在穩(wěn)定性方向遇到的挑戰(zhàn)，并重點介紹QA在穩(wěn)定性測試中的一些方法與實踐。 背景 美團支付承載...
閱讀 1382·2021-09-30 09:55
閱讀 1906·2021-08-27 13:10
閱讀 2254·2019-08-29 17:22
閱讀 1307·2019-08-29 16:30
閱讀 3474·2019-08-26 18:37
閱讀 2360·2019-08-26 11:47
閱讀 1173·2019-08-23 14:44
閱讀 1747·2019-08-23 13:46
