对SRE的理解
SRE
這兩年，不同類型、不同規(guī)模的企業(yè) IT 團(tuán)隊(duì)，他們?yōu)榱颂嵘脩魞r(jià)值的交付效率，都在積極采用微服務(wù)、容器，以及其他的分布式技術(shù)和產(chǎn)品，而且也在積極引入像 DevOps 這樣的先進(jìn)理念。
在引入了這么多先進(jìn)的技術(shù)和理念之后，效率提升了，但這種復(fù)雜架構(gòu)的系統(tǒng)穩(wěn)定性很難得到保障。
這幾年業(yè)界對(duì) SRE 的關(guān)注越來(lái)越多，大家也幾乎達(dá)成了共識(shí)，Google SRE 就是目前穩(wěn)定性領(lǐng)域的最佳實(shí)踐。也可以說(shuō)，SRE 已經(jīng)成為穩(wěn)定性的代名詞。
DevOps和SRE的區(qū)別
DevOps核心是做全棧交付，SRE的核心是穩(wěn)定性保障，關(guān)注業(yè)務(wù)所有活動(dòng)，兩者的共性是：都使用軟件工程解決問(wèn)題;
DevOps的誕生是由于互聯(lián)網(wǎng)商業(yè)市場(chǎng)競(jìng)爭(zhēng)加劇，企業(yè)為減少試錯(cuò)成本，往往僅推出最小可行產(chǎn)品，產(chǎn)品需要不斷且高頻的迭代來(lái)滿足市場(chǎng)需求，搶占市場(chǎng)(產(chǎn)品的迭代是關(guān)乎一整條交付鏈的事)，高頻的迭代則會(huì)促使研發(fā)團(tuán)隊(duì)使用敏捷模式，敏捷模式下對(duì)運(yùn)維的全棧交付能力要求更嚴(yán)格，則運(yùn)維必須開(kāi)啟DevOps來(lái)實(shí)現(xiàn)全棧交付；因?yàn)椴粩嗟牡桓?也就是俗稱的變更)是觸發(fā)故障的非穩(wěn)定性根源，而互聯(lián)網(wǎng)產(chǎn)品/服務(wù)穩(wěn)定性缺失會(huì)造成用戶流失，甚至流到競(jìng)爭(zhēng)對(duì)手那里， 因此關(guān)注業(yè)務(wù)穩(wěn)定性也變得十分重要，SRE由此誕生。
對(duì)SRE的理解
SRE 是一套體系化的方法，我們也只有用全局視角才能更透徹地理解它。
從職能分工上，SRE 體系的建設(shè)絕不是單個(gè)崗位或單個(gè)部門就能獨(dú)立完成的，必然要求有高效的跨團(tuán)隊(duì)組織協(xié)作才可以。比如容量評(píng)估、故障演練、服務(wù)降級(jí)、服務(wù)限流、異常熔斷、監(jiān)控告警等等，這些工作并不是某個(gè)人、某個(gè)角色，甚至是某個(gè)團(tuán)隊(duì)就可以單槍匹馬完成的。比如這里的很多事情要依賴運(yùn)維自動(dòng)化，像容量擴(kuò)縮容，必然會(huì)與運(yùn)維團(tuán)隊(duì)有交集；如果做得再?gòu)椥砸恍?#xff0c;還需要與監(jiān)控結(jié)合，就要與監(jiān)控團(tuán)隊(duì)有合作；同時(shí)還可能依賴 DevOps 提供持續(xù)交付、配置變更，以及灰度發(fā)布這些基礎(chǔ)能力，就要與開(kāi)發(fā)和效能團(tuán)隊(duì)有交集。
SRE的根本目的是為了提高穩(wěn)定性：
從業(yè)界穩(wěn)定性通用的衡量標(biāo)準(zhǔn)看，有兩個(gè)非常關(guān)鍵的指標(biāo)：
MTBF，Mean Time Between Failure，平均故障時(shí)間間隔。
MTTR，Mean Time To Repair， 故障平均修復(fù)時(shí)間。
還來(lái)看前面的 SRE 穩(wěn)定性保障規(guī)劃圖，你會(huì)發(fā)現(xiàn)我們把整個(gè)軟件運(yùn)行周期按照這兩個(gè)指標(biāo)分成了兩段。通俗地說(shuō)，MTBF 指示了系統(tǒng)正常運(yùn)行的階段，而 MTTR 則意味著系統(tǒng)故障狀態(tài)的階段。
如果想提升穩(wěn)定性，就會(huì)有兩個(gè)方向：提升 MTBF，也就是減少故障發(fā)生次數(shù)，提升故障發(fā)生間隔時(shí)長(zhǎng)；降低 MTTR，故障不可避免，那就提升故障處理效率，減少故障影響時(shí)長(zhǎng)。
從 SRE 穩(wěn)定性保障規(guī)劃圖中，可以看出 MTTR 可以細(xì)分為 4 個(gè)指標(biāo)：MTTI、MTTK、MTTF 和 MTTV。
SRE做的任何一件事情、開(kāi)發(fā)的任何一套系統(tǒng)、引入的任何一個(gè)理念和方法論，有且只有一個(gè)目標(biāo)，那就是“提升 MTBF，降低 MTTR”，也就是把故障發(fā)生時(shí)間的間隔變長(zhǎng)，將故障影響的時(shí)間減少。
比如，在 Pre-MTBF 階段（無(wú)故障階段），我們要做好架構(gòu)設(shè)計(jì)，提供限流、降級(jí)、熔斷這些 Design-for-Failure 的服務(wù)治理手段，以具備故障快速隔離的條件；還可以考慮引入混沌工程這樣的故障模擬機(jī)制，在線上模擬故障，提前發(fā)現(xiàn)問(wèn)題。
在 Post-MTBF 階段，也就是上一故障剛結(jié)束，開(kāi)啟新的 MTBF 階段，我們應(yīng)該要做故障復(fù)盤，總結(jié)經(jīng)驗(yàn)，找到不足，落地改進(jìn)措施等。
在 MTTI 階段，我們就需要依賴監(jiān)控系統(tǒng)幫我們及時(shí)發(fā)現(xiàn)問(wèn)題，對(duì)于復(fù)雜度較高和體量非常大的系統(tǒng)，要依賴 AIOps 的能力，提升告警準(zhǔn)確率，做出精準(zhǔn)的響應(yīng)。
同時(shí) AIOps 能力在大規(guī)模分布式系統(tǒng)中，在 MTTK 階段也非常關(guān)鍵，因?yàn)槲覀冊(cè)谶@個(gè)階段需要確認(rèn)根因，至少是根因的范圍。
系統(tǒng)可用性思考
衡量系統(tǒng)可用性的 2 種方式
- 時(shí)間維度：Availability = Uptime / (Uptime + Downtime)
- 請(qǐng)求維度：Availability = Successful request / Total request
時(shí)間維度，是從故障角度出發(fā)對(duì)系統(tǒng)穩(wěn)定性進(jìn)行評(píng)估，
對(duì)應(yīng)到系統(tǒng)上，我們會(huì)用一系列的標(biāo)準(zhǔn)和判定邏輯來(lái)說(shuō)明系統(tǒng)是否正常。比如，系統(tǒng)請(qǐng)求狀態(tài)碼為非 5xx 的比例，也就是請(qǐng)求成功率低于 95%，已經(jīng)連續(xù)超過(guò) 10 分鐘，這時(shí)就要算作故障，那么 10 分鐘就要納入 Downtime（宕機(jī)時(shí)間），如果達(dá)不到這個(gè)標(biāo)準(zhǔn)，就不算作故障，只是算作一般或偶然的異常問(wèn)題。
這里有三個(gè)要素：衡量指標(biāo)，系統(tǒng)請(qǐng)求狀態(tài)碼；衡量目標(biāo)，非 5xx 占比，也就是成功率達(dá)到 95%；影響時(shí)長(zhǎng)，持續(xù) 10 分鐘。
針對(duì)時(shí)長(zhǎng)維度的穩(wěn)定性計(jì)算方式最顯著的問(wèn)題就是，穩(wěn)定性只與故障發(fā)生掛鉤。
如有一個(gè)系統(tǒng)，因?yàn)榫W(wǎng)絡(luò)抖動(dòng)，有短暫的幾秒、十幾秒，或者幾分鐘異常，但是后來(lái)系統(tǒng)自己恢復(fù)了，業(yè)務(wù)并沒(méi)有中斷，這時(shí)我們按照時(shí)長(zhǎng)維度來(lái)判斷，這肯定不會(huì)算作系統(tǒng)故障。但是如果這種短暫的影響頻度非常高，一天來(lái)個(gè) 5、6 次，持續(xù)一兩周，我們應(yīng)該可以判定系統(tǒng)運(yùn)行狀況也是不正常的，可能不是故障，但肯定是不穩(wěn)定了。
這種用時(shí)長(zhǎng)維度來(lái)衡量系統(tǒng)穩(wěn)定性的方式，其主要缺點(diǎn)就是粒度不夠精細(xì)。這些小的異常問(wèn)題和它們的影響，如果從更長(zhǎng)的周期來(lái)看，也是有一定參考價(jià)值的。
第二種衡量方式，也就是從請(qǐng)求維度來(lái)衡量系統(tǒng)可用性。用一句話來(lái)說(shuō)，請(qǐng)求維度，是從成功請(qǐng)求占比的角度出發(fā)，對(duì)系統(tǒng)的穩(wěn)定性進(jìn)行評(píng)估。
假定我們的系統(tǒng)一天內(nèi)有 100,000 次請(qǐng)求，我們期望的成功率至少是 95%，如果有 5001 次請(qǐng)求失敗了，也就是成功率低于 95% 了，我們就認(rèn)為系統(tǒng)運(yùn)行狀態(tài)是不正常的。
請(qǐng)求維度的系統(tǒng)可用性同樣包含三個(gè)關(guān)鍵要素，第一個(gè)衡量指標(biāo)，請(qǐng)求成功率；第二個(gè)衡量目標(biāo)，成功率達(dá)到 95% 才算系統(tǒng)運(yùn)行正常；第三個(gè)是統(tǒng)計(jì)周期，比如一天、一周、一個(gè)月等等，我們是在一個(gè)統(tǒng)計(jì)周期內(nèi)計(jì)算整體狀況，而不是看單次的。
這種方式對(duì)系統(tǒng)運(yùn)行狀況是否穩(wěn)定監(jiān)管得更為嚴(yán)格，不會(huì)漏掉任何一次問(wèn)題的影響，因?yàn)樗鼘?duì)系統(tǒng)整體運(yùn)行的穩(wěn)定性判定，不僅僅會(huì)通過(guò)單次的異常影響進(jìn)行評(píng)估，還會(huì)累計(jì)疊加進(jìn)行周期性的評(píng)估。
到這里，我們就總結(jié)出一條至關(guān)重要的經(jīng)驗(yàn)了：故障一定意味著不穩(wěn)定，但是不穩(wěn)定，并不意味著一定有故障發(fā)生。
設(shè)定系統(tǒng)穩(wěn)定性目標(biāo)要考慮的 3 個(gè)因素
-
成本因素
從理論上來(lái)說(shuō)，肯定是 9 越多穩(wěn)定性越好，但是相應(yīng)付出的成本和代價(jià)也會(huì)更高。
-
業(yè)務(wù)容忍度
對(duì)于核心業(yè)務(wù)或核心應(yīng)用，比如電商的交易和支付系統(tǒng)，我們當(dāng)然是希望成功率越高越好，一般對(duì)系統(tǒng)穩(wěn)定性要求是“3 個(gè) 9”或“4 個(gè) 9”。對(duì)于非核心業(yè)務(wù)或應(yīng)用，比如商品評(píng)論，商品評(píng)分等，或許“2 個(gè) 9”也能容忍。因?yàn)槎虝r(shí)間的評(píng)論看不到，并不會(huì)對(duì)業(yè)務(wù)收入和用戶體驗(yàn)造成太大的影響。
-
系統(tǒng)當(dāng)前的穩(wěn)定性狀況
結(jié)合系統(tǒng)的實(shí)際情況，定一個(gè)合理的標(biāo)準(zhǔn)比定一個(gè)更高的標(biāo)準(zhǔn)會(huì)更重要。
SRE 會(huì)更多采用請(qǐng)求維度的統(tǒng)計(jì)方式，因?yàn)?SRE 關(guān)注的穩(wěn)定性是系統(tǒng)的整體運(yùn)行狀態(tài)，而不僅僅只關(guān)注故障狀態(tài)下的穩(wěn)定性，在系統(tǒng)運(yùn)行過(guò)程中的任何異常，都會(huì)被納入穩(wěn)定性的評(píng)估范疇中。
SRE切入點(diǎn)：選擇SLI，設(shè)定SLO
SRE 強(qiáng)調(diào)的穩(wěn)定性，一般不是看單次請(qǐng)求的成功與否，而是看整體情況，所以我們會(huì)把成功請(qǐng)求的占比設(shè)定為一個(gè)可以接受的目標(biāo)，也就是我們常說(shuō)的“3 個(gè) 9”或“4 個(gè) 9”這樣的可量化的數(shù)字。
那么，這個(gè)“確定成功請(qǐng)求條件，設(shè)定達(dá)成占比目標(biāo)”的過(guò)程，在 SRE 中就是設(shè)定穩(wěn)定性衡量標(biāo)準(zhǔn)的 SLI 和 SLO 的過(guò)程。具體來(lái)看下這兩個(gè)概念。
SLI，Service Level Indicator，服務(wù)等級(jí)指標(biāo)，其實(shí)就是我們選擇哪些指標(biāo)來(lái)衡量我們的穩(wěn)定性。
SLO，Service Level Objective，服務(wù)等級(jí)目標(biāo)，指的就是我們?cè)O(shè)定的穩(wěn)定性目標(biāo)，比如“幾個(gè) 9”這樣的目標(biāo)。
落地 SRE 的第一步其實(shí)就是“選擇合適的 SLI，設(shè)定對(duì)應(yīng)的 SLO”。
我們以電商交易系統(tǒng)中的一個(gè)核心應(yīng)用“購(gòu)物車”為例，給它取名叫做 trade_cart。trade_cart 是以請(qǐng)求維度來(lái)衡量穩(wěn)定性的，也就是說(shuō)單次請(qǐng)求如果返回的是非 5xx 的狀態(tài)碼，我們認(rèn)為該次請(qǐng)求是成功的；如果返回的是 5xx 狀態(tài)碼，如我們常見(jiàn)的 502 或 503，我們就判斷這次請(qǐng)求是失敗的。
在 SRE 實(shí)踐中，我們用 SLI 和 SLO 來(lái)描述。“狀態(tài)碼為非 5xx 的比例”就是 SLI，“大于等于 99.95%”就是 SLO。說(shuō)得更直接一點(diǎn)，SLO 是 SLI 要達(dá)成的目標(biāo)。
SLI 就是我們要監(jiān)控的指標(biāo)，SLO 就是這個(gè)指標(biāo)對(duì)應(yīng)的目標(biāo)。
選擇 SLI 指標(biāo)的兩大原則：
原則一：選擇能夠標(biāo)識(shí)一個(gè)主體是否穩(wěn)定的指標(biāo)，如果不是這個(gè)主體本身的指標(biāo)，或者不能標(biāo)識(shí)主體穩(wěn)定性的，就要排除在外。
原則二：針對(duì)電商這類有用戶界面的業(yè)務(wù)系統(tǒng)，優(yōu)先選擇與用戶體驗(yàn)強(qiáng)相關(guān)或用戶可以明顯感知的指標(biāo)。
還拿我們上面 trade_cart 的例子來(lái)說(shuō)，主體確定了，就是 trade_cart，應(yīng)用層面的，請(qǐng)求返回狀態(tài)碼和時(shí)延就是很好的指標(biāo)，再來(lái)檢查下它們能否標(biāo)識(shí)的 trade_cart 穩(wěn)定性，毫無(wú)疑問(wèn)，這兩個(gè)指標(biāo)都可以，那么請(qǐng)求返回狀態(tài)碼和時(shí)延就可以作為 trade_cart 穩(wěn)定性的 SLI 指標(biāo)。
我們換一個(gè)指標(biāo)，CPU 的使用率這個(gè)指標(biāo)適合嗎？根據(jù)我們剛才說(shuō)的原則，既然我們關(guān)注的是 trade_cart 的運(yùn)行狀況，而 CPU 是系統(tǒng)層的指標(biāo)，所以，在選擇應(yīng)用層 SLI 的指標(biāo)時(shí)，自然會(huì)把 CPU 排除掉。
快速識(shí)別 SLI 指標(biāo)的方法：VALET：
VALET 是 5 個(gè)單詞的首字母，分別是 Volume、Availability、Latency、Error 和 Ticket。這 5 個(gè)單詞就是我們選擇 SLI 指標(biāo)的 5 個(gè)維度。
Volume- 容量
Volume（容量）是指服務(wù)承諾的最大容量是多少。比如，一個(gè)應(yīng)用集群的 QPS（最大吞吐能力）、TPS（服務(wù)器每秒處理的事務(wù)數(shù)）、會(huì)話數(shù)以及連接數(shù)等等，如果我們對(duì)日常設(shè)定一個(gè)目標(biāo)，就是日常的容量 SLO，對(duì)雙 11 這樣的大促設(shè)定一個(gè)目標(biāo)，就是大促 SLO。對(duì)于數(shù)據(jù)平臺(tái)，我們要看它的吞吐能力，比如每小時(shí)能處理的記錄數(shù)或任務(wù)數(shù)。
Availablity- 可用性
Availablity（可用性）代表服務(wù)是否正常。比如，我們前面介紹到的請(qǐng)求調(diào)用的非 5xx 狀態(tài)碼成功率，就可以歸于可用性。對(duì)于數(shù)據(jù)平臺(tái)，我們就看任務(wù)的執(zhí)行成功情況，這個(gè)也可以根據(jù)不同的任務(wù)執(zhí)行狀態(tài)碼來(lái)歸類。
Latency- 時(shí)延
Latency（時(shí)延）是說(shuō)響應(yīng)是否足夠快。這是一個(gè)會(huì)直接影響用戶訪問(wèn)體驗(yàn)的指標(biāo)。對(duì)于任務(wù)類的作業(yè)，我們會(huì)看每個(gè)任務(wù)是否在規(guī)定時(shí)間內(nèi)完成了。
通常對(duì)于時(shí)延這個(gè)指標(biāo)，我們不會(huì)直接做所有請(qǐng)求時(shí)延的平均，因?yàn)檎麄€(gè)時(shí)延的分布也符合正態(tài)分布，所以通常會(huì)以類似“90% 請(qǐng)求的時(shí)延 <= 80ms，或者 95% 請(qǐng)求的時(shí)延 <=120ms ”這樣的方式來(lái)設(shè)定時(shí)延 SLO，熟悉數(shù)理統(tǒng)計(jì)的同學(xué)應(yīng)該知道，這個(gè) 90% 或 95% 我們稱之為置信區(qū)間。
因?yàn)椴慌懦芏嗾?qǐng)求從業(yè)務(wù)邏輯層面是不成功的，這時(shí)業(yè)務(wù)邏輯的處理時(shí)長(zhǎng)就會(huì)非常短（可能 10ms），或者出現(xiàn) 404 這樣的狀態(tài)碼（可能就 1ms）。從可用性來(lái)講，這些請(qǐng)求也算成功，但是這樣的請(qǐng)求會(huì)拉低整個(gè)均值。
同時(shí)，也會(huì)出現(xiàn)另一種極端情況，就是某幾次請(qǐng)求因?yàn)楦鞣N原因，導(dǎo)致時(shí)延高了，到了 500ms，但是因?yàn)榇螖?shù)所占比例較低，數(shù)據(jù)被平均掉了，單純從平均值來(lái)看是沒(méi)有異常的。但是從實(shí)際情況看，有少部分用戶的體驗(yàn)其實(shí)已經(jīng)非常糟糕了。所以，為了識(shí)別出這種情況，我們就要設(shè)定不同的置信區(qū)間來(lái)找出這樣的用戶占比，有針對(duì)性地解決。
Errors- 錯(cuò)誤率
錯(cuò)誤率有多少？這里除了 5xx 之外，我們還可以把 4xx 列進(jìn)來(lái)，因?yàn)榍懊嫖覀兊姆?wù)可用性不錯(cuò)，但是從業(yè)務(wù)和體驗(yàn)角度，4xx 太多，用戶也是不能接受的。
或者可以增加一些自定義的狀態(tài)碼，看哪些狀態(tài)是對(duì)業(yè)務(wù)有損的，比如某些熱門商品總是缺貨，用戶登錄驗(yàn)證碼總是輸入錯(cuò)誤，這些雖不是系統(tǒng)錯(cuò)誤，但從業(yè)務(wù)角度來(lái)看，對(duì)用戶的體驗(yàn)影響還是比較大的。
Tickets- 人工介入
是否需要人工介入？如果一項(xiàng)工作或任務(wù)需要人工介入，那說(shuō)明一定是低效或有問(wèn)題的。舉一個(gè)我們常見(jiàn)的場(chǎng)景，數(shù)據(jù)任務(wù)跑失敗了，但是無(wú)法自動(dòng)恢復(fù)，這時(shí)就要人工介入恢復(fù)；或者超時(shí)了，也需要人工介入，來(lái)中斷任務(wù)、重啟拉起來(lái)跑等等。
Tickets 的 SLO 可以想象成它的中文含義：門票。一個(gè)周期內(nèi)，門票數(shù)量是固定的，比如每月 20 張，每次人工介入，就消耗一張，如果消耗完了，還需要人工介入，那就是不達(dá)標(biāo)了。
這里給出一個(gè) Google 提供的，針對(duì)類似于我們 trade_cart 的一個(gè)應(yīng)用服務(wù)，基于 VALET 設(shè)計(jì)出來(lái)的 SLO 的 Dashboard 樣例，
如何通過(guò) SLO 計(jì)算可用性？
系統(tǒng)可用性：Availability = Successful request / Total request
第一種，直接根據(jù)成功的定義來(lái)計(jì)算。
也就是我們前面定義一個(gè)請(qǐng)求的返回狀態(tài)碼必須是非 5xx 才算成功，同時(shí)時(shí)延還要低于 80ms，同時(shí)滿足這兩個(gè)條件，我們才算是成功的，也就是納入上述公式中 Successful request 的統(tǒng)計(jì)中，用公式來(lái)表示：
Successful = （狀態(tài)碼非 5xx） & （時(shí)延 <= 80ms）
這種計(jì)算方式存在的問(wèn)題就是，對(duì)單次請(qǐng)求的成功與否的判定太過(guò)死板，容易錯(cuò)殺誤判。比如我們前面講對(duì)于時(shí)延，我們一般會(huì)設(shè)定置信區(qū)間，比如 90% 時(shí)延小于等于 200ms 這樣的場(chǎng)景，用這種方式就很難體現(xiàn)出來(lái)。而且，對(duì)于狀態(tài)碼成功率和時(shí)延成功率的容忍度，通常也是也不一樣的，通過(guò)這種方式就不夠準(zhǔn)確。所以，我們就會(huì)采取第二種方式。
第二種方式，SLO 方式計(jì)算。
SLO1：99.95% 狀態(tài)碼成功率
SLO2：90% Latency <= 80ms
SLO3：99% Latency <= 200ms
直接用公式表示：Availability = SLO1 & SLO2 & SLO3
只有當(dāng)這個(gè)三個(gè) SLO 同時(shí)達(dá)標(biāo)時(shí)，整個(gè)系統(tǒng)的穩(wěn)定性才算達(dá)標(biāo)，有一個(gè)不達(dá)標(biāo)就不算達(dá)標(biāo)，這樣就可以很好地將 SLO 設(shè)定的合理性與最終可用性結(jié)合了起來(lái)。所以，通常在 SRE 實(shí)踐中，我們通常會(huì)采用這種設(shè)定方式。
Google 的 SLI 和 SLO 設(shè)定模板鏈接：https://landing.google.com/sre/workbook/chapters/slo-document
落地 SLO，先轉(zhuǎn)化為 Error Budget
錯(cuò)誤預(yù)算其實(shí)和駕照記分制是一樣的，最大的作用就是“提示你還有多少次犯錯(cuò)的機(jī)會(huì)”，并且，錯(cuò)誤預(yù)算的警示效果比看成功率這種統(tǒng)計(jì)數(shù)據(jù)更直觀，感官?zèng)_擊力更強(qiáng)。
以 trade_cart 購(gòu)物車這個(gè)應(yīng)用為例，SLO 目標(biāo)就是我們上節(jié)課定過(guò)的。假設(shè)在 4 周的時(shí)間，這個(gè)應(yīng)用所有的請(qǐng)求次數(shù)是 4,653,680，按照給出的 SLO 反向推導(dǎo)，就可以得到容許的錯(cuò)誤次數(shù)，這就是錯(cuò)誤預(yù)算。
在 SLO 落地實(shí)踐時(shí)，我們通常就把 SLO 轉(zhuǎn)化為錯(cuò)誤預(yù)算，以此來(lái)推進(jìn)穩(wěn)定性目標(biāo)達(dá)成。
如何應(yīng)用 Error Budget？
1.穩(wěn)定性燃盡圖
在應(yīng)用錯(cuò)誤預(yù)算的時(shí)候，你要考慮設(shè)定一個(gè)合理的周期，比如 1 天、1 周或 1 個(gè)月。
1 天或 1 周，周期相對(duì)較短，我們通常的建議是 4 個(gè)自然周，這個(gè)周期設(shè)定更合理，這也是谷歌給出的建議。為什么選 4 個(gè)自然周，而不是 1 個(gè)自然月呢？主要是因?yàn)樽匀辉峦ǔ?huì)導(dǎo)致跨周的情況出現(xiàn)，相比于 4 個(gè)自然周，在統(tǒng)計(jì)上就要考慮額外的邊界問(wèn)題。
同時(shí)，在考慮定錯(cuò)誤預(yù)算的時(shí)候，還要考慮到部分特殊場(chǎng)景，這個(gè)要根據(jù)業(yè)務(wù)特點(diǎn)來(lái)定，比如電商會(huì)有雙 11 大促活動(dòng)，有些產(chǎn)品還要考慮春晚互動(dòng)活動(dòng)和搶紅包活動(dòng)，甚至有些社交類產(chǎn)品還要考慮應(yīng)對(duì)突發(fā)新聞導(dǎo)致的訪問(wèn)量激增問(wèn)題等等，這些場(chǎng)景必然因?yàn)樵L問(wèn)量太大而采取很多限流降級(jí)的策略，導(dǎo)致更多的請(qǐng)求失敗。
如果這些活動(dòng)或事件是發(fā)生在某個(gè)考核周期內(nèi)，這時(shí)要考慮放大錯(cuò)誤預(yù)算的值，特別是瞬時(shí)的錯(cuò)誤或失敗，應(yīng)該要有更大的容忍度，簡(jiǎn)單來(lái)講就是，特殊情況特殊處理，當(dāng)然最重要的，也要做好特殊保障和應(yīng)對(duì)工作。
2. 故障定級(jí)
以 trade_cart 購(gòu)物車為例，結(jié)合 P0～P4 的故障等級(jí)設(shè)置，trade_cart 請(qǐng)求成功率 SLO 對(duì)應(yīng)的錯(cuò)誤預(yù)算是 25,000 次，如果一個(gè)問(wèn)題產(chǎn)生的錯(cuò)誤請(qǐng)求數(shù)超過(guò)了 5000 次，也就是錯(cuò)誤預(yù)算一下就被消耗掉 20% 以上，這時(shí)，我們可以把這次故障定為 P2 級(jí)。以此類推，如果消耗 30% 以上，我們定為 P1 級(jí)，消耗 50% 以上，定為 P0 級(jí)等等。
第一，剩余預(yù)算充足或未消耗完之前，對(duì)問(wèn)題的發(fā)生要有容忍度。
第二，剩余預(yù)算消耗過(guò)快或即將消耗完之前，SRE 有權(quán)中止和拒絕任何線上變更
此時(shí)的情況已經(jīng)說(shuō)明系統(tǒng)穩(wěn)定出現(xiàn)了很大問(wèn)題，不能再讓它“帶病工作”。同樣，這時(shí)的業(yè)務(wù)開(kāi)發(fā)團(tuán)隊(duì)，也有權(quán)拒絕新的需求，他們首要的事情，應(yīng)該是跟 SRE 一起解決影響穩(wěn)定性的問(wèn)題，直至問(wèn)題解決，且等到下一個(gè)周期有了新的錯(cuò)誤預(yù)算后，再恢復(fù)正常變更節(jié)奏。
日常工作中，作為一線的工程師，你肯定要接收大量的告警短信，但是這些告警里面很大一部分都是沒(méi)有實(shí)際意義的。為什么這么說(shuō)呢？因?yàn)樗鼈儧](méi)有行動(dòng)指導(dǎo)意義，比如 CPU 使用率 80%、成功率低于 95%、時(shí)延超過(guò) 80ms 等等，這樣的告警只是告訴我們有問(wèn)題、有異常，但是否需要高優(yōu)先級(jí)馬上處理，還是說(shuō)可以先放一放、過(guò)一會(huì)再處理呢？你可能并沒(méi)有辦法判斷。這樣的告警，接收的次數(shù)多了，就會(huì)變成“狼來(lái)了”，你自己變得警惕性不高，當(dāng)故障真的發(fā)生時(shí)，你也沒(méi)法快速響應(yīng)。
那我們應(yīng)當(dāng)如何做告警收斂呢？從我的經(jīng)驗(yàn)看，有兩個(gè)解決辦法。
- 第一個(gè)，相同相似告警，合并后發(fā)送，比如同一應(yīng)用集群內(nèi)同一時(shí)間內(nèi)，同一異常告警，就先合并，對(duì)外只發(fā)送一條，這種比較簡(jiǎn)單直接。
- 第二個(gè)，基于錯(cuò)誤預(yù)算來(lái)做告警，也就是說(shuō)我們只關(guān)注對(duì)穩(wěn)定性造成影響的告警，比如我們前面提到的，當(dāng)單次問(wèn)題消耗的錯(cuò)誤預(yù)算達(dá)到 20% 或 30% 等某一閾值時(shí)，就意味著問(wèn)題非常嚴(yán)重了，這種告警信息一旦收到，就要馬上做出響應(yīng)。這樣告警數(shù)量不多，既達(dá)到了收斂效果，又非常精準(zhǔn)。
谷歌基于 SLO 和錯(cuò)誤預(yù)算的幾種告警算法： https://sre.google/workbook/alerting-on-slos/
如何衡量 SLO 的有效性？
衡量 SLO 及錯(cuò)誤預(yù)算策略是否有效，其實(shí)就是看實(shí)際運(yùn)行后，是否真的能達(dá)到我們的期望。
我們可以從下面三個(gè)關(guān)鍵維度來(lái)看。
- SLO 達(dá)成情況。我們用達(dá)成（Met），或未達(dá)成（Missed）來(lái)表示。
- “人肉”投入程度。英文表示為 Toil，這里用形象一點(diǎn)的“人肉”投入作為它的譯意，泛指需要大量人工投入、重復(fù)、繁瑣且沒(méi)有太多價(jià)值的事情。我們用投入程度高（High）和低（Low）來(lái)表示。
- 用戶滿意度。英文就是 Customer Satisfaction，可以理解為用戶感受和體驗(yàn)如何。這個(gè)信息可以通過(guò)真實(shí)和虛擬渠道獲得。真實(shí)渠道如客服投訴、客戶訪談和輿情監(jiān)控獲取；虛擬渠道如真機(jī)模擬撥測(cè)。我們用滿意度高（High）和低（Low）來(lái)表示。
總共 3 個(gè)維度，每個(gè)維度有 2 種情況，組合起來(lái)就是 8 種情況，我們直接引用 Google 給出的圖表和建議。
針對(duì)這 8 種情況，我們分別給出對(duì)應(yīng)策略：
第一類，收緊 SLO。
這個(gè)時(shí)候就是目標(biāo)定得太低了，比如 SLO 達(dá)成（Met），但是用戶不滿意（Low）。這就表示我們的 SLO 設(shè)定得太容易達(dá)成，沒(méi)有反饋真實(shí)的運(yùn)行狀況。
第二類，放寬 SLO。
與第一類相反，目標(biāo)定太高，總是達(dá)不成（Missed），但用戶反饋卻很不錯(cuò)（High），這種就會(huì)造成錯(cuò)誤預(yù)算提前消耗完，導(dǎo)致很多變更暫停，產(chǎn)品延期，甚至?xí)鲆恍o(wú)謂的優(yōu)化，這時(shí)就可以適當(dāng)松松綁。
第三類，保持現(xiàn)狀。
對(duì)有問(wèn)題的維度采取有針對(duì)性的優(yōu)化措施。比如表格第一行，是我們期望的最理想狀態(tài)，SLO 能達(dá)成，人肉投入又低，客戶滿意度又很高，也沒(méi)有特別的優(yōu)化空間，這時(shí)我們就可以增加發(fā)布和變更次數(shù)，更大程度地釋放生產(chǎn)力。
總結(jié)：
案例：落地SLO時(shí)還需要考慮哪些因素？
一般來(lái)說(shuō)，電商系統(tǒng)一定有一個(gè)或幾個(gè)核心服務(wù)，比如要給用戶提供商品選擇、搜索和購(gòu)買的服務(wù)等。但我們知道，大部分用戶并不是上來(lái)就購(gòu)買，而是會(huì)有一個(gè)訪問(wèn)的過(guò)程，他們會(huì)先登錄，再搜索，然后訪問(wèn)一個(gè)或多個(gè)商品詳情介紹，決定是放到購(gòu)物車候選，還是選擇物流地址后直接下單，最后支付購(gòu)買。
這條從登錄到購(gòu)買的鏈路，我們一般稱之為系統(tǒng)的核心鏈路（Critical Path），系統(tǒng)或網(wǎng)站就是依靠這樣一條訪問(wèn)鏈路，為用戶提供了購(gòu)買商品的服務(wù)能力。
至于電商系統(tǒng)的其它頁(yè)面或能力，比如網(wǎng)站政策、新手指導(dǎo)、開(kāi)店指南等等，這些對(duì)用戶購(gòu)買服務(wù)不會(huì)造成太大影響的，相對(duì)于核心鏈路來(lái)說(shuō)，它的重要性就相對(duì)低一些。
我們要給電商系統(tǒng)設(shè)定 SLO，大的原則就是先設(shè)定核心鏈路的 SLO，然后根據(jù)核心鏈路進(jìn)行 SLO 的分解。
核心鏈路：確定核心應(yīng)用與強(qiáng)弱依賴關(guān)系
要確定核心鏈路的 SLO，我們得先找到核心鏈路。
我們可以先通過(guò)全鏈路跟蹤這樣的技術(shù)手段找出所有相關(guān)應(yīng)用，也就是呈現(xiàn)出調(diào)用關(guān)系的拓?fù)鋱D，下圖是亞馬遜電商分布式系統(tǒng)的真實(shí)調(diào)用關(guān)系拓?fù)鋱D。之所以這么復(fù)雜，是因?yàn)榧词故菃螚l路徑，它實(shí)際覆蓋的應(yīng)用也是很多的，特別是對(duì)于大型的分布式業(yè)務(wù)系統(tǒng)，可能會(huì)有幾十甚至上百個(gè)路徑，這些應(yīng)用之間的依賴關(guān)系也特別復(fù)雜。
面對(duì)這樣復(fù)雜的應(yīng)用關(guān)系，繼續(xù)來(lái)做精簡(jiǎn)，也就是區(qū)分哪些是核心應(yīng)用，哪些是非核心應(yīng)用。
比如用戶訪問(wèn)商品詳情的時(shí)候，會(huì)同時(shí)展現(xiàn)商品評(píng)價(jià)信息，但是這些信息不展現(xiàn)，對(duì)于用戶選擇商品也不會(huì)造成非常大影響，特別是在雙十一大促這樣的場(chǎng)景中，用戶在這個(gè)時(shí)刻的目的很明確，就是購(gòu)買商品，并不是看評(píng)價(jià)。所以類似商品評(píng)價(jià)的應(yīng)用是可以降級(jí)的，或者短時(shí)間不提供服務(wù)。那這種不影響核心業(yè)務(wù)的應(yīng)用就可以歸為非核心應(yīng)用。
相反的，像商品 SKU（庫(kù)存）或優(yōu)惠券這樣的應(yīng)用，直接決定了用戶最終的購(gòu)買金額，這種應(yīng)用在任何時(shí)刻都要保持高可用。那這種必須是高可用的應(yīng)用就是核心應(yīng)用。
這張圖就呈現(xiàn)出一條典型的電商交易的關(guān)鍵路徑，其中綠色部分為核心應(yīng)用，藍(lán)色部分為非核心應(yīng)用。
核心應(yīng)用之間的依賴關(guān)系，我們稱之為強(qiáng)依賴，而其它應(yīng)用之間的依賴關(guān)系，我們稱之為弱依賴
設(shè)定 SLO 有哪些原則？
第一，核心應(yīng)用的 SLO 要更嚴(yán)格，非核心應(yīng)用可以放寬。 這么做，就是為了確保 SRE 的精力能夠更多地關(guān)注在核心業(yè)務(wù)上。
第二，強(qiáng)依賴之間的核心應(yīng)用，SLO 要一致。 比如下單的 Buy 應(yīng)用要依賴 Coupon 這個(gè)促銷應(yīng)用，我們要求下單成功率的 SLO 要 99.95%，如果 Coupon 只有 99.9%，那很顯然，下單成功率是達(dá)不成目標(biāo)的，所以我們就會(huì)要求 Coupon 的成功率 SLO 也要達(dá)到 99.95% 。
第三，弱依賴中，核心應(yīng)用對(duì)非核心的依賴，要有降級(jí)、熔斷和限流等服務(wù)治理手段。 這樣做是為了避免由非核心應(yīng)用的異常而導(dǎo)致核心應(yīng)用 SLO 不達(dá)標(biāo)。
第四，Error Budget 策略，核心應(yīng)用的錯(cuò)誤預(yù)算要共享，就是如果某個(gè)核心應(yīng)用錯(cuò)誤預(yù)算消耗完，SLO 沒(méi)有達(dá)成，那整條鏈路，原則上是要全部暫停操作的，因?yàn)閷?duì)于用戶來(lái)說(shuō)，他不會(huì)判斷是因?yàn)槟膫€(gè)應(yīng)用有問(wèn)題，導(dǎo)致的體驗(yàn)或感受不好。所以，單個(gè)應(yīng)用的錯(cuò)誤預(yù)算消耗完，都要停止變更，等問(wèn)題完全解決再恢復(fù)變更。當(dāng)然，也可以根據(jù)實(shí)際情況適當(dāng)寬松，如果某個(gè)核心應(yīng)用自身預(yù)算充足，且變更不影響核心鏈路功能，也可以按照自己的節(jié)奏繼續(xù)做變更。這一點(diǎn)，你可以根據(jù)業(yè)務(wù)情況自行判斷。
如何驗(yàn)證核心鏈路的 SLO？
梳理出系統(tǒng)的核心鏈路并設(shè)定好 SLO 后，我們需要一些手段來(lái)進(jìn)行驗(yàn)證。一種是容量壓測(cè)，另一種就是 Chaos Engineering，也就是混沌工程。
容量壓測(cè)
我們先來(lái)看容量壓測(cè)。容量壓測(cè)的主要作用，就是看 SLO 中的 Volume，也就是容量目標(biāo)是否可以達(dá)成。對(duì)于一般的業(yè)務(wù)系統(tǒng)，我們都會(huì)用 QPS 和 TPS 來(lái)表示系統(tǒng)容量，得到了容量這個(gè)指標(biāo)，你就可以在平時(shí)觀察應(yīng)用或系統(tǒng)運(yùn)行的容量水位情況。比如，我們?cè)O(shè)定容量的 SLO 是 5000 QPS，如果日常達(dá)到 4500，也就是 SLO 的 90%，我們認(rèn)為這個(gè)水位狀態(tài)下，就要啟動(dòng)擴(kuò)容，提前應(yīng)對(duì)更大的訪問(wèn)流量。
TPS和QPS的區(qū)別：https://blog.csdn.net/a745233700/article/details/117917333
容量壓測(cè)的另一個(gè)作用，就是看在極端的容量場(chǎng)景下，驗(yàn)證我們前面說(shuō)到的限流降級(jí)策略是否可以生效。
我們看上面電商交易的關(guān)鍵路徑圖，以 Detail（商品詳情頁(yè)）和 Comment（商品評(píng)論）這兩個(gè)應(yīng)用之間的弱依賴關(guān)系為例。從弱依賴的原則上講，如果 Comment 出現(xiàn)被調(diào)用次數(shù)過(guò)多超時(shí)或失敗，是不能影響 Detail 這個(gè)核心應(yīng)用的，這時(shí)，我們就要看這兩個(gè)應(yīng)用之間對(duì)應(yīng)的降級(jí)策略是否生效，如果生效業(yè)務(wù)流程是不會(huì)阻塞的，如果沒(méi)有生效，那這條鏈路的成功率就會(huì)馬上降下來(lái)。
另外，還有一種場(chǎng)景，如果某個(gè)非核心應(yīng)用調(diào)用 Detail 的次數(shù)突然激增，對(duì)于 Detail 來(lái)說(shuō)，它自身的限流保護(hù)機(jī)制要發(fā)揮作用，確保自己不會(huì)被外部流量隨意打垮。
Chaos Engineering- 混沌工程
現(xiàn)在混沌功能非常流行，因?yàn)樗梢詭椭覀冏龅皆诰€上模擬真實(shí)的故障，做線上應(yīng)急演練，提前發(fā)現(xiàn)隱患。很多公司都很推崇這種方法并在積極學(xué)習(xí)落地中。
比如對(duì)于機(jī)房故障，有些大廠會(huì)直接模擬斷電這樣的場(chǎng)景，看機(jī)房是否可以切換到雙活或備用機(jī)房；在網(wǎng)絡(luò)層面，我們會(huì)模擬丟包或網(wǎng)卡流量打滿；硬件和系統(tǒng)層面，可能故意把一塊磁盤寫滿，或者把 CPU 跑滿，甚至直接把一個(gè)服務(wù)器重啟；應(yīng)用層面，更多地會(huì)做一些故障注入，比如增加某個(gè)接口時(shí)延，直接返回錯(cuò)誤異常，線程池跑滿，甚至一個(gè)應(yīng)用集群直接下線一半或更多機(jī)器等。
其實(shí)混沌工程也是一個(gè)非常復(fù)雜的系統(tǒng)化工程，因?yàn)橐诰€上制造故障，或多或少都要對(duì)線上業(yè)務(wù)造成影響，如果模擬故障造成的真實(shí)影響超過(guò)了預(yù)估影響，也要能夠快速隔離，并快速恢復(fù)正常業(yè)務(wù)。即使是在穩(wěn)定性體系已經(jīng)非常完善的情況下，對(duì)于混沌工程的實(shí)施也要極為謹(jǐn)慎小心。對(duì)于一個(gè)模擬策略上線實(shí)施，一定是在一個(gè)隔離的環(huán)境中經(jīng)過(guò)了大量反復(fù)驗(yàn)證，包括異常情況下的恢復(fù)預(yù)案實(shí)施，確保影響可控之后，在經(jīng)過(guò)多方團(tuán)隊(duì)評(píng)審或驗(yàn)證，才最終在線上實(shí)施。
混沌工程是 SRE 穩(wěn)定性體系建設(shè)的高級(jí)階段，一定是 SRE 體系在服務(wù)治理、容量壓測(cè)、鏈路跟蹤、監(jiān)控告警、運(yùn)維自動(dòng)化等相對(duì)基礎(chǔ)和必需的部分非常完善的情況下才會(huì)考慮的。
應(yīng)該在什么時(shí)機(jī)做系統(tǒng)驗(yàn)證？
我們有了驗(yàn)證整個(gè)系統(tǒng) SLO 的手段，但是我們可以看到，這兩個(gè)手段都是要在生產(chǎn)系統(tǒng)上直接實(shí)施的，為了保證我們的業(yè)務(wù)正常運(yùn)行，那我們應(yīng)該選擇在什么時(shí)機(jī)，以及什么條件下做系統(tǒng)驗(yàn)證呢？
核心就是錯(cuò)誤預(yù)算充足就可以嘗試，盡量避開(kāi)錯(cuò)誤預(yù)算不足的時(shí)間段。因?yàn)樵谡I(yè)務(wù)下，我們要完成 SLO 已經(jīng)有很大的壓力了，不能再給系統(tǒng)穩(wěn)定性增加新的風(fēng)險(xiǎn)。
同時(shí)，我們還要評(píng)估故障模擬帶來(lái)的影響，比如，是否會(huì)損害到公司收益？是否會(huì)損害用戶體驗(yàn)相關(guān)的指標(biāo)？如果造成的業(yè)務(wù)影響很大，那就要把引入方案進(jìn)行粒度細(xì)化，分步驟，避免造成不可預(yù)估的損失。
團(tuán)隊(duì)通常的做法，就是選擇凌晨，業(yè)務(wù)量相對(duì)較小的情況下做演練。這樣即使出現(xiàn)問(wèn)題，影響面也可控，而且會(huì)有比較充足的時(shí)間執(zhí)行恢復(fù)操作，同時(shí)，在做較大規(guī)模的全站演練前，比如全鏈路的壓測(cè)，會(huì)做單鏈路和單業(yè)務(wù)的單獨(dú)演練，只有單鏈路全部演練通過(guò)，才會(huì)執(zhí)行更大規(guī)模的多鏈路和全鏈路同時(shí)演練。
總之，生產(chǎn)系統(tǒng)的穩(wěn)定性在任何時(shí)候，都是最高優(yōu)先級(jí)要保證的，決不能因?yàn)檠菥殞?dǎo)致系統(tǒng)異常或故障，這也是不被允許的。所以，一定要選擇合適的時(shí)機(jī)，在有充分準(zhǔn)備和預(yù)案的情況下實(shí)施各類驗(yàn)證工作。
故障發(fā)現(xiàn)：如何建設(shè)On-Call機(jī)制？
聚焦 MTTR，故障處理的關(guān)鍵環(huán)節(jié)
故障處理的環(huán)節(jié)就是 MTTR，它又細(xì)分為 4 個(gè)指標(biāo)：MTTI、MTTK、MTTF 和 MTTV，之所以分組分塊，也是為了更加有目的性地做到系統(tǒng)穩(wěn)定性。
故障處理 MTTR 又各自占多長(zhǎng)時(shí)間呢？下面這個(gè) MTTR 的時(shí)長(zhǎng)分布圖，是 IBM 在做了大量的統(tǒng)計(jì)分析之后給出的。
MTTK 部分，也就是故障定位部分的時(shí)長(zhǎng)占比最大。這一點(diǎn)，我們應(yīng)該都會(huì)有一些共鳴，就是絕大部分的故障，往往只要能定位出問(wèn)題出在哪兒了，一般都可以快速地解決故障，慢就慢在不知道問(wèn)題出在哪兒，所以說(shuō)我們大部分時(shí)間都花在尋找問(wèn)題上了。
但是，在一個(gè)分布式的軟件系統(tǒng)下，我們判定一個(gè)問(wèn)題發(fā)生在哪兒，影響范圍到底是怎么樣的，要召集哪些人共同參與定位排查等等，這個(gè)反而會(huì)消耗更多時(shí)間，所以我們看到 MTTI 階段占比會(huì)更重。
另外，當(dāng)一個(gè)分布式系統(tǒng)發(fā)生故障時(shí)，我們的策略一定不是找到根因，而是優(yōu)先恢復(fù)業(yè)務(wù)。所以，我們往往是通過(guò)故障隔離的方式，先快速恢復(fù)業(yè)務(wù)，也就是我們經(jīng)常聽(tīng)到的 Design for Failure 這樣的策略，再具體一點(diǎn)，就是服務(wù)限流、降級(jí)、熔斷甚至是主備切換這樣的手段，這樣的話，MTTK 的占比會(huì)有所下降。
因此，從分布式系統(tǒng)的實(shí)際情況來(lái)看，整個(gè) MTTR 的時(shí)間占比分布大致是這樣的：
MTTI：從發(fā)現(xiàn)故障到響應(yīng)故障
MTTI，就是故障的平均確認(rèn)時(shí)間，也就是從故障實(shí)際發(fā)生時(shí)間點(diǎn)，到觸發(fā)采取實(shí)際行動(dòng)去定位前的這段時(shí)間。
這個(gè)環(huán)節(jié)其實(shí)主要有兩件事情要做：第一件事，判斷出現(xiàn)的問(wèn)題是不是故障；第二件事，確定由誰(shuí)來(lái)響應(yīng)和召集。
在沒(méi)有 SLO 和錯(cuò)誤預(yù)算這個(gè)體系時(shí)，我們通常會(huì)根據(jù)用戶投訴，或客服對(duì)同一問(wèn)題的重復(fù)反饋來(lái)判斷。比如 10 分鐘內(nèi)，有超過(guò) 50 個(gè)用戶投訴無(wú)法購(gòu)買商品、支付不成功或者優(yōu)惠券未生效等問(wèn)題，我們就會(huì)啟動(dòng)應(yīng)急響應(yīng)。不過(guò)，一旦等用戶和客服反饋，就說(shuō)明故障影響已經(jīng)非常惡劣了，用戶也已經(jīng)處于無(wú)法忍受的狀態(tài)了。
顯然這種方式并不高效。既然我們已經(jīng)搭建了 SRE 體系，設(shè)定了 SLO，能對(duì)穩(wěn)定性進(jìn)行量化管理，那我們就能比用戶更快發(fā)現(xiàn)問(wèn)題并響應(yīng)問(wèn)題了。至于用戶投訴和客服反饋的渠道，只能是作為我們的輔助手段。
所以，我們可以根據(jù)設(shè)定的 SLO 和錯(cuò)誤預(yù)算，準(zhǔn)確判斷發(fā)生的問(wèn)題是否是故障，并依據(jù)故障等級(jí)決定我們采取什么樣的措施去處理這些問(wèn)題，大大提高反應(yīng)效率。
接著來(lái)看第二件事，誰(shuí)來(lái)響應(yīng)和召集。這件事很容易理解，如果我們判定這個(gè)問(wèn)題就是一個(gè)故障，首先要有人能判定，接下來(lái)需要哪些人來(lái)介入，并能夠把相關(guān)的人員召集起來(lái)，一起來(lái)處理故障。
這兩件事，其實(shí)就是 SRE 里面提到的 On-Call 機(jī)制。
我們可以看到，第一件事其實(shí)主要依賴于我們的監(jiān)控和告警體系。這里我想再?gòu)?qiáng)調(diào)一下，在 On-Call 階段，并不是所有的告警我們都要響應(yīng)，如果不影響穩(wěn)定性，一般的告警是可以降低響應(yīng)級(jí)別的，我們只需要響應(yīng)基于 SLO 的告警。
On-Call 的流程機(jī)制建設(shè)
1.確保關(guān)鍵角色在線。
這里的關(guān)鍵角色不是指一兩個(gè)值班的運(yùn)維或 SRE 人員，而是整個(gè)產(chǎn)品體系中的所有關(guān)鍵角色。比如電商就需要安排核心業(yè)務(wù)應(yīng)用（如用戶、商品、交易、優(yōu)惠及支付等）的 Owner，或 Backup 中至少有一人參與 On-Call 輪班。不過(guò)，接收故障告警或第一時(shí)間響應(yīng)故障的，一般是運(yùn)維、PE 或 SRE 這樣的角色，業(yè)務(wù)開(kāi)發(fā)同事要確保及時(shí)響應(yīng) SRE 發(fā)起的故障應(yīng)急。
2.組織 War Room 應(yīng)急組織。
有專門處理故障的“消防群”（暗含著滅火的意思），會(huì)將這些關(guān)鍵角色納入其中，當(dāng)有故障發(fā)生時(shí)會(huì)第一時(shí)間在消防群通報(bào)，這時(shí)對(duì)應(yīng)的 On-Call 同事就要第一時(shí)間最高優(yōu)先級(jí)響應(yīng)呼叫（Page）。如果是工作日，對(duì)于嚴(yán)重故障，會(huì)立刻組織成立 War Room，責(zé)任人會(huì)馬上聚到一起；如果是非工作時(shí)間，則會(huì)通過(guò)電話會(huì)議的方式拉起虛擬 War Room。
3.建立合理的呼叫方式。
在 On-Call 的落地過(guò)程中，我們經(jīng)常會(huì)遇到的一種情況，就是誰(shuí)最熟悉某個(gè)系統(tǒng)，誰(shuí)就最容易被 7*24 小時(shí)打擾。比如系統(tǒng)或應(yīng)用的 Owner 或者是架構(gòu)師，出現(xiàn)問(wèn)題的時(shí)候一定是找這些同事處理的效率最高，所以就會(huì)造成這些同事被默認(rèn)為 On-Call。
但是這樣做會(huì)極大地影響這些同事在正常業(yè)務(wù)開(kāi)發(fā)上的精力投入。他們要么總是被打斷，要么就是經(jīng)常通宵處理問(wèn)題，導(dǎo)致第二天無(wú)法正常工作，甚至在非工作日也得不到正常的休息。
這種情況下，我們建議使用固定的 On-Call 手機(jī)，建立手機(jī)與所有 On-Call 系統(tǒng)的對(duì)應(yīng)關(guān)系，比如這個(gè)手機(jī)號(hào)碼對(duì)應(yīng)交易核心應(yīng)用，另一個(gè)號(hào)碼對(duì)應(yīng) IDC 機(jī)房運(yùn)維等等。這樣我們?cè)?On-Call 時(shí)就不再找具體的哪個(gè)人，而是手機(jī)在誰(shuí)手中，誰(shuí)就承擔(dān) On-Call 職責(zé)。除非問(wèn)題遲遲得不到解決，或者遇到了疑難雜癥，這種時(shí)候再呼叫其他同事參與進(jìn)來(lái)。
無(wú)論是 SRE、架構(gòu)師，還是一線開(kāi)發(fā)，**熟悉某個(gè)系統(tǒng)的最快最好的方式就是參與 On-Call，而不是看架構(gòu)圖和代碼。**所以，有效的 On-Call 機(jī)制，可以讓團(tuán)隊(duì)更深刻地認(rèn)識(shí)到目前系統(tǒng)的存在哪些問(wèn)題，對(duì)自己的痛苦狀態(tài)也會(huì)有更深刻的感受，進(jìn)而對(duì)后面的改進(jìn)措施才能更有針對(duì)性和落地性。同時(shí)，On-Call 也可以培養(yǎng)和鍛煉新人和 Backup 角色，這也是讓新人盡快融入團(tuán)隊(duì)和承擔(dān)責(zé)任的最好的方式。
4.確保資源投入的升級(jí)機(jī)制。
這個(gè)跟前面幾條有相關(guān)性，有很多團(tuán)隊(duì)認(rèn)為 On-Call 就是設(shè)置幾個(gè)人值班，所有的事情都交給這幾個(gè)人做；最極端的還會(huì)認(rèn)為所有的事情，都應(yīng)該是沖在最前線的運(yùn)維或 SRE 來(lái)完成。但是，在分布式架構(gòu)這種復(fù)雜場(chǎng)景下，這種思路是明顯不可行的。
這里最核心的一點(diǎn)就是要給到運(yùn)維和 SRE 授權(quán)，當(dāng)他發(fā)現(xiàn)問(wèn)題不是自己或現(xiàn)有 On-Call 人員能解決的時(shí)候，他有權(quán)調(diào)動(dòng)其他必要資源投入。如果故障等級(jí)偏高，一下無(wú)法明確具體找哪些人員投入的時(shí)候，SRE 或運(yùn)維可以直接上升到自己的主管或相關(guān)主管那里，要求上級(jí)主管協(xié)調(diào)資源投入。必要時(shí)，還可以上升到更高級(jí)主管，甚至 CTO 或技術(shù) VP 來(lái)關(guān)注。所以，授權(quán)非常關(guān)鍵，這一點(diǎn)的具體操作層面，我們會(huì)在后面的故障處理過(guò)程中再詳細(xì)介紹。
5.與云廠商聯(lián)合的 On-Call。
現(xiàn)在企業(yè)上云是大勢(shì)所趨，絕大多數(shù)情況下，我們對(duì)問(wèn)題和故障的處理，是離不開(kāi)與云產(chǎn)品工程師一起高效聯(lián)動(dòng)的。所以，我們應(yīng)該把云產(chǎn)品和云廠商作為我們系統(tǒng)的一部分，而不是單純的第三方。而對(duì)于云廠商來(lái)說(shuō)，也要考慮把客戶業(yè)務(wù)作為自身業(yè)務(wù)的一部分，只有這樣雙方才能緊密合作。我們應(yīng)該提前做好與云廠商之間的協(xié)作磨合，聯(lián)合故障演練，必要的授權(quán)等等。
故障處理：一切以恢復(fù)業(yè)務(wù)為最高優(yōu)先級(jí)
如何建立有效的故障應(yīng)急響應(yīng)機(jī)制
比如雙十一這樣的大促活動(dòng)，團(tuán)隊(duì)的做法一般是空出一個(gè)樓層，讓所有參與保障的同事坐在一個(gè)樓層辦公。在已經(jīng)形成雙十一文化的阿里，他們把這樣的辦公地點(diǎn)稱為“光明頂”，各大高手齊聚于此，共同保障業(yè)務(wù)和系統(tǒng)穩(wěn)定。
僅僅有 War Room 這樣一個(gè)聚集形式還是不夠的，既然我們把解決故障類比成戰(zhàn)爭(zhēng)，我們就一定要有一套相對(duì)應(yīng)的指揮體系才可以，這個(gè)體系里面，我認(rèn)為最重要的就是“關(guān)鍵角色分工”和“溝通機(jī)制”。
關(guān)鍵角色分工：
Incident Commander，故障指揮官，簡(jiǎn)稱為 IC。這個(gè)角色是整個(gè)指揮體系的核心，他最重要的職責(zé)是組織和協(xié)調(diào)，而不是執(zhí)行，下面所有的角色都要接受他的指令并嚴(yán)格執(zhí)行。
**Communication Lead，溝通引導(dǎo)，簡(jiǎn)稱 CL。**負(fù)責(zé)對(duì)內(nèi)和對(duì)外的信息收集及通報(bào)，這個(gè)角色一般相對(duì)固定，由技術(shù)支持、QA 或者是某個(gè) SRE 來(lái)承擔(dān)都可以，但是要求溝通表達(dá)能力要比較好。
**Operations Lead，運(yùn)維指揮，簡(jiǎn)稱 OL。**負(fù)責(zé)指揮或指導(dǎo)各種故障預(yù)案的執(zhí)行和業(yè)務(wù)恢復(fù)。
這里其實(shí)還有一類角色，雖然不在指揮體系內(nèi)，但是也非常重要，我們也要做一下介紹：Incident Responders，簡(jiǎn)稱 IR。就是所有需要參與到故障處理中的各類人員，真正的故障定位和業(yè)務(wù)恢復(fù)都是他們來(lái)完成的，比如具體執(zhí)行的 SRE、網(wǎng)絡(luò)和系統(tǒng)運(yùn)維、業(yè)務(wù)開(kāi)發(fā)、平臺(tái)開(kāi)發(fā)、網(wǎng)絡(luò)或系統(tǒng)運(yùn)維、DBA，甚至是 QA 等。
流程機(jī)制
從我們的實(shí)踐經(jīng)驗(yàn)來(lái)看，如果是大范圍的故障，一般就是平臺(tái)技術(shù)總監(jiān)或電商業(yè)務(wù)的技術(shù)總監(jiān)來(lái)承擔(dān) IC 職責(zé)，接下來(lái)他就可以從更高的層面組織和協(xié)調(diào)資源投入并有效協(xié)作。這時(shí) SRE 會(huì)回歸到 OL 的職責(zé)上，負(fù)責(zé)組織和協(xié)調(diào)具體的執(zhí)行恢復(fù)操作的動(dòng)作。
反饋機(jī)制
沒(méi)有進(jìn)展也是進(jìn)展，也要及時(shí)反饋。比如 10 分鐘之內(nèi)還沒(méi)定位結(jié)果，可能我們就會(huì)選擇做有損的降級(jí)服務(wù)，不能讓故障持續(xù)蔓延，這個(gè)時(shí)候，反饋就顯得尤為重要。
同時(shí)，在這個(gè)過(guò)程中，為了盡量減少對(duì)執(zhí)行者的干擾，讓執(zhí)行者能夠更聚焦，我們一般要求團(tuán)隊(duì) Leader 來(lái)收集反饋并傳遞 IC 的指令。CL 也要收集信息，他要做的不是傳達(dá)指令，而是在更大范圍內(nèi)同步匯總后的信息，同時(shí)還要整理信息傳遞給外部聯(lián)系人。
故障復(fù)盤：黃金三問(wèn)與判定三原則
故障復(fù)盤黃金三問(wèn)：
第一問(wèn)：故障原因有哪些？
第二問(wèn)：我們做什么，怎么做才能確保下次不會(huì)再出現(xiàn)類似故障？
第三問(wèn)：當(dāng)時(shí)如果我們做了什么，可以用更短的時(shí)間恢復(fù)業(yè)務(wù)？
具體開(kāi)復(fù)盤會(huì)的時(shí)候，就是緊扣著這三問(wèn)來(lái)進(jìn)行的。除此之外不允許出現(xiàn)相互指責(zé)和埋怨的情況，如果出現(xiàn)，會(huì)議主持者要及時(shí)控制并打斷。會(huì)議主持者這個(gè)角色，一般情況下，跟我們上一講提到的 CL（Communication Lead），也就是“溝通引導(dǎo)”是一個(gè)角色，在公司內(nèi)部叫技術(shù)支持。
故障判定的三原則
通過(guò)黃金三問(wèn)，我們找到了故障發(fā)生的原因，也明確了做什么可以優(yōu)化，那接下來(lái)就是落地了。要落地，就要明確到底應(yīng)該由誰(shuí)來(lái)承擔(dān)主要的改進(jìn)職責(zé)。注意，這里我沒(méi)有用誰(shuí)應(yīng)該承擔(dān)主要責(zé)任，而是承擔(dān)主要的改進(jìn)職責(zé)，也就是由誰(shuí)來(lái)執(zhí)行改進(jìn)措施。
這個(gè)原則是說(shuō)每個(gè)部件自身要具備一定的自愈能力，比如主備、集群、限流、降級(jí)和重試等等。例如，在 B 依賴 A 的狀態(tài)下，被依賴方 A 出現(xiàn)問(wèn)題，但是能夠快速恢復(fù)，而依賴方 B 無(wú)法快速恢復(fù)，導(dǎo)致故障蔓延。這時(shí)，承擔(dān)主要責(zé)任的是依賴方 B，而不是被依賴方 A。
服務(wù)器和網(wǎng)絡(luò)類故障，其實(shí)就適用這個(gè)原則。如交換機(jī)故障發(fā)生主備切換導(dǎo)致的網(wǎng)絡(luò)瞬時(shí)或短暫抖動(dòng)，從網(wǎng)絡(luò)設(shè)備這個(gè)組件來(lái)說(shuō)，自身是有自愈能力的，而且在極短的時(shí)間內(nèi)就可以恢復(fù)。如果應(yīng)用因?yàn)槎秳?dòng)而失敗、無(wú)法自愈，這種情況，業(yè)務(wù)應(yīng)用就不能以服務(wù)器或網(wǎng)絡(luò)故障為理由，不承擔(dān)改進(jìn)職責(zé)。
再比如，我們之前講的強(qiáng)弱依賴問(wèn)題。原則上，核心應(yīng)用對(duì)非核心應(yīng)用的依賴必須要有降級(jí)和限流手段。如果因?yàn)榉呛诵膽?yīng)用的故障或者瞬時(shí)高并發(fā)訪問(wèn)，導(dǎo)致核心應(yīng)用故障，這種情況下，主要的改進(jìn)責(zé)任在核心應(yīng)用，非核心應(yīng)用只需要配合改造。
如果使用到了第三方的服務(wù)，如公有云的各類服務(wù)，包括 IaaS、PaaS、CDN 以及視頻等等，我們的原則就是默認(rèn)第三方無(wú)責(zé)。
這種涉及第三方服務(wù)的情況，在判定改進(jìn)責(zé)任時(shí)會(huì)分為兩部分，對(duì)內(nèi)誰(shuí)的服務(wù)受影響誰(shuí)改進(jìn)，并對(duì)外推進(jìn)第三方改進(jìn)，但是一定要按照我們之前講的，穩(wěn)定性一定要做到相對(duì)自我可控，而不是完全依賴外部。
比如，一個(gè)應(yīng)用使用了 CDN 服務(wù)，如果一家 CDN 廠商服務(wù)出現(xiàn)問(wèn)題，要做到隨時(shí)可以切換到另外一到兩家，這時(shí)就不能以某家 CDN 服務(wù)故障為由不做改進(jìn)。如果用到了云存儲(chǔ)，如 S3、OSS 或 COS 這樣的服務(wù)，一定要保證存儲(chǔ)有主備，當(dāng)一個(gè)區(qū)域有問(wèn)題時(shí)，也要做到可切換，甚至容忍一定的業(yè)務(wù)有損，但是必須保障全量沒(méi)有大問(wèn)題。
如果再提升下高可用視角，就要考慮做到雙活或多活，單個(gè) Zone 甚至單個(gè) Region 出現(xiàn)問(wèn)題時(shí)，也能做到切換。
對(duì)內(nèi)，默認(rèn)第三方無(wú)責(zé)，穩(wěn)定性責(zé)任一定是內(nèi)部角色承擔(dān)，這樣做有時(shí)看起來(lái)雖然不太合理，但這樣做的目的，就是讓內(nèi)部意識(shí)到穩(wěn)定性和高可用一定是我們自己的責(zé)任，決不能依賴任何一個(gè)第三方。這就相當(dāng)于一個(gè)國(guó)家的軍事國(guó)防，可以跟外部形成統(tǒng)一戰(zhàn)線，可以做聯(lián)合演習(xí)共同防御，但是絕不可能完完全全交給另外一個(gè)國(guó)家去建設(shè)和控制。
這個(gè)原則主要應(yīng)用在情況比較復(fù)雜的場(chǎng)景。當(dāng)發(fā)生衍生故障，或者故障蔓延的原因與觸發(fā)原因不同時(shí)，我們會(huì)將一次故障分段判斷。這樣分段判定會(huì)讓故障問(wèn)題更聚焦，改進(jìn)措施也會(huì)更有針對(duì)性。
案例：互聯(lián)網(wǎng)典型的SRE組織架構(gòu)是怎樣的？
這是蘑菇街基于微服務(wù)和分布式技術(shù)的 High-Level 的架構(gòu)圖，也是非常典型的互聯(lián)網(wǎng)技術(shù)架構(gòu)圖，自下而上共四層，分別是基礎(chǔ)設(shè)施層、業(yè)務(wù) & 技術(shù)中臺(tái)層、業(yè)務(wù)前臺(tái)層以及接入層，在右側(cè)還有一個(gè)技術(shù)保障體系。
在講 SRE 的組織架構(gòu)之前，我們需要先明確兩點(diǎn)內(nèi)容。
第一，組織架構(gòu)要與技術(shù)架構(gòu)相匹配。
技術(shù)架構(gòu)實(shí)現(xiàn)組織目標(biāo)，組織架構(gòu)服務(wù)并促成技術(shù)架構(gòu)的實(shí)現(xiàn)，所以，我們不會(huì)單純?nèi)ブv組織架構(gòu)，一定會(huì)結(jié)合著技術(shù)架構(gòu)的現(xiàn)狀和演進(jìn)過(guò)程來(lái)分析。
第二，SRE 是微服務(wù)和分布式架構(gòu)的產(chǎn)物。
SRE 這個(gè)崗位，或者說(shuō)這個(gè)通過(guò)最佳實(shí)踐提煉出來(lái)的方法論，就是在 Google 這樣一個(gè)全球最大的應(yīng)用分布式技術(shù)的公司產(chǎn)生出來(lái)的。
正是因?yàn)榉植际郊夹g(shù)的復(fù)雜性，特別是在運(yùn)維層面的超高復(fù)雜性，才產(chǎn)生了對(duì)傳統(tǒng)運(yùn)維模式和理念的沖擊和變革。
如果我們?nèi)ナ崂硪幌抡麄€(gè)軟件架構(gòu)發(fā)展的歷程，就可以得到下面這張圖。我們會(huì)發(fā)現(xiàn)不僅僅是 SRE 和 DevOps，就連容器相關(guān)的技術(shù)，持續(xù)交付相關(guān)的方法和理念，也是在微服務(wù)架構(gòu)不斷流行的趨勢(shì)下所產(chǎn)生的，它們的產(chǎn)生就是為了解決在這種架構(gòu)下運(yùn)維復(fù)雜度過(guò)高的問(wèn)題。
這樣一套架構(gòu)方法體系，也構(gòu)成了現(xiàn)在非常流行和火熱的概念：云原生架構(gòu)。
基本所有的 SRE 經(jīng)驗(yàn)都是基于微服務(wù)和分布式架構(gòu)的，也都是在這樣一個(gè)基礎(chǔ)下產(chǎn)生的。**想要引入 SRE 體系，并做對(duì)應(yīng)的組織架構(gòu)調(diào)整，首先要看我們的技術(shù)架構(gòu)是不是在朝著服務(wù)化和分布式的方向演進(jìn)。**如果架構(gòu)還沒(méi)這么復(fù)雜，其實(shí)也沒(méi)有必要引入 SRE 這么復(fù)雜的運(yùn)維體系，這本身就不匹配；再就是如果沒(méi)有對(duì)應(yīng)的架構(gòu)支持，SRE 技術(shù)層面的建設(shè)就沒(méi)有切入點(diǎn)，想做也沒(méi)法做。
總的來(lái)說(shuō)，如果我們的技術(shù)架構(gòu)朝著微服務(wù)和分布式的方向演進(jìn)，那我們可以考慮落地 SRE，這時(shí)候，我們的組織架構(gòu)就要匹配我們的技術(shù)架構(gòu)，也就是說(shuō)，要想在組織內(nèi)引入并落地 SRE 這套體系，原有技術(shù)團(tuán)隊(duì)的組織架構(gòu)，或者至少是協(xié)作模式必須要做出一些變革才可以。
蘑菇街的 SRE 組織架構(gòu)實(shí)踐
先看最下面的基礎(chǔ)設(shè)施層，我們現(xiàn)在也定義為 IaaS 層，主要是以資源為主，包括 IDC、服務(wù)器、虛擬機(jī)、存儲(chǔ)以及網(wǎng)絡(luò)等部分。
這里基礎(chǔ)設(shè)施層和所需的運(yùn)維能力，其實(shí)就是我們常說(shuō)的傳統(tǒng)運(yùn)維這個(gè)角色所要具備的能力。但是這一層現(xiàn)在對(duì)于絕大多數(shù)的公司，無(wú)論在資源層面還是在能力層面，都有很大的可替代性。如果能夠依托云的能力，不管是公有云還是私有云，這一部分傳統(tǒng)運(yùn)維的能力在絕大部分公司，基本就不需要了。
接下來(lái)往上，我們來(lái)看中臺(tái)這一層。這里包括兩部分，技術(shù)中臺(tái)和業(yè)務(wù)中臺(tái)。
技術(shù)中臺(tái)主要包括我們使用到的各種分布式部件，如緩存、消息、數(shù)據(jù)庫(kù)、對(duì)象存儲(chǔ)以及大數(shù)據(jù)等產(chǎn)品，這一層最大的特點(diǎn)就是“有狀態(tài)” ，也就是要存儲(chǔ)數(shù)據(jù)的產(chǎn)品。
業(yè)務(wù)中臺(tái)層，就是將具有業(yè)務(wù)共性的產(chǎn)品能力提煉出來(lái)，比如用戶、商品、交易、支付、風(fēng)控以及優(yōu)惠等等，上面支撐的是業(yè)務(wù)前臺(tái)應(yīng)用。
什么是業(yè)務(wù)前臺(tái)呢？如果以阿里的產(chǎn)品體系來(lái)舉例，可以類比為淘寶、天貓、盒馬、聚劃算這樣的業(yè)務(wù)產(chǎn)品。
無(wú)論這些業(yè)務(wù)前臺(tái)的形態(tài)是什么樣，但是都會(huì)利用到中臺(tái)這些共享能力。這兩層就是微服務(wù)化形態(tài)的業(yè)務(wù)應(yīng)用了，這些應(yīng)用最大的特點(diǎn)就是“無(wú)狀態(tài)”，有狀態(tài)的數(shù)據(jù)都會(huì)沉淀到剛才提到的技術(shù)中臺(tái)的產(chǎn)品中。
最上面是接入層，分為四層負(fù)載均衡和七層負(fù)載均衡。前者因?yàn)楦鷺I(yè)務(wù)邏輯不相關(guān)，所以通常會(huì)跟基礎(chǔ)設(shè)施層放在一起，由傳統(tǒng)運(yùn)維負(fù)責(zé)。但是七層負(fù)載需要做很多業(yè)務(wù)層面的規(guī)則配置，所以通常會(huì)跟中臺(tái)和前臺(tái)一起運(yùn)維。
業(yè)務(wù)中臺(tái)和前臺(tái)這兩層的運(yùn)維職責(zé)，通常就是我們常說(shuō)的應(yīng)用運(yùn)維、PE（Production Engineer）或者叫技術(shù)運(yùn)營(yíng)這樣的角色來(lái)承擔(dān)。團(tuán)隊(duì)是統(tǒng)一用 PE 來(lái)代表的。
其實(shí)這里 PE 的職責(zé)跟我們前面講的 SRE 的職責(zé)已經(jīng)非常接近了。在國(guó)內(nèi)，PE 這個(gè)角色與 Google 定義的 SRE 所具備的能力，最大差別就在于國(guó)內(nèi) PE 的軟件工程能力有所缺失或相對(duì)較弱。這就導(dǎo)致很多基于技術(shù)中臺(tái)的自動(dòng)化工具、服務(wù)治理以及穩(wěn)定性保障類的平臺(tái)沒(méi)辦法自己研發(fā)，需要由另外一個(gè)團(tuán)隊(duì)來(lái)支撐和彌補(bǔ)，也就是圖中技術(shù)中臺(tái)的衍生部分，技術(shù)保障體系。
技術(shù)保障平臺(tái)，這部分的能力一定基于技術(shù)中臺(tái)的能力之上生長(zhǎng)出來(lái)的，是技術(shù)中臺(tái)的一部分，如果脫離了這個(gè)架構(gòu)體系，這個(gè)技術(shù)保障體系是沒(méi)有任何意義的。“運(yùn)維能力一定是整個(gè)技術(shù)架構(gòu)能力的體現(xiàn)，而不是單純的運(yùn)維的運(yùn)維能力體現(xiàn)”。微服務(wù)和分布式架構(gòu)下的運(yùn)維能力，一定是跟整個(gè)架構(gòu)體系不分家的。
回到技術(shù)保障體系的建設(shè)上，我們看下架構(gòu)圖的右側(cè)，它又分為效率和穩(wěn)定兩塊。
工具平臺(tái)團(tuán)隊(duì)，負(fù)責(zé)效能工具的研發(fā)，比如實(shí)現(xiàn) CMDB、運(yùn)維自動(dòng)化、持續(xù)交付流水線以及部分技術(shù)運(yùn)營(yíng)報(bào)表的實(shí)現(xiàn)，為基礎(chǔ)運(yùn)維和應(yīng)用運(yùn)維提供效率平臺(tái)支持。
這個(gè)要更多地介入到研發(fā)流程中，因?yàn)榱鞒虖?fù)雜度比較高，而且還要對(duì)接很多研發(fā)平臺(tái)，如 Git、Maven、代碼掃描、自動(dòng)化測(cè)試以及安全等平臺(tái)，所以對(duì)業(yè)務(wù)理解及系統(tǒng)集成能力要比較強(qiáng)，但是技術(shù)能力要求相對(duì)就沒(méi)那么高。
穩(wěn)定性平臺(tái)團(tuán)隊(duì)，負(fù)責(zé)穩(wěn)定性保障相關(guān)的標(biāo)準(zhǔn)和平臺(tái)，比如監(jiān)控、服務(wù)治理相關(guān)的限流降級(jí)、全鏈路跟蹤、容量壓測(cè)和規(guī)劃。我們會(huì)看到這個(gè)團(tuán)隊(duì)主要是為穩(wěn)定性保障提供支撐，平臺(tái)提供出來(lái)的能力是可以直接支撐業(yè)務(wù)開(kāi)發(fā)團(tuán)隊(duì)的，反倒是 PE 這樣的角色并不會(huì)直接使用。
這個(gè)團(tuán)隊(duì)和人員的技術(shù)能力要求會(huì)比較高，因?yàn)檫@里面很多的技術(shù)點(diǎn)是要深入到代碼底層的，比如 Java 的字節(jié)碼或 Socket 網(wǎng)絡(luò)；有時(shí)還要面對(duì)海量數(shù)據(jù)，以及低時(shí)延實(shí)時(shí)計(jì)算的處理，比如全鏈路跟蹤和監(jiān)控；甚至是門檻更高的 AIOps，還要懂專業(yè)算法。所以這個(gè)團(tuán)隊(duì)的建設(shè)復(fù)雜度會(huì)比較高，會(huì)需要很多不同領(lǐng)域的專業(yè)人員。
如果我們用一張組織架構(gòu)圖來(lái)展示的話，基本形態(tài)就是下圖：
SRE 并不是一個(gè)單純的崗位定義，它是由多個(gè)不同角色組合而成的一個(gè)團(tuán)隊(duì)。如果從分工來(lái)看就是：
SRE = PE + 工具平臺(tái)開(kāi)發(fā) + 穩(wěn)定性平臺(tái)開(kāi)發(fā)
同時(shí)，這里的 SRE，跟我們前面講的運(yùn)維和架構(gòu)不分家一樣，在組織架構(gòu)上，是與承擔(dān)技術(shù)中臺(tái)或分布式架構(gòu)建設(shè)的中間件團(tuán)隊(duì)在同一個(gè)體系中的。
組織架構(gòu)往往是與技術(shù)架構(gòu)相匹配的，技術(shù)上如果朝著分布式和微服務(wù)架構(gòu)的方向演進(jìn)，那必然會(huì)產(chǎn)生出類似的組織模式。
經(jīng)驗(yàn)：都有哪些高效的SRE組織協(xié)作機(jī)制？
在互聯(lián)網(wǎng)企業(yè)典型的 SRE 團(tuán)隊(duì)中，一般包含幾個(gè)關(guān)鍵角色，PE、工具開(kāi)發(fā)和穩(wěn)定性開(kāi)發(fā)，他們分別承擔(dān)的職責(zé)就是業(yè)務(wù)運(yùn)維、建設(shè)運(yùn)維自動(dòng)化平臺(tái)和建設(shè)穩(wěn)定性平臺(tái)。在建設(shè)這些平臺(tái)的過(guò)程中，這些角色對(duì)內(nèi)要與中間件團(tuán)隊(duì)合作，基于微服務(wù)和分布式的架構(gòu)來(lái)開(kāi)發(fā)各類平臺(tái)；對(duì)外，還要與業(yè)務(wù)開(kāi)發(fā)配合，將提升效率和穩(wěn)定性的能力提供出去。
但是僅僅有組織架構(gòu)，有了隊(duì)形還是不夠的，各個(gè)團(tuán)隊(duì)和角色之間必須要配合協(xié)作起來(lái)才能發(fā)揮出 SRE 的作用，特別是對(duì)外與業(yè)務(wù)開(kāi)發(fā)的合作，這樣才能是一個(gè)有機(jī)的整體。
以賽帶練
類似的場(chǎng)景，比如說(shuō)極端的海量用戶訪問(wèn)，像電商類產(chǎn)品的雙十一大促、社交類產(chǎn)品在春晚的搶紅包，以及媒體類產(chǎn)品的突發(fā)熱點(diǎn)新聞等等，用戶瞬時(shí)訪問(wèn)的流量是極大的，對(duì)于系統(tǒng)的穩(wěn)定性沖擊和挑戰(zhàn)也就非常大。再或者，是極端的故障場(chǎng)景，比如機(jī)房斷電、存儲(chǔ)故障或核心部件失效等等。
所以，我們講穩(wěn)定性建設(shè)，一定也是針對(duì)極端場(chǎng)景下的穩(wěn)定性建設(shè)。
其實(shí)我們有很多的穩(wěn)定性保障技術(shù)和理念，比如容量規(guī)劃和壓測(cè)、全鏈路跟蹤、服務(wù)治理、同城雙活甚至是異地多活等，基本都是在這些場(chǎng)景下催生出來(lái)的，甚至是被倒逼出來(lái)的。
“以賽帶練”的目的就是要檢驗(yàn)我們的系統(tǒng)穩(wěn)定性狀況到底如何，我們的系統(tǒng)穩(wěn)定性還有哪些薄弱點(diǎn)。
SRE 的各個(gè)角色如何協(xié)作？
第一步，大促項(xiàng)目開(kāi)工會(huì)。
在這個(gè)會(huì)議上，我們會(huì)明確業(yè)務(wù)指標(biāo)，指定大促項(xiàng)目的技術(shù)保障負(fù)責(zé)人，通常由經(jīng)驗(yàn)豐富的業(yè)務(wù)技術(shù)成員或平臺(tái)技術(shù)成員承擔(dān)，同時(shí)會(huì)明確技術(shù)團(tuán)隊(duì)的分工以及各個(gè)團(tuán)隊(duì)的接口人，然后根據(jù)大促日期，倒排全鏈路壓測(cè)計(jì)劃。分工和計(jì)劃敲定了，接下來(lái)就是一步步執(zhí)行了。
第二步，業(yè)務(wù)指標(biāo)分解及用戶模型分析評(píng)審會(huì)。
業(yè)務(wù)指標(biāo)分解和用戶模型分析階段，需要業(yè)務(wù)開(kāi)發(fā)和 PE 團(tuán)隊(duì)共同配合，主要是共同分析出核心鏈路，同時(shí) PE 要分析鏈路上的應(yīng)用日常運(yùn)行情況，特別是 QPS 水位，這里就要利用到我們前面 03 講中示例的 SLO 的 Dashboard，結(jié)合這兩點(diǎn)，大致判斷出要擴(kuò)容的資源需求。
每個(gè) PE 是要負(fù)責(zé)一整條核心鏈路上的應(yīng)用的，所以 PE 可以識(shí)別出更全局的鏈路以及整條鏈路上的容量水位情況。而每位業(yè)務(wù)開(kāi)發(fā)往往只專注在某幾個(gè)應(yīng)用上，所以他可以把業(yè)務(wù)目標(biāo)拆解得更細(xì)致，并轉(zhuǎn)化成 QPS 和 TPS 容量要求，然后分配到一個(gè)個(gè)具體應(yīng)用上，并且每個(gè)應(yīng)用的 Owner 在后面要確保這些應(yīng)用能夠滿足各自的 QPS 和 TPS 容量要求。
PE 會(huì)更多地從全局角度關(guān)注線上真實(shí)的運(yùn)行狀態(tài)，而業(yè)務(wù)開(kāi)發(fā)則根據(jù)這些信息做更細(xì)致的分析，甚至是深入到代碼層面的分析。
同時(shí)，業(yè)務(wù)開(kāi)發(fā)和 PE 在分析的時(shí)候，就要使用到穩(wěn)定性開(kāi)發(fā)團(tuán)隊(duì)提供的全鏈路跟蹤和監(jiān)控平臺(tái)了，而不是靠手工提取日志來(lái)做統(tǒng)計(jì)分析。
接下來(lái)，根據(jù)容量評(píng)估的結(jié)果，由 PE 準(zhǔn)備擴(kuò)容資源，然后業(yè)務(wù)開(kāi)發(fā)的應(yīng)用 Owner，通過(guò)運(yùn)維自動(dòng)化平臺(tái)，做完全自動(dòng)化的應(yīng)用部署和服務(wù)上線即可，整個(gè)過(guò)程無(wú)需 PE 介入。
第三步，應(yīng)急預(yù)案評(píng)審會(huì)。
在預(yù)案準(zhǔn)備階段，仍然是 PE 與業(yè)務(wù)開(kāi)發(fā)配合，針對(duì)核心鏈路和核心應(yīng)用做有針對(duì)性的預(yù)案討論。這時(shí)就要細(xì)化到接口和方法上，看是否準(zhǔn)備好限流、降級(jí)和熔斷策略，策略有了還要討論具體的限流值是多少、降級(jí)和熔斷的具體條件是怎樣的，最后這些配置值和配置策略都要落到對(duì)應(yīng)的穩(wěn)定性配置中心管理起來(lái)。
這里 PE 更多地是負(fù)責(zé)平臺(tái)級(jí)的策略，比如，如果出現(xiàn)流量激增，首先要做的就是在接入層 Nginx 做限流，并發(fā) QPS 值要設(shè)定為多少合適；再比如緩存失效是否要降級(jí)到數(shù)據(jù)庫(kù)，如果降級(jí)到數(shù)據(jù)庫(kù)，必然要降低訪問(wèn) QPS，降低多少合適，等等。
而業(yè)務(wù)開(kāi)發(fā)則要更多地考慮具體業(yè)務(wù)邏輯上的策略，比如商品評(píng)論應(yīng)用故障，是否可以直接降級(jí)不顯示；首頁(yè)或詳情頁(yè)這樣的核心頁(yè)面，是否在故障時(shí)可以完全實(shí)現(xiàn)靜態(tài)化等等。
第四步，容量壓測(cè)及復(fù)盤會(huì)。
在容量壓測(cè)這個(gè)階段，就需要 PE、業(yè)務(wù)開(kāi)發(fā)和穩(wěn)定性平臺(tái)的同學(xué)來(lái)配合了。業(yè)務(wù)開(kāi)發(fā)在容量規(guī)劃平臺(tái)上構(gòu)造壓測(cè)數(shù)據(jù)和壓測(cè)模型，穩(wěn)定性平臺(tái)的同學(xué)在過(guò)程中要給予配合支持，如果有臨時(shí)性的平臺(tái)或工具需求，還要盡快開(kāi)發(fā)實(shí)現(xiàn)。
壓測(cè)過(guò)程會(huì)分為單機(jī)、單鏈路和全鏈路幾個(gè)環(huán)節(jié)，PE 和業(yè)務(wù)開(kāi)發(fā)，在過(guò)程中結(jié)合峰值數(shù)據(jù)做相應(yīng)的擴(kuò)容。如果是性能有問(wèn)題，業(yè)務(wù)開(kāi)發(fā)還要做代碼和架構(gòu)上的優(yōu)化，同時(shí)，雙方還要驗(yàn)證前面提到的服務(wù)治理手段是否生效。
壓測(cè)過(guò)程中和每次壓測(cè)結(jié)束后，都要不斷地總結(jié)和復(fù)盤，然后再壓測(cè)驗(yàn)證、擴(kuò)容和調(diào)優(yōu)，直至容量和預(yù)案全部驗(yàn)證通過(guò)。這個(gè)過(guò)程一般要持續(xù) 2～3 輪，時(shí)間周期上要 3～4 周左右。整個(gè)過(guò)程就會(huì)要求三個(gè)角色必須要非常緊密地配合才可以。
SRE 組織中的各個(gè)角色平時(shí)應(yīng)該要做些什么呢？
**第一項(xiàng)，核心應(yīng)用變更及新上線業(yè)務(wù)的穩(wěn)定性評(píng)審工作。**這里就包括前面講到的容量評(píng)估和壓測(cè)、預(yù)案策略是否完備等工作。PE 會(huì)跟業(yè)務(wù)開(kāi)發(fā)一起評(píng)估變動(dòng)的影響，比如變動(dòng)的業(yè)務(wù)邏輯會(huì)不會(huì)導(dǎo)致性能影響，進(jìn)而影響容量；對(duì)于新增加的接口或邏輯，是否要做限流、降級(jí)和熔斷等服務(wù)治理策略，如果評(píng)估出來(lái)是必需的，那上線前一定要把這些策略完善好；同時(shí)在測(cè)試環(huán)境上還要做驗(yàn)證，上線后要關(guān)注 SLO 是否發(fā)生變化等。
**第二項(xiàng)，周期性技術(shù)運(yùn)營(yíng)工作。**這些就包括了我們要例行關(guān)注錯(cuò)誤預(yù)算的消耗情況，每周或每月輸出系統(tǒng)整體運(yùn)行報(bào)表，并召集業(yè)務(wù)開(kāi)發(fā)一起開(kāi)評(píng)審會(huì)，對(duì)變化較大或有風(fēng)險(xiǎn)的 SLO 重點(diǎn)評(píng)估，進(jìn)而確認(rèn)是否要采取改進(jìn)措施或暫停變更，以此來(lái)驅(qū)動(dòng)業(yè)務(wù)開(kāi)發(fā)關(guān)注和提升穩(wěn)定性。
這里的技術(shù)運(yùn)營(yíng)工作，是 PE 職責(zé)非常大的轉(zhuǎn)變，因?yàn)殡S著各類平臺(tái)的完善，很多原來(lái)依賴運(yùn)維完成的事情，業(yè)務(wù)開(kāi)發(fā)完全可以依賴平臺(tái)自主完成，無(wú)需運(yùn)維介入。比如代碼發(fā)布、配置變更，甚至是資源申請(qǐng)。
所以，這時(shí)我們會(huì)更強(qiáng)調(diào) PE 從全局角度關(guān)注系統(tǒng)，除了穩(wěn)定性，還可以關(guān)注資源消耗的成本數(shù)據(jù)，在穩(wěn)定和效率都有保證的前提下，也能夠做到成本的不斷優(yōu)化。這樣也會(huì)使得 PE 從原有繁瑣的事務(wù)中抽離出來(lái)，能夠去做更有價(jià)值的事情。
引用：https://time.geekbang.org/column/intro/100048201?tab=catalog
總結(jié)
- 上一篇： DB2 9表分区
- 下一篇： 基于AT89C52单工串行通信系统设计