全鏈路壓測(11):聊聊穩定性預案

老_張發表於2022-05-08

前言

全鏈路壓測出現的初衷是阿里為了解決雙十一線上系統在峰值流量衝擊下的穩定性和可用性問題,在後續落地及不斷的演進過程中,出現了很多技術領域的最佳實踐。

前面的文章也為大家介紹了很多全鏈路壓測從專案啟動到準備階段的很多細節。這篇文章,我想談談在全鏈路壓測落地演進過程中,一個很重要的實踐——穩定性預案。

 

什麼是預案?

通過字面意思來看,預案通俗易懂,即針對預期可能出現的問題所設計的解決方案。

放在全鏈路壓測領域,其實穩定性預案並非全鏈路壓測體系中的一部分,而是可以看做一個獨立的細小領域,但又和全鏈路壓測有重要的聯動關係。

因為全鏈路壓測大多在生產環境開展,雖然可以通過流量識別和資料隔離來保證不對線上業務和資料造成影響,但畢竟是在生產環境執行,有些問題難以避免。

 

預案有哪些型別?

從我近幾年的實踐經驗來說,預案大概分入如下幾種型別:

日常預案

  1. 線上服務釋出失敗的回滾方案;
  2. 線上服務負載過高的監控告警通知方案;
  3. 使用者無感知的灰度釋出、無損釋出等方案;
  4. 限流、降級、熔斷等服務治理領域的技術方案;
  5. 線上服務防止黑客攻擊的各種高防和安全應對方案;

大促活動預案

一般大促活動都是指類似618、雙11等營銷活動,視業務情況而定。常見的有:

  1. 日誌歸檔;
  2. 訊息降級(小紅點);
  3. 評論關閉(商品評論、社群動態評論);
  4. 本地快取(降級和熔斷後的兜底手段);
  5. 快取預熱(優惠券、商品、使用者地址);
  6. 定時job錯峰(job任務錯開流量高峰);
  7. 依賴解耦(核心服務的強依賴解耦,避免雪崩);
  8. 服務分組(核心服務、核心MQ按照權重優先順序做分組隔離);
  9. 客戶端限流浮層(針對服務限流後使用者頻繁點選導致的流量放大場景);

業務穩定性預案

  1. 商品推薦臨時關閉;
  2. 線上對賬和防資損校驗;
  3. 調整商品退貨退款到賬時間;

PS:當預案體系比較熟練後,可通過平臺開關的方式進行配置,收攏許可權,避免人為操作導致的問題。

 

預案的作用是什麼?

從技術角度來講,任何一個細微問題都可能導致生產出現重大故障,因此針對性的設計對應的預案就顯得至關重要。

從業務角度來講,無論技術做任何的改動和優化,最終的目的都是為了業務目標的達成。而系統的穩定性,無論從使用者體驗還是業務目標達成的角度來看,都是不可忽視的一環。

因此預案的作用就呼之欲出:從技術的角度出發,為業務目標的達成提供多維度的穩定性保障

 

如何制定預案?

上面列舉了很多常見的穩定性預案,在我看來制定預案是一個經驗+評估的問題。常見的制定預案的方式如下:

  1. 從日常的線上問題著手,彙總問題和解決方案,覆盤得到TODO項和落地驗證;
  2. 從系統設計和業務需求分析角度開始,前置性的進行評估分析,設定對應的預案;
  3. 從使用者體驗和使用者行為分析角度出發,優化使用者操作過程和互動邏輯,避免類似問題;

 

最後的經驗之談

  1. 所有預案都需要經過評估分析;
  2. 沒有驗證的預案都是潛在的風險;
  3. 預案都是有風險和成本的,避免過度設計;
  4. 預案的最終目標是保障業務目標達成,而非秀技術;

 

相關文章