一 前言
年年有大促，大家對于大促穩定性保障這個詞都不陌生，業務場景盡管各不相同，“套路”往往殊路同歸，全鍊路壓測、容量評估、限流、緊急預案等，來來去去總少不了那麼幾闆斧。
跳出這些“套路”，回到問題的本質，我們為什麼要按照這些政策來做？
除了口口相傳的曆史經驗，我們還能做些什麼？又有什麼理論依據？
二 怎樣的系統算是穩定？
首先回答另一個問題，怎樣的系統算是穩定的？
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個月左右）。
考慮到上述特性，我們如何在短時間内針對大促大流量業務場景對系統穩定性需求進行優化鞏固？
既然時間有限，盲目撒網必然不是最佳政策，需要有針對性地從關鍵點、薄弱點下手。是以第一步，需要獲得全局系統鍊路現狀，包括關鍵外部依賴、重點業務影響等，找到整體保障的核心關注點。接下來進一步分析大促業務資料，得到除系統本身以外的變量幹擾因素。以這兩者為基礎，集中圍繞金字塔模型中系統監控、規劃容量、應急響應、測試和複盤等幾個方面需求對系統進行針對性集中保障建設，得到最終保障結果。
至此，基本獲得了完整的大促穩定性保障政策方向，按照執行順序依次是：
- 系統鍊路&業務政策梳理（System & Biz Profiling）
- 監控（Monitoring）
- 容量規劃（Capacity Planning）
- 應急響應（Incident Response）
- 測試
- 事後總結（Testing & Postmortem）
1 System & Biz Profiling - 系統鍊路梳理
系統鍊路梳理是所有保障工作的基礎，如同對整體應用系統進行一次全面體檢，從流量入口開始，按照鍊路軌迹，逐級分層節點，得到系統全局畫像與核心保障點。
入口梳理盤點
一個系統往往存在十幾個甚至更多流量入口，包含HTTP、RPC、消息等都多種來源。如果無法覆寫所有所有鍊路，可以從以下三類入口開始進行梳理：
- 核心重保流量入口
- 使用者承諾服務SLI較高，對資料準确性、服務響應時間、可靠度具有明确要求。
- 面向企業級使用者
- 資損事件對應入口
- 關聯到公司資金收入或者客戶資金收入
- 收費服務
- 大流量入口
- 系統TPS&QPS TOP5~10
- 該類入口雖然不涉及較高SLI與資損要求，但是流量較高，對整體系統負載有較大影響。
節點分層判斷
流量入口就如同線團中的線頭，挑出線頭後就可按照流量軌迹對鍊路上的節點(HSF\DB\Tair\HBase等一切外部依賴)按照依賴程度、可用性、可靠性進行初級分層區分。
（1）強弱依賴節點判斷
- 若節點不可用，鍊路業務邏輯被中斷 or 進階别有損(存在一定耐受門檻值)，則為業務強依賴；反之為弱依賴。
- 若節點不可用，鍊路執行邏輯被中斷(return error)，則為系統強依賴；反之為弱依賴。
- 若節點不可用，系統性能受影響，則為系統強依賴；反之為弱依賴。
- 按照快速失敗設計邏輯，該類節點不應存在，但是在不變更應用代碼前提下，如果出現該類節點，應作為強依賴看待。
- 若節點無感可降級 or 存在業務輕微損傷替換方案，則為弱依賴。
（2）低可用依賴節點判斷
- 節點服務日常逾時嚴重
- 節點對應系統資源不足
（3）高風險節點判斷
- 上次大促後，節點存在大版本系統改造
- 新上線未經曆過大促的節點
- 節點對應系統是否曾經出現進階别故障
- 節點故障後存在資損風險
應産出資料
完成該項梳理工作後，我們應該産出以下資料：對應業務域所有核心鍊路分析，技術&業務強依賴、核心上遊、下遊系統、資損風險應明确标注。
下圖為單條鍊路分析示例：
2 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故障的告警名額，應适當放寬範圍，通知方式也應更為實時直接。
完成該項梳理工作後，我們應該産出以下資料：
- 系統監控模型，格式同表1
- Biz、Application、System 分别存在哪些待監控點
- 監控點是否已全部存在名額，仍有哪些待補充
- 系統告警模型清單，需包含以下資料
- 關聯監控名額（連結）
- 告警關鍵級别
- 是否推送GOC
- 是否關聯故障
- 是否關聯預案
- 業務名額大盤，包含Biz層重點監控名額資料。
- 系統&應用名額大盤，包含核心系統關鍵系統名額，可用于白盒監控定位問題。
4 Capacity Planning - 容量規劃
容量規劃的本質是追求計算風險最小化和計算成本最小化之間的平衡，隻追求任意其一都不是合理的。為了達到這兩者的最佳平衡點，需盡量精準計算系統峰值負載流量，再将流量根據單點資源負載上限換算成相應容量，得到最終容量規劃模型。
流量模型評估
1）入口流量
對于一次大促，系統峰值入口流量一般由正常業務流量與非正常增量（比如容災預案&業務營銷政策變化帶來的流量模型配比變化）疊加拟合而成。
（a）正常業務流量一般有兩類計算方式：
曆史流量算法：該類算法假設當年大促增幅完全符合曆史流量模型，根據目前&曆年日常流量，計算整體業務體量同比增量模型；然後根據曆年大促-日常對比，計算預估流量環比增量模型；最後二者拟合得到最終評估資料。
由于計算時無需依賴任何業務資訊輸入，該類算法可用于保障工作初期業務尚未給出業務總量評估時使用，得到初估業務流量。
業務量-流量轉化算法(GMV\DAU\訂單量)：該類算法一般以業務預估總量（GMV\DAU\訂單量）為輸入，根據曆史大促&日常業務量-流量轉化模型（比如經典漏洞模型）換算得到對應子域業務體量評估。
該種方式強依賴業務總量預估，可在保障工作中後期使用，在初估業務流量基礎上納入業務評估因素考慮。
（b）非正常增量一般指前台業務營銷政策變更或系統應急預案執行後流量模型變化造成的增量流量。例如，NA61機房故障時，流量100%切換到NA62後，帶來的增量變化。
考慮到成本最小化，非正常增量P計算時一般無需與正常業務流量W一起，全量納入疊加入口流量K，一般會将非正常政策發生機率λ作為權重，即：
2）節點流量
節點流量由入口流量根據流量分支模型，按比例轉化而來。分支流量模型以系統鍊路為計算基礎，遵循以下原則：
- 同一入口，不同鍊路占比流量獨立計算。
- 針對同一鍊路上同一節點，若存在多次調用，需計算按倍數同比放大（比如DB\Tair等）。
- 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）核心播報名額
包含核心系統&服務名額(CPU\LOAD\RT)、業務關注名額等，每項名額應明确具體監控位址、采集方式。
7）域内&關聯域人員通訊錄、值班
包含域内技術、TL、業務方對應排班情況、聯系方式(電話)，相關上下遊、基礎元件(DB、中間件等)對應值班情況。
8）值班問題記錄
作戰記錄，記錄工單、業務問題、預案(前置\緊急)（至少包含：時間、問題描述（截圖）、影響分析、決策&解決過程等）。值班同學在值班結束前，進行記錄。
事後
1）系統恢複設定事項清單(限流、縮容)
一般與事前檢查事項清單對應，包含限流門檻值調整、叢集縮容等大促後恢複操作。
2）大促問題複盤記錄
應包含大促遇到的核心事件總結梳理。
7 Incident Response - 沙盤推演
實戰沙盤演練是應急響應方面的最後一項保障工作，以曆史真實故障CASE作為應急場景輸入，模拟大促期間緊急狀況，旨在考驗值班同學們對應急問題處理的響應情況。
一般來說，一個線上問題從發現到解決，中間需要經曆定位&排查&診斷&修複等過程，總體遵循以下幾點原則：
- 盡最大可能讓系統先恢複服務，同時為根源調查保護現場（機器、日志、水位記錄）。
- 避免盲目搜尋，依據白盒監控針對性診斷定位。
- 有序分工，各司其職，避免一窩蜂失控亂象。
- 依據現場情況實時評估影響範圍，實在無法通過技術手段挽救的情況(例如強依賴不可用)，轉化為業務問題思考（影響範圍、程度、是否有資損、如何協同業務方）。
- 沙盤演練旨在檢驗值班同學故障處理能力，着重關注止血政策、分工安排、問題定位等三個方面：
國際化中台雙11買家域演練
根據故障類型，常見止血政策有以下解決思路：
- 入口限流：調低對應Provider服務來源限流值
- 應對突發流量過高導緻自身系統、下遊強依賴負載被打滿。
- 下遊降級：降級對應下遊服務
- 下遊弱依賴不可用。
- 下遊業務強依賴經業務同意後降級（業務部分有損）。
- 單點失敗移除：摘除不可用節點
- 單機水位飙高時，先下線不可用單機服務（無需下線機器，保留現場）。
- 應對叢集單點不可用、性能差。
- 切換：單元切流或者切換備份
- 應對單庫或某單元依賴因為自身原因（主控端或網絡），造成局部流量成功率下跌下跌。
- 嵌套式職責分離，即分确的職能分工安排
- 控制中心\作戰室
- 實時事故狀态文檔
- 明确公開的職責交接
- 事故總控：負責協調分工以及未配置設定事務兜底工作，掌握全局概要資訊，一般為PM/TL擔任。
- 事務處理團隊：事故真正處理人員，可根據具體業務場景&系統特性分為多個小團隊。團隊内部存在域内負責人，與事故總控人員進行溝通。
- 發言人：事故對外聯絡人員，負責對事故處理内部成員以及外部關注人員資訊做周期性資訊同步，同時需要實時維護更新事故文檔。
- 規劃負責人：負責外部持續性支援工作，比如當大型故障出現，多輪排班輪轉時，負責組織職責交接記錄。