SRE最早是由Google提出的概念，其大概的意思就是：以標(biāo)準(zhǔn)化、自動化、可擴(kuò)展驅(qū)動維護(hù)，用軟件開發(fā)解決運維難題。這個崗位面世的時候，其根本要解決的問題就是打破傳統(tǒng)研發(fā)人員快速迭代而引發(fā)的業(yè)務(wù)不穩(wěn)定性，用以保證業(yè)務(wù)維護(hù)側(cè)重的服務(wù)質(zhì)量以及穩(wěn)定性之間的平衡。

不同公司的SRE定位是不同的，可能某些公司的運維崗位也是SRE，以此，不能以偏概全，國內(nèi)的SRE基本是以崗位來區(qū)分的，比如，有負(fù)責(zé)網(wǎng)絡(luò)的SRE，有負(fù)責(zé)DBA的SRE，有專門負(fù)責(zé)業(yè)務(wù)的SRE，還有什么安全SRE等等。就谷歌所提到的SRE的理解來講，基本都是以服務(wù)質(zhì)量穩(wěn)定為基線的維護(hù)工程師，只是對于SRE的要求是苛刻的，下面是我的個人理解：

第一：技能全面，比如網(wǎng)絡(luò)、操作系統(tǒng)、監(jiān)控、CICD、研發(fā)等，對于研發(fā)能力，可能不需要你精通，但是你需要具備可以使用一門語言完成某個功能的設(shè)計、開發(fā)與迭代。

第二：打破傳統(tǒng)運維思想壁壘，以產(chǎn)品角度思維貫穿整個業(yè)務(wù)架構(gòu)服務(wù)質(zhì)量為前提的溝通協(xié)調(diào)能力。

第三：始終以軟件工程解決問題為方向的規(guī)劃之路。

綜上所述，國內(nèi)現(xiàn)在的SRE，大致可以分成倆個層級，PasS-SRE和業(yè)務(wù)SRE，前者主要是維護(hù)平臺基建服務(wù)質(zhì)量為主的SRE，后者主要是維護(hù)業(yè)務(wù)服務(wù)質(zhì)量穩(wěn)定性為主的SRE，業(yè)務(wù)SRE比較像業(yè)務(wù)運維。

在《SRE谷歌運維解密》一書當(dāng)中已經(jīng)提到了幾個關(guān)鍵點：

• 可觀測性系統(tǒng)
• 故障響應(yīng)
• 故障復(fù)盤
• 測試與部署
• 容量規(guī)劃
• 自動化軟件開發(fā)
• 用戶支持
• Oncall
• 制定可交付的SLI/SLO/SLA

一、可觀測性系統(tǒng)

在任何有一定規(guī)模的企業(yè)內(nèi)部，一旦推行起來整個SRE的運維模式，那么對于可觀測性系統(tǒng)的建設(shè)將變得尤為重要，而在整個可觀測性系統(tǒng)中，通常我們會分為如下三個方面：

• 指標(biāo)監(jiān)控：即各種指標(biāo)監(jiān)控，比如基礎(chǔ)資源指標(biāo)，服務(wù)性能指標(biāo)，業(yè)務(wù)的調(diào)用指標(biāo)。
• 日志：各種設(shè)備以及服務(wù)的運行日志監(jiān)控。
• 調(diào)用鏈：業(yè)務(wù)層面的調(diào)用鏈分析，通常在分布式系統(tǒng)中幫助運營、開發(fā)以及運維人員快速識別整體調(diào)用的瓶頸點。

一整套的可觀測系統(tǒng)，它能確保你洞察系統(tǒng)，跟蹤系統(tǒng)的健康狀態(tài)、可用性以及系統(tǒng)內(nèi)部發(fā)生的事情。

對于整個可觀測系統(tǒng)的建設(shè)，需要注意如下兩點：

• 確定質(zhì)量標(biāo)準(zhǔn)是什么，并確保系統(tǒng)持續(xù)逼近或保持在質(zhì)量標(biāo)準(zhǔn)極限范圍內(nèi)。
• 系統(tǒng)地關(guān)注這項工作，而不應(yīng)該只是隨機地查看一下系統(tǒng)。

在整個企業(yè)級可觀測系統(tǒng)中，我認(rèn)為至少應(yīng)該包括如下幾個特征：

• 完備指標(biāo)采集

可以對接企業(yè)內(nèi)大部分的設(shè)備與技術(shù)棧相應(yīng)的監(jiān)控指標(biāo)；同時，支持常見設(shè)備的監(jiān)控指標(biāo)體系，可以快速接入監(jiān)控設(shè)備和指標(biāo)，避免所有設(shè)備監(jiān)控都是從頭構(gòu)建；對于日志數(shù)據(jù)的采集支持。

• 海量設(shè)備支持

企業(yè)IT系統(tǒng)數(shù)量和規(guī)模越來越大，因此監(jiān)控系統(tǒng)比以前需要監(jiān)控海量設(shè)備監(jiān)控。

• 監(jiān)控數(shù)據(jù)存儲和分析

監(jiān)控數(shù)據(jù)是運維分析、運維自動化和智能化的基礎(chǔ)，因此海量監(jiān)控數(shù)據(jù)存儲以及基于監(jiān)控數(shù)據(jù)的可視化分析是一個監(jiān)控系統(tǒng)的基本能力。

可觀測系統(tǒng)是整個運維體系的基礎(chǔ)，它需要提供整個運維體系的數(shù)據(jù)化支持。

因此，一個企業(yè)級的可觀測性系統(tǒng)應(yīng)該是平臺化的。一方面可以通過配置或者開發(fā)實現(xiàn)更多 運維指標(biāo)的接入；另一方面，亦可對接更多的專業(yè)運維工具，整合并打通多元的運維數(shù)據(jù)，為更多運維場景提供數(shù)據(jù)服務(wù)。從整體上，可觀測性系統(tǒng)為企業(yè)運維提供了一個數(shù)據(jù)基礎(chǔ)，讓我們對事故響應(yīng)以及容量預(yù)測等方面更多使用數(shù)據(jù)而非憑借以往經(jīng)驗和拍腦袋做出決策。

二、故障響應(yīng)

如果有什么東西出了故障，該如何提醒大家并做出回應(yīng)？工具可以幫助解決這個問題，因為它可以定義提醒人類的規(guī)則。

故障響應(yīng)是建立在使用可觀測性系統(tǒng)構(gòu)建的數(shù)據(jù)之上，并借助反饋循環(huán)，來幫助我們加強對服務(wù)的監(jiān)控。

故障響應(yīng)通常包含如下幾個動作：

• 關(guān)注: 不論是主動發(fā)現(xiàn)瓶頸點或異常點，還是通過可觀測性系統(tǒng)被動暴露瓶頸點，我們都應(yīng)該進(jìn)行主動關(guān)注。
• 交流: 及時將觀察到風(fēng)險點通知到相關(guān)方，并告知影響面以及相關(guān)的補救措施。
• 恢復(fù): 三方達(dá)成一致后，根據(jù)補救措施進(jìn)行修復(fù)相關(guān)風(fēng)險點和異常點。

需要注意的是，如果在前期整個可觀測性系統(tǒng)能夠做好，通常故障應(yīng)當(dāng)始于一個簡單的告警信息或一個報障電話，因此，通常情況下，可觀測系統(tǒng)做的足夠好僅能起到追溯和排查的作用，但是無法起到及時發(fā)現(xiàn)的作用，此時就需要依賴于各個觀測數(shù)據(jù)進(jìn)行計算和評估告警，以及時將相關(guān)的告警通知到相關(guān)人，以暴露風(fēng)險點。

告警只是整個故障響應(yīng)的第一個環(huán)節(jié)，解決的是故障如何發(fā)現(xiàn)的問題，而大多數(shù)的故障響應(yīng)工作都是關(guān)于定義處理策略和提供培訓(xùn)的，以便人們在收到警報時知道該怎么做，通常這部分更多的是過去歷史經(jīng)驗和運維經(jīng)歷的總結(jié)和沉淀，包括經(jīng)驗的一些抽象和工具化沉淀，以保證故障響應(yīng)的效率和普遍化(即不依賴人為經(jīng)驗)。

而對于整個告警系統(tǒng)來說，需要確保的是告警的有效性，否則，整個報警系統(tǒng)很有可能淪落為垃圾數(shù)據(jù)制造機，告警有效性意味著需要滿足如下兩個需求：

• 告警及時性: 系統(tǒng)有問題需要及時通過告警信息告知運維處理人員及時處理告警：
• 告警準(zhǔn)確性: 只要有告警信息系統(tǒng)必然出現(xiàn)問題(對于很多企業(yè)可能存在大量的無用告警，比如磁盤問題，mem等相關(guān)問題，當(dāng)然這里涉及到了自動化、業(yè)務(wù)形態(tài)、告警閾值的問題)。

在整個運維過程中，我們經(jīng)常會發(fā)現(xiàn)有大量的無關(guān)緊要的告警信息，讓運維人員的注意力迷失在告警海洋當(dāng)中，而通常非運維領(lǐng)域的領(lǐng)導(dǎo)會關(guān)注整個告警的響應(yīng)程度，因此，抑制和消除無效的告警，讓運維人員不被告警風(fēng)暴所吞沒，也是告警管理中重點建設(shè)的內(nèi)容。

通常情況，在我們的各個可觀測系統(tǒng)構(gòu)建完成后，可以通過整合到監(jiān)控平臺中的各種監(jiān)控數(shù)據(jù)，應(yīng)用趨勢預(yù)測、短周期檢測、間歇性恢復(fù)、基線判斷、重復(fù)壓縮等算法和手段實現(xiàn)告警壓縮收斂，強化告警的有效性。

同時，面向一線的運維人員，我們需要根據(jù)同一個系統(tǒng)或設(shè)備的多個監(jiān)控指標(biāo)進(jìn)行綜合性建模和分析，匯總成一個健康度的分值，給予一線運維人員系統(tǒng)的基于健康度的系統(tǒng)分層評價體系，真實、直觀反映系統(tǒng)運行狀態(tài)，實現(xiàn)問題快速定位。

比如，通過基礎(chǔ)資源的多個指標(biāo)進(jìn)行綜合加權(quán)計算來整體評估該資源的利用率；通過一個應(yīng)用關(guān)聯(lián)的全部資源的資源利用率以及應(yīng)用的運維架構(gòu)整體建模分析來計算一個分值來整體評估該應(yīng)用的健康程度。

這個過程如果做得成熟一些，可以根據(jù)內(nèi)部已有的解決方案和告警進(jìn)行閉環(huán)打通，一個簡單的場景就是，當(dāng)磁盤滿時，告警會首先觸發(fā)一次標(biāo)準(zhǔn)化的磁盤巡檢，并進(jìn)行相關(guān)的可丟棄數(shù)據(jù)的刪除，如果依然無法解決該報警，下次可直接關(guān)聯(lián)到一線運維進(jìn)行人工干預(yù)，之后進(jìn)行標(biāo)準(zhǔn)化經(jīng)驗總結(jié)。

三、測試與部署

測試與部署對于整個穩(wěn)定性和可靠性的主要出于一個預(yù)防的作用，預(yù)防是指嘗試限制發(fā)生的事故數(shù)量，并確保在發(fā)布新代碼時基礎(chǔ)架構(gòu)和服務(wù)能夠保持穩(wěn)定。

作為一個長期從事運維工作的人，可能內(nèi)心中最為恐懼的莫過于新應(yīng)用版本發(fā)布。因為除了硬件和網(wǎng)絡(luò)設(shè)備損壞這個屬于天災(zāi)級別的概率事件外，新應(yīng)用版本發(fā)布的第二天通常是停機與事故的高危期。所以，對于一些量級較大的產(chǎn)品通常會在節(jié)假日以及重要活動前夕進(jìn)行封網(wǎng)操作，以避免新版本上線而導(dǎo)致的業(yè)務(wù)bug出現(xiàn)。

而測試是在成本和風(fēng)險之間找到適當(dāng)?shù)钠胶饣顒?。如果過于冒險，你們可能就會疲于應(yīng)付系統(tǒng)失??；反過來說，如果你太保守，你就不能足夠快地發(fā)布新東西，讓企業(yè)在市場上生存下來。

在錯誤預(yù)算比較多（即在一段時間內(nèi)故障導(dǎo)致系統(tǒng)停機時長較少）的情況下，可以適當(dāng)減少測試資源并放寬系統(tǒng)上線的測試和條件，讓業(yè)務(wù)可以有更多的功能上線，以保持業(yè)務(wù)的敏態(tài)；在錯誤預(yù)算比較少（即在一段時間內(nèi)故障導(dǎo)致系統(tǒng)停機時長較多）的情況下，則要增加測試資源并收緊系統(tǒng)上線的測試，讓系統(tǒng)的潛在風(fēng)險得到更多有效的釋放，避免系統(tǒng)停機保持系統(tǒng)的穩(wěn)態(tài)。這種敏態(tài)與穩(wěn)態(tài)之間的平衡，需要整個運維與開發(fā)團(tuán)隊來共同承擔(dān)。

除了測試外，應(yīng)用發(fā)布也是一項運維團(tuán)隊通常要承擔(dān)的責(zé)任。SRE其中的一個原則是將一切可以重復(fù)性勞動代碼化和工具化；此外，應(yīng)用發(fā)布的復(fù)雜程度往往與系統(tǒng)的復(fù)雜程度成正比。因此在應(yīng)用系統(tǒng)上規(guī)模企業(yè)，往往已經(jīng)著手基于自動化框架構(gòu)建自動化的應(yīng)用發(fā)布過程。

通過自動化發(fā)布工具，我們可以構(gòu)建流水線實現(xiàn)部署的過程中所有的操作（如編譯打包、測試發(fā)布、生產(chǎn)準(zhǔn)備、告警屏蔽、服務(wù)停止、數(shù)據(jù)庫執(zhí)行、應(yīng)用部署、服務(wù)重啟等）全部自動化。

四、容量規(guī)劃

容量規(guī)劃是關(guān)于預(yù)測未來和發(fā)現(xiàn)系統(tǒng)極限的，容量規(guī)劃也是為了確保系統(tǒng)可以隨著時間的推移得到完善和增強。

規(guī)劃的主要目標(biāo)是管理風(fēng)險和期望，對于容量規(guī)劃，涉及到將容量擴(kuò)展到整個業(yè)務(wù)；所關(guān)注的期望是人們在看到業(yè)務(wù)增長時期望服務(wù)如何響應(yīng)。風(fēng)險是在額外的基礎(chǔ)設(shè)施上花費時間和金錢來處理這個問題。

容量規(guī)劃首先是對未來預(yù)測性的分析與判斷，其預(yù)測的基礎(chǔ)正是海量的運維數(shù)據(jù)。因此，容量規(guī)劃除了有相應(yīng)的架構(gòu)和規(guī)劃團(tuán)隊外，一個全面的運維數(shù)據(jù)中心是實現(xiàn)系統(tǒng)容量規(guī)劃的必須設(shè)施。

容量趨勢預(yù)警和分析將綜合地從各種運維監(jiān)控、流程管理等數(shù)據(jù)源中收集、整理、清洗并結(jié)構(gòu)化地存儲各種運維數(shù)據(jù)，將這些來自于各種工具的運維數(shù)據(jù)打通融合并且構(gòu)建各種數(shù)據(jù)主題。

應(yīng)用這些數(shù)據(jù)主題的數(shù)據(jù)用于幫助運維人員對問題進(jìn)行評估，包括：

• 當(dāng)前的容量是多少
• 何時達(dá)到容量極限
• 應(yīng)該如何更改容量
• 執(zhí)行容量規(guī)劃

運維平臺除了可以提供必要的數(shù)據(jù)支持外，還需要提供必要的數(shù)據(jù)可視化支持能力。運維數(shù)據(jù)可視化提供了一些必要的能力保障運維人員可以更好地利用其中的運維數(shù)據(jù)評估容量。

首先，運維平臺需要有極強的數(shù)據(jù)檢索能力。運維平臺存儲著海量的運維數(shù)據(jù)，運維人員為了嘗試建立和驗證一個探索性場景的時候，往往多次反復(fù)檢索和查詢特定數(shù)據(jù)。如果運維數(shù)據(jù)分析平臺的數(shù)據(jù)查詢很慢或者查詢角度很少的情況下，運維人員建立場景的時間就會拖得很長甚至進(jìn)行不下去。因此，運維人員可通過平臺可以實現(xiàn)關(guān)鍵字、統(tǒng)計函數(shù)、單條件、多條件、模糊多維度查找功能，以及實現(xiàn)海量數(shù)據(jù)秒級查詢，才能更有效幫助運維人員更便捷分析數(shù)據(jù)。

其二，平臺需要強大的數(shù)據(jù)可視化能力。人們常說“千言萬語不及一圖”，運維人員經(jīng)常會通過各系統(tǒng)的運維數(shù)據(jù)進(jìn)行統(tǒng)計分析并生成各類實時報表，對各類運維數(shù)據(jù)（如應(yīng)用日志、交易日志、系統(tǒng)日志）進(jìn)行多維度、多角度深入分析、預(yù)測及可視化展現(xiàn)，將他們分析的預(yù)測結(jié)果和經(jīng)驗向他人表達(dá)和推廣。

五、自動化工具開發(fā)

SRE不僅涉及運營，還涉及軟件開發(fā)，當(dāng)然這部分指的是和運維以及SRE領(lǐng)域相關(guān)的工具和平臺開發(fā)。在Google的SRE體系中，SRE工程師將花費大約一半的時間來開發(fā)新的工具和服務(wù)，這些工具的一部分用于自動化一些手動任務(wù)，而其他部分用于來不斷填補和修復(fù)整個SRE體系內(nèi)部的其他系統(tǒng)。

通過編寫代碼把自己和其他人從重復(fù)的工作中解放出來，如果我們不需要人類來完成任務(wù)，那么就編寫代碼，這樣人類就不需要參與其中了。

SRE從內(nèi)心上鄙視重復(fù)性的工作，將從原有的人工加被動響應(yīng)，轉(zhuǎn)變?yōu)楦咝А⒏鼮樽詣踊倪\維體系。

1 自動化運維框架

2 自動化運維工具的優(yōu)勢和必要性

• 提高效率: 由程序自動化操作，有效地降低運維人力資源的投入，也讓運維人員的精力得以釋放并投向更為重要的領(lǐng)域。
• 操作的標(biāo)準(zhǔn)化: 將原來許多復(fù)雜、易錯的手工操作實現(xiàn)統(tǒng)一運維操作入口，實現(xiàn)運維操作白屏化，提升運維操作的可管理性；同時，減少由于運維人員情緒帶來手工誤操作，避免“從刪庫到跑路”這樣的悲劇的發(fā)生。
• 運維經(jīng)驗?zāi)芰Φ膫鞒? 運維自動化工具將原來許多運維團(tuán)隊積累的經(jīng)驗以代碼方式總結(jié)為各種運維工具，實現(xiàn)自動化和白屏化的運維操作。運維團(tuán)隊的后來者，可以有效地繼承、重復(fù)使用并優(yōu)化它們。這種代碼化的工作傳承，將個人能力轉(zhuǎn)變?yōu)閳F(tuán)隊能力，并減少人員流動帶來對工作的影響。

構(gòu)建自動化運維體系就必須以運維場景為基礎(chǔ)，這些運維場景是在本企業(yè)內(nèi)反復(fù)迭代和打造，是企業(yè)中最常用的運維場景。

比如常見的運維場景：軟件安裝部署、應(yīng)用發(fā)布交付、資產(chǎn)管理、告警自動處理、故障分析、資源申請、自動化巡檢等等。因此，整個自動化運維體系建設(shè)時也應(yīng)支持多種不同類型的自動化作業(yè)配置能力，通過簡單的腳本開發(fā)、場景配置和可視化定制流程實現(xiàn)更多運維場景的實現(xiàn)。

六、用戶支持

用戶體驗這一層要說的是，作為SRE來講，從用戶的角度來保證業(yè)務(wù)的穩(wěn)定性和可用性才是最終目標(biāo)。這個才傳統(tǒng)意義上的運維人員是不會關(guān)注這一點的，因為大家通常只會考慮到我底層運維的系統(tǒng)或底層資源是否穩(wěn)定，但實際上整個業(yè)務(wù)的穩(wěn)定才是SRE需要關(guān)心的問題，而業(yè)務(wù)的穩(wěn)定性和可用性通常需要站在用戶的角度來模擬和衡量整體的可用性和可靠性。

在前面提到的所有SRE相關(guān)的工作范疇，無論是監(jiān)控、事故響應(yīng)、回顧、測試與發(fā)布、容量規(guī)劃以及構(gòu)建自動化工具，無非都是為了提供更好的系統(tǒng)用戶業(yè)務(wù)體驗而服務(wù)的。因此，我們在運維的過程中無不需要注意關(guān)注系統(tǒng)的用戶體驗。

而在實際運維工作中，我們往往可以通過應(yīng)用日志、監(jiān)控數(shù)據(jù)、業(yè)務(wù)探測等業(yè)務(wù)相關(guān)的用戶體驗信息。在運維數(shù)據(jù)平臺中，通過這些用戶體驗監(jiān)測數(shù)據(jù)之間的關(guān)聯(lián)和串聯(lián)，重現(xiàn)用戶的最終業(yè)務(wù)調(diào)用鏈路以及各應(yīng)用環(huán)節(jié)對性能數(shù)據(jù)的關(guān)系。最終形成從業(yè)務(wù)用戶體驗數(shù)據(jù)入手，逐步實現(xiàn)系統(tǒng)運行狀態(tài)數(shù)據(jù)、設(shè)備運行狀態(tài)數(shù)據(jù)鏈路的打通，讓運維體系實現(xiàn)以最終用戶體驗為中心的目標(biāo)。

這些用戶體驗的信息，對于運維團(tuán)隊掌握客戶整體的用戶體驗情況、系統(tǒng)可用性的監(jiān)測以及系統(tǒng)針對性的優(yōu)化提供著無可替代的作用。

其實，SRE運維體系更為強調(diào)以用戶的體驗為核心，以自動化和運維數(shù)據(jù)為手段，實現(xiàn)應(yīng)用業(yè)務(wù)連續(xù)性保障，從這個點出發(fā)，我們會發(fā)現(xiàn)和以往的傳統(tǒng)運維還是有很大的區(qū)別的，我們不再僅僅是單純的安裝和部署工程師，我們需要通過一系列的技術(shù)手段來不斷保障上層業(yè)務(wù)的穩(wěn)定性和可靠性。

七、Oncall

Oncall 簡單來說就是要保證線上服務(wù)的正常運行。典型的工作流程是：收到告警，檢查告警發(fā)出的原因，確認(rèn)線上服務(wù)是否有問題，定位到問題，解決問題。

收到告警并不總意味著真正的問題，也有可能告警設(shè)置的不合理。告警和監(jiān)控面板并不是一個靜態(tài)的配置，它應(yīng)該是每天都在變化的，時刻在調(diào)整的。如果發(fā)現(xiàn)沒有標(biāo)志真正線上問題的告警發(fā)了出來，就應(yīng)該修改告警規(guī)則。如果發(fā)現(xiàn)當(dāng)前的監(jiān)控?zé)o法快速定位問題，應(yīng)該調(diào)整監(jiān)控面板，添加或者刪除監(jiān)控指標(biāo)。業(yè)務(wù)在發(fā)展，請求量在變化，某些閾值也需要不斷地調(diào)整。

定位問題沒有一概而論的方法了，需要根據(jù)看到的實時監(jiān)控數(shù)據(jù)，結(jié)合自己的經(jīng)驗，然后做推測，然后使用工具驗證自己的推測，然后確定問題的根因。

但是解決問題是可以有方法論的，叫做 SOP，標(biāo)準(zhǔn)操作流程。即：如果出現(xiàn)了這種現(xiàn)象，那么執(zhí)行那種操作，就可以恢復(fù)業(yè)務(wù)。SOP 文檔應(yīng)該提前制定，并且驗證其有效性。

需要注意的是上述定位問題、解決問題并沒有順序關(guān)系。一個經(jīng)常犯的錯誤是，在出現(xiàn)故障的時候，花了很長時間定位到故障的根因，然后再修復(fù)。這樣花的時間一般會比較長。正確的做法是先根據(jù)現(xiàn)象看現(xiàn)有的 SOP 能否恢復(fù)業(yè)務(wù)。比如說當(dāng)前錯誤只發(fā)生在某一個節(jié)點上，那么就直接下線這個節(jié)點，具體的原因后面再排查?；謴?fù)當(dāng)前的故障永遠(yuǎn)是第一要務(wù)。但是恢復(fù)操作也要經(jīng)過測試，比如猜測可以通過重啟解決問題的話，可以先重啟一臺做測試，而不是一次性將所有服務(wù)重啟。大部分情況是需要臨場分析的，是一個緊張又刺激的過程。

故障到底多久恢復(fù)算好？出現(xiàn)多少故障是可以容忍的？怎么檢測服務(wù)的穩(wěn)定性到底如何？我們使用 SLI/SLO 來衡量這些問題。

八、制定可交付的SLI/SLO/SLA

SLO 和 SLA 是大家常見的兩個名詞：服務(wù)等級目標(biāo)和服務(wù)等級協(xié)議。

云計算時代，各大云服務(wù)提供商都發(fā)布有自己服務(wù)的 SLA 條款，比如 Amazon 的 EC2 和 S3 服務(wù)都有相應(yīng)的 SLA 條款。這些大公司的 SLA 看上去如此的高大上，一般是怎么定義出來的呢？

說 SLA 不能不提 SLO，這個是眾所周知的，但是還有一個概念知道的人就不多了，那就是 SLI（Service Level Indicator），定義一個可執(zhí)行的 SLA，好的 SLO 和 SLI 是必不可少的。

另外必須要提到的是，SLI/SLO/SLA主要是為服務(wù)指定的，如果沒有服務(wù)作為依托關(guān)系，那這些概念也就失去了原有的意義。

下面是一個 SLA 在制定過程中需要考慮到的一些問題：

例如：設(shè)計一個可用率的時候，并不是說達(dá)到了”4個9“為標(biāo)準(zhǔn)就足夠了，因為我們需要考慮如下問題：

• 如何定義這個可用率？比如我們以可用率 > 99.9% 為目標(biāo)，有一個服務(wù)部署了 5 個 區(qū)域, 那么有一個 區(qū)域 掛了，其余的 區(qū)域 是可用的，那么可用率被破壞了嗎？這個可用率是每一個 區(qū)域 的還是所有的 區(qū)域 一起計算的？
• 可用率計算的最小單位是什么？如果 1min 內(nèi)有 50s 沒有達(dá)到可用率，那么這一分鐘算是 down 還是 up？
• 可用率的周期是怎么計算的？按照一個月還是一個周？一個周是最近的 7 天還是計算一個自然周？
• 如何設(shè)計與規(guī)劃 SLI 和 SLO 監(jiān)控？
• 如果錯誤預(yù)算即將用完，有什么處理措施？比如減少發(fā)布以及配置變更？

1、Service

什么是服務(wù)？

簡單說就是一切提供給客戶的有用功能都可以稱為服務(wù)。

服務(wù)一般會由服務(wù)提供者提供，提供這個有用功能的組織被稱為服務(wù)提供者，通常是人加上軟件，軟件的運行需要計算資源，為了能對外提供有用的功能軟件可能會有對其他軟件系統(tǒng)的依賴。

客戶是使用服務(wù)提供者提供的服務(wù)的人或公司。

2、SLI

SLI 是經(jīng)過仔細(xì)定義的測量指標(biāo)，它根據(jù)不同系統(tǒng)特點確定要測量什么，SLI 的確定是一個非常復(fù)雜的過程。

SLI 的確定需要回答以下幾個問題：

• 要測量的指標(biāo)是什么？
• 測量時的系統(tǒng)狀態(tài)？
• 如何匯總處理測量的指標(biāo)？
• 測量指標(biāo)能否準(zhǔn)確描述服務(wù)質(zhì)量？
• 測量指標(biāo)的可靠度 (trustworthy)？

1）常見的測量指標(biāo)

① 性能

• 響應(yīng)時間 (latency)
• 吞吐量 (throughput)
• 請求量 (qps)
• 實效性 (freshness)

② 可用性

• 運行時間 (uptime)
• 故障時間 / 頻率
• 可靠性

③ 質(zhì)量

• 準(zhǔn)確性 (accuracy)
• 正確性 (correctness)
• 完整性 (completeness)
• 覆蓋率 (coverage)
• 相關(guān)性 (relevance)

④ 內(nèi)部指標(biāo)

• 隊列長度 (queue length)
• 內(nèi)存占用 (RAM usage)

⑤ 因素人

• 響應(yīng)時間 (time to response)
• 修復(fù)時間 (time to fix)
• 修復(fù)率 (fraction fixed)

下面通過一個例子來說明一下：hotmail 的 downtime SLI

• 錯誤率 (error rate) 計算的是服務(wù)返回給用戶的 error 總數(shù)；
• 如果錯誤率大于 X%，就算是服務(wù) down 了，開始計算 downtime；
• 如果錯誤率持續(xù)超過 Y 分鐘，這個 downtime 就會被計算在內(nèi)；
• 間斷性的小于 Y 分鐘的 downtime 是不被計算在內(nèi)的。

2）測量時的系統(tǒng)狀態(tài)，在什么情況下測量會嚴(yán)重影響測量的結(jié)果？

• 測量異常 (badly-formed) 請求，還是失敗 (fail) 請求還是超時請求 (timeout)；
• 測量時的系統(tǒng)負(fù)載（是否最大負(fù)載）；
• 測量的發(fā)起位置，服務(wù)器端還是客戶端；
• 測量的時間窗口（僅工作日、還是一周 7 天、是否包括計劃內(nèi)的維護(hù)時間段）。

3）如何匯總處理測量的指標(biāo)？

• 計算的時間區(qū)間是什么：是一個滾動時間窗口，還是簡單的按照月份計算；
• 使用平均值還是百分位值，比如：某服務(wù) X 的 ticket 處理響應(yīng)時間 SLI 的；
• 測量指標(biāo)：統(tǒng)計所有成功解決請求，從用戶創(chuàng)建 ticket 到問題被解決的時間；
• 怎么測量：用 ticket 自帶的時間戳，統(tǒng)計所有用戶創(chuàng)建的 ticket；
• 什么情況下的測量：只包括工作時間，不包含法定假日；
• 用于 SLI 的數(shù)據(jù)指標(biāo)：以一周為滑動窗口，95% 分位的解決時間。

4）測量指標(biāo)能否準(zhǔn)確描述服務(wù)質(zhì)量？

• 性能：時效性、是否有偏差
• 準(zhǔn)確性：精度、覆蓋率、數(shù)據(jù)穩(wěn)定性
• 完整性：數(shù)據(jù)丟失、無效數(shù)據(jù)、異常 (outlier) 數(shù)據(jù)

5）測量指標(biāo)的可靠度

• 是否服務(wù)提供者和客戶都認(rèn)可；
• 是否可被獨立驗證，比如三方機構(gòu)；
• 客戶端還是服務(wù)器端測量，取樣間隔；
• 錯誤請求是如何計算的。

3、SLO

**SLO (服務(wù)等級目標(biāo)) ** 指定了服務(wù)所提供功能的一種期望狀態(tài)。SLO 里面應(yīng)該包含什么呢？所有能夠描述服務(wù)應(yīng)該提供什么樣功能的信息。

服務(wù)提供者用它來指定系統(tǒng)的預(yù)期狀態(tài)；開發(fā)人員編寫代碼來實現(xiàn)；客戶依賴于 SLO 進(jìn)行商業(yè)判斷。SLO 里沒有提到，如果目標(biāo)達(dá)不到會怎么樣。

SLO 是用 SLI 來描述的，一般描述為：

比如以下 SLO：

• 每分鐘平均 qps > 100k/s
• 99% 訪問延遲 < 500ms
• 99% 每分鐘帶寬 > 200MB/s

設(shè)置 SLO 時的幾個最佳實踐：

① 指定計算的時間窗口

② 使用一致的時間窗口 (XX 小時滾動窗口、季度滾動窗口)

③ 要有一個免責(zé)條款，比如：95% 的時間要能夠達(dá)到 SLO

④ 如果 Service 是第一次設(shè)置 SLO，可以遵循以下原則

⑤ 測量系統(tǒng)當(dāng)前狀態(tài)

• 設(shè)置預(yù)期 (expectations)，而不是保證 (guarantees)
• 初期的 SLO 不適合作為服務(wù)質(zhì)量的強化工具

⑥ 改進(jìn) SLO

• 設(shè)置更低的響應(yīng)時間、更改的吞吐量等

⑦ 保持一定的安全緩沖

• 內(nèi)部用的 SLO 要高于對外宣稱的 SLO

⑧ 不要超額完成

• 定期的 downtime 來使 SLO 不超額完成

設(shè)置 SLO 時的目標(biāo)依賴于系統(tǒng)的不同狀態(tài) (conditions)，根據(jù)不同狀態(tài)設(shè)置不同的 SLO：**總 SLO = service1.SLO1 weight1 + service2.SLO2 weight2 + …

為什么要有 SLO，設(shè)置 SLO 的好處是什么呢？

① 對于客戶而言，是可預(yù)期的服務(wù)質(zhì)量，可以簡化客戶端的系統(tǒng)設(shè)計

② 對于服務(wù)提供者而言

• 可預(yù)期的服務(wù)質(zhì)量
• 更好的取舍成本 / 收益
• 更好的風(fēng)險控制 (當(dāng)資源受限的時候)
• 故障時更快的反應(yīng)，采取正確措施
• SLO 設(shè)好了，怎么保證能夠達(dá)到目標(biāo)呢？
• 需要一個控制系統(tǒng)來：

監(jiān)控 / 測量 SLIs 對比檢測到的 SLIs 值是否達(dá)到目標(biāo)，如果需要，修正目標(biāo)或者修正系統(tǒng)以滿足目標(biāo)需要 實施目標(biāo)的修改或者系統(tǒng)的修改 該控制系統(tǒng)需要重復(fù)的執(zhí)行以上動作，以形成一個標(biāo)準(zhǔn)的反饋環(huán)路，不斷的衡量和改進(jìn) SLO / 服務(wù)本身。

我們討論了目標(biāo)以及目標(biāo)是怎么測量的，還討論了控制機制來達(dá)到設(shè)置的目標(biāo)，但是如果因為某些原因，設(shè)置的目標(biāo)達(dá)不到該怎么辦呢？

也許是因為大量的新增負(fù)載；也許是因為底層依賴不能達(dá)到標(biāo)稱的 SLO 而影響上次服務(wù)的 SLO。這就需要 SLA 出場了。

4、SLA

SLA 是一個涉及 2 方的合約，雙方必須都要同意并遵守這個合約。當(dāng)需要對外提供服務(wù)時，SLA 是非常重要的一個服務(wù)質(zhì)量信號，需要產(chǎn)品和法務(wù)部門的同時介入。

SLA 用一個簡單的公式來描述就是：SLA = SLO + 后果

• SLO 不能滿足的一系列動作，可以是部分不能達(dá)到

比如：達(dá)到響應(yīng)時間 SLO + 未達(dá)到可用性 SLO

• 對動作的具體實施

需要一個通用的貨幣來獎勵 / 懲罰，比如：績效得分等

SLA 是一個很好的工具，可以用來幫助合理配置資源。一個有明確 SLA 的服務(wù)最理想的運行狀態(tài)是：增加額外資源來改進(jìn)系統(tǒng)所帶來的收益小于把該資源投給其他服務(wù)所帶來的收益。

一個簡單的例子就是某服務(wù)可用性從 99.9% 提高到 99.99% 所需要的資源和帶來的收益之比，是決定該服務(wù)是否應(yīng)該提供 4 個 9 的重要依據(jù)。

九、故障復(fù)盤

故障復(fù)盤就是對于過去的一些服務(wù)異常和服務(wù)中斷情況進(jìn)行回顧和總結(jié)，以確保相同問題下次不會再出現(xiàn)。為了讓大家團(tuán)結(jié)協(xié)作，我們希望建立一種無指責(zé)、透明的事后文化。個人不應(yīng)該害怕事故，而是確信如果事故發(fā)生，團(tuán)隊將會響應(yīng)和改進(jìn)系統(tǒng)。

備注: 其實在國內(nèi)的SRE文化中，一般只有對大型，對業(yè)務(wù)有重大影響的事故才會進(jìn)行復(fù)盤，但實際上如果在時間和經(jīng)歷允許的情況下，對于一般的普通事故也應(yīng)該在小范圍進(jìn)行復(fù)盤，正所謂大的故障都是從不斷的小問題一點一點積累的。另外，其實對于運維相關(guān)的個人而言，我們也應(yīng)當(dāng)及時的進(jìn)行小故障復(fù)盤，以不斷加強個人的故障處理和修復(fù)能力。

我認(rèn)為SRE的一個關(guān)鍵共識正是承認(rèn)了系統(tǒng)的不完美性，追求永不停機的系統(tǒng)是不現(xiàn)實的。基于不完美系統(tǒng)，我們無可避免要面對和經(jīng)歷系統(tǒng)故障與失敗。

所以我們重要的并非找到為這個故障責(zé)任的這個人或者那個人，而是更應(yīng)該刨根問底地復(fù)盤這個故障和失敗的根本原因是什么，以及如何避免再次出現(xiàn)相同的故障。系統(tǒng)可靠性是整個團(tuán)隊共同奮斗的方向，從失敗中快速恢復(fù)并吸取教訓(xùn)，每個人放心地提出問題，應(yīng)對停機，并努力改進(jìn)系統(tǒng)。

備注: 通常很多企業(yè)內(nèi)部在故障復(fù)盤過程中，相關(guān)人員可能將故障和失敗的根因追溯 不經(jīng)意間 當(dāng)做了故障定責(zé)和一系列的懲罰措施，通過一些懲戒措施來強行約定故障的發(fā)生，這種方式往往是非常不可取的，試想每個人都不想出現(xiàn)事故，要么是認(rèn)知之外，要么是規(guī)則缺陷，永遠(yuǎn)沒有一個人明知會有故障而偏偏去制造故障的。

需要牢記的是: 故障是我們可以從中學(xué)習(xí)的東西，而不是讓人害怕和羞恥的事情！

在日常運維過程中，出現(xiàn)故障等事故對于我們而言其實是一個很好的復(fù)盤學(xué)習(xí)機會。通過歷史監(jiān)控數(shù)據(jù)，分析事故其中的根本原因，制定后續(xù)應(yīng)對策略，并且通過運維平臺將這些應(yīng)對策略編輯成標(biāo)準(zhǔn)化、可重用、自動化的運維應(yīng)用場景，為后續(xù)相同問題的處理提供標(biāo)準(zhǔn)且快捷的解決方案。這正是事后回顧這個過程最真實的價值體現(xiàn)。

故障復(fù)盤的唯一目的是減少故障的發(fā)生。有幾個我目前認(rèn)為不錯的做法。

故障復(fù)盤需要有文檔記錄，包括故障發(fā)生的過程，時間線的記錄，操作的記錄，故障恢復(fù)的方法，故障根因的分析，為什么故障會發(fā)生的分析。文檔應(yīng)該隱去所有當(dāng)事人的姓名對公司的所有人公開。很多公司對故障文檔設(shè)置查看權(quán)限，我覺得沒什么道理。有些公司的故障復(fù)盤甚至對外也是公開的。

故障在復(fù)盤的時候應(yīng)該將當(dāng)事人的名字用代碼替代，可以營造更好的討論氛圍。

不應(yīng)該要求所有的故障復(fù)盤都產(chǎn)生 Action。之前一家的公司的故障復(fù)盤上，因為必須給領(lǐng)導(dǎo)一個“交待”，所以每次都會產(chǎn)生一些措施來預(yù)防相同的故障再次發(fā)生，比如增加審批流程之類的。這很扯，讓級別很高的領(lǐng)導(dǎo)審批他自己也看不懂的操作，只能讓領(lǐng)導(dǎo)更痛苦，也讓操作流程變得又臭又長，最后所有人都會忘記這里為什么會有一個審批，但是又沒有人敢刪掉。你刪掉，出了事情你負(fù)責(zé)。

Blame Free 文化？之前我認(rèn)為是好的。但是后來發(fā)現(xiàn)，有些不按照流程操作導(dǎo)致的問題確實多少應(yīng)該 Blame 一下，比如下線服務(wù)的時候沒有檢查還沒有 tcp 連接就直接下線了，或者操作的時候沒有做 canary 就全部操作了，這種不理智的行為導(dǎo)致的故障。但是條條框框又不應(yīng)該太多，不然活都沒法干了。