Google在10年前創(chuàng)造了SRE這個工種。SRE，Site Reliability Engineering的縮寫，其中site是指Website，可以翻譯為網(wǎng)站可靠性工程。幾年前資深Google SRE Chris Jones等人聯(lián)合撰寫了《Google SRE: How Google runs production systems》，首次向外界解密了Google的生產(chǎn)環(huán)境以及整個SRE的方法論。那么如何從零搭建一套SRE體系呢？下面內(nèi)容主要介紹了站點可靠性工程（SRE）以及如何在系統(tǒng)擴展時監(jiān)控和保持系統(tǒng)快速可靠。

編輯搜圖

圖1 構(gòu)建SRE架構(gòu)思維導(dǎo)圖

在云時代，客戶體驗是所有重要企業(yè)的新口號，即使命宣言?？蛻趔w驗、可用性和可訪問性是在端決定的，在這里站點應(yīng)當(dāng)始終可用 [24/7/365]。 對用戶來說，可靠性才是最重要的； 一個未使用的應(yīng)用程序?qū)τ脩艉推髽I(yè)毫無價值。

如今，每家公司都在努力推動科技變革。公司業(yè)務(wù)戰(zhàn)略都圍繞云功能構(gòu)建。這對他們來說是一項重大的運維挑戰(zhàn)。站點性能下降、客戶體驗的下降都將導(dǎo)致現(xiàn)金、收入和競爭力的損失，并導(dǎo)致傳統(tǒng)運維無法應(yīng)對可觀察性的大問題（包括實時監(jiān)控和告警）。

為什么存在站點可靠性工程（SRE）？敏捷運動提升了跨職能團(tuán)隊之間協(xié)作的重要性，這催生了DevOps。

DevOps是關(guān)于深入研究自己組織的具體問題和挑戰(zhàn)的。它還與速度、效率和質(zhì)量有關(guān)。從本質(zhì)上講，它是一種以實現(xiàn)組織的預(yù)期結(jié)果的文化、一種運動、一種價值觀、原則、方法和實踐。

這種速度也造成了一定的不穩(wěn)定性， 開發(fā)人員的行動速度比以往任何時候都快了，但卻給運維團(tuán)隊帶來了挑戰(zhàn)。IT運維團(tuán)隊沒有能力應(yīng)對這樣的速度，這讓他們遇到了瓶頸和嚴(yán)重的積壓，導(dǎo)致生產(chǎn)中產(chǎn)生了不穩(wěn)定的因素，結(jié)果使系統(tǒng)變得不可靠。因此，Google提出了對SRE的要求：“一群能夠?qū)⒐こ虒I(yè)知識應(yīng)用于運維問題的開發(fā)人員?！?

SRE是一種規(guī)范的DevOps方式。 它是系統(tǒng)管理任務(wù)的一種思維方式，側(cè)重于通過縮短交付周期和事件管理生命周期，并通過減少工作量來支持開發(fā)人員和運維人員來運維服務(wù)的原則。SRE團(tuán)隊的日常任務(wù)包括：

• 可用性

• 延遲

• 性能

• 效率

• 變更管理

• 監(jiān)控和告警

• 應(yīng)急響應(yīng)

• 事件響應(yīng)

• 準(zhǔn)備工作

• 容量規(guī)劃

一、那么，什么是站點可靠性工程（SRE）？

SRE團(tuán)隊的角色是在生產(chǎn)“關(guān)鍵任務(wù)系統(tǒng)”中運行應(yīng)用程序，并執(zhí)行任何必要的事情來保持站點正常運行。它通常被定義為從事運維工作的軟件工程師。SRE團(tuán)隊負(fù)責(zé)維護(hù)和建立其系統(tǒng)的服務(wù)水平指標(biāo)（SLI）、目標(biāo)（SLO）、協(xié)議（SLA）和錯誤預(yù)算，并確保滿足這些指標(biāo)。

他們預(yù)計將花費一定的時間進(jìn)行運維工作（確保系統(tǒng)按期工作）并改進(jìn)他們管理的系統(tǒng)。SRE專注于編寫軟件來自動化流程并減少“臟活累活”的工作量。這個“臟活累活”就是目前還未實現(xiàn)系統(tǒng)自動化并且需要手動處理的工作。

SRE 的戰(zhàn)略目標(biāo)是：

• 使部署更加容易

• 提高或維持正常運行時間

• 針對應(yīng)用性能去建設(shè)可視化能力

• 設(shè)置SLI和SLO以及錯誤預(yù)算

• 通過承擔(dān)計算風(fēng)險來提高速度

• 消除手動操作任務(wù)

• 降低故障成本以縮短新功能的周期時間

二、SLI和SLO

服務(wù)水平目標(biāo)（SLO）只是SRE團(tuán)隊與產(chǎn)品所有者或業(yè)務(wù)線（LOB）之間的協(xié)議。指標(biāo)在很大程度上取決于團(tuán)隊管理的系統(tǒng)的性質(zhì)。服務(wù)水平指標(biāo)（SLI）是為系統(tǒng)定義的量化指標(biāo)，也稱為“我們正在度量的內(nèi)容”。

這些指標(biāo) 取決于所管理的系統(tǒng)。 對于典型的Web應(yīng)用程序，這些指標(biāo)可能是可用性、請求延遲或錯誤率。但是，例如Hyperledger Fabric區(qū)塊鏈應(yīng)用程序可能會使用每秒背書和分類帳提交率來衡量網(wǎng)絡(luò)的吞吐量。

SRE團(tuán)隊最終將管理多個系統(tǒng)。 跨各種應(yīng)用程序定義一組標(biāo)準(zhǔn)的服務(wù)水平指標(biāo)將幫助團(tuán)隊標(biāo)準(zhǔn)化整個堆棧的監(jiān)控、日志記錄和自動化。

SLO是系統(tǒng)應(yīng)該運行的“應(yīng)該有多好”的目標(biāo)值或范圍。這些是之前定義的SLI的預(yù)期操作值。例如，區(qū)塊鏈網(wǎng)絡(luò)必須以不到5秒的端到端延遲來維持50到100個事務(wù)提交速率的事務(wù)吞吐量。當(dāng)然這也有可能存在過度設(shè)計SLI和SLO的傾向。一開始就讓它們保持簡單是很重要的。隨著你對系統(tǒng)的了解隨著時間的推移而增長，你可以設(shè)定更嚴(yán)格的目標(biāo)。

三、SLA關(guān)鍵業(yè)務(wù)價值

當(dāng)客戶對所提供的服務(wù)不滿意，未能按照相關(guān)協(xié)議交付時，服務(wù)水平協(xié)議（SLA）就會發(fā)揮作用；它可能是一個系統(tǒng)的可靠性。SLA是產(chǎn)品與其最終用戶之間的協(xié)議，是與客戶就服務(wù)可靠性簽訂的合同，簡單表述為“SLA = SLO + consequences”。 SRE團(tuán)隊可能不參與定義SLA的過程，但是他們需要確保滿足SLO。

SLA通常包含一段時間內(nèi)服務(wù)正常運行時間的計算。

圖二 用9展示SRE

99.9%是三個9的正常運行時間，允許每天有1.44s的停機時間。如上表所示，每周、每月和每年的停機時間分別為10.1分鐘、43.8分鐘和8.78小時。

例如，SLA可以保證電信線路99.9%的正常運行時間；因此，服務(wù)只能減少0.1%的停機時間，超過這一時間將被視為違反SLA，后果將是罰款。

四、減輕工作負(fù)擔(dān)并控制SRE團(tuán)隊的工作量

SRE團(tuán)隊中總會存在一些手動、乏味的事情需要執(zhí)行。在你的日常工作中，無論你是軟件開發(fā)人員還是架構(gòu)師，你都需要完成自己不喜歡的這類任務(wù)。這些通常是 手動的、無聊的和重復(fù)的任務(wù)也可能會導(dǎo)致錯誤。 SRE團(tuán)隊也必須執(zhí)行類似的任務(wù)。這是SRE可以使用他們的開發(fā)技能并盡可能消除手動流程的一個實例。讓SRE花費多達(dá)50%的時間來改進(jìn)他們管理的系統(tǒng)是一種很好的做法。

五、錯誤預(yù)算

錯誤預(yù)算是SRE團(tuán)隊用來平衡服務(wù)可靠性的工具，計算如下：

Availability = (Number of good events / Total events) * 100
Error budget = (100 — Availability) = failed requests / (successful requests + failed requests)1.2.

誤差預(yù)算是100減去服務(wù)的SLO。99.99%的SLO服務(wù)有0.01%的誤差預(yù)算。

錯誤預(yù)算是SLO的另一個例子，其中每個服務(wù)都受其帶有懲罰條款的服務(wù)級別協(xié)議的約束。它衡量你有多少空間來滿足你的另一個SLO。

例如，如果你有一個服務(wù)級別指示器，它顯示99.99%的交易必須在5秒內(nèi)提交記賬，則只有0.01%的交易可以超過5秒。一個主要版本發(fā)布后，你可能會意識到系統(tǒng)運行開始緩慢，突然耗盡你所有的錯誤預(yù)算。

請記住， 變更是中斷的最重要原因，發(fā)布是變更的主要來源。 如果你一直超出你的誤差預(yù)算，你將需要重新審視你的一些SLO和過程。

你是否在單個版本中引入了太多更改？請保持簡單，并將你的版本分成更小的需求變更。

SLO是否過于嚴(yán)格？你可能需要協(xié)商并放寬SLO。

你的發(fā)布過程中是否有任何導(dǎo)致問題的手動步驟？嘗試引入自動化和測試。

系統(tǒng)的架構(gòu)是否容錯？硬件故障、網(wǎng)絡(luò)包丟失、上游或下游應(yīng)用程序可能會出現(xiàn)異常行為。你的系統(tǒng)架構(gòu)應(yīng)該能夠容忍這些故障。

開發(fā)團(tuán)隊是否解決了技術(shù)債問題？在急于發(fā)布新功能時，技術(shù)債常常被忽視。

你的監(jiān)控和告警是否抓住了主要指標(biāo)？不斷增長的隊列規(guī)模、網(wǎng)絡(luò)速度變慢、潛在客戶變更過多等都可能導(dǎo)致下游事件。

你是否定期監(jiān)控日志并保持其清潔？你的日志中可能存在不會立即導(dǎo)致問題的警告。但是，再加上其他基礎(chǔ)設(shè)施問題，這些告警可能會導(dǎo)致重大事故。

六、監(jiān)控分布式系統(tǒng)的四個黃金指標(biāo)

SRE的四個黃金指標(biāo)是構(gòu)建成功的監(jiān)控和告警系統(tǒng)的一些基本原則和最佳實踐。它們是大型生產(chǎn)應(yīng)用程序的服務(wù)級別目標(biāo)（SLO）的關(guān)鍵部分。他們的目標(biāo)是 幫助識別和修復(fù)你系統(tǒng)中的任何潛在問題。

他們主動解決你的基礎(chǔ)架構(gòu)問題，每當(dāng)你的運維團(tuán)隊需要快速了解問題，并需要近乎實時地跟蹤所有服務(wù)的延遲、流量、錯誤和飽和度時。

讓我們簡要描述每個指標(biāo)，然后看看如何利用四個關(guān)鍵指標(biāo)來監(jiān)控你的系統(tǒng)：

延遲

延遲是信息發(fā)送方和接收方之間的時間延遲，以毫秒（ms）為單位。而原因往往是由于數(shù)據(jù)包丟失網(wǎng)絡(luò)擁塞和網(wǎng)絡(luò)抖動造成的，稱為“數(shù)據(jù)包延遲差異”延遲對客戶體驗有直接影響，轉(zhuǎn)化為成功請求的延遲和失敗請求的延遲。

流量

流量是系統(tǒng)工作量帶來的壓力。它通過每秒查詢數(shù)（QPS）或每秒事務(wù)數(shù)（TPS）來衡量。企業(yè)通過數(shù)量來衡量這一點：關(guān)鍵績效指標(biāo)（KPI）是在給定時間來到站點的人數(shù)。這與商業(yè)價值有直接關(guān)系。

錯誤

錯誤是根據(jù)整個系統(tǒng)中發(fā)生的錯誤來衡量的。被認(rèn)為是服務(wù)錯誤率的重要指標(biāo)！有兩類錯誤：顯式錯誤，如失敗的HTTP請求（500個錯誤代碼，例如）；隱含錯誤是成功的響應(yīng)，但內(nèi)容錯誤或響應(yīng)時間長。

飽和度

飽和度定義了服務(wù)的過載程度。它衡量系統(tǒng)利用率，強調(diào)服務(wù)的資源和整體容量。這通常適用于CPU利用率、內(nèi)存使用、磁盤容量和每秒操作數(shù)等資源。儀表板和監(jiān)控警報是幫助你密切關(guān)注這些資源并幫助你在容量飽和之前主動調(diào)整容量的理想工具。

利用率

雖然不是公認(rèn)的“四大黃金指標(biāo)”的一部分，但值得一提；利用率表明資源或系統(tǒng)有多忙。它以百分比表示，范圍從0到100%。

圖三 黃金信號

我們都同意這些指標(biāo)很重要，必須加以監(jiān)控。那么如何開始？為簡單起見，讓我們創(chuàng)建一個非?；镜木仃?，首先考慮非?；竞蛡鹘y(tǒng)的資源，例如CPU、磁盤、網(wǎng)絡(luò)和RAM。

黃金指標(biāo)的優(yōu)勢在于它能夠發(fā)出告警、排除故障以及調(diào)整和容量規(guī)劃：

• 告警可以通知你出現(xiàn)問題。

• 故障排除可以幫助找到并解決問題，分析根本原因。

• 調(diào)整和容量規(guī)劃可以幫助隨著時間的推移使用正確的指標(biāo)、日志和從監(jiān)控系統(tǒng)收集的跟蹤來改善問題。

編輯搜圖

圖四 黃金信號之網(wǎng)絡(luò)和延遲

編輯搜圖

圖五 黃金信號之錯誤和飽和

七、風(fēng)險分析

風(fēng)險分析定義如下：可能導(dǎo)致違反SLO的項目列表。

• TDD： 檢測時間（time-to-detect）

• TTR： 修復(fù)時間（time-to-resolve）

• Freq/Yr： 每年的錯誤頻率（frequency of error per year）

• Users： 受影響的用戶

• Bad/Yr： 每年有異常的分鐘數(shù)，相當(dāng)于錯誤預(yù)算

SRE通過使用錯誤預(yù)算來控制可接受的風(fēng)險級別和風(fēng)險并做出明智的決策，從而以可控的方式接受風(fēng)險關(guān)于何時應(yīng)結(jié)合SLI和SLO進(jìn)行更改。如果需要，SRE團(tuán)隊可以控制發(fā)布周期。

Risk = TTD * TTR * (Freq /Yr) * (% of users)

If TTD = 0,

Risk = TTR * (Freq /Yr) * (% of users)1.2.3.4.5.

圖六 風(fēng)險分析和度量

八、監(jiān)控和告警

監(jiān)控是觀察系統(tǒng)運行方式的一種好方法，告警是系統(tǒng)崩潰或即將崩潰時可以觸發(fā)的事件。因此，SRE團(tuán)隊必須構(gòu)建 可靠且有意義的監(jiān)控系統(tǒng)。 我們可以使用一些工具來構(gòu)建良好的監(jiān)控系統(tǒng)。Prometheus是一個開源應(yīng)用程序，用于事件監(jiān)控和告警。它在使用HTTP拉模型構(gòu)建的時間序列數(shù)據(jù)庫中記錄實時指標(biāo)。例如，Prometheus可以配置為從Hyperledger Fabric區(qū)塊鏈節(jié)點提取指標(biāo)。

編輯搜圖

圖七 監(jiān)控和告警

你可以配置Grafana來構(gòu)建可視化和儀表板來查詢Prometheus。

編輯搜圖

圖八 使用“四個黃金信號”監(jiān)控服務(wù)的示例Grafana儀表板

九、促進(jìn)事后分析

當(dāng)你在組織中構(gòu)建SRE角色時，一個重要但經(jīng)常被遺忘的方面是事后分析，“事后分析是無可指責(zé)的”。它可以被定義為一個組織從它所犯的錯誤中吸取教訓(xùn)的機會。 故障解決后應(yīng)盡快進(jìn)行事后分析以及復(fù)盤。 在復(fù)雜的企業(yè)IT環(huán)境中，組件和應(yīng)用程序最終會失敗，這些失敗可能是由于部署錯誤，最近版本中引入的軟件bug或僅僅是硬件故障。

將事件的根本原因和短長期修復(fù)方案一起歸檔，并在開發(fā)和SRE團(tuán)隊中進(jìn)行傳播，這對于知識在企業(yè)的傳承顯得很重要。故障的發(fā)現(xiàn)可以用作其他系統(tǒng)的預(yù)防性修復(fù)，也可以作為未來類似事件的參考點。事后分析如果做得好，這些分析應(yīng)該被記錄，并用于建設(shè)內(nèi)部知識庫，便于以后查詢。

十、如何獲取一個可靠的服務(wù)？

SRE團(tuán)隊的角色是運維應(yīng)用程序并通過執(zhí)行必要的操作來保持系統(tǒng)正常運行。以下是SRE在各個階段執(zhí)行日?；顒拥囊恍┎呗院凸ぞ撸?

階段1：Development

• 流水線（Pipelining）

• 負(fù)載和容量考量（load and scale）

階段2：Pilot

• 監(jiān)控（Monitoring）

• 輪值和無指責(zé)的事后分析（On-call + blameless postmortems）

• 聚合和可檢索的日志系統(tǒng)（Consolidated + searchable logging）

• 和產(chǎn)品負(fù)責(zé)人定期審查 SLI/SLO

• 基礎(chǔ)設(shè)施即代碼（Infrastructure as code）

階段3：Production

• 灰度部署和自動回滾（Canary deployment + automated rollbacks）

• 負(fù)載和擴展執(zhí)行（Load and scale implementation）

• 應(yīng)用性能監(jiān)控（APM）

• 混沌引擎（Chaos engineering）

十一、結(jié)論

所以，可靠運行是什么意思？這篇博文試圖涵蓋構(gòu)建成功SRE團(tuán)隊所需的基本概念和技術(shù)。討論了如何通過改進(jìn)的指標(biāo)、日志、跟蹤和儀表板關(guān)注可觀察性來主動識別和補救事件以及什么是SLO、SLI和SLA。了解如何使用錯誤預(yù)算和風(fēng)險分析等基本工具來指導(dǎo)必要的決策，以平衡你對可靠性的投入與對應(yīng)用程序功能或其他業(yè)務(wù)優(yōu)先級的投入。最后文中詳細(xì)闡述了監(jiān)控分布式系統(tǒng)的四個黃金指標(biāo)。