工作中我們常常會接收到例如來自預警系統的告警郵件或者你的領導轉發來的線上問題，那麼當我們遇到這類問題的時候該如何去完成處理這個任務呢？以下的處理方法步驟可以提供參考建議。
一、一般我們目前線上問題的來源：
1.主動發現
相關owner每天查看系統監控情況，主動發現了一些異常的現象。
2.監控系統告警
比如應用響應時間在某個時間段上升了，資源層面cpu、內存、io、tcp連接數、disk、線程數、GC、連接池等各個服務器指標異常，可能是某臺的服務器出現了異常，但是業務還未受到大面積影響
3.你的領導轉發來自來組郵件或者產品
通常這類郵件會有明確的uid,日期時間，服務名稱，問題現象。
4.來自微信
通常有截圖，這個時候可以問清楚具體觸發時間點，重複3的操作，遇到非必現問題，可以嘗試多種操作來還原場景
5.生產故障郵件
OPS的發來的郵件
二、查問題的基本步驟
—瞭解問題概況，評估影響的範圍
根據問題的來源，我們首先要確認的是這到底不是線上的故障？ 還是個別的極端case問題？極端的case引起的一般我們會降低優先級。 比如不能下單這樣的就是大大大大大大大大大大大大問題。
【tips:針對不同的問題範圍直接會影響處理問題的優先級哦~~~】
如果已經確定了是線上故障，我們需要快速響應去定位故障點，找其原因。
稍大一點的公司，一般都有自己的監控系統（服務器監控，服務監控，業務監控）和日誌系統。具體分析問題現象，定位問題，看log還是數據。一般能快速判是功能還是性能的問題。
如果是確定功能問題，我們一般可以從日誌系統的trace入手：
若有拋錯誤，通過跟蹤日誌信息或者特定用戶問題追溯來確定，一般這樣的日誌系統都有唯一的標識id串聯上下游，日誌是實時的，且支持過濾，統計等查詢，可以查看一段時間的趨勢情況
如果是確定性能問題，我們一般除了日誌系統還會更多的結合監控系統並行靈活組合來看：
日誌系統一般都會有各類型的埋點（自定義埋點，實時統計類埋點，PV)，所有數據都是實時埋點，很短的delay。
監控系統裏面一般會有應用監控，也包括上下游的服務，調用SOA，被調SOA，調redis監控，調用DAL監控，系統本身的監控，C#的應用還有IIS的監控，java的有VM的監控等
—協調資源
判斷故障的影響面，這點很重要，你需要給一個明確的範圍，配合關聯的產品經理，告知有多少用戶（百分比，訂單量）會受到影響；
再結合影響面，找你的頭，要麼申請hotfix，要麼放在就近版本修復，如果要修復，一定要讓相關人員（主管，產品，測試，關聯開發）清楚這個事情的來龍去脈。
—深入分析
針對上面的系統查看，我們一般能找到切入關鍵點，之後是一個複雜的收集信息-假設-驗證—收集信息-假設-驗證的循環過程，直到我們找到重現，找到根源。
這裏簡單列舉下常見的一些疑點方向：
- 剛發佈新版本不久後，線上在很短的時間內就出了問題。---那很大程度上是由於這次上的版本帶來的問題，重點可以檢查這次代碼的改動點是什麼。
- 版本是之前的，突然出現內存方面的錯誤，嚴重導致服務不可用。---可能是之前潛在的重大的bug。
- 線上之前一直穩定運行，業務量突增，各服務的響應時間增長，QPS先陡增然後下降，最後大量報錯，最嚴重的時候出現服務不可用。---這種情況很大情況下是上游調用方的突然增加流量，或者是遭遇異常的攻擊。
- 版本是之前上線的，QPS正常，服務響應時間增長，日誌中出現警告。---可能是數據庫，Redis的連接問題，或者定時任務出了問題，導致等等。。。
- 版本是之前上線的，QPS正常，但服務響應時間下降，錯誤率上升。---可能是下游依賴的服務有異常。
- 很多服務大面積出現短暫的業務失敗。---很大可能是網絡問題導致。
—問題重現，故障排除
確定好問題的範圍後，接下來就是問題重現：
功能類問題，一般比較好重現，如果遇到不是每次都能重現的問題。如果是APP問題，還可以嘗試借來手機還原場景，或者通過DEBUG模式嘗試定位Dump文件。
根據前面掌握的基本信息，幫助我們快速去理清楚業務發生的時序，比如進入App頁，會發生什麼事情，Native邏輯做了什麼，發起了什麼請求（上傳參數，內容），服務下發是否爲空（檢查服務下發），是否正常觸發了業務回調，業務回調處理完畢頁面內容渲染是否完成。
如果確定是性能問題，需要進行重現，這個過程有時候是比較困難的。。
- 要先拉取當前線上的發佈版本，發佈到測試環境，分析場景，準備相關的數據
- 我們要看上的機器配置 CPU ，內核，磁盤，物理機還是虛擬機 ，內存， 網絡io 等
- JDK版本 ，JVM的參數
- 應用開關配置，數據庫， 緩存， redis
- 接口平均的響應時間RT 是的多少， 接口的QPS是多少 平常的性能如何
6.。。
—-驗證問題是否解決
通常情況下，對於性能問題的驗證：
- 如果線上直接保存了dump文件，直接拉下來分析，若無，轉2
- 一般會拉取當前線上有問題的版本看是否能重現問題
- 然後先拉取生產一個穩定的版本，進行兩者比對。
- 如果是上線前壓測過的版本，我們要詳細分析壓測的場景。
- 再切換壓測一個開發修復後的版本進行對比，還要和基線版本對比。
- 其中比對包括各項性能指標，有的還必須針對dump文件進行對比分析 。 最終的結果是一定要所有修復後的版本性能不能比原來生產穩定的版本差。
- 針對內存的問題，我們一般壓測的時間會相對而言比較長一點，觀察其趨勢。
—上線驗證
驗證修復後的版本，確認OK後，進行上線，一般都是灰度發佈完成後進行觀察，看是否正常。
三、如何快速恢復(這個步驟應該和二並行做）
因爲系統的可用性決定着公司的客戶利益，影響公司的收益和信譽，所以一般我們遇到生產故障的第一要務是，恢復服務，儘可能的把對線上服務影響降到最低。
怎麼來快速保障把影響減少到最小呢。一般會參考以下的方法：
- 版本回退：大量報錯的情況下，又沒有辦法快速定位問題根源。一般我們都是功能測試人員負責版本上線，如果在是新版本上線後觀察出現了問題，一般都是快速回退，切到近期穩定的一個版本。一般大一點的公司發佈系統都做的比較好，可以快速切換版本，且大部分都採用的是灰度發佈，可以將範圍儘可能減少。
- 備份以及失效轉移： 對於服務而言，一但某個服務器宕機，就將服務切換到其他可用的集羣服務器上去。對於數據而言，如果某個磁盤出現損壞，就從備份的磁盤讀取數據（一般都是事先就做好了數據的同步複製），這個一般都是DBA或者運維人員去操作。
- 切流量： 一般都會有開關控制，如果出現問題，進行關閉一部分流量。 這個發佈人員都有權限。但需要事先和相關人員溝通好。
- 擴容機器：線上訪問壓力大，不能重啓機器，或者重啓也無法解決時，增加集羣機器。
- 重啓：當某臺服務器的CPU高，或者連接數飆升時，會採取這種方法。這個一般也是運維的人員去完成該操作。
四、如果避免下次再入坑
等找到了根本原因，解決了問題之後，我們需要總結，舉一反三，想想在這個故障排查和處理過程中，有哪些環節存在弱點？哪些流程/規範/制度需要優化？
這類似的問題是否在其他系統，模塊或者團隊中也存在？不斷完善，以避免再次踩坑，也在團隊中交流經驗，共同提高。
再來聊聊我們的架構的一些保護機制
現在一般隨着用戶的訪問增多，大的系統一般做到一定的規模後，架構都會經歷過好幾次的變遷，巨無霸的系統架構一般都是縱向和橫向進行了拆分的，都是將各個模塊獨立部署，降低了系統的耦合性。這樣的架構也更好的方便了我們能夠快速排查問題。
總之，線上問題來臨肯定有壓力的，但不要怕！！！！！