引子

近期隨著業務的改造，新舊交替，不同系統的穩定性問題大量爆發，基于此我們對穩定加大了投入，梳理出來了部分保證系統平穩運行的方法論，在這里做一下分享，切記"穩定性壓倒一切".

保障總則

保障總則，即保障策略，對于一個系統，如果要做到全方位的穩定性保障，應該具備一下3個硬性條件，脫離這3個條件，很難保證線上業務能夠在波譎云詭的大海上長久穩定運行。

可感知
可預防和應急
可快速處理

下面就上面的3個條件，這里做一些細致的說明。

可感知

可感知顧名思義，就是要能夠實時的監測到系統的運行狀態，任何細微的波動都能反饋出來。可感知最重要的便是監控系統，監控是我們的眼睛，有了他我們才能觀察到我們的業務在線上運行的怎么樣。

監控體系是感知、預防問題最主要、最有效的手段，主要包括業務監控、應用監控、系統監控。對于監控來說必須保障靈敏性、準確性，在此基礎上在配合告警系統，我們就能第一時間發現問題并處理問題，減少故障帶來的損失，減少輿論壓力，贏得使用方的信賴。此外一些特殊的優先級高的故障應該發送給GOC故障報警，防止工作時間盲區不能及時發現。

業務監控

業務監控突出的是業務場景，業務指標，他和一些硬件指標不同，我們需要有鏈路追蹤功能（trace），要能實時反應一個用戶的操作從客戶端發起一直到服務端的整個過程，能夠沒階段的耗時，花銷，調用等信息。方便我們定位故障發生的位置，縮短問題處理時間。當然了這只是最基本的一個監控埋點，對于不同的業務形態，我們還需定義不同的指標。

對于網關層我們關注的是：

PV， UV

業務qps

錯誤狀態碼請求量

請求耗時

不通region的流量占比...

對于分布式系統，我們可能更關注：

set/get等各種指令的qps（不同分布是系統，這塊兒不同）
latency
slot是否均衡
error

應用監控

應用監控強調的是一些支撐業務運行的框架或系統的監控信息，他們是業務運行的土壤，常見的監控內容

JVM：內存、GC、線程、CPU
異常：應用的異常數
WEB URL：應用URL的調用數量、時間、并發情況
Spring 方法：方法調用數量、時間、并發情況
SQL：執行次數、時間、并發
服務HSF：執行次數、時間、成功率

系統監控

系統監控就是監控我們的硬件資源，這是業務最最最底層的東西，所有的應用都直接或者間接的跑在硬件上。要包括：

RT(頁面平均響應時間)
LOAD/CPU/MEMORY/DISK/TRAFFIC(網卡流量)
TCP(各個狀態、請求量、retry)/端口監控
網絡：LVS/交換機流量/帶寬容量
容量水位：集群的實時QPS水位

異常報警

有了監控不配置告警，那么你的監控系統將不能發揮他的作用，將顯得一無是處。

GOC故障報警配置：需要注意的是一定要和故障等級保持一致，為了避免誤報，建議增加多維度監控，如成功率+失敗量，成功量+總量組合等。
報警閾值必須和故障等級定義保持一致（如P4是下跌10%等），如果有平時波動比較大，請和GOC同學確認故障等級定義的閾值。
接入風險預警：曲線下跌接近故障點時，提前在群里推送通知提醒
自己感知的報警：P1、P2故障點要有業務自己感知的報警機制，提前發現異常，不要等到GOC推送報警，過于被動

線上巡檢

定期的線上巡檢，能夠提前發現系統的瓶頸，從而在故障發生前消除故障，像資源容量，訪問量的增長趨勢，訪問不均衡等都能在問題出現前得到處理。對于線上巡檢：

核心頁面線上巡檢：P1、P2故障點的頁面巡檢頻率需要縮短到分鐘級（如15分鐘），因為P1、P2故障點一旦發生就是分鐘級，迅速下跌
頁面請求耗時前端監控：前端或測試同學增加核心頁面響應時間耗時監控

可預防及應急

強弱依賴

穩定性建設非常重要的一環是梳理出應用、接口的強弱依賴，首先梳理出哪些是強依賴，哪些是弱依賴。強依賴一般指此服務有問題，流程會卡住，直接影響功能，否則為弱依賴。

要有強弱依賴梳理工具，能夠查詢接口的調用鏈，根據業務場景去判斷哪些接口是強依賴、哪些是弱依賴

強弱依賴接口治理：

先去除沒有必要、不合理的依賴
不影響核心業務的依賴全部變為弱依賴
弱依賴：增設降級開關，緊急情況直接降級處理；配置限流
強依賴：能加緩存的加緩存；加預案開關 ，可快速止血

限流降級

限流閾值：壓測目標達成且壓測穩定后，根據壓測時段接口的單機qps峰值和壓測時段系統的水位來設置；一般是接口單機qps峰值上調20%。線上驗證的時候，根據block的次數和系統的水位來決定是否再次調整。

降級：對外部依賴服務接口，要做降級處理

反爬：對異常流量進行攔截和清洗，將其扼殺在門外

針對被第三方調用的接口要做限流處理，以防流量暴增被拖垮；

同時依賴別人的服務接口，也要做一定的降級處理，以免受到抖動等異常的影響。

應急預案

對于線上的故障和異常，我們要設置應急預案，應急SOP，應急工作流能夠保證快速恢復，再此基礎上我們更應該建設自己的應急預案平臺，能夠做到一鍵降級，一鍵切流。

預案平臺要支持switch、diamond、orange等多種配置推送方式，應急情況下可打開預案開關。

預案開關在緊急情況下可快速止血，但是預案在線上使用前必須在日常、預發環境驗證通過后，再到線上開啟。此外，建議提前掛公告，對消費者有影響的，同步客滿，更建議做好產品體驗優化，避免降級后帶來的大量客訴。

故障演練

我司沒周都會有固定時間進行壓測，驗證節假日或大促的峰值，除此之外還有每個業務團隊（包括中間件）也有自己的定期演練計劃，最好能夠建設自己的故障演練平臺，能夠全方位的模擬故障。

故障演練隸屬于破壞性測試，但其本身的應用范圍不僅僅在于測試環節，業務應用相當廣泛，談談可能存在三種業務。

建立基于SLO（SLA）的故障體系

Google SRE中已經說明絕對的高可用付出的成本極大，零故障系統是不存在的，任何服務都應該給出自己服務風險容忍度，并且應該要采用錯誤預算的機制來鼓勵提高系統可靠性。

通過故障演練來推進建設服務SLA體系（SLA是服務SLO，加上不滿足SLO的“處罰”內容），也是一可行路徑：

任何系統，尤其是底層服務系統，比方說網關類如aserver，中間件類如vipserver，基礎設施類如網絡設備，都應該提供對外服務能力申明（即SLA），通過故障演練確定具體SLO值，并且采用錯誤預算方法來定期錘煉服務系統。
故障等級制度，應該以SLA為標準激勵系統改進穩定性，故障恢復時長滿足SLA的重大故障是否可降級，雖然故障發生由天定，但故障恢復處理時長的縮短，從2個小時到30分鐘到10分鐘，這就標識著穩定性的進步，故障演練平時可錘煉和夯實故障恢復能力。
服務系統對外透明服務SLA，本身就對上游系統的依賴提出了要求，因此在系統開發中就會考慮到異常的處理方案，故障演練可檢測出不滿足“契約”的上游系統，基于此制定不同的服務承諾，如不同應用分組穩定性等級不同。

穩定性建設的評估體系

隨著業務飛速發展，部署環境非常復雜，大系統和小系統在同一個機房部署是不可避免的，不同的系統對穩定性訴求其實是不一樣的，這主要取決于業務的發展情況和成本控制，不可能一刀切以最高級穩定性要求每個系統。

某些系統（像交易）由于承載的業務量巨大，影響范圍很廣，因此必須要滿足異地多活的容災要求。但有些業務系統只需要做到同城雙機房的容災能力即可，剛起步的業務系統甚至只需要滿足集群層面的穩定即可。我們需要對系統的穩定性能力加以辨別區分，從業務流量、部署結構、可靠性容災能力建設三方面給系統準確的評分，配合于資源的申請、發布的控制，給業務系統提供量身定制的穩定性保障服務，故障演練為穩定性評估體系建設提供數據支撐。

故障管理的驗證閉環

圍繞故障生命周期有四個環節，分別是發現、處理、復盤、驗證，故障演練作為故障改進措施驗證的有力手段，完善故障周期管理，提高系統穩定性的同時，反向又驗證了復盤環節的效能，對改進措施是否有效是否缺失，流程機制是否合理，皆可實現量化管理。

服務治理

應用治理

根據應用對應故障點等級、發布情況、是否外部應用等對應用劃分等級，然后針對性進行治理。

智運營團隊梳理標準如下：

P0 面向外部用戶并且能夠產生P2以上故障的故障點
P1 能夠產生P2以上故障的故障點
P2 面向外部用戶業務的應用
P3 近三個月有變更并且能夠產生P3以下故障點的應用
P4 發布頻次均三個月一次以下，幾乎不會產生故障的應用
P5 待下線,待移交的應用

推動下線

對于待下線的應用，請及時下線，一般對于待下線應用都瀕臨無人維護無人關注的境地，但卻存在出現問題的風險。

應用拆分

核心應用單元化
推動承載多個服務的核心應用進行拆分：如果存在一個服務承載了很多核心功能，服務數高達100+，如果它掛，很多應用都受影響，那這樣的應用就屬于高風險應用，需要盡快根據業務場景進行拆分。

非法應用

理論上所有應用準確來說是所有的變更，都應該可灰度、可監控、可回滾
檢查是否存在不可灰度、不可回滾，沒有接入changefree的應用，此類應用是違法亂紀應用，貿然發布出了問題就是觸發研發紅線，后果極其嚴重

核心應用

核心應用支持彈性擴容，做最后的兜底
理論上建議承載P1、P2故障點的應用在有資源的情況下都升級高配機
長時間未發布（2/3個月）：定時進行重啟
定時檢查線上水位，保證維持在一個正常水位

慢SQL治理

這個就專門開一篇文章講。

總結

以上是生活随笔為你收集整理的如何全方位的保障系统的稳定性的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。