那個沒被云原生干掉的運維，轉(zhuǎn)頭就做了SRE……

作者：張亞龍 2022-06-10 10:49:16

云計算

云原生

新聞 本文主要介紹了站點可靠性工程（SRE）以及如何在系統(tǒng)擴展時監(jiān)控和保持系統(tǒng)快速可靠。

創(chuàng)新互聯(lián)公司從2013年創(chuàng)立，是專業(yè)互聯(lián)網(wǎng)技術(shù)服務公司，擁有項目成都網(wǎng)站設計、成都網(wǎng)站制作網(wǎng)站策劃，項目實施與項目整合能力。我們以讓每一個夢想脫穎而出為使命，1280元華池做網(wǎng)站,已為上家服務,為華池各地企業(yè)和個人服務,聯(lián)系電話:18980820575

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)思維導圖

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

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

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

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

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

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

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

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

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

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

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

• 使部署更加容易
• 提高或維持正常運行時間
• 針對應用性能去建設可視化能力
• 設置SLI和SLO以及錯誤預算
• 通過承擔計算風險來提高速度
• 消除手動操作任務
• 降低故障成本以縮短新功能的周期時間

二、SLI和SLO

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

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

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

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

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

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

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

圖二 用9展示SRE

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

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

四、減輕工作負擔并控制SRE團隊的工作量

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

五、錯誤預算

錯誤預算是SRE團隊用來平衡服務可靠性的工具，計算如下：

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

誤差預算是100減去服務的SLO。99.99%的SLO服務有0.01%的誤差預算。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

延遲

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

流量

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

錯誤

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

飽和度

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

利用率

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

圖三 黃金信號

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

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

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

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

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

七、風險分析

風險分析定義如下：可能導致違反SLO的項目列表。

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

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

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

If TTD = 0,

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

圖六 風險分析和度量

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

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

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

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

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

九、促進事后分析

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

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

十、如何獲取一個可靠的服務？

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

階段1：Development

• 流水線（Pipelining）
• 負載和容量考量（load and scale）

階段2：Pilot

• 監(jiān)控（Monitoring）
• 輪值和無指責的事后分析（On-call + blameless postmortems）
• 聚合和可檢索的日志系統(tǒng)（Consolidated + searchable logging）
• 和產(chǎn)品負責人定期審查 SLI/SLO
• 基礎設施即代碼（Infrastructure as code）

階段3：Production

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

十一、結(jié)論

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

網(wǎng)站名稱：那個沒被云原生干掉的運維，轉(zhuǎn)頭就做了SRE……
網(wǎng)頁鏈接：http://fisionsoft.com.cn/article/ccdogoc.html