小程序穩(wěn)定性保障方案:高可用系統(tǒng)大促作戰(zhàn)指南
一 前言
年年有大促，大家對于大促穩(wěn)定性保障這個詞都不陌生，業(yè)務(wù)場景盡管各不相同，“套路”往往殊路同歸，全鏈路壓測、容量評估、限流、緊急預(yù)案等，來來去去總少不了那么幾板斧。
跳出這些“套路”，回到問題的本質(zhì)，我們?yōu)槭裁匆凑者@些策略來做？
除了口口相傳的歷史經(jīng)驗，我們還能做些什么？又有什么理論依據(jù)？
二 怎樣的系統(tǒng)算是穩(wěn)定？
首先回答另一個問題，怎樣的系統(tǒng)算是穩(wěn)定的？
Google SRE中(SRE三部曲[1])有一個層級模型來描述系統(tǒng)可靠性基礎(chǔ)和高層次需求(Dickerson's Hierarchy of Service Reliability)，該模型由Google SRE工程師Mikey Dickerson在2013年提出，將系統(tǒng)穩(wěn)定性需求按照基礎(chǔ)程度進行了不同層次的體系化區(qū)分，形成穩(wěn)定性標準金字塔模型。
金字塔的底座是監(jiān)控(Monitoring)，這是一個系統(tǒng)對于穩(wěn)定性最基礎(chǔ)的要求，缺少監(jiān)控的系統(tǒng)，如同蒙上眼睛狂奔的野馬，無從談及可控性，更遑論穩(wěn)定性。更上層是應(yīng)急響應(yīng)(Incident Response)，從一個問題被監(jiān)控發(fā)現(xiàn)到最終解決，這期間的耗時直接取決于應(yīng)急響應(yīng)機制的成熟度。合理的應(yīng)急策略能保證當故障發(fā)生時，所有問題能得到有序且妥善的處理，而不是慌亂成一鍋粥。事后總結(jié)以及根因分析(Postmortem&Root Caue Analysis)，即我們平時談到的“復(fù)盤”，雖然很多人都不太喜歡這項活動，但是不得不承認這是避免我們下次犯同樣錯誤的最有效手段，只有當摸清故障的根因以及對應(yīng)的缺陷，我們才能對癥下藥，合理進行規(guī)避。
假設(shè)一個系統(tǒng)從初次發(fā)布后就不再進行更新迭代，做好上述三個方面的工作就能基本滿足系統(tǒng)對于穩(wěn)定性的全部需求。可惜目前基本不會存在這樣的系統(tǒng)，大大小小的應(yīng)用都離不開不斷的變更與發(fā)布，因此要保證系統(tǒng)在這些迭代中持續(xù)穩(wěn)定，測試和發(fā)布管控(Testing&Release procedures)是必不可少的。有效的測試與發(fā)布策略能保障系統(tǒng)所有新增變量都處于可控穩(wěn)定區(qū)間內(nèi)，從而達到整體服務(wù)終態(tài)穩(wěn)定。除了代碼邏輯更新，迭代同樣可能帶來業(yè)務(wù)規(guī)模及流量的變化，容量規(guī)劃(Capacity Planning)則是針對于這方面變化進行的保障策略。現(xiàn)有系統(tǒng)體量是否足夠支撐新的流量需求，整體鏈路上是否存在不對等的薄弱節(jié)點，都是容量規(guī)劃需要考慮的問題。
位于金字塔模型最頂端的是產(chǎn)品設(shè)計(Product)與軟件研發(fā)(Development)，即通過優(yōu)秀的產(chǎn)品設(shè)計與軟件設(shè)計使系統(tǒng)具備更高的可靠性，構(gòu)建高可用產(chǎn)品架構(gòu)體系，從而提升用戶體驗。
三 大促穩(wěn)定性保障方法
從金字塔模型我們可以看到構(gòu)建維護一個高可用服務(wù)所需要做到的幾方面工作，那么問題回到大促穩(wěn)定性，如何體系化地保障大促期間系統(tǒng)穩(wěn)定性？
大促保障實際上針對于特定業(yè)務(wù)場景的集中穩(wěn)定性建設(shè)工作，相較于日常保障工作，具有高并發(fā)流量、短保障周期的特點，對系統(tǒng)性能與保障時間有明確要求（一般為2個月左右）。
考慮到上述特性，我們?nèi)绾卧诙虝r間內(nèi)針對大促大流量業(yè)務(wù)場景對系統(tǒng)穩(wěn)定性需求進行優(yōu)化鞏固？
既然時間有限，盲目撒網(wǎng)必然不是最佳策略，需要有針對性地從關(guān)鍵點、薄弱點下手。因此第一步，需要獲得全局系統(tǒng)鏈路現(xiàn)狀，包括關(guān)鍵外部依賴、重點業(yè)務(wù)影響等，找到整體保障的核心關(guān)注點。接下來進一步分析大促業(yè)務(wù)數(shù)據(jù)，得到除系統(tǒng)本身以外的變量干擾因素。以這兩者為基礎(chǔ)，集中圍繞金字塔模型中系統(tǒng)監(jiān)控、規(guī)劃容量、應(yīng)急響應(yīng)、測試和復(fù)盤等幾個方面需求對系統(tǒng)進行針對性集中保障建設(shè)，得到最終保障結(jié)果。
至此，基本獲得了完整的大促穩(wěn)定性保障策略方向，按照執(zhí)行順序依次是：
系統(tǒng)鏈路&業(yè)務(wù)策略梳理（System & Biz Profiling）
監(jiān)控（Monitoring）
容量規(guī)劃（Capacity Planning）
應(yīng)急響應(yīng)（Incident Response）
測試
事后總結(jié)（Testing & Postmortem）
系統(tǒng)鏈路梳理是所有保障工作的基礎(chǔ)，如同對整體應(yīng)用系統(tǒng)進行一次全面體檢，從流量入口開始，按照鏈路軌跡，逐級分層節(jié)點，得到系統(tǒng)全局畫像與核心保障點。
入口梳理盤點
一個系統(tǒng)往往存在十幾個甚至更多流量入口，包含HTTP、RPC、消息等都多種來源。如果無法覆蓋所有所有鏈路，可以從以下三類入口開始進行梳理：
核心重保流量入口
用戶承諾服務(wù)SLI較高，對數(shù)據(jù)準確性、服務(wù)響應(yīng)時間、可靠度具有明確要求。
面向企業(yè)級用戶
資損事件對應(yīng)入口
關(guān)聯(lián)到公司資金收入或者客戶資金收入
收費服務(wù)
大流量入口
系統(tǒng)TPS&QPS TOP5~10
該類入口雖然不涉及較高SLI與資損要求，但是流量較高，對整體系統(tǒng)負載有較大影響。
節(jié)點分層判斷
流量入口就如同線團中的線頭，挑出線頭后就可按照流量軌跡對鏈路上的節(jié)點(HSF\DB\Tair\HBase等一切外部依賴)按照依賴程度、可用性、可靠性進行初級分層區(qū)分。
（1）強弱依賴節(jié)點判斷
若節(jié)點不可用，鏈路業(yè)務(wù)邏輯被中斷 or 高級別有損(存在一定耐受閾值)，則為業(yè)務(wù)強依賴；反之為弱依賴。
若節(jié)點不可用，鏈路執(zhí)行邏輯被中斷(return error)，則為系統(tǒng)強依賴；反之為弱依賴。
若節(jié)點不可用，系統(tǒng)性能受影響，則為系統(tǒng)強依賴；反之為弱依賴。
按照快速失敗設(shè)計邏輯，該類節(jié)點不應(yīng)存在，但是在不變更應(yīng)用代碼前提下，如果出現(xiàn)該類節(jié)點，應(yīng)作為強依賴看待。
若節(jié)點無感可降級 or 存在業(yè)務(wù)輕微損傷替換方案，則為弱依賴。
（2）低可用依賴節(jié)點判斷
節(jié)點服務(wù)日常超時嚴重
節(jié)點對應(yīng)系統(tǒng)資源不足
（3）高風(fēng)險節(jié)點判斷
上次大促后，節(jié)點存在大版本系統(tǒng)改造
新上線未經(jīng)歷過大促的節(jié)點
節(jié)點對應(yīng)系統(tǒng)是否曾經(jīng)出現(xiàn)高級別故障
節(jié)點故障后存在資損風(fēng)險
應(yīng)產(chǎn)出數(shù)據(jù)
完成該項梳理工作后，我們應(yīng)該產(chǎn)出以下數(shù)據(jù)：對應(yīng)業(yè)務(wù)域所有核心鏈路分析，技術(shù)&業(yè)務(wù)強依賴、核心上游、下游系統(tǒng)、資損風(fēng)險應(yīng)明確標注。
2 System & Biz Profiling - 業(yè)務(wù)策略同步
不同于高可用系統(tǒng)建設(shè)體系，大促穩(wěn)定性保障體系與面向特定業(yè)務(wù)活動的針對性保障建設(shè)，因此，業(yè)務(wù)策略與數(shù)據(jù)是我們進行保障前不可或缺的數(shù)據(jù)。
一般大促業(yè)務(wù)數(shù)據(jù)可分為兩類，全局業(yè)務(wù)形態(tài)評估以及應(yīng)急策略&玩法。
全局評估
該類數(shù)據(jù)從可以幫助我們進行精準流量評估、峰值預(yù)測、大促人力排班等等，一般包含下面幾類：
大促業(yè)務(wù)時長（XX日-XX日）
業(yè)務(wù)量預(yù)估體量（日常X倍）
預(yù)估峰值日期
業(yè)務(wù)場景預(yù)估流量分配
應(yīng)急策略
該類數(shù)據(jù)指相較于往年大促活動，本次大促業(yè)務(wù)變量，可用于應(yīng)急響應(yīng)預(yù)案與高風(fēng)險節(jié)點評估等，一般包含下面兩類：
特殊業(yè)務(wù)玩法
應(yīng)急情況打法策略
3 Monitoring - 監(jiān)控&告警梳理
目前業(yè)界常用的監(jiān)控手段一般有兩種模式，黑盒監(jiān)控(Black-box monitoring)與白盒監(jiān)控(White-box monitoring)。黑盒監(jiān)控面向?qū)ο螅话惚O(jiān)控正在發(fā)生（而非即將發(fā)生）的異常，即系統(tǒng)現(xiàn)有故障。而白盒監(jiān)控主要依賴系統(tǒng)內(nèi)部指標監(jiān)控，面向?qū)ο蟮耐瑫r也面向原因，可對系統(tǒng)即將面臨的異常進行提前預(yù)警，也可在異常發(fā)生時同步監(jiān)控下層內(nèi)部指標，從而定位根本原因。因此大促穩(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)用進程與中間件運行狀態(tài)；業(yè)務(wù)層為最上層，為業(yè)務(wù)視角下服務(wù)對外運行狀態(tài)。
因此進行大促穩(wěn)定性監(jiān)控梳理時，可以先脫離現(xiàn)有監(jiān)控，先從核心、資損鏈路開始，按照業(yè)務(wù)、應(yīng)用（中間件、JVM、DB）、系統(tǒng)三個層次梳理需要哪些監(jiān)控，再從根據(jù)這些索引找到對應(yīng)的監(jiān)控告警，如果不存在，則相應(yīng)補上；如果存在則檢查閾值、時間、告警人是否合理。
監(jiān)控
監(jiān)控系統(tǒng)一般有四項黃金指標：延時（Latency）, 錯誤（Error）,流量（Traffic）, 飽和度（Situation），各層的關(guān)鍵性監(jiān)控同樣也可以按照這四項指標來進行歸類，具體如下：
告警
是不是每項監(jiān)控都需要告警？答案當然是否定的。建議優(yōu)先設(shè)置Biz層告警，因為Biz層我們對外服務(wù)最直觀業(yè)務(wù)表現(xiàn)，最貼切用戶感受。Application&System層指標主要用于監(jiān)控，部分關(guān)鍵&高風(fēng)險指標可設(shè)置告警，用于問題排查定位以及故障提前發(fā)現(xiàn)。
對于一項告警，我們一般需要關(guān)注級別、閾值、通知人等幾個點。
1）級別
即當前告警被觸發(fā)時，問題的嚴重程度，一般來說有幾個衡量點：
是否關(guān)聯(lián)GOC
是否產(chǎn)生嚴重業(yè)務(wù)影響
是否產(chǎn)生資損
2）閾值
即一項告警的觸發(fā)條件&時間，需根據(jù)具體場景合理制定。一般遵循以下原則：
不可過于遲鈍。一個合理的監(jiān)控體系中，任何異常發(fā)生后都應(yīng)觸發(fā)相關(guān)告警。
不可過于敏感。過于敏感的閾值會造成頻繁告警，從而導(dǎo)致響應(yīng)人員疲勞應(yīng)對，無法篩選真實異常。若一個告警頻繁出現(xiàn)，一般是兩個原因：系統(tǒng)設(shè)計不合理 or 閾值設(shè)置不合理。
若單一指標無法反饋覆蓋整體業(yè)務(wù)場景，可結(jié)合多項指標關(guān)聯(lián)構(gòu)建。
需符合業(yè)務(wù)波動曲線，不同時段可設(shè)置不同條件&通知策略。
3）通知人&方式
若為業(yè)務(wù)指標異常(Biz層告警)，通知人應(yīng)為問題處理人員(開發(fā)、運維同學(xué))與業(yè)務(wù)關(guān)注人員(TL、業(yè)務(wù)同學(xué))的集合，通知方式較為實時，比如電話通知。
若為應(yīng)用 & 系統(tǒng)層告警，主要用于定位異常原因，通知人設(shè)置問題排查處理人員即可，通知方式可考慮釘釘、短信等低干擾方式。
除了關(guān)聯(lián)層次，對于不同級別的告警，通知人范圍也可適當擴大，尤其是關(guān)聯(lián)GOC故障的告警指標，應(yīng)適當放寬范圍，通知方式也應(yīng)更為實時直接。
應(yīng)產(chǎn)出數(shù)據(jù)
完成該項梳理工作后，我們應(yīng)該產(chǎn)出以下數(shù)據(jù)：
系統(tǒng)監(jiān)控模型，格式同表1
Biz、Application、System 分別存在哪些待監(jiān)控點
監(jiān)控點是否已全部存在指標，仍有哪些待補充
系統(tǒng)告警模型列表，需包含以下數(shù)據(jù)
關(guān)聯(lián)監(jiān)控指標（鏈接）
告警關(guān)鍵級別
是否推送GOC
是否產(chǎn)生資損
是否關(guān)聯(lián)故障
是否關(guān)聯(lián)預(yù)案
業(yè)務(wù)指標大盤，包含Biz層重點監(jiān)控指標數(shù)據(jù)。
系統(tǒng)&應(yīng)用指標大盤，包含核心系統(tǒng)關(guān)鍵系統(tǒng)指標，可用于白盒監(jiān)控定位問題。
4 Capacity Planning - 容量規(guī)劃
容量規(guī)劃的本質(zhì)是追求計算風(fēng)險最小化和計算成本最小化之間的平衡，只追求任意其一都不是合理的。為了達到這兩者的最佳平衡點，需盡量精準計算系統(tǒng)峰值負載流量，再將流量根據(jù)單點資源負載上限換算成相應(yīng)容量，得到最終容量規(guī)劃模型。
流量模型評估
1）入口流量
對于一次大促，系統(tǒng)峰值入口流量一般由常規(guī)業(yè)務(wù)流量與非常規(guī)增量（比如容災(zāi)預(yù)案&業(yè)務(wù)營銷策略變化帶來的流量模型配比變化）疊加擬合而成。
（a）常規(guī)業(yè)務(wù)流量一般有兩類計算方式：
歷史流量算法：該類算法假設(shè)當年大促增幅完全符合歷史流量模型，根據(jù)當前&歷年日常流量，計算整體業(yè)務(wù)體量同比增量模型；然后根據(jù)歷年大促-日常對比，計算預(yù)估流量環(huán)比增量模型；最后二者擬合得到最終評估數(shù)據(jù)。
由于計算時無需依賴任何業(yè)務(wù)信息輸入，該類算法可用于保障工作初期業(yè)務(wù)尚未給出業(yè)務(wù)總量評估時使用，得到初估業(yè)務(wù)流量。
業(yè)務(wù)量-流量轉(zhuǎn)化算法(GMV\DAU\訂單量)：該類算法一般以業(yè)務(wù)預(yù)估總量（GMV\DAU\訂單量）為輸入，根據(jù)歷史大促&日常業(yè)務(wù)量-流量轉(zhuǎn)化模型（比如經(jīng)典漏洞模型）換算得到對應(yīng)子域業(yè)務(wù)體量評估。
該種方式強依賴業(yè)務(wù)總量預(yù)估，可在保障工作中后期使用，在初估業(yè)務(wù)流量基礎(chǔ)上納入業(yè)務(wù)評估因素考慮。
（b）非常規(guī)增量一般指前臺業(yè)務(wù)營銷策略變更或系統(tǒng)應(yīng)急預(yù)案執(zhí)行后流量模型變化造成的增量流量。例如，NA61機房故障時，流量100%切換到NA62后，帶來的增量變化。
考慮到成本最小化，非常規(guī)增量P計算時一般無需與常規(guī)業(yè)務(wù)流量W一起，全量納入疊加入口流量K，一般會將非常規(guī)策略發(fā)生概率λ作為權(quán)重，即：
2）節(jié)點流量
節(jié)點流量由入口流量根據(jù)流量分支模型，按比例轉(zhuǎn)化而來。分支流量模型以系統(tǒng)鏈路為計算基礎(chǔ)，遵循以下原則：
同一入口，不同鏈路占比流量獨立計算。
針對同一鏈路上同一節(jié)點，若存在多次調(diào)用，需計算按倍數(shù)同比放大（比如DB\Tair等）。
DB寫流量重點關(guān)注，可能出現(xiàn)熱點造成DB HANG死。
容量轉(zhuǎn)化
1）Little Law衍生法則
不同類型資源節(jié)點(應(yīng)用容器、Tair、DB、HBASE等)流量-容量轉(zhuǎn)化比各不相同，但都服從Little Law衍生法則，即：
2）N + X 冗余原則
在滿足目標流量所需要的最小容量基礎(chǔ)上，冗余保留X單位冗余能力
X與目標成本與資源節(jié)點故障概率成正相關(guān)，不可用概率越高，X越高
對于一般應(yīng)用容器集群，可考慮X = 0.2N
上述法則只能用于容量初估(大促壓測前&新依賴)，最終精準系統(tǒng)容量還是需要結(jié)合系統(tǒng)周期性壓力測試得出。
應(yīng)產(chǎn)出數(shù)據(jù)
基于模型評估的入口流量模型 & 集群自身容量轉(zhuǎn)化結(jié)果（若為非入口應(yīng)用，則為限流點梳理）。
基于鏈路梳理的分支流量模型 & 外部依賴容量轉(zhuǎn)化結(jié)果。
5 Incident Response - 緊急&前置預(yù)案梳理
要想在大促高并發(fā)流量場景下快速對線上緊急事故進行響應(yīng)處理，僅僅依賴值班同學(xué)臨場發(fā)揮是遠遠不夠的。爭分奪秒的情況下，無法給處理人員留有充足的策略思考空間，而錯誤的處理決策，往往會導(dǎo)致更為失控嚴重的業(yè)務(wù)&系統(tǒng)影響。因此，要想在大促現(xiàn)場快速而正確的響應(yīng)問題，值班同學(xué)需要做的是選擇題(Which)，而不是陳述題(What)。而選項的構(gòu)成，便是我們的業(yè)務(wù)&系統(tǒng)預(yù)案。
從執(zhí)行時機與解決問題屬性來劃分，預(yù)案可分為技術(shù)應(yīng)急預(yù)案、技術(shù)前置預(yù)案、業(yè)務(wù)應(yīng)急預(yù)案、業(yè)務(wù)前置預(yù)案等四大類。結(jié)合之前的鏈路梳理和業(yè)務(wù)評估結(jié)果，我們可以快速分析出鏈路中需要的預(yù)案，遵循以下原則：
技術(shù)應(yīng)急預(yù)案：該類預(yù)案用于處理系統(tǒng)鏈路中，某層次節(jié)點不可用的情況，例如技術(shù)/業(yè)務(wù)強依賴、弱穩(wěn)定性、高風(fēng)險等節(jié)點不可用等異常場景。
技術(shù)前置預(yù)案：該類預(yù)案用于平衡整體系統(tǒng)風(fēng)險與單節(jié)點服務(wù)可用性，通過熔斷等策略保障全局服務(wù)可靠。例如弱穩(wěn)定性&弱依賴服務(wù)提前降級、與峰值流量時間沖突的離線任務(wù)提前暫定等。
業(yè)務(wù)應(yīng)急預(yù)案：該類預(yù)案用于應(yīng)對業(yè)務(wù)變更等非系統(tǒng)性異常帶來的需應(yīng)急處理問題，例如業(yè)務(wù)數(shù)據(jù)錯誤（數(shù)據(jù)正確性敏感節(jié)點）、務(wù)策略調(diào)整（配合業(yè)務(wù)應(yīng)急策略）等
業(yè)務(wù)前置預(yù)案：該類預(yù)案用于配和業(yè)務(wù)全局策略進行的前置服務(wù)調(diào)整（非系統(tǒng)性需求）
應(yīng)產(chǎn)出數(shù)據(jù)
完成該項梳理工作后，我們應(yīng)該產(chǎn)出以下數(shù)據(jù)：
執(zhí)行&關(guān)閉時間（前置預(yù)案）
觸發(fā)閾值（緊急預(yù)案，須關(guān)聯(lián)相關(guān)告警）
關(guān)聯(lián)影響（系統(tǒng)&業(yè)務(wù)）
決策&執(zhí)行&驗證人員
開啟驗證方式
關(guān)閉閾值（緊急預(yù)案）
關(guān)閉驗證方式
階段性產(chǎn)出-全鏈路作戰(zhàn)地圖
進行完上述幾項保障工作，我們基本可得到全局鏈路作戰(zhàn)地圖，包含鏈路分支流量模型、強弱依賴節(jié)點、資損評估、對應(yīng)預(yù)案&處理策略等信息。大促期間可憑借該地圖快速從全局視角查看應(yīng)急事件相關(guān)影響，同時也可根據(jù)地圖反向評估預(yù)案、容量等梳理是否完善合理。
6 Incident Response - 作戰(zhàn)手冊梳理
作戰(zhàn)手冊是整個大促保障的行動依據(jù)，貫穿于整個大促生命周期，可從事前、事中、事后三個階段展開考慮。
整體梳理應(yīng)本著精準化、精細化的原則，理想狀態(tài)下，即便是對業(yè)務(wù)、系統(tǒng)不熟悉的輪班同學(xué)，憑借手冊也能快速響應(yīng)處理線上問題。
事前
1）前置檢查事項清單
大促前必須執(zhí)行事項checklist,通常包含以下事項：
集群機器重啟 or 手動FGC
影子表數(shù)據(jù)清理
檢查上下游機器權(quán)限
檢查限流值
檢查機器開關(guān)一致性
檢查數(shù)據(jù)庫配置
檢查中間件容量、配置(DB\緩存\NoSQL等)
檢查監(jiān)控有效性（業(yè)務(wù)大盤、技術(shù)大盤、核心告警）
每個事項都需包含具體執(zhí)行人、檢查方案、檢查結(jié)果三列數(shù)據(jù)
2）前置預(yù)案
域內(nèi)所有業(yè)務(wù)&技術(shù)前置預(yù)案。
事中
1）緊急技術(shù)&業(yè)務(wù)預(yù)案
需要包含的內(nèi)容基本同前置預(yù)案，差異點如下：
執(zhí)行條件&恢復(fù)條件：具體觸發(fā)閾值，對應(yīng)監(jiān)控告警項。
通知決策人。
2）應(yīng)急工具&腳本
常見故障排查方式、核心告警止血方式(強弱依賴不可用等)，業(yè)務(wù)相關(guān)日志撈取腳本等。
3）告警&大盤
應(yīng)包含業(yè)務(wù)、系統(tǒng)集群及中間件告警監(jiān)控梳理結(jié)果，核心業(yè)務(wù)以及系統(tǒng)大盤，對應(yīng)日志數(shù)據(jù)源明細等數(shù)據(jù)：
日志數(shù)據(jù)源明細：數(shù)據(jù)源名稱、文件位置、樣例、切分格式。
業(yè)務(wù)、系統(tǒng)集群及中間件告警監(jiān)控梳理結(jié)果：關(guān)聯(lián)監(jiān)控指標（鏈接）、告警關(guān)鍵級別、是否推送GOC、是否產(chǎn)生資損、是否關(guān)聯(lián)故障、是否關(guān)聯(lián)預(yù)案。
核心業(yè)務(wù)&系統(tǒng)大盤：大盤地址、包含指標明細(含義、是否關(guān)聯(lián)告警、對應(yīng)日志)。
4）上下游機器分組
應(yīng)包含核心系統(tǒng)、上下游系統(tǒng)，在不同機房、單元集群分組、應(yīng)用名，可用于事前-機器權(quán)限檢查、事中-應(yīng)急問題排查黑屏處理。
5）值班注意事項
包含每班輪班同學(xué)值班必做事項、應(yīng)急變更流程、核心大盤鏈接等。
6）核心播報指標
包含核心系統(tǒng)&服務(wù)指標(CPU\LOAD\RT)、業(yè)務(wù)關(guān)注指標等，每項指標應(yīng)明確具體監(jiān)控地址、采集方式。
7）域內(nèi)&關(guān)聯(lián)域人員通訊錄、值班
包含域內(nèi)技術(shù)、TL、業(yè)務(wù)方對應(yīng)排班情況、聯(lián)系方式(電話)，相關(guān)上下游、基礎(chǔ)組件(DB、中間件等)對應(yīng)值班情況。
8）值班問題記錄
作戰(zhàn)記錄，記錄工單、業(yè)務(wù)問題、預(yù)案(前置\緊急)（至少包含：時間、問題描述（截圖）、影響分析、決策&解決過程等）。值班同學(xué)在值班結(jié)束前，進行記錄。
事后
1）系統(tǒng)恢復(fù)設(shè)置事項清單(限流、縮容)
一般與事前檢查事項清單對應(yīng)，包含限流閾值調(diào)整、集群縮容等大促后恢復(fù)操作。
2）大促問題復(fù)盤記錄
應(yīng)包含大促遇到的核心事件總結(jié)梳理。
7 Incident Response - 沙盤推演
實戰(zhàn)沙盤演練是應(yīng)急響應(yīng)方面的最后一項保障工作，以歷史真實故障CASE作為應(yīng)急場景輸入，模擬大促期間緊急狀況，旨在考驗值班同學(xué)們對應(yīng)急問題處理的響應(yīng)情況。
一般來說，一個線上問題從發(fā)現(xiàn)到解決，中間需要經(jīng)歷定位&排查&診斷&修復(fù)等過程，總體遵循以下幾點原則：
盡最大可能讓系統(tǒng)先恢復(fù)服務(wù)，同時為根源調(diào)查保護現(xiàn)場（機器、日志、水位記錄）。
避免盲目搜索，依據(jù)白盒監(jiān)控針對性診斷定位。
有序分工，各司其職，避免一窩蜂失控亂象。
依據(jù)現(xiàn)場情況實時評估影響范圍，實在無法通過技術(shù)手段挽救的情況(例如強依賴不可用)，轉(zhuǎn)化為業(yè)務(wù)問題思考（影響范圍、程度、是否有資損、如何協(xié)同業(yè)務(wù)方）。
沙盤演練旨在檢驗值班同學(xué)故障處理能力，著重關(guān)注止血策略、分工安排、問題定位等三個方面：
根據(jù)故障類型，常見止血策略有以下解決思路：
入口限流：調(diào)低對應(yīng)Provider服務(wù)來源限流值
應(yīng)對突發(fā)流量過高導(dǎo)致自身系統(tǒng)、下游強依賴負載被打滿。
下游降級：降級對應(yīng)下游服務(wù)
下游弱依賴不可用。
下游業(yè)務(wù)強依賴經(jīng)業(yè)務(wù)同意后降級（業(yè)務(wù)部分有損）。
單點失敗移除：摘除不可用節(jié)點
單機水位飆高時，先下線不可用單機服務(wù)（無需下線機器，保留現(xiàn)場）。
應(yīng)對集群單點不可用、性能差。
切換：單元切流或者切換備份
應(yīng)對單庫或某單元依賴因為自身原因（宿主機或網(wǎng)絡(luò)），造成局部流量成功率下跌下跌。
Google SRE中，對于緊急事故管理有以下幾點要素：
嵌套式職責(zé)分離，即分確的職能分工安排
控制中心\作戰(zhàn)室
實時事故狀態(tài)文檔
明確公開的職責(zé)交接
其中嵌套式職責(zé)分離，即分確的職能分工安排，達到各司其職，有序處理的效果，一般可分為下列幾個角色：
事故總控：負責(zé)協(xié)調(diào)分工以及未分配事務(wù)兜底工作，掌握全局概要信息，一般為PM/TL擔(dān)任。
事務(wù)處理團隊：事故真正處理人員，可根據(jù)具體業(yè)務(wù)場景&系統(tǒng)特性分為多個小團隊。團隊內(nèi)部存在域內(nèi)負責(zé)人，與事故總控人員進行溝通。
發(fā)言人：事故對外聯(lián)絡(luò)人員，負責(zé)對事故處理內(nèi)部成員以及外部關(guān)注人員信息做周期性信息同步，同時需要實時維護更新事故文檔。
規(guī)劃負責(zé)人：負責(zé)外部持續(xù)性支持工作，比如當大型故障出現(xiàn)，多輪排班輪轉(zhuǎn)時，負責(zé)組織職責(zé)交接記錄。
穩(wěn)定
產(chǎn)品高可用性高并發(fā)貼心
項目群及時溝通專業(yè)
產(chǎn)品經(jīng)理1v1支持快速
MVP模式小步快跑承諾
我們選擇聲譽堅持
10年專注高端品質(zhì)開發(fā)