SRE（站點可靠度工程）是一種確保 Web 專案可用性的方法。 它被認為是 DevOps 的框架，討論如何在應用 DevOps 實踐中取得成功。 本文的翻譯 書籍 來自Google。 我自己準備了這個翻譯，並依靠自己在理解監控流程的經驗。 在電報頻道 и 我還出版了同一本書中有關服務等級目標的第 6 章的翻譯。
貓翻譯。 享受閱讀！
如果不了解哪些指標真正重要以及如何衡量和評估它們，就不可能管理服務。 為此，我們為使用者定義並提供一定程度的服務，無論他們使用我們的內部 API 還是公共產品。
我們利用我們的直覺、經驗和對使用者願望的理解來了解服務等級指標 (SLI)、服務等級目標 (SLO) 和服務等級協定 (SLA)。 這些維度描述了我們想要監控的主要指標，以及如果我們無法提供預期的服務品質我們將做出反應的主要指標。 最終，選擇正確的指標有助於在出現問題時指導正確的操作，並且還可以讓 SRE 團隊對服務的健康狀況充滿信心。
本章描述了我們用來解決度量建模、度量選擇和度量分析問題的方法。 大多數解釋都沒有示例，因此我們將使用其實現示例（搜尋莎士比亞作品）中描述的莎士比亞服務來說明要點。
服務等級術語
許多讀者可能熟悉 SLA 的概念，但術語 SLI 和 SLO 值得仔細定義，因為一般來說，術語 SLA 的含義過多，並且根據上下文具有多種含義。 為了清楚起見，我們希望將這些值分開。
指標
SLI 是一種服務水準指標，是對所提供服務水準的某個面向精心定義的定量衡量標準。
對於大多數服務，關鍵的 SLI 被認為是請求延遲 - 返回請求回應所需的時間。 其他常見的 SLI 包括錯誤率（通常表示為收到的所有請求的一部分）和系統吞吐量（通常以每秒請求數來衡量）。 測量結果通常是聚合的：首先收集原始數據，然後轉換為變化率、平均值或百分位數。
理想情況下，SLI 直接測量感興趣的服務水平，但有時只有相關指標可用於測量，因為原始指標難以取得或解釋。 例如，客戶端延遲通常是更合適的指標，但有時只能在伺服器上測量延遲。
對 SRE 來說重要的另一種 SLI 是可用性，或可以使用服務的時間部分。 通常定義為成功請求的比率，有時稱為產量。 （生命週期——資料長期保留的可能性——對於資料儲存系統也很重要。）雖然不可能實現 100% 的可用性，但接近 100% 的可用性通常是可以實現的；可用性值表示為“99”的數量» 可用性百分比。 例如，99,999% 和 2% 可用性可能被標記為「5 個 99,95」和「XNUMX 個 XNUMX」。 Google Compute Engine 目前規定的可用性目標是「三個半九」或 XNUMX%。
目標
SLO 是服務等級目標：由 SLI 衡量的服務等級的目標值或值範圍。 SLO 的正常值為「SLI ≤ 目標」或「下限 ≤ SLI ≤ 上限」。 例如，我們可能決定透過將 SLO 設定為小於 100 毫秒的平均搜尋查詢延遲來「快速」返回莎士比亞搜尋結果。
選擇正確的 SLO 是一個複雜的過程。 首先，您不能總是選擇特定值。 對於對您的服務的外部傳入 HTTP 請求，每秒查詢 (QPS) 指標主要由使用者存取您的服務的願望決定，您無法為此設定 SLO。
另一方面，您可以說您希望每個請求的平均延遲都小於 100 毫秒。 設定這樣的目標可能會迫使您以低延遲編寫前端或購買提供此類延遲的裝置。 （100毫秒顯然是一個任意數字，但最好有更低的延遲數字。有證據表明，快的速度比慢的速度更好，並且處理用戶請求的延遲高於特定值實際上會迫使人們遠離來自您的服務。）
同樣，這比乍看之下更加模糊：您不應該將 QPS 完全排除在計算之外。 事實上，QPS 和延遲是密切相關的：較高的 QPS 往往會導致較高的延遲，當服務達到某個負載閾值時，效能通常會急劇下降。
選擇和發布 SLO 會設定使用者對服務如何運作的期望。 此策略可以減少對服務所有者的毫無根據的投訴，例如效能緩慢。 如果沒有明確的 SLO，使用者通常會創建自己對所需效能的期望，這可能與設計和管理服務的人員的意見無關。 當使用者錯誤地認為服務比實際更容易存取時，這種情況可能會導致對服務的期望過高；當使用者認為系統不如實際可靠時，會導致不信任。
協議
服務等級協議是與使用者簽訂的顯式或隱式合同，其中包括滿足（或不滿足）其所包含的 SLO 的後果。 當後果是財務方面的（折扣或罰款）時，最容易被識別，但它們也可以採取其他形式。 討論 SLO 和 SLA 之間差異的一個簡單方法是問“如果不滿足 SLO 會發生什麼？” 如果沒有明顯的後果，您幾乎肯定會考慮 SLO。
SRE 通常不參與建立 SLA，因為 SLA 與業務和產品決策密切相關。 然而，SRE 參與幫助減輕失敗的 SLO 的後果。 它們還可以幫助確定 SLI：顯然，協議中必須有一種客觀的方法來衡量 SLO，否則就會出現分歧。
Google 搜尋是沒有公共 SLA 的重要服務的一個範例：我們希望每個人都盡可能有效率地使用搜索，但我們尚未與全世界簽署合約。 然而，如果搜尋不可用，仍然會產生後果 - 不可用會導致我們的聲譽下降以及廣告收入減少。 許多其他 Google 服務（例如 Google for Work）與使用者都有明確的服務等級協定。 無論特定服務是否具有 SLA，定義 SLI 和 SLO 並使用它們來管理服務都很重要。
這麼多理論 - 現在來體驗。
實踐中的指標
鑑於我們已經得出結論，選擇適當的指標來衡量服務水準非常重要，那麼您現在如何知道哪些指標對於服務或系統很重要？
您和您的用戶關心什麼？
您無需將每個指標都用作可在監控系統中追蹤的 SLI； 了解使用者想要從系統中獲得什麼將有助於您選擇多個指標。 選擇過多的指標會導致難以專注於重要的指標，而選擇較少的指標則會導致系統的大部分內容無人關注。 我們通常使用幾個關鍵指標來評估和了解系統的健康狀況。
服務通常可以根據與其相關的 SLI 分為幾個部分：
- 自訂前端系統，例如我們範例中莎士比亞服務的搜尋介面。 它們必須可用、沒有延遲並且有足夠的頻寬。 因此，可以提出問題：我們可以回覆應該請求嗎？ 響應請求需要多長時間？ 可以處理多少個請求？
- 儲存系統。 他們看重低響應延遲、可用性和耐用性。 相關問題：讀取或寫入資料需要多長時間？ 我們可以根據要求存取資料嗎？ 當我們需要時，數據是否可用？ 有關這些問題的詳細討論，請參閱第 26 章資料完整性：所讀即所寫。
- 資料處理管道等大數據系統依賴吞吐量和查詢處理延遲。 相關問題：處理了多少數據？ 資料從收到請求到發出回應需要多長時間？ （系統的某些部分也可能在某些階段出現延遲。）
指標收集
許多服務等級指標最自然地在伺服器端收集，使用 Borgmon 等監控系統（見下文）。 ）或 Prometheus，或只是定期分析日誌，識別狀態為 500 的 HTTP 回應。但是，有些系統應該配備客戶端指標收集，因為缺乏客戶端監控可能會導致遺漏一些影響效能的問題。用戶，但不影響伺服器端指標。 例如，關注莎士比亞搜尋測試應用程式的後端回應延遲可能會因 JavaScript 問題而導致用戶端出現延遲：在這種情況下，測量瀏覽器處理頁面所需的時間是一個更好的指標。
聚合
為了簡單和易於使用，我們經常匯總原始測量結果。 這必須仔細完成。
有些指標看起來很簡單，例如每秒的請求數，但即使這種看似簡單的測量也會隨著時間的推移隱式地聚合資料。 測量值是每秒專門接收一次還是測量值是每分鐘請求數的平均值？ 後一個選項可以隱藏大量僅持續幾秒鐘的瞬時請求。 考慮一個每秒處理 200 個請求的系統，其中偶數個請求，其餘時間為 0。 每秒 100 個請求的平均值形式的常數和兩倍瞬時負載不是一回事。 同樣，平均查詢延遲可能看起來很有吸引力，但它隱藏了一個重要的細節：大多數查詢可能很快，但也有許多查詢很慢。
大多數指標最好被視為分佈而不是平均值。 例如，對於 SLI 延遲，有些請求會很快得到處理，而有些請求總是需要更長的時間，有時甚至更長。 簡單的平均值可以隱藏這些長時間的延遲。 該圖顯示了一個範例：雖然一個典型的請求需要大約 50 毫秒來處理，但 5% 的請求慢了 20 倍！ 僅基於平均延遲的監視和警報不會顯示全天行為的變化，而實際上某些請求的處理時間（最上面一行）有明顯的變化。
50、85、95 和 99 個百分點的系統延遲。 Y 軸採用對數格式。
使用百分位數作為指標可以讓您了解分佈的形狀及其特徵：高百分位數水平（例如99 或99,9）顯示最差值，而50 百分位數（也稱為中位數）顯示最常見的狀態指標。 回應時間離散度越大，長時間運行的請求對使用者體驗的影響就越大。 在高負載和存在佇列的情況下效果會增強。 使用者體驗研究表明，人們通常更喜歡響應時間方差較大的較慢系統，因此一些SRE 團隊僅關注高百分位數分數，因為如果某個指標在99,9 百分位數處的行為良好，則大多數用戶不會遇到問題。
統計誤差注意事項
我們通常喜歡使用百分位數而不是一組值的平均值（算術平均值）。 這使我們能夠考慮更分散的值，這些值通常具有與平均值顯著不同（且更有趣）的特徵。 由於計算系統的人為特性，指標值常常有偏差，使得任何請求都無法在小於 0 毫秒的時間內收到回應，而逾時 1000 毫秒錶示無法成功回應值大於逾時。 因此，我們不能接受平均值和中位數可以相同或接近！
如果沒有事先測試，而且除非某些標準假設和近似成立，否則我們會小心不要得出資料呈常態分佈的結論。 如果分佈不符合預期，則修復問題的自動化過程（例如，當它看到異常值時，它會以較高的請求處理延遲重新啟動伺服器）可能會執行得太頻繁或不夠頻繁（這兩者都不是非常好）。
標準化指標
我們建議標準化 SLI 的一般特性，這樣您就不必每次都對它們進行推測。 任何滿足標準模式的功能都可能被排除在單一 SLI 的規格之外，例如：
- 聚合間隔：“平均超過 1 分鐘”
- 聚合區域：“叢集中的所有任務”
- 測量頻率：“每 10 秒”
- 啟用哪些請求：“來自黑盒子監控作業的 HTTP GET”
- 數據如何取得：“感謝我們在伺服器上測得的監控”
- 資料存取延遲：“到最後一個位元組的時間”
為了節省精力，為每個常用指標建立一組可重複使用的 SLI 範本； 它們也使每個人都更容易理解某個 SLI 的含義。
實踐中的目標
首先思考（或找出！）您的用戶關心什麼，而不是您可以衡量的內容。 通常，用戶關心的內容很難或無法衡量，因此您最終會更接近他們的需求。 但是，如果您只是從易於衡量的內容開始，最終會得到不太有用的 SLO。 因此，我們有時發現，先確定預期目標，然後使用特定指標，比選擇指標然後實現目標效果更好。
定義你的目標
為了最大程度地清晰起見，應定義 SLO 的測量方式及其有效條件。 例如，我們可以說以下內容（第二行與第一行相同，但使用 SLI 預設值）：
- 99%（平均超過 1 分鐘）的 Get RPC 呼叫將在 100 毫秒內完成（在所有後端伺服器上測量）。
- 99% 的 Get RPC 呼叫將在 100 毫秒內完成。
如果效能曲線的形狀很重要，您可以指定多個 SLO：
- 90% 的 Get RPC 呼叫在 1 毫秒內完成。
- 99% 的 Get RPC 呼叫在 10 毫秒內完成。
- 99.9% 的 Get RPC 呼叫在 100 毫秒內完成。
如果您的使用者產生異質工作負載：批次處理（吞吐量很重要）和互動式處理（延遲很重要），則可能值得為每個負載類別定義單獨的目標：
- 95% 的客戶請求需要吞吐量。 設定執行的 RPC 呼叫的計數 <1 秒。
- 99% 的客戶關心延遲。 設定流量 <1 KB 且運行時間 <10 毫秒的 RPC 呼叫計數。
堅持 100% 滿足 SLO 是不切實際且不可取的：這會降低引入新功能和部署的速度，並且需要昂貴的解決方案。 相反，最好允許錯誤預算（允許的系統停機時間的百分比）並每天或每週監控該值。 高階管理層可能需要每月或每季進行評估。 （錯誤預算只是一個 SLO，用於與另一個 SLO 進行比較。）
SLO 違規的百分比可以與錯誤預算進行比較（請參閱第 3 章和第 XNUMX 章） ），並將差值用作決定何時部署新版本的流程的輸入。
選擇目標值
選擇規劃值（SLO）並不是純粹的技術活動，因為產品和業務利益必須反映在所選的 SLI、SLO（可能還有 SLA）中。 同樣，可能需要就人員配備、上市時間、設備可用性和融資等問題交換資訊。 SRE 應該成為這種對話的一部分，並幫助了解不同選項的風險和可行性。 我們提出了一些可能有助於確保更有成效的討論的問題：
不要根據當前表現來選擇目標。
雖然了解系統的優勢和限制很重要，但不經過推理就調整指標可能會妨礙您維護系統：需要付出巨大的努力才能實現不進行重大重新設計就無法實現的目標。
把事情簡化
複雜的 SLI 計算可能會隱藏系統效能的變化，並使尋找問題原因變得更加困難。
避免絕對化
雖然擁有一個能夠處理無限增長的負載而不增加延遲的系統很誘人，但這種要求是不切實際的。 一個接近這種理想的系統可能需要大量的時間來設計和構建，操作起來會很昂貴，並且對於那些願意做更少事情的用戶的期望來說太過美好了。
使用盡可能少的 SLO
選擇足夠數量的SLO以確保系統屬性的良好覆蓋。 保護您選擇的 SLO：如果您永遠無法透過指定特定的 SLO 來贏得有關優先順序的爭論，那麼可能不值得考慮該 SLO。 然而，並非所有系統屬性都適合 SLO：很難使用 SLO 來計算使用者滿意度。
不要追求完美
隨著您對系統在負載下的行為有了更多了解，您始終可以不斷完善 SLO 的定義和目標。 最好從一個浮動目標開始，隨著時間的推移不斷完善，而不是選擇一個過於嚴格的目標，當你發現它無法實現時就必須放鬆。
SLO 可以而且應該成為 SRE 和產品開發人員優先工作的關鍵驅動因素，因為它們反映了對使用者的關注。 好的 SLO 對開發團隊來說是一個有用的執行工具。 但是，如果團隊為實現過於激進的 SLO 付出了巨大的努力，那麼設計不當的 SLO 可能會導致工作浪費；如果 SLO 太低，則可能會導致產品很差。 SLO 是一個強大的槓桿，明智地使用它。
控制您的測量
SLI 和 SLO 是用於管理系統的關鍵元素：
- 監控和測量 SLI 系統。
- 比較 SLI 和 SLO 並決定是否需要採取措施。
- 如果需要採取行動，請弄清楚需要採取什麼措施才能實現目標。
- 完成這個動作。
例如，如果步驟 2 顯示請求逾時，如果不採取任何措施，將在幾個小時內破壞 SLO，則步驟 3 可能涉及測試伺服器受 CPU 限制的假設，並且添加更多伺服器將分配負載。 如果沒有 SLO，您將不知道是否（或何時）採取行動。
設定 SLO - 然後將設定使用者期望
發布 SLO 設定使用者對系統行為的期望。 使用者（和潛在使用者）通常想知道對服務有何期望，以了解該服務是否適合使用。 例如，想要使用照片分享網站的人可能希望避免使用承諾長壽和低成本的服務，以換取稍低的可用性，即使相同的服務可能非常適合檔案記錄管理系統。
若要為使用者設定切合實際的期望，請使用以下一種或兩種策略：
- 保持安全邊際。 使用比向用戶公佈的更嚴格的內部 SLO。 這將使您有機會在問題變得明顯之前對其做出反應。 SLO 緩衝區還允許您在安裝影響系統效能的版本時擁有安全裕度，並確保系統易於維護，而不必因停機而讓使用者感到沮喪。
- 不要超越用戶的期望。 用戶是基於您提供的內容，而不是您所說的內容。 如果您的服務的實際效能比規定的 SLO 好得多，使用者將依賴當前的效能。 您可以透過有意關閉系統或限制輕負載下的效能來避免過度依賴。
了解系統滿足期望的程度有助於決定是否投資於加速系統並使其更易於存取和恢復。 或者，如果服務表現太好，則應將一些員工時間花在其他優先事項上，例如償還技術債、新增功能或推出新產品。
實踐中的協議
創建 SLA 需要業務和法律團隊定義違反 SLA 的後果和處罰。 SRE 的作用是幫助他們了解在滿足 SLA 中包含的 SLO 時可能遇到的挑戰。 大多數創建 SLO 的建議也適用於 SLA。 在向用戶承諾的內容上保持保守是明智的，因為您擁有的內容越多，更改或刪除看似不合理或難以滿足的 SLA 就越困難。
感謝您將翻譯讀到最後。 訂閱我的關於監控的電報頻道 и .
來源： www.habr.com