一、前言

年年有大促，大家對(duì)于大促穩(wěn)定性保障這個(gè)詞都不陌生，業(yè)務(wù)場(chǎng)景盡管各不相同，“套路”往往殊路同歸，全鏈路壓測(cè)、容量評(píng)估、限流、緊急預(yù)案等，來(lái)來(lái)去去總少不了那么幾板斧。

跳出這些“套路”，回到問(wèn)題的本質(zhì)，我們?yōu)槭裁匆凑者@些策略來(lái)做?

除了口口相傳的歷史經(jīng)驗(yàn)，我們還能做些什么?又有什么理論依據(jù)?

二、怎樣的系統(tǒng)算是穩(wěn)定?

首先回答另一個(gè)問(wèn)題，怎樣的系統(tǒng)算是穩(wěn)定的?

Google SRE中(SRE三部曲[1])有一個(gè)層級(jí)模型來(lái)描述系統(tǒng)可靠性基礎(chǔ)和高層次需求(Dickerson's Hierarchy of Service Reliability)，如下圖：

該模型由Google SRE工程師Mikey Dickerson在2013年提出，將系統(tǒng)穩(wěn)定性需求按照基礎(chǔ)程度進(jìn)行了不同層次的體系化區(qū)分，形成穩(wěn)定性標(biāo)準(zhǔn)金字塔模型。

金字塔的底座是監(jiān)控(Monitoring)，這是一個(gè)系統(tǒng)對(duì)于穩(wěn)定性最基礎(chǔ)的要求，缺少監(jiān)控的系統(tǒng)，如同蒙上眼睛狂奔的野馬，無(wú)從談及可控性，更遑論穩(wěn)定性。更上層是應(yīng)急響應(yīng)(Incident Response)，從一個(gè)問(wèn)題被監(jiān)控發(fā)現(xiàn)到最終解決，這期間的耗時(shí)直接取決于應(yīng)急響應(yīng)機(jī)制的成熟度。合理的應(yīng)急策略能保證當(dāng)故障發(fā)生時(shí)，所有問(wèn)題能得到有序且妥善的處理，而不是慌亂成一鍋粥。事后總結(jié)以及根因分析(Postmortem&Root Caue Analysis)，即我們平時(shí)談到的“復(fù)盤(pán)”，雖然很多人都不太喜歡這項(xiàng)活動(dòng)，但是不得不承認(rèn)這是避免我們下次犯同樣錯(cuò)誤的最有效手段，只有當(dāng)摸清故障的根因以及對(duì)應(yīng)的缺陷，我們才能對(duì)癥下藥，合理進(jìn)行規(guī)避。

假設(shè)一個(gè)系統(tǒng)從初次發(fā)布后就不再進(jìn)行更新迭代，做好上述三個(gè)方面的工作就能基本滿(mǎn)足系統(tǒng)對(duì)于穩(wěn)定性的全部需求。可惜目前基本不會(huì)存在這樣的系統(tǒng)，大大小小的應(yīng)用都離不開(kāi)不斷的變更與發(fā)布，因此要保證系統(tǒng)在這些迭代中持續(xù)穩(wěn)定，測(cè)試和發(fā)布管控(Testing&Release procedures)是必不可少的。有效的測(cè)試與發(fā)布策略能保障系統(tǒng)所有新增變量都處于可控穩(wěn)定區(qū)間內(nèi)，從而達(dá)到整體服務(wù)終態(tài)穩(wěn)定。除了代碼邏輯更新，迭代同樣可能帶來(lái)業(yè)務(wù)規(guī)模及流量的變化，容量規(guī)劃(Capacity Planning)則是針對(duì)于這方面變化進(jìn)行的保障策略?，F(xiàn)有系統(tǒng)體量是否足夠支撐新的流量需求，整體鏈路上是否存在不對(duì)等的薄弱節(jié)點(diǎn)，都是容量規(guī)劃需要考慮的問(wèn)題。

位于金字塔模型最頂端的是產(chǎn)品設(shè)計(jì)(Product)與軟件研發(fā)(Development)，即通過(guò)優(yōu)秀的產(chǎn)品設(shè)計(jì)與軟件設(shè)計(jì)使系統(tǒng)具備更高的可靠性，構(gòu)建高可用產(chǎn)品架構(gòu)體系，從而提升用戶(hù)體驗(yàn)。

三、大促穩(wěn)定性保障方法

從金字塔模型我們可以看到構(gòu)建維護(hù)一個(gè)高可用服務(wù)所需要做到的幾方面工作，那么問(wèn)題回到大促穩(wěn)定性，如何體系化地保障大促期間系統(tǒng)穩(wěn)定性?

大促保障實(shí)際上針對(duì)于特定業(yè)務(wù)場(chǎng)景的集中穩(wěn)定性建設(shè)工作，相較于日常保障工作，具有高并發(fā)流量、短保障周期的特點(diǎn)，對(duì)系統(tǒng)性能與保障時(shí)間有明確要求(一般為2個(gè)月左右)。

考慮到上述特性，我們?nèi)绾卧诙虝r(shí)間內(nèi)針對(duì)大促大流量業(yè)務(wù)場(chǎng)景對(duì)系統(tǒng)穩(wěn)定性需求進(jìn)行優(yōu)化鞏固?

既然時(shí)間有限，盲目撒網(wǎng)必然不是最佳策略，需要有針對(duì)性地從關(guān)鍵點(diǎn)、薄弱點(diǎn)下手。因此第一步，需要獲得全局系統(tǒng)鏈路現(xiàn)狀，包括關(guān)鍵外部依賴(lài)、重點(diǎn)業(yè)務(wù)影響等，找到整體保障的核心關(guān)注點(diǎn)。接下來(lái)進(jìn)一步分析大促業(yè)務(wù)數(shù)據(jù)，得到除系統(tǒng)本身以外的變量干擾因素。以這兩者為基礎(chǔ)，集中圍繞金字塔模型中系統(tǒng)監(jiān)控、規(guī)劃容量、應(yīng)急響應(yīng)、測(cè)試和復(fù)盤(pán)等幾個(gè)方面需求對(duì)系統(tǒng)進(jìn)行針對(duì)性集中保障建設(shè)，得到最終保障結(jié)果。

至此，基本獲得了完整的大促穩(wěn)定性保障策略方向，按照?qǐng)?zhí)行順序依次是：

1. 系統(tǒng)鏈路&業(yè)務(wù)策略梳理(System & Biz Profiling)
2. 監(jiān)控(Monitoring)
3. 容量規(guī)劃(Capacity Planning)
4. 應(yīng)急響應(yīng)(Incident Response)
5. 測(cè)試
6. 事后總結(jié)(Testing & Postmortem)

1、System & Biz Profiling - 系統(tǒng)鏈路梳理

系統(tǒng)鏈路梳理是所有保障工作的基礎(chǔ)，如同對(duì)整體應(yīng)用系統(tǒng)進(jìn)行一次全面體檢，從流量入口開(kāi)始，按照鏈路軌跡，逐級(jí)分層節(jié)點(diǎn)，得到系統(tǒng)全局畫(huà)像與核心保障點(diǎn)。

入口梳理盤(pán)點(diǎn)

一個(gè)系統(tǒng)往往存在十幾個(gè)甚至更多流量入口，包含HTTP、RPC、消息等都多種來(lái)源。如果無(wú)法覆蓋所有所有鏈路，可以從以下三類(lèi)入口開(kāi)始進(jìn)行梳理：

核心重保流量入口

• 用戶(hù)承諾服務(wù)SLI較高，對(duì)數(shù)據(jù)準(zhǔn)確性、服務(wù)響應(yīng)時(shí)間、可靠度具有明確要求。
• 面向企業(yè)級(jí)用戶(hù)

資損事件對(duì)應(yīng)入口

• 關(guān)聯(lián)到公司資金收入或者客戶(hù)資金收入
• 收費(fèi)服務(wù)

大流量入口

• 系統(tǒng)TPS&QPS TOP5~10
• 該類(lèi)入口雖然不涉及較高SLI與資損要求，但是流量較高，對(duì)整體系統(tǒng)負(fù)載有較大影響。

節(jié)點(diǎn)分層判斷

流量入口就如同線(xiàn)團(tuán)中的線(xiàn)頭，挑出線(xiàn)頭后就可按照流量軌跡對(duì)鏈路上的節(jié)點(diǎn)(HSF\DB\Tair\HBase等一切外部依賴(lài))按照依賴(lài)程度、可用性、可靠性進(jìn)行初級(jí)分層區(qū)分。

(1)強(qiáng)弱依賴(lài)節(jié)點(diǎn)判斷

• 若節(jié)點(diǎn)不可用，鏈路業(yè)務(wù)邏輯被中斷 or 高級(jí)別有損(存在一定耐受閾值)，則為業(yè)務(wù)強(qiáng)依賴(lài);反之為弱依賴(lài)。
• 若節(jié)點(diǎn)不可用，鏈路執(zhí)行邏輯被中斷(return error)，則為系統(tǒng)強(qiáng)依賴(lài);反之為弱依賴(lài)。
• 若節(jié)點(diǎn)不可用，系統(tǒng)性能受影響，則為系統(tǒng)強(qiáng)依賴(lài);反之為弱依賴(lài)。
  • 按照快速失敗設(shè)計(jì)邏輯，該類(lèi)節(jié)點(diǎn)不應(yīng)存在，但是在不變更應(yīng)用代碼前提下，如果出現(xiàn)該類(lèi)節(jié)點(diǎn)，應(yīng)作為強(qiáng)依賴(lài)看待。
• 若節(jié)點(diǎn)無(wú)感可降級(jí) or 存在業(yè)務(wù)輕微損傷替換方案，則為弱依賴(lài)。

(2)低可用依賴(lài)節(jié)點(diǎn)判斷

• 節(jié)點(diǎn)服務(wù)日常超時(shí)嚴(yán)重
• 節(jié)點(diǎn)對(duì)應(yīng)系統(tǒng)資源不足

(3)高風(fēng)險(xiǎn)節(jié)點(diǎn)判斷

• 上次大促后，節(jié)點(diǎn)存在大版本系統(tǒng)改造
• 新上線(xiàn)未經(jīng)歷過(guò)大促的節(jié)點(diǎn)
• 節(jié)點(diǎn)對(duì)應(yīng)系統(tǒng)是否曾經(jīng)出現(xiàn)高級(jí)別故障
• 節(jié)點(diǎn)故障后存在資損風(fēng)險(xiǎn)

應(yīng)產(chǎn)出數(shù)據(jù)

完成該項(xiàng)梳理工作后，我們應(yīng)該產(chǎn)出以下數(shù)據(jù)：對(duì)應(yīng)業(yè)務(wù)域所有核心鏈路分析，技術(shù)&業(yè)務(wù)強(qiáng)依賴(lài)、核心上游、下游系統(tǒng)、資損風(fēng)險(xiǎn)應(yīng)明確標(biāo)注。

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

2、System & Biz Profiling - 業(yè)務(wù)策略同步

不同于高可用系統(tǒng)建設(shè)體系，大促穩(wěn)定性保障體系與面向特定業(yè)務(wù)活動(dòng)的針對(duì)性保障建設(shè)，因此，業(yè)務(wù)策略與數(shù)據(jù)是我們進(jìn)行保障前不可或缺的數(shù)據(jù)。

一般大促業(yè)務(wù)數(shù)據(jù)可分為兩類(lèi)，全局業(yè)務(wù)形態(tài)評(píng)估以及應(yīng)急策略&玩法。

全局評(píng)估

該類(lèi)數(shù)據(jù)從可以幫助我們進(jìn)行精準(zhǔn)流量評(píng)估、峰值預(yù)測(cè)、大促人力排班等等，一般包含下面幾類(lèi)：

• 大促業(yè)務(wù)時(shí)長(zhǎng)(XX日-XX日)
• 業(yè)務(wù)量預(yù)估體量(日常X倍)
• 預(yù)估峰值日期
• 業(yè)務(wù)場(chǎng)景預(yù)估流量分配

應(yīng)急策略

該類(lèi)數(shù)據(jù)指相較于往年大促活動(dòng)，本次大促業(yè)務(wù)變量，可用于應(yīng)急響應(yīng)預(yù)案與高風(fēng)險(xiǎn)節(jié)點(diǎn)評(píng)估等，一般包含下面兩類(lèi)：

• 特殊業(yè)務(wù)玩法
• 應(yīng)急情況打法策略

3、Monitoring - 監(jiān)控&告警梳理

目前業(yè)界常用的監(jiān)控手段一般有兩種模式，黑盒監(jiān)控(Black-box monitoring)與白盒監(jiān)控(White-box monitoring)。黑盒監(jiān)控面向?qū)ο?，一般監(jiān)控正在發(fā)生(而非即將發(fā)生)的異常，即系統(tǒng)現(xiàn)有故障。而白盒監(jiān)控主要依賴(lài)系統(tǒng)內(nèi)部指標(biāo)監(jiān)控，面向?qū)ο蟮耐瑫r(shí)也面向原因，可對(duì)系統(tǒng)即將面臨的異常進(jìn)行提前預(yù)警，也可在異常發(fā)生時(shí)同步監(jiān)控下層內(nèi)部指標(biāo)，從而定位根本原因。因此大促穩(wěn)定性保障中，我們一般選擇的是白盒監(jiān)控。

站在監(jiān)控的角度看，我們的系統(tǒng)從上到下一般可以分為三層：業(yè)務(wù)(Biz)、應(yīng)用(Application)、系統(tǒng)(System)。系統(tǒng)層為最下層基礎(chǔ)，表示操作系統(tǒng)相關(guān)狀態(tài);應(yīng)用層為JVM層，涵蓋主應(yīng)用進(jìn)程與中間件運(yùn)行狀態(tài);業(yè)務(wù)層為最上層，為業(yè)務(wù)視角下服務(wù)對(duì)外運(yùn)行狀態(tài)。

因此進(jìn)行大促穩(wěn)定性監(jiān)控梳理時(shí)，可以先脫離現(xiàn)有監(jiān)控，先從核心、資損鏈路開(kāi)始，按照業(yè)務(wù)、應(yīng)用(中間件、JVM、DB)、系統(tǒng)三個(gè)層次梳理需要哪些監(jiān)控，再?gòu)母鶕?jù)這些索引找到對(duì)應(yīng)的監(jiān)控告警，如果不存在，則相應(yīng)補(bǔ)上;如果存在則檢查閾值、時(shí)間、告警人是否合理。

監(jiān)控

監(jiān)控系統(tǒng)一般有四項(xiàng)黃金指標(biāo)：延時(shí)(Latency), 錯(cuò)誤(Error),流量(Traffic), 飽和度(Situation)，各層的關(guān)鍵性監(jiān)控同樣也可以按照這四項(xiàng)指標(biāo)來(lái)進(jìn)行歸類(lèi)，具體如下：

表 1

告警

是不是每項(xiàng)監(jiān)控都需要告警?答案當(dāng)然是否定的。建議優(yōu)先設(shè)置Biz層告警，因?yàn)锽iz層我們對(duì)外服務(wù)最直觀(guān)業(yè)務(wù)表現(xiàn)，最貼切用戶(hù)感受。Application&System層指標(biāo)主要用于監(jiān)控，部分關(guān)鍵&高風(fēng)險(xiǎn)指標(biāo)可設(shè)置告警，用于問(wèn)題排查定位以及故障提前發(fā)現(xiàn)。

對(duì)于一項(xiàng)告警，我們一般需要關(guān)注級(jí)別、閾值、通知人等幾個(gè)點(diǎn)。

1)級(jí)別

即當(dāng)前告警被觸發(fā)時(shí)，問(wèn)題的嚴(yán)重程度，一般來(lái)說(shuō)有幾個(gè)衡量點(diǎn)：

• 是否關(guān)聯(lián)GOC
• 是否產(chǎn)生嚴(yán)重業(yè)務(wù)影響
• 是否產(chǎn)生資損

2)閾值

即一項(xiàng)告警的觸發(fā)條件&時(shí)間，需根據(jù)具體場(chǎng)景合理制定。一般遵循以下原則：

• 不可過(guò)于遲鈍。一個(gè)合理的監(jiān)控體系中，任何異常發(fā)生后都應(yīng)觸發(fā)相關(guān)告警。
• 不可過(guò)于敏感。過(guò)于敏感的閾值會(huì)造成頻繁告警，從而導(dǎo)致響應(yīng)人員疲勞應(yīng)對(duì)，無(wú)法篩選真實(shí)異常。若一個(gè)告警頻繁出現(xiàn)，一般是兩個(gè)原因：系統(tǒng)設(shè)計(jì)不合理 or 閾值設(shè)置不合理。
• 若單一指標(biāo)無(wú)法反饋覆蓋整體業(yè)務(wù)場(chǎng)景，可結(jié)合多項(xiàng)指標(biāo)關(guān)聯(lián)構(gòu)建。
• 需符合業(yè)務(wù)波動(dòng)曲線(xiàn)，不同時(shí)段可設(shè)置不同條件&通知策略。

3)通知人&方式

若為業(yè)務(wù)指標(biāo)異常(Biz層告警)，通知人應(yīng)為問(wèn)題處理人員(開(kāi)發(fā)、運(yùn)維同學(xué))與業(yè)務(wù)關(guān)注人員(TL、業(yè)務(wù)同學(xué))的集合，通知方式較為實(shí)時(shí)，比如電話(huà)通知。

若為應(yīng)用 & 系統(tǒng)層告警，主要用于定位異常原因，通知人設(shè)置問(wèn)題排查處理人員即可，通知方式可考慮釘釘、短信等低干擾方式。

除了關(guān)聯(lián)層次，對(duì)于不同級(jí)別的告警，通知人范圍也可適當(dāng)擴(kuò)大，尤其是關(guān)聯(lián)GOC故障的告警指標(biāo)，應(yīng)適當(dāng)放寬范圍，通知方式也應(yīng)更為實(shí)時(shí)直接。

應(yīng)產(chǎn)出數(shù)據(jù)

完成該項(xiàng)梳理工作后，我們應(yīng)該產(chǎn)出以下數(shù)據(jù)：

• 系統(tǒng)監(jiān)控模型，格式同表1
  • Biz、Application、System 分別存在哪些待監(jiān)控點(diǎn)
  • 監(jiān)控點(diǎn)是否已全部存在指標(biāo)，仍有哪些待補(bǔ)充
• 系統(tǒng)告警模型列表，需包含以下數(shù)據(jù)
  • 關(guān)聯(lián)監(jiān)控指標(biāo)(鏈接)
  • 告警關(guān)鍵級(jí)別
  • 是否推送GOC
  • 是否產(chǎn)生資損
  • 是否關(guān)聯(lián)故障
  • 是否關(guān)聯(lián)預(yù)案
• 業(yè)務(wù)指標(biāo)大盤(pán)，包含Biz層重點(diǎn)監(jiān)控指標(biāo)數(shù)據(jù)。
• 系統(tǒng)&應(yīng)用指標(biāo)大盤(pán)，包含核心系統(tǒng)關(guān)鍵系統(tǒng)指標(biāo)，可用于白盒監(jiān)控定位問(wèn)題。

4、Capacity Planning - 容量規(guī)劃

容量規(guī)劃的本質(zhì)是追求計(jì)算風(fēng)險(xiǎn)最小化和計(jì)算成本最小化之間的平衡，只追求任意其一都不是合理的。為了達(dá)到這兩者的最佳平衡點(diǎn)，需盡量精準(zhǔn)計(jì)算系統(tǒng)峰值負(fù)載流量，再將流量根據(jù)單點(diǎn)資源負(fù)載上限換算成相應(yīng)容量，得到最終容量規(guī)劃模型。

流量模型評(píng)估

1)入口流量

對(duì)于一次大促，系統(tǒng)峰值入口流量一般由常規(guī)業(yè)務(wù)流量與非常規(guī)增量(比如容災(zāi)預(yù)案&業(yè)務(wù)營(yíng)銷(xiāo)策略變化帶來(lái)的流量模型配比變化)疊加擬合而成。

(a)常規(guī)業(yè)務(wù)流量一般有兩類(lèi)計(jì)算方式：

歷史流量算法：該類(lèi)算法假設(shè)當(dāng)年大促增幅完全符合歷史流量模型，根據(jù)當(dāng)前&歷年日常流量，計(jì)算整體業(yè)務(wù)體量同比增量模型;然后根據(jù)歷年大促-日常對(duì)比，計(jì)算預(yù)估流量環(huán)比增量模型;最后二者擬合得到最終評(píng)估數(shù)據(jù)。

由于計(jì)算時(shí)無(wú)需依賴(lài)任何業(yè)務(wù)信息輸入，該類(lèi)算法可用于保障工作初期業(yè)務(wù)尚未給出業(yè)務(wù)總量評(píng)估時(shí)使用，得到初估業(yè)務(wù)流量。

業(yè)務(wù)量-流量轉(zhuǎn)化算法(GMV\DAU\訂單量)：該類(lèi)算法一般以業(yè)務(wù)預(yù)估總量(GMV\DAU\訂單量)為輸入，根據(jù)歷史大促&日常業(yè)務(wù)量-流量轉(zhuǎn)化模型(比如經(jīng)典漏洞模型)換算得到對(duì)應(yīng)子域業(yè)務(wù)體量評(píng)估。

該種方式強(qiáng)依賴(lài)業(yè)務(wù)總量預(yù)估，可在保障工作中后期使用，在初估業(yè)務(wù)流量基礎(chǔ)上納入業(yè)務(wù)評(píng)估因素考慮。

(b)非常規(guī)增量一般指前臺(tái)業(yè)務(wù)營(yíng)銷(xiāo)策略變更或系統(tǒng)應(yīng)急預(yù)案執(zhí)行后流量模型變化造成的增量流量。例如，NA61機(jī)房故障時(shí)，流量100%切換到NA62后，帶來(lái)的增量變化。

考慮到成本最小化，非常規(guī)增量P計(jì)算時(shí)一般無(wú)需與常規(guī)業(yè)務(wù)流量W一起，全量納入疊加入口流量K，一般會(huì)將非常規(guī)策略發(fā)生概率λ作為權(quán)重，即：

2)節(jié)點(diǎn)流量

節(jié)點(diǎn)流量由入口流量根據(jù)流量分支模型，按比例轉(zhuǎn)化而來(lái)。分支流量模型以系統(tǒng)鏈路為計(jì)算基礎(chǔ)，遵循以下原則：

• 同一入口，不同鏈路占比流量獨(dú)立計(jì)算。
• 針對(duì)同一鏈路上同一節(jié)點(diǎn)，若存在多次調(diào)用，需計(jì)算按倍數(shù)同比放大(比如DB\Tair等)。
• DB寫(xiě)流量重點(diǎn)關(guān)注，可能出現(xiàn)熱點(diǎn)造成DB HANG死。

容量轉(zhuǎn)化

1)Little Law衍生法則

不同類(lèi)型資源節(jié)點(diǎn)(應(yīng)用容器、Tair、DB、HBASE等)流量-容量轉(zhuǎn)化比各不相同，但都服從Little Law衍生法則，即：

2)N + X 冗余原則

• 在滿(mǎn)足目標(biāo)流量所需要的最小容量基礎(chǔ)上，冗余保留X單位冗余能力
• X與目標(biāo)成本與資源節(jié)點(diǎn)故障概率成正相關(guān)，不可用概率越高，X越高
• 對(duì)于一般應(yīng)用容器集群，可考慮X = 0.2N

上述法則只能用于容量初估(大促壓測(cè)前&新依賴(lài))，最終精準(zhǔn)系統(tǒng)容量還是需要結(jié)合系統(tǒng)周期性壓力測(cè)試得出。

應(yīng)產(chǎn)出數(shù)據(jù)

• 基于模型評(píng)估的入口流量模型 & 集群自身容量轉(zhuǎn)化結(jié)果(若為非入口應(yīng)用，則為限流點(diǎn)梳理)。
• 基于鏈路梳理的分支流量模型 & 外部依賴(lài)容量轉(zhuǎn)化結(jié)果。

5、Incident Response - 緊急&前置預(yù)案梳理

要想在大促高并發(fā)流量場(chǎng)景下快速對(duì)線(xiàn)上緊急事故進(jìn)行響應(yīng)處理，僅僅依賴(lài)值班同學(xué)臨場(chǎng)發(fā)揮是遠(yuǎn)遠(yuǎn)不夠的。爭(zhēng)分奪秒的情況下，無(wú)法給處理人員留有充足的策略思考空間，而錯(cuò)誤的處理決策，往往會(huì)導(dǎo)致更為失控嚴(yán)重的業(yè)務(wù)&系統(tǒng)影響。因此，要想在大促現(xiàn)場(chǎng)快速而正確的響應(yīng)問(wèn)題，值班同學(xué)需要做的是選擇題(Which)，而不是陳述題(What)。而選項(xiàng)的構(gòu)成，便是我們的業(yè)務(wù)&系統(tǒng)預(yù)案。

從執(zhí)行時(shí)機(jī)與解決問(wèn)題屬性來(lái)劃分，預(yù)案可分為技術(shù)應(yīng)急預(yù)案、技術(shù)前置預(yù)案、業(yè)務(wù)應(yīng)急預(yù)案、業(yè)務(wù)前置預(yù)案等四大類(lèi)。結(jié)合之前的鏈路梳理和業(yè)務(wù)評(píng)估結(jié)果，我們可以快速分析出鏈路中需要的預(yù)案，遵循以下原則：

• 技術(shù)應(yīng)急預(yù)案：該類(lèi)預(yù)案用于處理系統(tǒng)鏈路中，某層次節(jié)點(diǎn)不可用的情況，例如技術(shù)/業(yè)務(wù)強(qiáng)依賴(lài)、弱穩(wěn)定性、高風(fēng)險(xiǎn)等節(jié)點(diǎn)不可用等異常場(chǎng)景。
• 技術(shù)前置預(yù)案：該類(lèi)預(yù)案用于平衡整體系統(tǒng)風(fēng)險(xiǎn)與單節(jié)點(diǎn)服務(wù)可用性，通過(guò)熔斷等策略保障全局服務(wù)可靠。例如弱穩(wěn)定性&弱依賴(lài)服務(wù)提前降級(jí)、與峰值流量時(shí)間沖突的離線(xiàn)任務(wù)提前暫定等。
• 業(yè)務(wù)應(yīng)急預(yù)案：該類(lèi)預(yù)案用于應(yīng)對(duì)業(yè)務(wù)變更等非系統(tǒng)性異常帶來(lái)的需應(yīng)急處理問(wèn)題，例如業(yè)務(wù)數(shù)據(jù)錯(cuò)誤(數(shù)據(jù)正確性敏感節(jié)點(diǎn))、務(wù)策略調(diào)整(配合業(yè)務(wù)應(yīng)急策略)等
• 業(yè)務(wù)前置預(yù)案：該類(lèi)預(yù)案用于配和業(yè)務(wù)全局策略進(jìn)行的前置服務(wù)調(diào)整(非系統(tǒng)性需求)

應(yīng)產(chǎn)出數(shù)據(jù)

完成該項(xiàng)梳理工作后，我們應(yīng)該產(chǎn)出以下數(shù)據(jù)：

• 執(zhí)行&關(guān)閉時(shí)間(前置預(yù)案)
• 觸發(fā)閾值(緊急預(yù)案，須關(guān)聯(lián)相關(guān)告警)
• 關(guān)聯(lián)影響(系統(tǒng)&業(yè)務(wù))
• 決策&執(zhí)行&驗(yàn)證人員
• 開(kāi)啟驗(yàn)證方式
• 關(guān)閉閾值(緊急預(yù)案)
• 關(guān)閉驗(yàn)證方式

階段性產(chǎn)出-全鏈路作戰(zhàn)地圖

進(jìn)行完上述幾項(xiàng)保障工作，我們基本可得到全局鏈路作戰(zhàn)地圖，包含鏈路分支流量模型、強(qiáng)弱依賴(lài)節(jié)點(diǎn)、資損評(píng)估、對(duì)應(yīng)預(yù)案&處理策略等信息。大促期間可憑借該地圖快速?gòu)娜忠暯遣榭磻?yīng)急事件相關(guān)影響，同時(shí)也可根據(jù)地圖反向評(píng)估預(yù)案、容量等梳理是否完善合理。

6、Incident Response - 作戰(zhàn)手冊(cè)梳理

作戰(zhàn)手冊(cè)是整個(gè)大促保障的行動(dòng)依據(jù)，貫穿于整個(gè)大促生命周期，可從事前、事中、事后三個(gè)階段展開(kāi)考慮。

整體梳理應(yīng)本著精準(zhǔn)化、精細(xì)化的原則，理想狀態(tài)下，即便是對(duì)業(yè)務(wù)、系統(tǒng)不熟悉的輪班同學(xué)，憑借手冊(cè)也能快速響應(yīng)處理線(xiàn)上問(wèn)題。

事前

1)前置檢查事項(xiàng)清單

大促前必須執(zhí)行事項(xiàng)checklist,通常包含以下事項(xiàng)：

• 集群機(jī)器重啟 or 手動(dòng)FGC
• 影子表數(shù)據(jù)清理
• 檢查上下游機(jī)器權(quán)限
• 檢查限流值
• 檢查機(jī)器開(kāi)關(guān)一致性
• 檢查數(shù)據(jù)庫(kù)配置
• 檢查中間件容量、配置(DB\緩存\NoSQL等)
• 檢查監(jiān)控有效性(業(yè)務(wù)大盤(pán)、技術(shù)大盤(pán)、核心告警)
• 每個(gè)事項(xiàng)都需包含具體執(zhí)行人、檢查方案、檢查結(jié)果三列數(shù)據(jù)

2)前置預(yù)案

域內(nèi)所有業(yè)務(wù)&技術(shù)前置預(yù)案。

事中

1)緊急技術(shù)&業(yè)務(wù)預(yù)案

需要包含的內(nèi)容基本同前置預(yù)案，差異點(diǎn)如下：

• 執(zhí)行條件&恢復(fù)條件：具體觸發(fā)閾值，對(duì)應(yīng)監(jiān)控告警項(xiàng)。
• 通知決策人。

2)應(yīng)急工具&腳本

常見(jiàn)故障排查方式、核心告警止血方式(強(qiáng)弱依賴(lài)不可用等)，業(yè)務(wù)相關(guān)日志撈取腳本等。

3)告警&大盤(pán)

應(yīng)包含業(yè)務(wù)、系統(tǒng)集群及中間件告警監(jiān)控梳理結(jié)果，核心業(yè)務(wù)以及系統(tǒng)大盤(pán)，對(duì)應(yīng)日志數(shù)據(jù)源明細(xì)等數(shù)據(jù)：

• 日志數(shù)據(jù)源明細(xì)：數(shù)據(jù)源名稱(chēng)、文件位置、樣例、切分格式。
• 業(yè)務(wù)、系統(tǒng)集群及中間件告警監(jiān)控梳理結(jié)果：關(guān)聯(lián)監(jiān)控指標(biāo)(鏈接)、告警關(guān)鍵級(jí)別、是否推送GOC、是否產(chǎn)生資損、是否關(guān)聯(lián)故障、是否關(guān)聯(lián)預(yù)案。
• 核心業(yè)務(wù)&系統(tǒng)大盤(pán)：大盤(pán)地址、包含指標(biāo)明細(xì)(含義、是否關(guān)聯(lián)告警、對(duì)應(yīng)日志)。

4)上下游機(jī)器分組

應(yīng)包含核心系統(tǒng)、上下游系統(tǒng)，在不同機(jī)房、單元集群分組、應(yīng)用名，可用于事前-機(jī)器權(quán)限檢查、事中-應(yīng)急問(wèn)題排查黑屏處理。

5)值班注意事項(xiàng)

包含每班輪班同學(xué)值班必做事項(xiàng)、應(yīng)急變更流程、核心大盤(pán)鏈接等。

6)核心播報(bào)指標(biāo)

包含核心系統(tǒng)&服務(wù)指標(biāo)(CPU\LOAD\RT)、業(yè)務(wù)關(guān)注指標(biāo)等，每項(xiàng)指標(biāo)應(yīng)明確具體監(jiān)控地址、采集方式。

7)域內(nèi)&關(guān)聯(lián)域人員通訊錄、值班

包含域內(nèi)技術(shù)、TL、業(yè)務(wù)方對(duì)應(yīng)排班情況、聯(lián)系方式(電話(huà))，相關(guān)上下游、基礎(chǔ)組件(DB、中間件等)對(duì)應(yīng)值班情況。

8)值班問(wèn)題記錄

作戰(zhàn)記錄，記錄工單、業(yè)務(wù)問(wèn)題、預(yù)案(前置\緊急)(至少包含：時(shí)間、問(wèn)題描述(截圖)、影響分析、決策&解決過(guò)程等)。值班同學(xué)在值班結(jié)束前，進(jìn)行記錄。

事后

1)系統(tǒng)恢復(fù)設(shè)置事項(xiàng)清單(限流、縮容)

一般與事前檢查事項(xiàng)清單對(duì)應(yīng)，包含限流閾值調(diào)整、集群縮容等大促后恢復(fù)操作。

2)大促問(wèn)題復(fù)盤(pán)記錄

應(yīng)包含大促遇到的核心事件總結(jié)梳理。

7、Incident Response - 沙盤(pán)推演

實(shí)戰(zhàn)沙盤(pán)演練是應(yīng)急響應(yīng)方面的最后一項(xiàng)保障工作，以歷史真實(shí)故障CASE作為應(yīng)急場(chǎng)景輸入，模擬大促期間緊急狀況，旨在考驗(yàn)值班同學(xué)們對(duì)應(yīng)急問(wèn)題處理的響應(yīng)情況。

一般來(lái)說(shuō)，一個(gè)線(xiàn)上問(wèn)題從發(fā)現(xiàn)到解決，中間需要經(jīng)歷定位&排查&診斷&修復(fù)等過(guò)程，總體遵循以下幾點(diǎn)原則：

• 盡最大可能讓系統(tǒng)先恢復(fù)服務(wù)，同時(shí)為根源調(diào)查保護(hù)現(xiàn)場(chǎng)(機(jī)器、日志、水位記錄)。
• 避免盲目搜索，依據(jù)白盒監(jiān)控針對(duì)性診斷定位。
• 有序分工，各司其職，避免一窩蜂失控亂象。
• 依據(jù)現(xiàn)場(chǎng)情況實(shí)時(shí)評(píng)估影響范圍，實(shí)在無(wú)法通過(guò)技術(shù)手段挽救的情況(例如強(qiáng)依賴(lài)不可用)，轉(zhuǎn)化為業(yè)務(wù)問(wèn)題思考(影響范圍、程度、是否有資損、如何協(xié)同業(yè)務(wù)方)。

沙盤(pán)演練旨在檢驗(yàn)值班同學(xué)故障處理能力，著重關(guān)注止血策略、分工安排、問(wèn)題定位等三個(gè)方面：

國(guó)際化中臺(tái)雙11買(mǎi)家域演練

根據(jù)故障類(lèi)型，常見(jiàn)止血策略有以下解決思路：

• 入口限流：調(diào)低對(duì)應(yīng)Provider服務(wù)來(lái)源限流值

應(yīng)對(duì)突發(fā)流量過(guò)高導(dǎo)致自身系統(tǒng)、下游強(qiáng)依賴(lài)負(fù)載被打滿(mǎn)。

• 下游降級(jí)：降級(jí)對(duì)應(yīng)下游服務(wù)

下游弱依賴(lài)不可用。

下游業(yè)務(wù)強(qiáng)依賴(lài)經(jīng)業(yè)務(wù)同意后降級(jí)(業(yè)務(wù)部分有損)。

• 單點(diǎn)失敗移除：摘除不可用節(jié)點(diǎn)

單機(jī)水位飆高時(shí)，先下線(xiàn)不可用單機(jī)服務(wù)(無(wú)需下線(xiàn)機(jī)器，保留現(xiàn)場(chǎng))。

應(yīng)對(duì)集群?jiǎn)吸c(diǎn)不可用、性能差。

• 切換：?jiǎn)卧辛骰蛘咔袚Q備份

應(yīng)對(duì)單庫(kù)或某單元依賴(lài)因?yàn)樽陨碓?宿主機(jī)或網(wǎng)絡(luò))，造成局部流量成功率下跌下跌。

Google SRE中，對(duì)于緊急事故管理有以下幾點(diǎn)要素：

• 嵌套式職責(zé)分離，即分確的職能分工安排
• 控制中心\作戰(zhàn)室
• 實(shí)時(shí)事故狀態(tài)文檔
• 明確公開(kāi)的職責(zé)交接

其中嵌套式職責(zé)分離，即分確的職能分工安排，達(dá)到各司其職，有序處理的效果，一般可分為下列幾個(gè)角色：

• 事故總控：負(fù)責(zé)協(xié)調(diào)分工以及未分配事務(wù)兜底工作，掌握全局概要信息，一般為PM/TL擔(dān)任。
• 事務(wù)處理團(tuán)隊(duì)：事故真正處理人員，可根據(jù)具體業(yè)務(wù)場(chǎng)景&系統(tǒng)特性分為多個(gè)小團(tuán)隊(duì)。團(tuán)隊(duì)內(nèi)部存在域內(nèi)負(fù)責(zé)人，與事故總控人員進(jìn)行溝通。
• 發(fā)言人：事故對(duì)外聯(lián)絡(luò)人員，負(fù)責(zé)對(duì)事故處理內(nèi)部成員以及外部關(guān)注人員信息做周期性信息同步，同時(shí)需要實(shí)時(shí)維護(hù)更新事故文檔。
• 規(guī)劃負(fù)責(zé)人：負(fù)責(zé)外部持續(xù)性支持工作，比如當(dāng)大型故障出現(xiàn)，多輪排班輪轉(zhuǎn)時(shí)，負(fù)責(zé)組織職責(zé)交接記錄。

相關(guān)閱讀

[1]https://landing.google.com/sre/books/

https://sre.google/sre-book/table-of-contents/

https://sre.google/workbook/table-of-contents/