DevOps-SRE網(wǎng)站可靠性保障圖
近段時(shí)間西安由于疫情嚴(yán)重導(dǎo)致西安一碼通連續(xù)幾次崩潰，導(dǎo)致一些工程師無法掃碼而進(jìn)不到小區(qū)內(nèi)維修設(shè)備，大量市民無法乘坐地鐵和出租車，進(jìn)不了公司和商廈，甚至有家都不能回。
造成一碼通崩潰的主要原因還是由于西安疫情暴增導(dǎo)致大量市民日常出行需要訪問和使用一碼通，一碼通后臺(tái)服務(wù)器扛不住突然暴增的流量而導(dǎo)致服務(wù)器宕機(jī)，同時(shí)沒有一套完善的服務(wù)器擴(kuò)容機(jī)制，導(dǎo)致恢復(fù)后沒多久又崩潰了，最后連西安大數(shù)據(jù)局局長都被停職！
今天我們從網(wǎng)站的可靠性保障工程的角度來聊聊“西安一碼通”應(yīng)該如何來保障系統(tǒng)的穩(wěn)定性。
SRE是什么？
談到網(wǎng)站的可靠性保障就離不開一個(gè)詞SRE，它的全稱是Site Reliability Engineer (網(wǎng)站可靠性工程師)。
SRE不單單是一個(gè)崗位，而是一個(gè)體系化的工程。我們需要學(xué)習(xí)各項(xiàng)技術(shù)，諸如：容量評估、故障演練、服務(wù)降級(jí)、服務(wù)限流、異常熔斷、監(jiān)控告警等等，然后將這些技術(shù)有機(jī)地結(jié)合起來，形成一套穩(wěn)定的體系。同時(shí)需要與開發(fā)團(tuán)隊(duì)、運(yùn)維團(tuán)隊(duì)、測試團(tuán)隊(duì)、效能團(tuán)隊(duì)等等，進(jìn)行高效的跨團(tuán)隊(duì)組織協(xié)作，并最終提高系統(tǒng)的穩(wěn)定性。
SRE的概念最早是Google提出來的，他們出了一本書《Site Reliability Engineering》?，描述了這個(gè)套體系化工程是如何高效協(xié)同工作的。
系統(tǒng)穩(wěn)定性衡量指標(biāo)
我們要提高系統(tǒng)的穩(wěn)定性，就要制定衡量系統(tǒng)穩(wěn)定性的相關(guān)指標(biāo)，系統(tǒng)的穩(wěn)定性指標(biāo)主要有以下兩個(gè)：
MTBF，Mean Time Between Failure，平均故障時(shí)間間隔
MTTR，Mean Time To Repair， 故障平均修復(fù)時(shí)間
MTTR又可以分為四個(gè)小指標(biāo)，分別是：
MTTI：發(fā)現(xiàn)問題的時(shí)間
MTTK：找到問題原因的時(shí)間
MTTF：解決問題的時(shí)間
MTTV：驗(yàn)證問題是否已解決的時(shí)間
我們要想提升穩(wěn)定性，就會(huì)有兩個(gè)方向：
提升 MTBF，也就是減少故障發(fā)生次數(shù)，提升故障發(fā)生間隔時(shí)長；
降低 MTTR，故障不可避免，那就提升故障處理效率，減少故障影響時(shí)長
SRE的目的是什么？
減少故障，提升 MTBF；同時(shí)，提升故障處理效率，降低 MTTR。
SRE穩(wěn)定性保障規(guī)劃
從上圖可以看到針對于網(wǎng)站的可靠性保障我們可以做到的幾個(gè)方面：故障預(yù)防、故障發(fā)現(xiàn)、故障定位、故障恢復(fù)、故障改進(jìn)；其目的是提升MTBF，降低MTTR。
如何衡量系統(tǒng)的可用性？
衡量系統(tǒng)可用性的 2 種方式
時(shí)間維度：Availability = Uptime / (Uptime + Downtime)
請求維度：Availability = Successful request / Total request
測量和判斷方法
時(shí)間維度
衡量指標(biāo)：比如狀態(tài)碼
衡量目標(biāo)：達(dá)到什么目標(biāo)是正常，達(dá)不到就是異常
影響時(shí)長：比如持續(xù)超過 12 小時(shí)
請求維度
衡量指標(biāo)：請求成功率
衡量目標(biāo)：成功率達(dá)到 95% 才算系統(tǒng)運(yùn)行正常
統(tǒng)計(jì)周期：比如一天、一周、一個(gè)月等等
上圖為系統(tǒng)穩(wěn)定性的幾個(gè)9以及對應(yīng)的描述。
對于系統(tǒng)穩(wěn)定性到底定“幾個(gè)9”？應(yīng)從三方面考慮
成本因素
業(yè)務(wù)容忍度
系統(tǒng)當(dāng)前的穩(wěn)定性狀況
SRE切入點(diǎn)
在一個(gè)系統(tǒng)中，我們該如何切入SRE可靠性保障工程呢？
先了解兩個(gè)概念：
SLI，Service Level Indicator：服務(wù)等級(jí)指標(biāo)
SLO，Service Level Objective：服務(wù)等級(jí)目標(biāo)
SLI就用來判斷系統(tǒng)穩(wěn)定性的指標(biāo)，比如接口請求狀態(tài)碼是非500的比例
SLO就SLI要達(dá)成的目標(biāo)，比如接口請求狀態(tài)碼是非500的比例要達(dá)到99.95%
SRE應(yīng)該如何選擇SLI？
兩個(gè)原則
原則一：選擇能夠標(biāo)識(shí)一個(gè)主體是否穩(wěn)定的指標(biāo)，如果不是這個(gè)主體本身的指標(biāo)，或者不能標(biāo)識(shí)主體穩(wěn)定性的，就要排除在外。
原則二：針對電商這類有用戶界面的業(yè)務(wù)系統(tǒng)，優(yōu)先選擇與用戶體驗(yàn)強(qiáng)相關(guān)或用戶可以明顯感知的指標(biāo)。
VALET方法
Google推薦使用的方法。
Volume- 容量
????服務(wù)承諾的最大容量是多少
Availablity- 可用性
????代表服務(wù)是否正常
Latency- 時(shí)延
????錯(cuò)誤率有多少？
Errors- 錯(cuò)誤率
????錯(cuò)誤率有多少？
Tickets- 人工介入
????是否需要人工介入？
如何通過 SLO 計(jì)算可用性？
非常簡單，比如我們選擇了三個(gè)SLO：
SLO1：99.95% 狀態(tài)碼成功率
SLO2：90% Latency <= 80ms
SLO3：99% Latency <= 200ms
那么可用性就是：
Availability（可用性） = SLO1 & SLO2 & SLO3
錯(cuò)誤預(yù)算（Error Budget）
什么是錯(cuò)誤預(yù)算呢？其實(shí)就是可以犯錯(cuò)誤的次數(shù)。我們要落地SLO，應(yīng)該先將其轉(zhuǎn)換為Error Budget。
如何計(jì)算錯(cuò)誤預(yù)算？
假設(shè)在 4 周的時(shí)間，這個(gè)應(yīng)用所有的請求次數(shù)是 4,653,680，按照給出的 SLO 反向推導(dǎo)，就可以得到容許的錯(cuò)誤次數(shù)，這就是錯(cuò)誤預(yù)算。
例如：99.95%Availability，則錯(cuò)誤預(yù)算就等于4,653,680 * 0.05%=23268
在SRE實(shí)踐中如何應(yīng)用錯(cuò)誤預(yù)算？
穩(wěn)定性燃盡圖
制定好錯(cuò)誤預(yù)算后SRE需要嚴(yán)格遵守它，所以我們需要把錯(cuò)誤預(yù)算盡可能直觀地表現(xiàn)出來，隨時(shí)可以看到它的消耗情況。當(dāng)你和團(tuán)隊(duì)成員能夠時(shí)刻看到還有多少犯錯(cuò)的機(jī)會(huì)時(shí)，對生產(chǎn)系統(tǒng)的敬畏心理也會(huì)大大增強(qiáng)。而且當(dāng)錯(cuò)誤預(yù)算消耗到一定比例，如 80% 或 90% 時(shí)，就要開始預(yù)警，控制各種變更，或者投入精力去解決影響穩(wěn)定性的問題。
設(shè)定四個(gè)自然周內(nèi)看看錯(cuò)誤預(yù)算還剩下多少來評定這個(gè)周期的穩(wěn)定性要求是否達(dá)標(biāo)。
故障定級(jí)
將故障等級(jí)設(shè)置為 P0~P4 這么 5 個(gè)級(jí)別，P0 為最高，P4 為最低。
穩(wěn)定性共識(shí)機(jī)制
當(dāng)錯(cuò)誤預(yù)算處于不同狀態(tài)時(shí)，一般都會(huì)采取哪些常見措施呢？
第一，剩余預(yù)算充足或未消耗完之前，對問題的發(fā)生要有容忍度。
第二，剩余預(yù)算消耗過快或即將消耗完之前，SRE 有權(quán)中止和拒絕任何線上變更。
基于錯(cuò)誤預(yù)算的告警
第一個(gè)，相同相似告警，合并后發(fā)送，比如同一應(yīng)用集群內(nèi)同一時(shí)間內(nèi)，同一異常告警，就先合并，對外只發(fā)送一條，這種比較簡單直接。
第二個(gè)，基于錯(cuò)誤預(yù)算來做告警，也就是說我們只關(guān)注對穩(wěn)定性造成影響的告警，比如我們前面提到的，當(dāng)單次問題消耗的錯(cuò)誤預(yù)算達(dá)到 20% 或 30% 等某一閾值時(shí)，就意味著問題非常嚴(yán)重了，這種告警信息一旦收到，就要馬上做出響應(yīng)。這樣告警數(shù)量不多，既達(dá)到了收斂效果，又非常精準(zhǔn)。
如何衡量 SLO 的有效性？
SLO 達(dá)成情況。我們用達(dá)成（Met），或未達(dá)成（Missed）來表示。
“人肉”投入程度。英文表示為 Toil，這里用形象一點(diǎn)的“人肉”投入作為它的譯意，泛指需要大量人工投入、重復(fù)、繁瑣且沒有太多價(jià)值的事情。我們用投入程度高（High）和低（Low）來表示。
用戶滿意度。英文就是 Customer Satisfaction，可以理解為用戶感受和體驗(yàn)如何。這個(gè)信息可以通過真實(shí)和虛擬渠道獲得。真實(shí)渠道如客服投訴、客戶訪談和輿情監(jiān)控獲?。惶摂M渠道如真機(jī)模擬撥測。我們用滿意度高（High）和低（Low）來表示。
總共 3 個(gè)維度，每個(gè)維度有 2 種情況，組合起來就是 8 種情況。
落地SLO還需要考慮的因素
1.梳理出系統(tǒng)的核心核心鏈路以及核心應(yīng)用，以及這些應(yīng)用之間的強(qiáng)弱關(guān)系。
針對核心和非核心應(yīng)用，以及強(qiáng)弱依賴關(guān)系，我們在設(shè)定 SLO 時(shí)的要求也是不同的，具體來說，可以采取下面 4 個(gè)原則。
第一，核心應(yīng)用的 SLO 要更嚴(yán)格，非核心應(yīng)用可以放寬。
第二，強(qiáng)依賴之間的核心應(yīng)用，SLO 要一致。
第三，弱依賴中，核心應(yīng)用對非核心的依賴，要有降級(jí)、熔斷和限流等服務(wù)治理手段。
第四，Error Budget 策略，核心應(yīng)用的錯(cuò)誤預(yù)算要共享，就是如果某個(gè)核心應(yīng)用錯(cuò)誤預(yù)算消耗完，SLO 沒有達(dá)成，那整條鏈路，原則上是要全部暫停操作的
2.通過容量壓測和混沌工程來驗(yàn)證核心鏈路的SLO是否達(dá)成。
故障發(fā)現(xiàn)：如何建設(shè)On-Call的流程機(jī)制
1.確保關(guān)鍵角色在線。
????關(guān)鍵角色是指整個(gè)產(chǎn)品體系中的所有關(guān)鍵角色。
2.組織 War Room 應(yīng)急組織。
????有專門處理故障的“消防群”（暗含著滅火的意思），會(huì)將這些關(guān)鍵角色納入其中，當(dāng)有故障發(fā)生時(shí)會(huì)第一時(shí)間在消防群通報(bào)，這時(shí)對應(yīng)的 On-Call 同事就要第一時(shí)間最高優(yōu)先級(jí)響應(yīng)呼叫（Page）。如果是工作日，對于嚴(yán)重故障，會(huì)立刻組織成立 War Room，責(zé)任人會(huì)馬上聚到一起；如果是非工作時(shí)間，則會(huì)通過電話會(huì)議的方式拉起虛擬 War Room。
3.建立合理的呼叫方式。
????使用固定的 On-Call 手機(jī)，建立手機(jī)與所有 On-Call 系統(tǒng)的對應(yīng)關(guān)系，比如這個(gè)手機(jī)號(hào)碼對應(yīng)交易核心應(yīng)用，另一個(gè)號(hào)碼對應(yīng) IDC 機(jī)房運(yùn)維等等。這樣我們在 On-Call 時(shí)就不再找具體的哪個(gè)人，而是手機(jī)在誰手中，誰就承擔(dān) On-Call 職責(zé)。除非問題遲遲得不到解決，或者遇到了疑難雜癥，這種時(shí)候再呼叫其他同事參與進(jìn)來。
4.確保資源投入的升級(jí)機(jī)制。
????要給到運(yùn)維和 SRE 授權(quán)，當(dāng)他發(fā)現(xiàn)問題不是自己或現(xiàn)有 On-Call 人員能解決的時(shí)候，他有權(quán)調(diào)動(dòng)其他必要資源投入。
5.與云廠商聯(lián)合的 On-Call。
????做好與云廠商之間的協(xié)作磨合，聯(lián)合故障演練，必要的授權(quán)等等
故障處理：一切以恢復(fù)業(yè)務(wù)為最高優(yōu)先級(jí)
故障響應(yīng)有兩個(gè)方面：技術(shù)方面和流程方面，這里主要講一下流程方面該如何應(yīng)對
流程主要有：
1.War Room（應(yīng)急作戰(zhàn)指揮室）：真實(shí)的會(huì)議室辦公或者虛擬群組
2.關(guān)鍵角色分工
Incident Commander，故障指揮官，簡稱為 IC
這個(gè)角色是整個(gè)指揮體系的核心，他最重要的職責(zé)是組織和協(xié)調(diào)，而不是執(zhí)行，下面所有的角色都要接受他的指令并嚴(yán)格執(zhí)行。
Communication Lead，溝通引導(dǎo)，簡稱 CL
負(fù)責(zé)對內(nèi)和對外的信息收集及通報(bào)，這個(gè)角色一般相對固定，由技術(shù)支持、QA 或者是某個(gè) SRE 來承擔(dān)都可以，但是要求溝通表達(dá)能力要比較好。
Operations Lead，運(yùn)維指揮，簡稱 OL
負(fù)責(zé)指揮或指導(dǎo)各種故障預(yù)案的執(zhí)行和業(yè)務(wù)恢復(fù)
Incident Responders，簡稱 IR
就是所有需要參與到故障處理中的各類人員，真正的故障定位和業(yè)務(wù)恢復(fù)都是他們來完成的，比如具體執(zhí)行的 SRE、網(wǎng)絡(luò)和系統(tǒng)運(yùn)維、業(yè)務(wù)開發(fā)、平臺(tái)開發(fā)、網(wǎng)絡(luò)或系統(tǒng)運(yùn)維、DBA，甚至是 QA 等。
客服、PR 以及商家和其它各類合作代表
對客戶進(jìn)行必要的安撫措施
故障響應(yīng)流程機(jī)制
3.溝通反饋機(jī)制
以團(tuán)隊(duì)為單位，每隔 10～15 分鐘做一次反饋，反饋當(dāng)前處理進(jìn)展以及下一步 Action，沒有進(jìn)展也是進(jìn)展，也要及時(shí)反饋。
故障復(fù)盤：黃金三問與判定三原則
黃金三問
第一問：故障原因有哪些？
第二問：我們做什么，怎么做才能確保下次不會(huì)再出現(xiàn)類似故障？
第三問：當(dāng)時(shí)如果我們做了什么，可以用更短的時(shí)間恢復(fù)業(yè)務(wù)？
故障判定的三原則
1. 健壯性原則。
這個(gè)原則是說每個(gè)部件自身要具備一定的自愈能力，比如主備、集群、限流、降級(jí)和重試等等。
2. 第三方默認(rèn)無責(zé)。
如果使用到了第三方的服務(wù)，如公有云的各類服務(wù)，包括 IaaS、PaaS、CDN 以及視頻等等，我們的原則就是默認(rèn)第三方無責(zé)。
3. 分段判定原則。
這個(gè)原則主要應(yīng)用在情況比較復(fù)雜的場景。當(dāng)發(fā)生衍生故障，或者故障蔓延的原因與觸發(fā)原因不同時(shí)，我們會(huì)將一次故障分段判斷。
“故障是系統(tǒng)運(yùn)行的常態(tài)，正常才是特殊狀態(tài)”。
所以，你無論作為什么角色，一定要以一顆平常心來對待故障，能做到這個(gè)程度不容易，這就需要我們更加辯證地看待故障，我們一定要做到鼓勵(lì)改進(jìn)，而不是處罰錯(cuò)誤。
---end---
我是Seven，一個(gè)不懈努力的程序猿，希望本文能對你有所裨益
如何看懂Apache Log4j 遠(yuǎn)程代碼執(zhí)行漏洞原理？
細(xì)數(shù)Java8-14的那些經(jīng)典特性，語言的車輪正在滾滾向前...
