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

圖1 構建SRE架構思維導圖

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

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

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

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

這種速度也造成了一定的不穩定性， 開發人員的行動速度比以往任何時候都快了，但卻給運維團隊帶來了挑戰。IT運維團隊沒有能力應對這樣的速度，這讓他們遇到了瓶頸和嚴重的積壓，導致生產中產生了不穩定的因素，結果使系統變得不可靠。因此，Google提出了對SRE的要求：“一群能夠將工程專業知識應用于運維問題的開發人員。”

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

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

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

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

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

SRE 的戰略目標是：

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

二、SLI和SLO

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

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

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

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

三、SLA關鍵業務價值

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

SLA通常包含一段時間內服務正常運行時間的計算。

圖二 用9展示SRE

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

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

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

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

五、錯誤預算

錯誤預算是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的另一個例子，其中每個服務都受其帶有懲罰條款的服務級別協議的約束。它衡量你有多少空間來滿足你的另一個SLO。

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

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

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

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

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

系統的架構是否容錯？硬件故障、網絡包丟失、上游或下游應用程序可能會出現異常行為。你的系統架構應該能夠容忍這些故障。

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

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

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

六、監控分布式系統的四個黃金指標

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

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

讓我們簡要描述每個指標，然后看看如何利用四個關鍵指標來監控你的系統：

延遲

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

流量

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

錯誤

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

飽和度

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

利用率

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

圖三 黃金信號

我們都同意這些指標很重要，必須加以監控。那么如何開始？為簡單起見，讓我們創建一個非常基本的矩陣，首先考慮非常基本和傳統的資源，例如CPU、磁盤、網絡和RAM。

黃金指標的優勢在于它能夠發出告警、排除故障以及調整和容量規劃：

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

圖四 黃金信號之網絡和延遲

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

七、風險分析

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

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

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

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

If TTD = 0,

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

圖六 風險分析和度量

八、監控和告警

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

圖七 監控和告警

你可以配置Grafana來構建可視化和儀表板來查詢Prometheus。

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

九、促進事后分析

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

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

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

SRE團隊的角色是運維應用程序并通過執行必要的操作來保持系統正常運行。以下是SRE在各個階段執行日常活動的一些策略和工具：

階段1：Development

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

階段2：Pilot

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

階段3：Production

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

十一、結論

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