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