摘要
通常處理線上問題的三板斧是重啟-回滾-擴容，能夠快速有效的解決問題，但是根據我多年的線上經驗，這三個操作略微有些簡單粗暴，解決問題的概率也非常隨機，並不總是有效。這邊總結下通常我處理應用中遇到的故障的解決方案。
原則
處理故障的時候必須遵循的一些原則
-
提早發現問題，避免故障擴散
故障的出現鏈路一般如下圖所示
每一層都有可能出現問題，越底層出現問題，影響面越大。所以每一個層次都需要有相應的問題監控機制，這樣越早發現問題，越能儘早解決故障，避免問題的擴散。比如服務依賴的一個資料庫主庫有問題了，如果等到使用者報過來，這時候可能服務已經掛了幾分鐘了。再等你分析問題，解決問題，切換主備什麼的，可能幾分鐘又過去了。影響訪問比較大了。如果在資料庫出問題時，就已經收到警報，迅速解決，可能沒等使用者報過來，問題解決了。 -
迅速廣播
當收到一個P0警報，判斷應用出現問題了，第一時間在組內廣播。全部人員進入一級戰鬥狀態，發現可能和其他依賴的服務/中介軟體/運維/雲廠商有關，立即通知相關責任人，要求進入協同作戰。 -
快速恢復
保留現場很重要，有助於發現root cause。但是發生故障了，必須要爭分奪秒，不能為了保留現場浪費幾分鐘的時間去幹什麼dump記憶體，jstack執行緒狀態的事。必須第一時間內先恢復服務，之後再根據當時監控資料，去找root cause -
持續觀察
為了解決問題，可能需要線上上進行了重啟/回滾/mock/限流等操作，一定要檢視是否達到了預期效果。
需要持續觀察一段時間，服務是否真的正常。 有時候可能只是短暫下去了，還會反撲。
處理手段
處理手段無非是重啟、擴容、回滾、限流、降級、hotfix
以下是我一般處理線上問題的流程
主要分為四大塊
step1: 是否有變化
和造成大部分車禍的原因是由於變化導致一樣，線上故障通常也是由於變化導致的。外部的變化很難感知到，但是服務自身的變化很容易感知，當有服務釋出、配置變更等變化時。那麼首先判斷是否可回滾，可回滾的立馬回滾。
step2: 是否單機
現在一般是叢集部署，服務高可用。如果只是一臺機器有問題，在服務可摘除的情況下立即摘除。不可立即摘除的，先擴容再摘除。
step3: 是否叢集
整個服務叢集都出問題了，問題就相對比較複雜一些了，需要分為單個API與多個API錯誤。
- 單個API錯誤
是否對應用內其他API，模組、下游的儲存有影響。有影響的話，可降級的及時降級。由於請求量增加引起的，限流。對其他模組無影響，再排查問題，hotfix。 - 多個API錯誤
這種通常是step4出錯了，可以直接到step4檢視。
如果不是step4錯誤，如果流量超預期，限流擴容操作。如果不是，找程式碼問題，hotfix上線
step4: 依賴的服務/儲存有問題
立即找到相關團隊，一起看問題。如果是自身服務不正常的請求引起的，再做相應的fix。如果是正常操作引起的，那需要緊急擴容，升級配置。
如何預防
從上述操作可以看出，故障發生時需要做的判斷還是很多的，如果經驗不夠豐富,處理不得當，很容易引發故障升級、資產損失。
所以需要提前預防。
瞭解你的服務
像哲學家剖析自己一樣去了解你的服務。一般包含以下內容
繪製應用系統架構圖
需要包含以下模組，
- 服務給誰用
出了問題應該通知到誰 - 包含哪些模組
應用了哪些功能模組。使用者報問題過來的時候知道大體屬於哪個服務出了問題 - 系統流程
模組間如何流轉的 - 依賴的中介軟體
依賴了哪些中介軟體，對應負責人是誰 - 依賴的儲存、訊息佇列
依賴了哪些儲存，儲存運維負責人是誰 - 依賴的服務
依賴了哪些服務，什麼功能依賴了什麼服務，出了問題，找誰。是否是弱依賴，可降級的。
繪製應用系統部署圖
系統是如何部署的，部署在什麼環境。如何登陸、擴容、升配。
梳理系統故障等級
哪些模組是核心的，哪些模組是沒那麼重要的，可以降級的。
壓測演練
當前系統能夠支援的單機QPS是多少，可能存在的效能瓶頸是什麼，需要通過壓測來得出來。
當前應用的API讀寫比是多少，對應到各個儲存層面的比例是多少。當應用QPS上升，哪個依賴最先掛掉。redis/mysql 還是依賴的服務，還是應用本身。
定期盤點
無論是使用者反饋故障，還是監控警報，基本都晚了，因為這時候已經累積了一定錯誤量的呼叫了。所以需要再搶先一步，定期盤點應用。衡量的指標一般圍繞使用率、飽和度、吞吐量以及響應時間
盤點的內容包括所有的依賴。
-
應用層面
磁碟cpu，記憶體，load數，jvm gc情況 -
系統層面
qps -
依賴的儲存
磁碟，cpu, IOPS， qps。 -
訊息佇列
消費速度是否正常
另外系統日誌是第一手的故障資訊來源，應用owner需要定期對錯誤日誌進行查詢，能夠有效的將潛在問題扼殺在搖籃裡。
監控警報
監控警報有助於提早發現故障，所以確保監控項完備，警報能夠有效報出來。
以下是常用的一些監控項
| 型別 | 監控項 |
|---|---|
| 主機狀態 | 磁碟使用率>85 |
| 主機狀態 | 5分鐘load > 核數*1.5 |
| 主機狀態 | 5分鐘記憶體使用率 > 80 |
| 主機狀態 | 5分鐘CPU > 50 |
| API | 5分鐘API錯誤率>0.1 |
| SQL | 慢查詢 耗時>100ms |
| 日誌 | 1分鐘錯誤數>10 |
| 日誌 | 5分鐘錯誤數>50 |