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。了解如何使用錯誤預算和風險分析等基本工具來指導必要的決策，以平衡你對可靠性的投入與對應用程式功能或其他業務優先級的投入。最後文中詳細闡述了監控分布式系統的四個黃金名額。
譯者丨BGBiao