Google在10年前創(chuàng)造了SRE這個(gè)工種。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)境以及整個(gè)SRE的方法論。那么如何從零搭建一套SRE體系呢？下面內(nèi)容主要介紹了站點(diǎn)可靠性工程（SRE）以及如何在系統(tǒng)擴(kuò)展時(shí)監(jiān)控和保持系統(tǒng)快速可靠。

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

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

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

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

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

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

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

• 可用性
• 延遲
• 性能
• 效率
• 變更管理
• 監(jiān)控和告警
• 應(yīng)急響應(yīng)
• 事件響應(yīng)
• 準(zhǔn)備工作
• 容量規(guī)劃

一、那么，什么是站點(diǎn)可靠性工程（SRE）？

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

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

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

• 使部署更加容易
• 提高或維持正常運(yùn)行時(shí)間
• 針對應(yīng)用性能去建設(shè)可視化能力
• 設(shè)置SLI和SLO以及錯(cuò)誤預(yù)算
• 通過承擔(dān)計(jì)算風(fēng)險(xiǎn)來提高速度
• 消除手動(dòng)操作任務(wù)
• 降低故障成本以縮短新功能的周期時(shí)間

二、SLI和SLO

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

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

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

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

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

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

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

圖二 用9展示SRE

99.9%是三個(gè)9的正常運(yùn)行時(shí)間，允許每天有1.44s的停機(jī)時(shí)間。如上表所示，每周、每月和每年的停機(jī)時(shí)間分別為10.1分鐘、43.8分鐘和8.78小時(shí)。

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

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

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

五、錯(cuò)誤預(yù)算

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

延遲

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

流量

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

錯(cuò)誤

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

飽和度

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

利用率

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

圖三 黃金信號

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

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

• 告警可以通知你出現(xiàn)問題。
• 故障排除可以幫助找到并解決問題，分析根本原因。
• 調(diào)整和容量規(guī)劃可以幫助隨著時(shí)間的推移使用正確的指標(biāo)、日志和從監(jiān)控系統(tǒng)收集的跟蹤來改善問題。

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

圖五 黃金信號之錯(cuò)誤和飽和

七、風(fēng)險(xiǎn)分析

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

• TDD： 檢測時(shí)間（time-to-detect）
• TTR： 修復(fù)時(shí)間（time-to-resolve）
• Freq/Yr： 每年的錯(cuò)誤頻率（frequency of error per year）
• Users： 受影響的用戶
• Bad/Yr： 每年有異常的分鐘數(shù)，相當(dāng)于錯(cuò)誤預(yù)算

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

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

If TTD = 0,

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

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

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

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

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

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

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

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

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

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

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

SRE團(tuán)隊(duì)的角色是運(yùn)維應(yīng)用程序并通過執(zhí)行必要的操作來保持系統(tǒng)正常運(yùn)行。以下是SRE在各個(gè)階段執(zhí)行日常活動(dòng)的一些策略和工具：

階段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

• 灰度部署和自動(dòng)回滾（Canary deployment + automated rollbacks）
• 負(fù)載和擴(kuò)展執(zhí)行（Load and scale implementation）
• 應(yīng)用性能監(jiān)控（APM）
• 混沌引擎（Chaos engineering）

十一、結(jié)論

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