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

石鵬

美圖SRE負責人

• 2016年加入美圖，運維技術專家，目前擔任產品SRE負責人。

• 負責美圖社交、直播、電商、商業化等全線產品的運維工作。

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

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

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

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

• 先聊一聊SRE的工作職責，聊一下我所理解的SRE的核心目標；

• 初步看一下穩定性建設的工作范疇，看一看從宏觀上如何劃分我們的工作內容；

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

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

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

一、SRE的工作職責

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

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

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

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

其中這3個目標中，我們今天要重點談的是最核心、最基礎的“穩定性”。

二、穩定性建設

那么，

• 什么是穩定性？我們應該如何定義這個詞？

• 我們應該如何度量穩定性?

• 穩定性的目標應該怎么設置？

• 我們又該如何管理，如何提升穩定性呢?

這些問題，之前你是否有過系統的思考？

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

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

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

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

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

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

如上圖，在一個時間軸上，標注有幾個關鍵的時間點：

• 故障維修結束：上一次故障恢復結束的時間；

• 故障開始：故障開始發生的時間；

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

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

• 維修結束 -> 故障開始：T1

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

• 維修開始 -> 維修結束：T3

其中，

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

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

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

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

衡量穩定性的指標明確了，那我們穩定性的目標也就明確了：

• 提高MTBF

• 降低MTTR

MTBF的提升可以看做是我們眾多穩定性建設工作的一個結果(穩定)狀態，MTTR則是我們對故障的應急處理、恢復服務的過程，這是一個集中檢驗我們穩定性建設水平過程。

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

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

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

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

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

MTTR的指標被細化之后，我們的目標也就變成了降低這些細化之后的指標；我們可以分而治之、各個擊破，那么我們應該如何去達成這些目標呢？

我們可用的手段，總結如上圖：

• MTTI階段：多管齊下；盡可能用更多的手段來覆蓋可以發現、暴露問題的通道，包括完善監控的覆蓋，建設體系化的監控系統。

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

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

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

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

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

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

在這幾個階段中SRE的職責分別是：

• Pre-MTBF：預案建設、災備演練、OnCall值守等；

• MTTR：應急響應；

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

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

故障預防 -> 故障發現 -> 故障定位 -> 故障恢復 -> 故障改進

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

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

在深入故障管理的細節之前，我們先統一下對「故障」這個事情的認識，看一看我們推崇的故障文化。

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

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

三、故障管理

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

根據故障發生的時間順序，我們把故障管理分為故障前、故障中和故障后，在每個環節都有一些核心的工作內容和目標。

• 故障前：故障預防、災備預案；目標是盡可能地做足準備工作，畢竟有背方可無患；

• 故障中：發現、定位、解決故障；目標是盡可能的提高效率，縮短故障恢復的時間；

• 故障后：故障復盤、故障改進；目標是盡可能多的從故障中吸取教訓，反思和學習，完善和修復故障中暴露出來的問題。

1、故障前

故障前的故障預防和災備預案，我們應該怎么做呢？

這里列出了這么幾個比較關鍵工作內容：監控覆蓋、架構設計、容量評估、災備預案、災備演練、還有持續交付。

1）監控覆蓋

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

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

之前我們是把大的監控體系分為兩塊：客戶端質量監控和服務端質量監控。

①客戶端質量監控

我們在客戶端質量監控里邊去感知客戶端的狀態。

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

客戶端質量監控我們都使用了哪些手段呢？

• 常規的有一些第三方的撥測、第三方的APM。除了一些商用的產品，當然也有一些免費的工具是可以用的。

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

②服務端質量監控

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

Zabbix。除此之外，我們還建設了一些基于大數據流式計算的系統，主要是用來做我們SLA的體系

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

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

下圖是我們SLA的監控：

這是我們服務端質量體系里邊最重要的一張報表，請求數、錯誤數、慢請求有多少、服務整體平均響應時間、后端響應時間、成功率等SLA的指標都會在這張報表里邊體現。

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

下圖就是前文提到的客戶端的質量監控：

其實在這之前我們有用過一些商業產品，但后來發現商業產品不能很好的滿足我們的監控需求，所以后來就決定自己研發了哈勃監控。

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

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

2）架構設計

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

下圖是我們偏運維側的一張數據流向圖：

主要是說明一個業務包含了哪些域名，大概經過了什么鏈路，經過了哪些中間組件，最終到達了服務端。

3）容量評估

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

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

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

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

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

4）災備預案和災備演練

這兩點是比較關鍵的，跟故障會更強相關。下圖是我所整理的關于怎么做災備預案和災備演練的架構圖：

我們把這個過程分為了五個環節，基本按照這五個環節來做，災備預案就差不多可以完全覆蓋了。下面來具體地說一下：

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

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

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

• 預案落地：這一步是需要做落地，包括文檔輸出、功能實現、架構適配、工具建設。

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

下圖是美圖內部災備預案和故障演練的例子：

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

5）持續交付

持續交付也是需要我們在日常建設中就做好的事情。

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

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

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

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

2、故障中

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

1）監控告警

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

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

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

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

2）日志分析

3）鏈路跟蹤

4）預案執行

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

恢復之后還要確認執行結果，看服務是否恢復正常。這是我們在故障處理中實際案例的截圖。下面進入非常關鍵的故障后環節。

3、故障后

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

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

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

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

1）故障復盤

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

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

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

• 我們應該怎么做，才能更快地恢復業務？

• 我們應該怎么做，才能避免再次出現類似問題？

• 我們有哪些好的經驗可以總結、提煉，并固化？

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

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

到此做個總結，故障本質上是持續迭代的，當故障發生了，開始恢復、復盤、改進、驗收，回到穩定運行的狀態，再過一段時間又出現故障。同時，服務也持續地迭代，因此要不斷去提升穩定性，這是我們都逃不出的一環。

四、故障管理體系

為了做好故障管理，需要建設一些SRE體系提供支撐，下面談談故障管理體系應該有哪些內容以及如何建設。

1、可用性體系

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

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

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

• 可用性（Availability）：服務是否正常，看HTTP狀態碼2xx的占比；

• 延遲（Latency）：服務響應速度是否夠快，rt是否在預期范圍內；

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

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

2、故障定級、定性、定責

1）定級：通用標準

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

2）定級：個性化標準

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

注意這里個性化標準是無法規避的。它的存在體現了康威定律：一個設計系統的架構受制于產生于設置架構的組織，業務架構體現組織關系。定級制度同樣體現了不同部門內部個性化之處，所以要有方法去把它映射成通用的定級標準，只有我標準統一了，才有可能堅持推行好故障管理。

3）定性：有效分類

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

4）定責：判定原則

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

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

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

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

• 第三方默認無責：內部做故障定位時，默認第三方無責，當然該追責的還是會追責。

3、錯誤預算

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

4、組織結構支撐

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

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

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

五、SRE體系建設

1、穩定性建設

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

2、PPTV

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

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

六、未來展望

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

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

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

獲取本期PPT

請添加右側二維碼微信

QQ群號：763628645

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

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。