穩定性保障6步走：高可用系統大促做戰指南！

簡介： 年年有大促，你們對於大促穩定性保障這個詞都不陌生，業務場景儘管各不相同，「套路」每每殊路同歸，全鏈路壓測、容量評估、限流、緊急預案等，來來去去總少不了那麼幾板斧。跳出這些「套路」，回到問題的本質，咱們爲何要按照這些策略來作？除了口口相傳的歷史經驗，咱們還能作些什麼？又有什麼理論依據？

一 、前言

年年有大促，你們對於大促穩定性保障這個詞都不陌生，業務場景儘管各不相同，「套路」每每殊路同歸，全鏈路壓測、容量評估、限流、緊急預案等，來來去去總少不了那麼幾板斧。

跳出這些「套路」，回到問題的本質，咱們爲何要按照這些策略來作？

除了口口相傳的歷史經驗，咱們還能作些什麼？又有什麼理論依據？

二 、怎樣的系統算是穩定？

首先回答另外一個問題，怎樣的系統算是穩定的？

Google SRE中(SRE三部曲[1])有一個層級模型來描述系統可靠性基礎和高層次需求(Dickerson's Hierarchy of Service Reliability)，以下圖：

該模型由Google SRE工程師Mikey Dickerson在2013年提出，將系統穩定性需求按照基礎程度進行了不一樣層次的體系化區分，造成穩定性標準金字塔模型。

金字塔的底座是監控(Monitoring)，這是一個系統對於穩定性最基礎的要求，缺乏監控的系統，如同蒙上眼睛狂奔的野馬，無從談及可控性，更遑論穩定性。更上層是應急響應(Incident Response)，從一個問題被監控發現到最終解決，這期間的耗時直接取決於應急響應機制的成熟度。合理的應急策略能保證當故障發生時，全部問題能獲得有序且妥善的處理，而不是慌亂成一鍋粥。過後總結以及根因分析(Postmortem&Root Caue Analysis)，即咱們平時談到的「覆盤」，雖然不少人都不太喜歡這項活動，可是不得不認可這是避免咱們下次犯一樣錯誤的最有效手段，只有當摸清故障的根因以及對應的缺陷，咱們才能對症下藥，合理進行規避。

假設一個系統從初次發佈後就再也不進行更新迭代，作好上述三個方面的工做就能基本知足系統對於穩定性的所有需求。惋惜目前基本不會存在這樣的系統，大大小小的應用都離不開不斷的變動與發佈，所以要保證系統在這些迭代中持續穩定，測試和發佈管控(Testing&Release procedures)是必不可少的。有效的測試與發佈策略能保障系統全部新增變量都處於可控穩定區間內，從而達到總體服務終態穩定。除了代碼邏輯更新，迭代一樣可能帶來業務規模及流量的變化，容量規劃(Capacity Planning)則是針對於這方面變化進行的保障策略。現有系統體量是否足夠支撐新的流量需求，總體鏈路上是否存在不對等的薄弱節點，都是容量規劃須要考慮的問題。

位於金字塔模型最頂端的是產品設計(Product)與軟件研發(Development)，即經過優秀的產品設計與軟件設計使系統具有更高的可靠性，構建高可用產品架構體系，從而提高用戶體驗。

三 、大促穩定性保障方法

從金字塔模型咱們能夠看到構建維護一個高可用服務所須要作到的幾方面工做，那麼問題回到大促穩定性，如何體系化地保障大促期間系統穩定性？

大促保障實際上針對於特定業務場景的集中穩定性建設工做，相較於平常保障工做，具備高併發流量、短保障週期的特色，對系統性能與保障時間有明確要求（通常爲2個月左右）。

考慮到上述特性，咱們如何在短期內針對大促大流量業務場景對系統穩定性需求進行優化鞏固？

既然時間有限，盲目撒網必然不是最佳策略，須要有針對性地從關鍵點、薄弱點下手。所以第一步，須要得到全局系統鏈路現狀，包括關鍵外部依賴、重點業務影響等，找到總體保障的核心關注點。接下來進一步分析大促業務數據，獲得除系統自己之外的變量干擾因素。以這二者爲基礎，集中圍繞金字塔模型中系統監控、規劃容量、應急響應、測試和覆盤等幾個方面需求對系統進行鍼對性集中保障建設，獲得最終保障結果。

至此，基本得到了完整的大促穩定性保障策略方向，按照執行順序依次是：

1. 系統鏈路&業務策略梳理（System & Biz Profiling）
2. 監控（Monitoring）
3. 容量規劃（Capacity Planning）
4. 應急響應（Incident Response）
5. 測試
6. 過後總結（Testing & Postmortem）

一、 System & Biz Profiling - 系統鏈路梳理

系統鏈路梳理是全部保障工做的基礎，如同對總體應用系統進行一次全面體檢，從流量入口開始，按照鏈路軌跡，逐級分層節點，獲得系統全局畫像與核心保障點。

入口梳理盤點

一個系統每每存在十幾個甚至更多流量入口，包含HTTP、RPC、消息等都多種來源。若是沒法覆蓋全部全部鏈路，能夠從如下三類入口開始進行梳理：

• 核心重保流量入口用戶承諾服務SLI較高，對數據準確性、服務響應時間、可靠度具備明確要求。面向企業級用戶
• 資損事件對應入口關聯到公司資金收入或者客戶資金收入收費服務
• 大流量入口系統TPS&QPS TOP5~10該類入口雖然不涉及較高SLI與資損要求，可是流量較高，對總體系統負載有較大影響。

節點分層判斷

流量入口就如同線團中的線頭，挑出線頭後就可按照流量軌跡對鏈路上的節點(HSFDBTairHBase等一切外部依賴)按照依賴程度、可用性、可靠性進行初級分層區分。

（1）強弱依賴節點判斷

• 若節點不可用，鏈路業務邏輯被中斷 or 高級別有損(存在必定耐受閾值)，則爲業務強依賴；反之爲弱依賴。
• 若節點不可用，鏈路執行邏輯被中斷(return error)，則爲系統強依賴；反之爲弱依賴。
• 若節點不可用，系統性能受影響，則爲系統強依賴；反之爲弱依賴。按照快速失敗設計邏輯，該類節點不該存在，可是在不變動應用代碼前提下，若是出現該類節點，應做爲強依賴看待。
• 若節點無感可降級 or 存在業務輕微損傷替換方案，則爲弱依賴。

（2）低可用依賴節點判斷

• 節點服務平常超時嚴重
• 節點對應系統資源不足

（3）高風險節點判斷

• 上次大促後，節點存在大版本系統改造
• 新上線未經歷過大促的節點
• 節點對應系統是否曾經出現高級別故障
• 節點故障後存在資損風險

應產出數據

完成該項梳理工做後，咱們應該產出如下數據：對應業務域全部核心鏈路分析，技術&業務強依賴、核心上游、下游系統、資損風險應明確標註。

下圖爲單條鏈路分析示例：

二、 System & Biz Profiling - 業務策略同步

不一樣於高可用系統建設體系，大促穩定性保障體系與面向特定業務活動的針對性保障建設，所以，業務策略與數據是咱們進行保障前不可或缺的數據。

通常大促業務數據可分爲兩類，全局業務形態評估以及應急策略&玩法。

全局評估

該類數據從能夠幫助咱們進行精準流量評估、峯值預測、大促人力排班等等，通常包含下面幾類：

• 大促業務時長（XX日-XX日）
• 業務量預估體量（平常X倍）
• 預估峯值日期
• 業務場景預估流量分配

應急策略

該類數據指相較於往年大促活動，本次大促業務變量，可用於應急響應預案與高風險節點評估等，通常包含下面兩類：

• 特殊業務玩法
• 應急狀況打法策略

3 、Monitoring - 監控&告警梳理

目前業界經常使用的監控手段通常有兩種模式，黑盒監控(Black-box monitoring)與白盒監控(White-box monitoring)。黑盒監控面向對象，通常監控正在發生（而非即將發生）的異常，即系統現有故障。而白盒監控主要依賴系統內部指標監控，面向對象的同時也面向緣由，可對系統即將面臨的異常進行提早預警，也可在異常發生時同步監控下層內部指標，從而定位根本緣由。所以大促穩定性保障中，咱們通常選擇的是白盒監控。

站在監控的角度看，咱們的系統從上到下通常能夠分爲三層：業務（Biz）、應用（Application）、系統（System）。系統層爲最下層基礎，表示操做系統相關狀態；應用層爲JVM層，涵蓋主應用進程與中間件運行狀態；業務層爲最上層，爲業務視角下服務對外運行狀態。

所以進行大促穩定性監控梳理時，能夠先脫離現有監控，先從核心、資損鏈路開始，按照業務、應用（中間件、JVM、DB）、系統三個層次梳理須要哪些監控，再從根據這些索引找到對應的監控告警，若是不存在，則相應補上；若是存在則檢查閾值、時間、告警人是否合理。

監控

監控系統通常有四項黃金指標：延時（Latency）, 錯誤（Error）,流量（Traffic）, 飽和度（Situation），各層的關鍵性監控一樣也能夠按照這四項指標來進行歸類，具體以下：

表 1

告警

是否是每項監控都須要告警？答案固然是否認的。建議優先設置Biz層告警，由於Biz層咱們對外服務最直觀業務表現，最貼切用戶感覺。Application&System層指標主要用於監控，部分關鍵&高風險指標可設置告警，用於問題排查定位以及故障提早發現。

對於一項告警，咱們通常須要關注級別、閾值、通知人等幾個點。

1）級別

即當前告警被觸發時，問題的嚴重程度，通常來講有幾個衡量點：

• 是否關聯GOC
• 是否產生嚴重業務影響
• 是否產生資損

2）閾值

即一項告警的觸發條件&時間，需根據具體場景合理制定。通常遵循如下原則：

• 不可過於遲鈍。一個合理的監控體系中，任何異常發生後都應觸發相關告警。
• 不可過於敏感。過於敏感的閾值會形成頻繁告警，從而致使響應人員疲勞應對，沒法篩選真實異常。若一個告警頻繁出現，通常是兩個緣由：系統設計不合理 or 閾值設置不合理。
• 若單一指標沒法反饋覆蓋總體業務場景，可結合多項指標關聯構建。
• 需符合業務波動曲線，不一樣時段可設置不一樣條件&通知策略。

3）通知人&方式

若爲業務指標異常(Biz層告警)，通知人應爲問題處理人員(開發、運維同窗)與業務關注人員(TL、業務同窗)的集合，通知方式較爲實時，好比電話通知。

若爲應用 & 系統層告警，主要用於定位異常緣由，通知人設置問題排查處理人員便可，通知方式可考慮釘釘、短信等低干擾方式。

除了關聯層次，對於不一樣級別的告警，通知人範圍也可適當擴大，尤爲是關聯GOC故障的告警指標，應適當放寬範圍，通知方式也應更爲實時直接。

應產出數據

完成該項梳理工做後，咱們應該產出如下數據：

• 系統監控模型，格式同表1Biz、Application、System 分別存在哪些待監控點監控點是否已所有存在指標，仍有哪些待補充
• 系統告警模型列表，需包含如下數據關聯監控指標（連接）告警關鍵級別是否推送GOC是否產生資損是否關聯故障是否關聯預案
• 業務指標大盤，包含Biz層重點監控指標數據。
• 系統&應用指標大盤，包含核心系統關鍵系統指標，可用於白盒監控定位問題。

4 、Capacity Planning - 容量規劃

容量規劃的本質是追求計算風險最小化和計算成本最小化之間的平衡，只追求任意其一都不是合理的。爲了達到這二者的最佳平衡點，需儘可能精準計算系統峯值負載流量，再將流量根據單點資源負載上限換算成相應容量，獲得最終容量規劃模型。

流量模型評估

1）入口流量

對於一次大促，系統峯值入口流量通常由常規業務流量與很是規增量（好比容災預案&業務營銷策略變化帶來的流量模型配比變化）疊加擬合而成。

（a）常規業務流量通常有兩類計算方式：

歷史流量算法：該類算法假設當年大促增幅徹底符合歷史流量模型，根據當前&歷年平常流量，計算總體業務體量同比增量模型；而後根據歷年大促-平常對比，計算預估流量環比增量模型；最後兩者擬合獲得最終評估數據。

因爲計算時無需依賴任何業務信息輸入，該類算法可用於保障工做初期業務還沒有給出業務總量評估時使用，獲得初估業務流量。

業務量-流量轉化算法(GMVDAU訂單量)：該類算法通常以業務預估總量（GMVDAU訂單量）爲輸入，根據歷史大促&平常業務量-流量轉化模型（好比經典漏洞模型）換算獲得對應子域業務體量評估。

該種方式強依賴業務總量預估，可在保障工做中後期使用，在初估業務流量基礎上歸入業務評估因素考慮。

（b）很是規增量通常指前臺業務營銷策略變動或系統應急預案執行後流量模型變化形成的增量流量。例如，NA61機房故障時，流量100%切換到NA62後，帶來的增量變化。

考慮到成本最小化，很是規增量P計算時通常無需與常規業務流量W一塊兒，全量歸入疊加入口流量K，通常會將很是規策略發生機率λ做爲權重，即：

2）節點流量

節點流量由入口流量根據流量分支模型，按比例轉化而來。分支流量模型以系統鏈路爲計算基礎，遵循如下原則：

• 同一入口，不一樣鏈路佔比流量獨立計算。
• 針對同一鏈路上同一節點，若存在屢次調用，需計算按倍數同比放大（好比DBTair等）。
• DB寫流量重點關注，可能出現熱點形成DB HANG死。

容量轉化

1）Little Law衍生法則

不一樣類型資源節點(應用容器、Tair、DB、HBASE等)流量-容量轉化比各不相同，但都服從Little Law衍生法則，即：

2）N + X 冗餘原則

• 在知足目標流量所須要的最小容量基礎上，冗餘保留X單位冗餘能力
• X與目標成本與資源節點故障機率成正相關，不可用機率越高，X越高
• 對於通常應用容器集羣，可考慮X = 0.2N

上述法則只能用於容量初估(大促壓測前&新依賴)，最終精準系統容量仍是須要結合系統週期性壓力測試得出。

應產出數據

• 基於模型評估的入口流量模型 & 集羣自身容量轉化結果（若爲非入口應用，則爲限流點梳理）。
• 基於鏈路梳理的分支流量模型 & 外部依賴容量轉化結果。

5 Incident Response - 緊急&前置預案梳理

要想在大促高併發流量場景下快速對線上緊急事故進行響應處理，僅僅依賴值班同窗臨場發揮是遠遠不夠的。爭分奪秒的狀況下，沒法給處理人員留有充足的策略思考空間，而錯誤的處理決策，每每會致使更爲失控嚴重的業務&系統影響。所以，要想在大促現場快速而正確的響應問題，值班同窗須要作的是選擇題(Which)，而不是陳述題(What)。而選項的構成，即是咱們的業務&系統預案。

從執行時機與解決問題屬性來劃分，預案可分爲技術應急預案、技術前置預案、業務應急預案、業務前置預案等四大類。結合以前的鏈路梳理和業務評估結果，咱們能夠快速分析出鏈路中須要的預案，遵循如下原則：

• 技術應急預案：該類預案用於處理系統鏈路中，某層次節點不可用的狀況，例如技術/業務強依賴、弱穩定性、高風險等節點不可用等異常場景。
• 技術前置預案：該類預案用於平衡總體系統風險與單節點服務可用性，經過熔斷等策略保障全局服務可靠。例如弱穩定性&弱依賴服務提早降級、與峯值流量時間衝突的離線任務提早暫定等。
• 業務應急預案：該類預案用於應對業務變動等非系統性異常帶來的需應急處理問題，例如業務數據錯誤（數據正確性敏感節點）、務策略調整（配合業務應急策略）等
• 業務前置預案：該類預案用於配和業務全局策略進行的前置服務調整（非系統性需求）

應產出數據

完成該項梳理工做後，咱們應該產出如下數據：

• 執行&關閉時間（前置預案）
• 觸發閾值（緊急預案，須關聯相關告警）
• 關聯影響（系統&業務）
• 決策&執行&驗證人員
• 開啓驗證方式
• 關閉閾值（緊急預案）
• 關閉驗證方式

階段性產出-全鏈路做戰地圖

進行完上述幾項保障工做，咱們基本可獲得全局鏈路做戰地圖，包含鏈路分支流量模型、強弱依賴節點、資損評估、對應預案&處理策略等信息。大促期間可憑藉該地圖快速從全局視角查看應急事件相關影響，同時也可根據地圖反向評估預案、容量等梳理是否完善合理。

6 、Incident Response - 做戰手冊梳理

做戰手冊是整個大促保障的行動依據，貫穿於整個大促生命週期，可從事前、事中、過後三個階段展開考慮。

總體梳理應本着精準化、精細化的原則，理想狀態下，即使是對業務、系統不熟悉的輪班同窗，憑藉手冊也能快速響應處理線上問題。

事前

1）前置檢查事項清單

大促前必須執行事項checklist,一般包含如下事項：

• 集羣機器重啓 or 手動FGC
• 影子表數據清理
• 檢查上下游機器權限
• 檢查限流值
• 檢查機器開關一致性
• 檢查數據庫配置
• 檢查中間件容量、配置(DB緩存NoSQL等)
• 檢查監控有效性（業務大盤、技術大盤、核心告警）
• 每一個事項都需包含具體執行人、檢查方案、檢查結果三列數據

2）前置預案

域內全部業務&技術前置預案。

事中

1）緊急技術&業務預案

須要包含的內容基本同前置預案，差別點以下：

• 執行條件&恢復條件：具體觸發閾值，對應監控告警項。
• 通知決策人。

2）應急工具&腳本

常見故障排查方式、核心告警止血方式(強弱依賴不可用等)，業務相關日誌撈取腳本等。

3）告警&大盤

應包含業務、系統集羣及中間件告警監控梳理結果，核心業務以及系統大盤，對應日誌數據源明細等數據：

• 日誌數據源明細：數據源名稱、文件位置、樣例、切分格式。
• 業務、系統集羣及中間件告警監控梳理結果：關聯監控指標（連接）、告警關鍵級別、是否推送GOC、是否產生資損、是否關聯故障、是否關聯預案。
• 核心業務&系統大盤：大盤地址、包含指標明細(含義、是否關聯告警、對應日誌)。

4）上下游機器分組

應包含核心系統、上下游系統，在不一樣機房、單元集羣分組、應用名，可用於事前-機器權限檢查、事中-應急問題排查黑屏處理。

5）值班注意事項

包含每班輪班同窗值班必作事項、應急變動流程、核心大盤連接等。

6）核心播報指標

包含核心系統&服務指標(CPULOADRT)、業務關注指標等，每項指標應明確具體監控地址、採集方式。

7）域內&關聯域人員通信錄、值班

包含域內技術、TL、業務方對應排班狀況、聯繫方式(電話)，相關上下游、基礎組件(DB、中間件等)對應值班狀況。

8）值班問題記錄

做戰記錄，記錄工單、業務問題、預案(前置緊急)（至少包含：時間、問題描述（截圖）、影響分析、決策&解決過程等）。值班同窗在值班結束前，進行記錄。

過後

1）系統恢復設置事項清單(限流、縮容)

通常與事前檢查事項清單對應，包含限流閾值調整、集羣縮容等大促後恢復操做。

2）大促問題覆盤記錄

應包含大促遇到的核心事件總結梳理。

7 Incident Response - 沙盤推演

實戰沙盤演練是應急響應方面的最後一項保障工做，以歷史真實故障CASE做爲應急場景輸入，模擬大促期間緊急情況，旨在考驗值班同窗們對應急問題處理的響應狀況。

通常來講，一個線上問題從發現到解決，中間須要經歷定位&排查&診斷&修復等過程，整體遵循如下幾點原則：

• 盡最大可能讓系統先恢復服務，同時爲根源調查保護現場（機器、日誌、水位記錄）。
• 避免盲目搜索，依據白盒監控針對性診判定位。
• 有序分工，各司其職，避免一窩蜂失控亂象。
• 依據現場狀況實時評估影響範圍，實在沒法經過技術手段挽救的狀況(例如強依賴不可用)，轉化爲業務問題思考（影響範圍、程度、是否有資損、如何協同業務方）。
• 沙盤演練旨在檢驗值班同窗故障處理能力，着重關注止血策略、分工安排、問題定位等三個方面：

國際化中臺雙11買家域演練

根據故障類型，常見止血策略有如下解決思路：

• 入口限流：調低對應Provider服務來源限流值應對突發流量太高致使自身系統、下游強依賴負載被打滿。
• 下游降級：降級對應下游服務下游弱依賴不可用。下游業務強依賴經業務贊成後降級（業務部分有損）。
• 單點失敗移除：摘除不可用節點單機水位飆高時，先下線不可用單機服務（無需下線機器，保留現場）。應對集羣單點不可用、性能差。
• 切換：單元切流或者切換備份應對單庫或某單元依賴由於自身緣由（宿主機或網絡），形成局部流量成功率下跌下跌。

Google SRE中，對於緊急事故管理有如下幾點要素：

• 嵌套式職責分離，即分確的職能分工安排
• 控制中心做戰室
• 實時事故狀態文檔
• 明確公開的職責交接

其中嵌套式職責分離，即分確的職能分工安排，達到各司其職，有序處理的效果，通常可分爲下列幾個角色：

• 事故總控：負責協調分工以及未分配事務兜底工做，掌握全局概要信息，通常爲PM/TL擔任。
• 事務處理團隊：事故真正處理人員，可根據具體業務場景&系統特性分爲多個小團隊。團隊內部存在域內負責人，與事故總控人員進行溝通。
• 發言人：事故對外聯絡人員，負責對事故處理內部成員以及外部關注人員信息作週期性信息同步，同時須要實時維護更新事故文檔。
• 規劃負責人：負責外部持續性支持工做，好比當大型故障出現，多輪排班輪轉時，負責組織職責交接記錄。

做者：開發者小助手_LS
原文連接

本文爲阿里雲原創內容，未經容許不得轉載