本文根據(jù)石鵬老師在〖deeplus直播第227期〗線上分享演講內(nèi)容整理而成。（文末有獲取本期PPT&回放的方式，不要錯過）

石鵬

美圖SRE負(fù)責(zé)人

• 2016年加入美圖，運維技術(shù)專家，目前擔(dān)任產(chǎn)品SRE負(fù)責(zé)人。

• 負(fù)責(zé)美圖社交、直播、電商、商業(yè)化等全線產(chǎn)品的運維工作。

我們都知道SRE是一個體系化的工程，SRE體系的建設(shè)涉及的內(nèi)容繁多，比如日常需求處理、容量規(guī)劃、資源部署、監(jiān)控告警、預(yù)案梳理、災(zāi)備演練、OnCall值班、應(yīng)急事件響應(yīng)、故障處理、運維自動化建設(shè)等等；其中「故障」可以算作是這眾多事項的一個交匯點。

故障處理是一個特別符合“臺上一分鐘，臺下十年功”這句俗語的場景，一次故障就是一次考試。SRE團隊的響應(yīng)速度、對服務(wù)的掌控能力、監(jiān)控告警的覆蓋是否完整、配置是否合理，災(zāi)備預(yù)案的體系是否完善、是否做了充分的災(zāi)備演練、應(yīng)急預(yù)案是否有效....這些都是用于考核SRE體系建設(shè)水平的一些指標(biāo)，都會在「故障處理」的過程中得到淋漓盡致的體現(xiàn)。不管你是研發(fā)、測試、運維，或其他“工種”，只要你身處IT行業(yè)，「故障」怕都是大家避之唯恐不及卻無法繞開的一個夢魘和話題。

我將圍繞「故障管理」這個點跟大家聊一聊SRE的工作范疇，跟大家共同探討SRE體系的建設(shè)。希望可以通過分享讓大家對故障管理有一個宏觀的框架，可以更從容淡定、有章可循地做服務(wù)穩(wěn)定性建設(shè)。

本次分享將按照如下的順序展開：

• 先聊一聊SRE的工作職責(zé)，聊一下我所理解的SRE的核心目標(biāo)；

• 初步看一下穩(wěn)定性建設(shè)的工作范疇，看一看從宏觀上如何劃分我們的工作內(nèi)容；

• 然后我們由此進入今天的主題：故障管理，我將按照我的理解對故障管理進行拆解和分析；

• 再后面，圍繞故障管理，我們深入聊一下SRE的體系建設(shè)，如何通過體系建設(shè)來更好地做故障管理；

• 最后我們再簡單做下對未來的展望，共同暢想一下SRE工作的未來。

一、SRE的工作職責(zé)

同樣的崗位名稱，在不同公司的具體職責(zé)和目標(biāo)可能會有些差異，這是我們在美圖的職責(zé)定位：我把SRE的核心目標(biāo)歸結(jié)為3點：穩(wěn)定性、效率和成本。

• 穩(wěn)定性是核心職責(zé)，這也是SRE崗位跟之前運維相關(guān)崗位的名稱(像SA、OP、PE等)之間最大的區(qū)別；SRE這個崗位在名稱中重點突出了崗位目標(biāo)——穩(wěn)定性，而SA、OP、PE等崗位名稱則沒有明確出目標(biāo)；

• 然后我們需要通過建設(shè)工具、平臺、基礎(chǔ)設(shè)施的建設(shè)來提高效率；

• 最后一個核心目標(biāo)，我們定為成本；連同上一個點效率，可以用一個現(xiàn)在比較流行的詞來概括——「降本增效」。這個點之所以重要，原因是多方面的，可以明確的是現(xiàn)在企業(yè)(當(dāng)然也包括互聯(lián)網(wǎng)行業(yè))對成本控制的重視程度是越來越高了。我們SRE也可以切實的通過技術(shù)手段來達(dá)成“優(yōu)化服務(wù)運行成本”的目標(biāo)，這也是SRE團隊對于企業(yè)的一個重要價值體現(xiàn)。

其中這3個目標(biāo)中，我們今天要重點談的是最核心、最基礎(chǔ)的“穩(wěn)定性”。

二、穩(wěn)定性建設(shè)

那么，

• 什么是穩(wěn)定性？我們應(yīng)該如何定義這個詞？

• 我們應(yīng)該如何度量穩(wěn)定性?

• 穩(wěn)定性的目標(biāo)應(yīng)該怎么設(shè)置？

• 我們又該如何管理，如何提升穩(wěn)定性呢?

這些問題，之前你是否有過系統(tǒng)的思考？

面對這一系列的問你，你的腦中會不會有很多問號?

著名的管理學(xué)大師 彼得德魯里曾經(jīng)說過一句名言：如果你不能度量它，你就無法改進它。這句話同樣適用于「穩(wěn)定性」，那我們我們應(yīng)該如何度量「穩(wěn)定性」呢?

在業(yè)界我們通常用MTBF和MTTR這兩個關(guān)鍵指標(biāo)來衡量穩(wěn)定性，這兩個指標(biāo)分別是「平均故障時間間隔」(Mean Time Between Failure)、「平均故障修復(fù)時間」(Mean Time To Repair)。

這兩個指標(biāo)也很好理解，我們用二分法簡單地把服務(wù)狀態(tài)分為“正常態(tài)”和“異常態(tài)”；異常態(tài)(故障)之間的平均時間間隔就是MTBF，從異常態(tài)(故障)恢復(fù)到正常態(tài)之間的平均時間就是MTTR。

如果我們把故障發(fā)生的時間間隔變長，讓服務(wù)更長時間地保持穩(wěn)定運行；并把故障恢復(fù)的時間變短，讓服務(wù)更少(時間)地受到故障的影響；那么服務(wù)的穩(wěn)定性也就自然提升了。這也就是我們之所以用這兩個指標(biāo)來衡量穩(wěn)定性的原因。

上面的二分法是為了方便大家理解，在定義上不夠嚴(yán)謹(jǐn)。我們再把上面這兩個時間細(xì)化一下，看一下相對嚴(yán)格的定義：

如上圖，在一個時間軸上，標(biāo)注有幾個關(guān)鍵的時間點：

• 故障維修結(jié)束：上一次故障恢復(fù)結(jié)束的時間；

• 故障開始：故障開始發(fā)生的時間；

• 故障維修開始：開始介入故障，開始處理的時間。

上面這幾個時間點就把時間劃分為了幾個時間段：

• 維修結(jié)束 -> 故障開始：T1

• 故障開始 -> 維修開始：T2

• 維修開始 -> 維修結(jié)束：T3

其中，

• T1的平均值為「平均無故障時間」，MTTF(Mean Time To Failure)

• T2+T3的平均值為「平均修復(fù)時間」，MTTR(Mean Time To Repair)

• T1+T2+T3的平均值為「平均故障間隔」，MTBF(Mean Time Between Failure)

所以我們可以看到 MTBF = MTTF + MTTR，因為MTTR通常遠(yuǎn)小于MTTF，所以MTBF近似等于MTTF；因此我們平時常用的衡量指標(biāo)就是MTBF和MTTR。

衡量穩(wěn)定性的指標(biāo)明確了，那我們穩(wěn)定性的目標(biāo)也就明確了：

• 提高MTBF

• 降低MTTR

MTBF的提升可以看做是我們眾多穩(wěn)定性建設(shè)工作的一個結(jié)果(穩(wěn)定)狀態(tài)，MTTR則是我們對故障的應(yīng)急處理、恢復(fù)服務(wù)的過程，這是一個集中檢驗我們穩(wěn)定性建設(shè)水平過程。

為了更好的理解和掌控故障恢復(fù)這個階段，我們對MTTR做進一步拆解；根據(jù)時間順序，MTTR可以細(xì)化為MTTI、MTTK、MTTF、MTTV四個階段(指標(biāo))。

• MTTI(Mean Time To Identify，平均故障發(fā)現(xiàn)時間)：指的是從故障實際發(fā)生，到我們真正開始感知、識別、響應(yīng)的時間。這個過程最長見的渠道可能是服務(wù)監(jiān)控告警、常規(guī)巡檢、用戶或者同事反饋，也可能是輿情監(jiān)控等。

• MTTK(Mean Time To Know，平均故障認(rèn)知時間)：也就是我們常說的平均故障定位時間。

• MTTF(Mean Time To Fix，平均故障恢復(fù)(解決)時間)：這個時間指從我們定位到故障的原因到我們采取措施恢復(fù)業(yè)務(wù)為止。這里采用的方式可能有很多：故障隔離、容災(zāi)切換、限流、降級、熔斷等，甚至是重啟服務(wù)。

• MTTV(Mean Time To Verify，平均故障修復(fù)驗證時間)：即故障解決之后，我們用來驗證服務(wù)是否真正恢復(fù)的時間。

MTTR的指標(biāo)被細(xì)化之后，我們的目標(biāo)也就變成了降低這些細(xì)化之后的指標(biāo)；我們可以分而治之、各個擊破，那么我們應(yīng)該如何去達(dá)成這些目標(biāo)呢？

我們可用的手段，總結(jié)如上圖：

• MTTI階段：多管齊下；盡可能用更多的手段來覆蓋可以發(fā)現(xiàn)、暴露問題的通道，包括完善監(jiān)控的覆蓋，建設(shè)體系化的監(jiān)控系統(tǒng)。

• MTTK階段：工具賦能；這個過程中需要更多的借助工具、平臺的能力，建設(shè)健全運維系統(tǒng)，比如監(jiān)控平臺、日志平臺、鏈路跟蹤平臺等，如果能力允許也可以去嘗試建設(shè)“根因自動定位”系統(tǒng)。

• MTTF階段：完備預(yù)案、一鍵應(yīng)急、緊密協(xié)作；這個是在故障處理過程中最核心的部分，是真正可以讓服務(wù)恢復(fù)正常的階段；這個過程有比較多的前置依賴，也就是需要我們在平時做好儲備的，比如建立健全預(yù)案體系，將預(yù)案的執(zhí)行手段盡可能沉淀到工具平臺中，盡可能做到一鍵直達(dá)，縮短預(yù)案執(zhí)行的路徑。其次這個過程中可能還會涉及到部門內(nèi)部、部門之間的協(xié)作，尤其是在處理重大故障的場景；這時候就需要有一套可以讓大家緊密協(xié)作的流程或共識，讓大家可以信息互通、各司其職、有條不紊。

• MTTV階段：自動校驗；這個過程也是需要盡可能依賴自動化的手段去做。

講完這些之后，讓我們來看一下SRE穩(wěn)定性建設(shè)的全景圖，看一看上面的內(nèi)容在整個穩(wěn)定系體系中的位置：

看圖中帶箭頭標(biāo)識的部分，整個時間軸總體分為MTBF和MTTR兩部分。

根據(jù)MTBF所處的位置，MTBF又可以被分為兩部分：一個是故障前的Pre階段，一個是故障后的Post階段；但其實因為整個時間軸是連續(xù)的，上次故障的Post-MTBF就是本次故障的Pre-MTBF，同理本次故障的Post-MTBF就是下次故障的Pre-MTBF。

在這幾個階段中SRE的職責(zé)分別是：

• Pre-MTBF：預(yù)案建設(shè)、災(zāi)備演練、OnCall值守等；

• MTTR：應(yīng)急響應(yīng)；

• Post-MTBF：故障復(fù)盤、故障改進、OnCall值守等。

看上圖中紅色的故障管理主線，整個過程可以被歸納為：

故障預(yù)防 -> 故障發(fā)現(xiàn) -> 故障定位 -> 故障恢復(fù) -> 故障改進

圍繞故障管理這條主線，我們把SRE穩(wěn)定性建設(shè)的眾多工作內(nèi)容串聯(lián)起來；夸張一點講，我們做的所有穩(wěn)定性建設(shè)都是為「故障」服務(wù)的，SRE的穩(wěn)定性建設(shè)都必須圍繞“提高MTBF”和“降低MTTR”這兩個目標(biāo)展開。

接下來，我們將沿著這條主線對「故障管理」進行進一步分析和講解。

在深入故障管理的細(xì)節(jié)之前，我們先統(tǒng)一下對「故障」這個事情的認(rèn)識，看一看我們推崇的故障文化。

「故障」其實是服務(wù)運行中的一個常態(tài)，是無法完全避免的；因此我們需要用一個積極的心態(tài)，至少是一顆平常心來看待故障，不能懼怕故障，更不要談之色變；只有我們正視故障，分析并改進才有更可能在未來去規(guī)避它；這就需要我們辯證的看待故障，我們需要盡可能從故障中汲取正向的意義，建議把關(guān)注點聚焦在「改進」上，而不是「處罰」。

這是我們基于No Blame Culture得出的公司內(nèi)部的故障文化的標(biāo)語：「擁抱故障，卓越運維」，我們希望在這樣的基調(diào)之下去做開展故障管理的工作。

三、故障管理

接下來，讓我們進入今天的核心部分。我將按照前、中、后三部分對故障管理的工作內(nèi)容做拆解，按照時間順序來層層推進，解開故障管理的面紗。

根據(jù)故障發(fā)生的時間順序，我們把故障管理分為故障前、故障中和故障后，在每個環(huán)節(jié)都有一些核心的工作內(nèi)容和目標(biāo)。

• 故障前：故障預(yù)防、災(zāi)備預(yù)案；目標(biāo)是盡可能地做足準(zhǔn)備工作，畢竟有背方可無患；

• 故障中：發(fā)現(xiàn)、定位、解決故障；目標(biāo)是盡可能的提高效率，縮短故障恢復(fù)的時間；

• 故障后：故障復(fù)盤、故障改進；目標(biāo)是盡可能多的從故障中吸取教訓(xùn)，反思和學(xué)習(xí)，完善和修復(fù)故障中暴露出來的問題。

1、故障前

故障前的故障預(yù)防和災(zāi)備預(yù)案，我們應(yīng)該怎么做呢？

這里列出了這么幾個比較關(guān)鍵工作內(nèi)容：監(jiān)控覆蓋、架構(gòu)設(shè)計、容量評估、災(zāi)備預(yù)案、災(zāi)備演練、還有持續(xù)交付。

1）監(jiān)控覆蓋

監(jiān)控覆蓋的話比較容易理解，服務(wù)上線后，只有擁有足夠的監(jiān)控手段，并且盡可能多的覆蓋服務(wù)的各個環(huán)節(jié)，才有可能在后面發(fā)生問題的時候，快速的感知到。也就是說，我們的目標(biāo)是盡可能有多的監(jiān)控手段去覆蓋我們服務(wù)，保障各個場景。下圖是我們之前用到的一些監(jiān)控組件：

也是比較多的，大概是分為這么些類別：

之前我們是把大的監(jiān)控體系分為兩塊：客戶端質(zhì)量監(jiān)控和服務(wù)端質(zhì)量監(jiān)控。

①客戶端質(zhì)量監(jiān)控

我們在客戶端質(zhì)量監(jiān)控里邊去感知客戶端的狀態(tài)。

當(dāng)然，現(xiàn)在大家對這一點也越來越重視了。其實在移動互聯(lián)網(wǎng)興起之前，大部分的監(jiān)控產(chǎn)品、監(jiān)控思路都是集中在服務(wù)端的。而如今，移動端的流量越來越高，用戶會花更多時間在移動端，但傳統(tǒng)服務(wù)端的一些質(zhì)量監(jiān)控體系并不能夠完全感知到客戶端的狀態(tài)，所以說這一點也就顯得比較重要。

客戶端質(zhì)量監(jiān)控我們都使用了哪些手段呢？

• 常規(guī)的有一些第三方的撥測、第三方的APM。除了一些商用的產(chǎn)品，當(dāng)然也有一些免費的工具是可以用的。

• 應(yīng)對一些流媒體的應(yīng)用，我們自研了一套融合CDN的監(jiān)控還有流媒體的監(jiān)控。這個其實也比較關(guān)鍵，因為現(xiàn)在業(yè)務(wù)體量大了之后，CDN是不可避免的會用到，但如果沒有這部分監(jiān)控的話，CDN質(zhì)量就要依賴于用戶反饋，鏈路就會比較長。所以說要有手段去主動監(jiān)測CDN的質(zhì)量。我們建設(shè)了這樣的CDN的質(zhì)量監(jiān)控，然后會去給不同的CDN廠商去打分，再去做智能的調(diào)度，是這樣的。

②服務(wù)端質(zhì)量監(jiān)控

服務(wù)端的質(zhì)量體系是用到了一些比較通用的，像InfluxDB套件、ELK、Prometheus、Open-Falcon

Zabbix。除此之外，我們還建設(shè)了一些基于大數(shù)據(jù)流式計算的系統(tǒng)，主要是用來做我們SLA的體系

接下來展示一些我們現(xiàn)在正在使用的監(jiān)控大盤案例，都是需要我們在日常工作中完善的：

比如下圖，是我們一組ECS的磁盤監(jiān)控，通過這張圖可以非常快速識別到哪組機器的磁盤的利用率比較高。

下圖是我們SLA的監(jiān)控：

這是我們服務(wù)端質(zhì)量體系里邊最重要的一張報表，請求數(shù)、錯誤數(shù)、慢請求有多少、服務(wù)整體平均響應(yīng)時間、后端響應(yīng)時間、成功率等SLA的指標(biāo)都會在這張報表里邊體現(xiàn)。

下圖是我們基于Grafana，用了ES的數(shù)據(jù)源來做了一些日志的報表：

下圖就是前文提到的客戶端的質(zhì)量監(jiān)控：

其實在這之前我們有用過一些商業(yè)產(chǎn)品，但后來發(fā)現(xiàn)商業(yè)產(chǎn)品不能很好的滿足我們的監(jiān)控需求，所以后來就決定自己研發(fā)了哈勃監(jiān)控。

在這里面，我們就可以對客戶端的狀態(tài)有一個感知能力。比如說有時候客戶端的網(wǎng)絡(luò)質(zhì)量不好，或者說因為一些網(wǎng)絡(luò)錯誤、SSL證書的錯誤，連接到CDN之類的失敗了，導(dǎo)致最終請求沒有到達(dá)服務(wù)端。

此時，你看SLA報表里面顯示一直是OK的，但其實這時候用戶真實的體驗并不是這樣的，他對服務(wù)的感受其實已經(jīng)是很糟糕了。所以我們就需要有客戶端的監(jiān)控體系，在這個報表里，就可以用一些指標(biāo)，將用戶真實的用戶體驗反饋出來。

2）架構(gòu)設(shè)計

架構(gòu)設(shè)計可能會更偏業(yè)務(wù)側(cè)一些。我們在故障之前，要盡可能做好服務(wù)的架構(gòu)設(shè)計，同時在做一些預(yù)案之前，也要把服務(wù)架構(gòu)做好梳理。只有當(dāng)我們把服務(wù)的架構(gòu)了然于胸，才更有可能在故障發(fā)生的時候從容不迫，更好地定位問題。此外，要更多去加入柔性設(shè)計，也就是說你的服務(wù)要具備一些像降級熔斷、故障隔離這些手段，要有這樣的柔性設(shè)計在里邊。這樣架構(gòu)可以提供這些能力，后面才能更好地去做服務(wù)的保障。再有一點就是，要盡可能的去規(guī)避常規(guī)的風(fēng)險點，比如說單點之類的；同時還要盡可能地去規(guī)避架構(gòu)里面常見的坑。

下圖是我們偏運維側(cè)的一張數(shù)據(jù)流向圖：

主要是說明一個業(yè)務(wù)包含了哪些域名，大概經(jīng)過了什么鏈路，經(jīng)過了哪些中間組件，最終到達(dá)了服務(wù)端。

3）容量評估

下圖是我們壓力測試的一個頁面：

以這個圖為例，容量評估其實就是我們的服務(wù)在上線之前，要去對服務(wù)的承載能力做一個壓測，這樣我們才能更好的了解服務(wù)上線之后的狀態(tài)。然后我們基于這個，再根據(jù)業(yè)務(wù)方量級的評估，去規(guī)劃服務(wù)的容量。

但有一點需要注意的是，容量評估是不是要完全基于這些壓測來做呢？在做壓測之前，有沒有一些其他的手段可以輔助我們，來更科學(xué)地做容量評估呢？其實是有的，但很多時候都被大家忽略了，也就是數(shù)學(xué)計算。

容量評估其實是不能完全依賴于壓測的。在壓縮之前，要基于我們對自己服務(wù)的理解，包括每一條請求大概會耗費多少資源等，要有一個基礎(chǔ)的認(rèn)識，再基于這些認(rèn)識去評估大概需要用多少后端資源、大概會用多少CPU內(nèi)存，這些東西是可以用數(shù)學(xué)計算的方法來計算出來的。當(dāng)然，非常精確的計算可能比較難達(dá)到，但這個手段是不能忽略的。我們要先有一個粗略的計算，再去輔助壓測，才能最終得出一個比較科學(xué)的容量評估。

其實像Google這種大廠里面，他們有專門容量評估的系統(tǒng)，但目前業(yè)界據(jù)我了解，是沒有這方面特別好用的系統(tǒng)。如果大家知道什么比較好用的系統(tǒng)，也可以在評論區(qū)留言，我們交流一下。

4）災(zāi)備預(yù)案和災(zāi)備演練

這兩點是比較關(guān)鍵的，跟故障會更強相關(guān)。下圖是我所整理的關(guān)于怎么做災(zāi)備預(yù)案和災(zāi)備演練的架構(gòu)圖：

我們把這個過程分為了五個環(huán)節(jié)，基本按照這五個環(huán)節(jié)來做，災(zāi)備預(yù)案就差不多可以完全覆蓋了。下面來具體地說一下：

• 服務(wù)梳理：在服務(wù)梳理階段，要基于前面的架構(gòu)圖等來梳理請求鏈路，要分段分層地梳理請求都經(jīng)歷了哪些層次、有哪些階段、經(jīng)過了哪些設(shè)備、周邊有哪些依賴（包括內(nèi)部的服務(wù)依賴、后端的資源依賴、第三方的依賴等），然后還要梳理架構(gòu)目前是不是有什么風(fēng)險、流量有沒有經(jīng)過一個單點、有沒有哪個點可能是存在瓶頸的……這些都是我們在服務(wù)梳理階段需要去梳理清楚的。

• 預(yù)案梳理：了解各種情況后，就可以梳理相應(yīng)的預(yù)案了。仔細(xì)分析應(yīng)該用什么樣的手段來覆蓋，將風(fēng)險各個擊破；然后要盡可能地做多級預(yù)案，因為預(yù)案如果只有一級的話，容災(zāi)能力是不夠柔性的；此外，還要借助到一些智能調(diào)度的手段；最后就是柔性設(shè)計，前面也有提到，是更偏業(yè)務(wù)側(cè)一些，也就是說在服務(wù)里要有盡可能多的手段來做自己的一些failover，可以去做一些降級、熔斷等。

• 沙盤推演：梳理出來預(yù)案后，并不是直接到做演練。要了解預(yù)案是不是真的有效，不是直接做演練，而應(yīng)該是先想清楚。我的建議是去做沙盤推演。在這個過程里，我們要盡可能去發(fā)動多的部門協(xié)作起來，來看我們的預(yù)案是不是有效。畢竟人多力量大，并且不同團隊的人對業(yè)務(wù)可能有不同的理解，在這種頭腦風(fēng)暴下，就有可能碰撞出更多的可能性。然后在這個過程里，會基于一些可能的故障場景、case等來做推演，當(dāng)故障場景A出現(xiàn)了，梳理出了預(yù)案A’，那 A’能不能把故障A完全解決掉？在解決故障場景的時候，有沒有引入一些其他的風(fēng)險點或問題？在這個過程里面，我們都要想清楚，當(dāng)?shù)贸鲆粋€大家都認(rèn)可的推演結(jié)果后，預(yù)案才推演完了。

• 預(yù)案落地：這一步是需要做落地，包括文檔輸出、功能實現(xiàn)、架構(gòu)適配、工具建設(shè)。

• 預(yù)案演練：落地之后，要通過演練的方法來驗證預(yù)案是不是真的有效。在這里，我大概列了幾種。比如無損演練和輕損演練：我們做故障演練要盡可能地做到對業(yè)務(wù)無損，但有些預(yù)案本身應(yīng)對的故障場景就是會損害業(yè)務(wù)的，那這種時候我們要盡可能降低這種演練帶來的損失，比如說選不同的時間段、流量的控制、灰度之類的，盡量去做輕損的演練，既然我們是通過故障演練的方式來確保預(yù)案有效，那肯定不能因為故障演練而演練出一個大的故障，這就有些得不償失了；還有就是單點演練跟組合演練：你的演練到底是要一次演練某個模塊，還是說要把一個大故障場景里所有涉及的點都演練一遍？這個也是我們在預(yù)案演練里需要考慮的。

下圖是美圖內(nèi)部災(zāi)備預(yù)案和故障演練的例子：

大家可以看到，我們是分了幾級來做的預(yù)案，包括數(shù)據(jù)的冷備、同城的雙AZ、異地災(zāi)備、熱備等。我們在做故障梳理的時候，大致也是按照前面講到的環(huán)節(jié)來做：先梳理（分為研發(fā)側(cè)和運維側(cè)梳理），然后盤點（盤點這個過程里有哪些故障點），再做case推演，而后是預(yù)案的輸出，最后是演練。

5）持續(xù)交付

持續(xù)交付也是需要我們在日常建設(shè)中就做好的事情。

舉個例子，10年之前，我們用的機器大部分都是物理機，當(dāng)線上發(fā)生了一個故障，定位到的原因是有一波大流量導(dǎo)致性能扛不住了。那么這時候應(yīng)對策略首先想到的是什么？是擴容。只有擴容才能完全的扛住流量，才能降低損失，否則的話，就只能是做有損的降級，也就是把請求丟掉。那么這個就涉及到持續(xù)交付能力。

回過頭來，時間放到現(xiàn)在，如果我們選擇了云、容器，它本身基礎(chǔ)設(shè)施架構(gòu)就具備了彈性伸縮的能力，具備更快提供擴容的手段，那么問題是不是就解決了呢？不是。與持續(xù)交付相關(guān)的場景還有非常多，萬一發(fā)生故障，去做修復(fù)的時候發(fā)現(xiàn)持續(xù)交付的能力跟不上，其實還是會拖長故障恢復(fù)時間。

上圖幾個是我們目前公司在用的一些持續(xù)交付的體系組件，可能大家也都比較熟悉。可能除了最右上角這個，是我們公司內(nèi)部開發(fā)的一個基于K8S的云管平臺，支持多集群管控，內(nèi)部代號Matrix。與其他外部的云管平臺類似，不過我們開發(fā)得比較早。基于這些基礎(chǔ)設(shè)施的存在，我們能夠保持良好的持續(xù)交付能力。

上述講的都是我們在故障管理之前需要做的事情：在故障來臨之前，如何做好預(yù)防和準(zhǔn)備，以及應(yīng)對的能力儲備。

2、故障中

當(dāng)故障真的發(fā)生了，我們應(yīng)該怎么做？去發(fā)現(xiàn)定位和恢復(fù)。這里列舉幾個比較核心的手段：監(jiān)控告警、日志分析、鏈路跟蹤、故障隔離、容災(zāi)切換、降級熔斷。只看字面意思也很好理解。下面我將以圖結(jié)合案例分享具體做法。

1）監(jiān)控告警

左圖是一個流量突變的告警，可能是大家常見到的一種，通過這種文字的手段把報警發(fā)給你。這里有一個點引起關(guān)注，突降30%，它其實是不同于常規(guī)那種告警，說目前的某個指標(biāo)超出某個值或者低于某個值，或達(dá)到什么水平線那種閥值的告警。兩者區(qū)別在于，突降是通過對比值得出的結(jié)論。這個示例說明在做監(jiān)控報警時，可能需要考慮的建設(shè)點，想想是否有這類需求，有沒有這類場景。

最右面的圖看起來比較酷，它是怎么實現(xiàn)的呢？它的意義是什么？對比前面這兩張文字圖，文字圖只是告知流量突降30%，這是一種告警方式。中間的圖就是由名為“監(jiān)控大盤”的機器人發(fā)送出來的，也是我們服務(wù)的架構(gòu)圖。放大圖看，我們的業(yè)務(wù)模塊、交互鏈路已經(jīng)暴露出來了；圖中有一塊是紅色的，紅色代表標(biāo)識異常，與異常關(guān)聯(lián)的某個組件就變成淡綠色。

由于紅色這塊故障引發(fā)了另外一個異常，接連引發(fā)了一個又一個的異常。通過這張告警圖，收獲了更多的信息：首先知道系統(tǒng)掛了，或者系統(tǒng)異常了，然后這次異常大概是由什么引起的。一張圖就可以讓你非常快速地感知?，F(xiàn)在有了這張圖，不再需要文字告警來通知我組件異常，也不用翻找過往經(jīng)驗做排查。只要看圖就能結(jié)合已有的監(jiān)控系統(tǒng)直接做分析、排查，最終得出結(jié)論。后者這種監(jiān)控手段就是讓故障背后的原因甚至根因更快觸達(dá)到用戶。

具體是怎么實現(xiàn)的呢？這是基于grafana的插件flowcharting基于draw.io的一個繪圖，結(jié)合我們的數(shù)據(jù)填充和告警配置來實現(xiàn)的。

2）日志分析

3）鏈路跟蹤

4）預(yù)案執(zhí)行

日志分析、鏈路跟蹤、預(yù)案執(zhí)行都是定位手段，在已經(jīng)定位問題之后，并且匹配了相應(yīng)的預(yù)案，要求去執(zhí)行預(yù)案。當(dāng)然前提是有相應(yīng)的預(yù)案應(yīng)對故障場景。然后依據(jù)操作手冊，分別按不同的故障層次去執(zhí)行處理。

恢復(fù)之后還要確認(rèn)執(zhí)行結(jié)果，看服務(wù)是否恢復(fù)正常。這是我們在故障處理中實際案例的截圖。下面進入非常關(guān)鍵的故障后環(huán)節(jié)。

3、故障后

大家要重視一點，在故障發(fā)生和解決以后，以為問題真的結(jié)束了嗎？其實并沒有。在故障后，我們應(yīng)該做好以下環(huán)節(jié)：故障復(fù)盤、故障改進、預(yù)案完善、容量壓測、故障模擬、周邊清查。我解釋下其中幾個概念：

• 預(yù)案完善：故障發(fā)生之前有做過預(yù)案，這些預(yù)案是不是完善的？在故障處理的過程中，有沒有暴露出問題？是否要完善之前的預(yù)案中做的不完善的地方等等；

• 故障模擬：意思是用某種手段模擬某些故障，提前知道該如何解決這些問題；

• 周邊清查：應(yīng)該具備舉一反三的能力，比如A服務(wù)出故障，那么A服務(wù)周邊有一些相關(guān)聯(lián)的服務(wù)有可能會受到影響。舉個例子，比如集群里面有N臺機器，收到機器A磁盤接近100%的一條告警，只需處理機器A就可以了嗎？當(dāng)然不是，在處理完該異常之后，肯定要查看同集群的其他機器是否存在類似情況。

1）故障復(fù)盤

在故障復(fù)盤階段，最核心的思想就是要回顧關(guān)鍵的時間點：故障是從什么時間發(fā)生的？從什么時間到什么時間結(jié)束的？在這過程里面有哪些非常關(guān)鍵的操作？有哪些關(guān)鍵的信息？從什么時間點定位到問題？在什么時候執(zhí)行怎樣的操作？這些時間點都是非常重要的。

在故障復(fù)盤的過程中，要把這些操作的時間點一一還原回去，才能完整地回看操作是否合理有效。看在某個時間點執(zhí)行了某個預(yù)案，思考某個時刻做出這樣的操作是否恰當(dāng)，此時有沒有其他更好的手段能夠恢復(fù)服務(wù)，某個時間段為什么沒有及時處理而導(dǎo)致故障時間變長等等。

做好故障復(fù)盤，我們有黃金三問法：

• 我們應(yīng)該怎么做，才能更快地恢復(fù)業(yè)務(wù)？

• 我們應(yīng)該怎么做，才能避免再次出現(xiàn)類似問題？

• 我們有哪些好的經(jīng)驗可以總結(jié)、提煉，并固化？

基于以上三個問題，通過自問自答的形式弄清故障復(fù)盤。

這是故障解決后繞不開的一點，在故障發(fā)生后都會做一個報告，上圖就是我們內(nèi)部的一個故障報告模板。在報告里面寫清楚故障級別、責(zé)任人、處理過程、改進措施，將這些關(guān)鍵點歸納成故障報告的文檔。

到此做個總結(jié)，故障本質(zhì)上是持續(xù)迭代的，當(dāng)故障發(fā)生了，開始恢復(fù)、復(fù)盤、改進、驗收，回到穩(wěn)定運行的狀態(tài)，再過一段時間又出現(xiàn)故障。同時，服務(wù)也持續(xù)地迭代，因此要不斷去提升穩(wěn)定性，這是我們都逃不出的一環(huán)。

四、故障管理體系

為了做好故障管理，需要建設(shè)一些SRE體系提供支撐，下面談?wù)劰收瞎芾眢w系應(yīng)該有哪些內(nèi)容以及如何建設(shè)。

1、可用性體系

關(guān)于可用性體系里面的三個名詞需要達(dá)成一致的理解。平時我們所講的SLA并不是真正意義上的SLA。SLI是指標(biāo)，SLO是目標(biāo)，SLA是我們的目標(biāo)加上目標(biāo)未達(dá)成的后果，通常運用在雙方一些商務(wù)合約上，例如使用某云廠商的服務(wù)，對方承諾可用性不低于99.95%。一旦沒有達(dá)到我的要求，處罰性的或者賠償性的一些條款將會生效，這才是真正意義上的SLA。

那么如何選擇SLI？參照VALET法則，有五大選擇依據(jù)：

• 容量（Volume）：服務(wù)承諾的最大容量是多少，從QPS、TPS、流量、連接數(shù)、吞吐思考；

• 可用性（Availability）：服務(wù)是否正常，看HTTP狀態(tài)碼2xx的占比；

• 延遲（Latency）：服務(wù)響應(yīng)速度是否夠快，rt是否在預(yù)期范圍內(nèi)；

• 錯誤率（Errors）：錯誤率有多少，看HTTP狀態(tài)碼5xx的占比；

• 人工介入（Tickets）：是否需要人工介入處理，考慮人工修復(fù)。

2、故障定級、定性、定責(zé)

1）定級：通用標(biāo)準(zhǔn)

這張圖列出的故障等級衡量指標(biāo)是非常具備參考性的，可以基于此建設(shè)自己的故障等級體系，看看用哪些指標(biāo)來衡量故障的影響，從而給服務(wù)定級。圖中列出四點都是常規(guī)的考核項，主要看對服務(wù)功能的影響、影響時長、故障所發(fā)生的時段、對用戶的影響范圍。對用戶影響范圍就是看是主要功能還是次要功能不能使用，大概會算出權(quán)重占比。

2）定級：個性化標(biāo)準(zhǔn)

除了通用標(biāo)準(zhǔn)，還有一些沒有被囊括到體系中來，比如某些電商類、商業(yè)化、廣告類和金融類的業(yè)務(wù)，有可能造成資產(chǎn)損失，那么不同的部門會有不同的故障管理的定級策略。為此，我們要把這些不同部門的體系映射到通用的定級標(biāo)準(zhǔn)里面，以便更好地管理。

注意這里個性化標(biāo)準(zhǔn)是無法規(guī)避的。它的存在體現(xiàn)了康威定律：一個設(shè)計系統(tǒng)的架構(gòu)受制于產(chǎn)生于設(shè)置架構(gòu)的組織，業(yè)務(wù)架構(gòu)體現(xiàn)組織關(guān)系。定級制度同樣體現(xiàn)了不同部門內(nèi)部個性化之處，所以要有方法去把它映射成通用的定級標(biāo)準(zhǔn)，只有我標(biāo)準(zhǔn)統(tǒng)一了，才有可能堅持推行好故障管理。

3）定性：有效分類

上圖是故障定性的一些有效分類，即定性故障是由什么原因引起的。是代碼質(zhì)量、測試質(zhì)量、流程規(guī)范出了問題，還是變更操作不夠規(guī)范呢？還有其他種種原因，我們要對故障做定性的分析和歸類。

4）定責(zé)：判定原則

定責(zé)任并不意味著處罰。我們整體的故障管理從原則上來說盡量不指責(zé)，但不指責(zé)不代表著可以持續(xù)犯錯誤。這里由于時間原因重點解釋四個原則：

• 高壓線原則：不能犯一些低級的錯誤；不能持續(xù)犯某些錯誤；

• 上下游原則：根據(jù)服務(wù)的上下游依賴程度去做判斷；

• 健壯性原則：根據(jù)服務(wù)的健壯性定性。例如服務(wù)A掛掉導(dǎo)致服務(wù)B出問題，這時候責(zé)任不能完全劃分到服務(wù)A上，還要考慮到服務(wù)B本身的健壯性；

• 第三方默認(rèn)無責(zé)：內(nèi)部做故障定位時，默認(rèn)第三方無責(zé)，當(dāng)然該追責(zé)的還是會追責(zé)。

3、錯誤預(yù)算

在SRE里經(jīng)常聽到錯誤預(yù)算，如何做到實際落地？前面講了故障的定級規(guī)則，明確定級規(guī)則之后，不同的故障被定為ABC級，按對應(yīng)計分標(biāo)準(zhǔn)扣分?？鄣姆?jǐn)?shù)來源于給出的預(yù)算。我們每半年為一個OKR考核周期，在一個考核周期里面每個BU會分到一定的故障分，允許在考核周期里由于故障被扣分，如果分?jǐn)?shù)扣完了意味著錯誤預(yù)算用完了。這里提到的和Google SRE類似，即可用性達(dá)到多少標(biāo)準(zhǔn)，發(fā)布將受到限制。我們將錯誤預(yù)算和OKR做了綁定，讓大家在目標(biāo)驅(qū)動之下達(dá)成這個目標(biāo)。

4、組織結(jié)構(gòu)支撐

故障管理特別依賴于組織結(jié)構(gòu)的支撐，因為故障管理不僅僅是運營部門或者技術(shù)保障部門能單獨完成的事情，需要不同團隊協(xié)作。為此，我們成立了故障管理委員會。故障委員會是一個虛擬的組織，不是一個實體的組織，由BU接口人負(fù)責(zé)故障委員會故障判定和定責(zé)之類的事情、傳達(dá)信息給BU內(nèi)部。

我們從上往下看。當(dāng)故障發(fā)生了，基于判定規(guī)則給故障定級、定責(zé)。定級意味著每個級別產(chǎn)生對應(yīng)的故障分；定責(zé)會涉及到故障的拆分，比如發(fā)生了一個故障，它由A、B兩個部門共同承擔(dān)。根據(jù)定責(zé)發(fā)現(xiàn)責(zé)任上A、B部門實際是五五開，因此A、B平分故障分，再從A、B部門的BU負(fù)責(zé)人各自的錯誤預(yù)算里扣除故障分。

通過這種方式就能約束好BU嗎？當(dāng)然不是，要用行政手段來保障，那就是OKR。周期OKR里需要有服務(wù)穩(wěn)定性的目標(biāo)項才行，把服務(wù)穩(wěn)定性寫進OKR后，BU出于壓力而去共同做好故障管理。在上述這種組織支撐的情況下，才能更好地推行故障管理。

五、SRE體系建設(shè)

1、穩(wěn)定性建設(shè)

看SRE穩(wěn)定性全景圖，按照 MTBF和MTTR，把日常時間分成幾段，不同時段里要做哪些事情？先是建設(shè)演練、Oncall值班，然后應(yīng)急響應(yīng)，最后復(fù)盤改進、再Oncall。在一個循環(huán)里面完成了SRE的工作。這張圖里有一些需要我們持續(xù)關(guān)注的前沿部分，例如AIOps智能預(yù)測、混沌工程。

2、PPTV

最后以PPTV總結(jié)SRE體系建設(shè)，即PPT+V。PPT包涵了人員、流程、技術(shù)，是ITIL中的IT管理的三要素。SRE體系建設(shè)同樣無法脫離這個模型，做好故障管理要有一個合適的組織結(jié)構(gòu)、流程流程保障。光有前兩者沒有辦法落地，還要有強力的技術(shù)保障支撐。

在此基礎(chǔ)上，我給增加了Vision即目標(biāo)。只有對穩(wěn)定性的建設(shè)有共同的目標(biāo)期許，才能做好SRE。不同的業(yè)務(wù)部門要有對服務(wù)穩(wěn)定性的一些共同追求，不管出于行政壓力，還是基于自身對服務(wù)穩(wěn)定性的追求，我們都要有統(tǒng)一的目標(biāo)。PPTV做好以上四點，更有利于SRE體系的落地。

六、未來展望

基于當(dāng)下的想象力，我對未來有一些必要和明確的期待。第一點個人認(rèn)為是AIOps，很多大廠已經(jīng)涌現(xiàn)出一批AIOps開源的東西，大家都在做一些探索。但是AIOps何時能實現(xiàn)大規(guī)模落地，應(yīng)用在SRE建設(shè)并發(fā)揮更大的價值，甚至驅(qū)動SRE自我革命，目前都無法給出定論。

第二，混沌工程Chaos Engineering 在做故障發(fā)現(xiàn)時可能有用，已經(jīng)有一些公司對此進行探索。以上就是我認(rèn)為可能有好的未來發(fā)展的兩種趨勢。

相關(guān)閱讀：直播問答丨圍繞故障管理談SRE體系建設(shè)，這14個問題不要錯過

獲取本期PPT

請?zhí)砑佑覀?cè)二維碼微信

QQ群號：763628645

QQ群二維碼如下，?添加請注明：姓名+地區(qū)+職位，否則不予通過

總結(jié)

以上是生活随笔為你收集整理的美团围绕故障管理谈SRE体系建设的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。