SRE最佳實踐

什麼是站點可靠性工程(SRE)?

站點可靠性工程(SRE)的概念起源於谷歌。這個想法與DevOps的原則密切相關。它是It運營的一種方法。SRE團隊使用軟件來管理系統、解決問題和自動化操作任務。

SRE團隊將IT團隊完成的任務(通常是手工完成的)交給工程師或運維團隊,後者使用工具和自動化來解決問題和管理生產系統。

在創建可伸縮和高度可靠的軟件系統時,這是一種有價值的實踐。它通過代碼幫助組織管理大量的基礎設施,對於管理數十萬臺機器的系統管理員來說,代碼具有更強的可伸縮性和可持續性。

爲什麼SRE很重要?好的SRE團隊需要具備哪些條件?

SRE就像是軟件工程和IT操作之間的橋樑,填補了它們之間的空白。在幾乎所有地方,SRE都在爲生產系統中的故障做準備時發揮作用。它確保組織的系統是可伸縮的、可靠的、可預測的和自動化的。

SRE還設置了服務水平指標(SLIs)、服務水平目標(slo)、服務水平協議(SLA), SLA定義了性能的真實數字、團隊必須達到的目標以滿足該協議,以及系統對最終用戶需要有多可靠。

SRE的主要目標是提高性能和運行效率。

所以,SRE不僅僅是負責編碼的行動人員。另外,SRE是開發團隊中擁有不同技能集的成員,特別是在部署、配置管理、監視、度量等方面。正如爲應用程序開發漂亮外觀的工程師必須知道如何從數據存儲中獲取數據一樣,SRE並不僅僅負責這些領域。整個團隊一起工作以交付易於更新、管理和監視的產品。當團隊在實現DevOps時,對站點可靠性工程師的需求自然會出現,但他們意識到他們對開發人員要求太多,需要一個專家來處理ops團隊過去處理的事情。

在我們深入挖掘SRE以及SREs如何與開發團隊合作之前,我們需要了解站點可靠性工程在DevOps範式中是如何發揮作用的。

SRE如何與DevOps一起工作?

站點可靠性工程的核心是DevOps範例的實現。正如持續集成和持續交付是DevOps在軟件發佈中的應用一樣,SRE也是這些原則在軟件可靠性上的應用。

定義DevOps的方法有很多種。然而,在傳統的模型中,開發(devs)和運維(ops)團隊是分開的,導致編寫代碼的團隊在客戶開始使用代碼時不負責代碼的工作方式。開發團隊將把代碼扔到給運維團隊安裝和支持。

根據谷歌的方法,您可以使用SRE更好地在組織中採用DevOps原則,並衡量您的實現的程度。

爲了更好地理解如何將兩者結合起來,可以考慮以下原則:

  • 減少組織之間的代溝:SRE通過在開發人員和運維團隊之間共享所有信息來降低摩擦。這是DevOps哲學的主要原則之一。當SREs專注於改進問題檢測和應用程序性能時,運維團隊可以專注於管理基礎設施,而開發人員可以專注於功能特性改進。

  • 接受失敗:像DevOps一樣,SREs不會在IT團隊之間推卸失敗和生產事件的責任。不責備事後分析是SRE的最佳實踐,可以確保所有事件都被用作學習機會。當失敗的可能性被規範化時,團隊可以承擔更大的風險,潛在地產生更大的創新,而不必擔心過度的挫折或停機。

  • 實施漸進式變更:與DevOps一樣,SRE也鼓勵通過變更進行持續改進。SRE要求更小且頻繁的變更。因此,任何負面影響的影響都較小,低風險的增強可以很容易地測試和實現。

  • 利用工具和自動化:DevOps鼓勵採用自動化技術,而SRE則專注於跨IT團隊擁抱一致的技術和信息使用。這使得溝通更容易,並減少了技術不兼容造成問題的機會。這種標準化還有助於確保團隊成員能夠更好地協作,因爲工具是統一的,而且不太可能需要某些成員的專門技能。

  • 度量一切:SRE將度量與反饋循環相結合,以度量操作並識別改進的機會。它還根據需要爲風險和手工操作構建度量標準,通過度量使其更具可預測性。通過應用度量數據,團隊可以設置適當的目標,同時保持對性能的合理預期。

既然我們知道了爲什麼SRE很重要,那麼讓我們繼續討論在擁抱SRE文化時必須遵循的SRE最佳實踐。

SRE最佳實踐

在實現SRE時,您可能需要一些時間來改進您的策略和定製實踐,以滿足您的操作需求。爲了幫助加快這個過程,請考慮以下SRE原則和最佳實踐。

錯誤的預算

簡而言之,錯誤預算是指你的服務在用戶開始不開心之前的一段時間內積累的錯誤數量。您可以將其視爲對用戶的忍耐力,但應用於服務的特定維度:可用性、延遲等。爲了計算誤差預算,我們必須使用SLI方程:

SLI = [Good events / Valid events] x 100

現在百分比用SLI表示,一旦您爲每個SLI定義了目標,誤差預算是剩下的,那就是您的服務水平目標(SLO),最多100。

例如,假設您正在度量主頁的可用性。可用性由響應錯誤的請求數除以主頁接收到的所有有效請求數(以百分比表示)來衡量。如果您確定可用性的目標是99.9%,那麼錯誤預算就是0.1%。您最多可以提供0.1%的錯誤(最好略低於0.1%),用戶將愉快地繼續使用該服務。

看看這個表格,看看百分比是如何轉化爲時間的:

乍一看,錯誤預算似乎沒有那麼重要。它們只是IT和DevOps需要跟蹤的另一個指標,以確保一切順利運行,對嗎?幸運的是,答案是否定的。錯誤預算不僅僅是確保你滿足合同承諾的方式。如果團隊在特定季度耗盡了他們的錯誤預算,新的更新通常會被凍結。它們也是開發團隊創新和承擔風險的機會。

像用戶一樣定義SLOs

以對最終用戶重要的術語衡量可用性和性能。服務水平目標是所有站點可靠性工程的基礎。如果沒有錯誤預算、開發工作的優先級或及時有效的事件管理,您就無法做到這一點。SLOs應該指定它們是如何度量的以及它們在哪些條件下是有效的。

服務水平指標(SLIs):對所提供的服務水平的某些方面仔細定義的定量度量,如吞吐量、延遲。它還包括:

  • 用戶可以直接測量和觀察。
  • 這可以代表用戶的體驗。
  • 簡單地說,討論了您將要度量的具體內容。

服務水平目標:由SLI測量的服務水平的目標值或值的範圍。它還包括:

  • 從用戶的角度定義服務應該如何執行(通過SLI度量)。簡而言之,服務應該有多好?需要改進服務的閾值。
  • 用戶可能會考慮打開支持的功能點。
  • 由業務需求驅動,而不僅僅是當前的性能。

服務水平協議(SLA):

  • 如果服務沒有達到預期,爲客戶提供某種形式的補償的業務合同。
  • 簡單地說,就是遲緩+結果。

監視錯誤和可用性

爲了識別性能錯誤並維護服務可用性,SRE團隊需要查看他們的系統中發生了什麼。需要監控來驗證應用程序/系統是否按照預期運行。這意味着一個服務,滿足特定的目標,並理解發生更改時會發生什麼。另外,我們想在客戶之前知道發生了什麼。

有效地規劃服務容量

組織需要爲一些事情做計劃,比如有機增長,這可能是產品採用的增加,無機增長,這是由於功能發佈,市場活動等導致的需求突然增長。這將消耗更多的資源(比如黑色星期五或網絡星期一的宕機)。爲了準備這些活動,您需要預測需求並計劃獲取的時間。

容量規劃的重要方面包括定期的負載測試和準確的配置。定期的負載測試允許您查看系統在日常用戶的平均壓力下是如何運行的。此外,添加任何形式的容量都可能是昂貴的,所以知道在哪裏需要額外的資源是關鍵。

關注變更管理

在許多組織中,大多數宕機都是由變更引起的,無論是新的二進制推送還是新的配置推送。每一個微小的變化都會影響業務。因此,分析每個變更所帶來的風險。它應該受到監督。縱觀全局,考慮長期變化的影響,而不僅僅是它們如何影響目前的系統。

爲了確保在變更過程中沒有意外發生,必須由執行推出階段的工程師進行監控,或者最好是一個可靠的監控系統。如果檢測到意外行爲,首先回滾,然後進行診斷,以最小化平均恢復時間(MTTR)。

無指責的事後分析

一個真正無可指責的事後分析文化有助於在組織中建立一個更可靠的系統。事後分析應該是無可指責的,應該關注過程和技術,而不是人。

假設捲入事件的人都很聰明,出發點是好的,並且根據他們當時掌握的信息做出了最好的選擇。把一件事歸咎於一個人或一羣人會適得其反。它創造了一種人們不敢冒險、不敢創新、不敢解決問題的氛圍。

失敗一定會發生。沒有別的辦法。但是,通過良好的事件解決方案和適當的追溯實踐,失敗可以是有益的。它揭示了提高彈性的重點領域。只要你從事件中吸取教訓,你就取得了進步。

自動化管理

SRE的主要關注點之一是自動化。人肉工作是寶貴工程時間的浪費,通過SREs創建框架、流程、內部工具/構建工具來消除它,工程師可以重新開始創新。

總結

這篇博文試圖涵蓋建立成功的SRE團隊所需的基本概念和實踐。如果您計劃在您的項目/組織中採用SRE文化,請培訓您的團隊,遵循最佳實踐,並信任該過程。你不可能做到100%的完美。這是一個神話。但你將使整個過程變得更加流暢,並儘可能地接近完美。

引用

  • https://sre.google/sre-book/service-best-practices/
  • https://opensource.com/article/18/10/sre-startup
  • https://stackpulse.com/blog/site-reliability-engineering-sre-what-why-and-5-best-practices/
  • https://www.usenix.org/blog/what-is-sre-how-does-it-relate-to-devops-lisa18
  • https://www.bmc.com/blogs/sre-vs-devops/
  • https://cloud.google.com/blog/products/management-tools/sre-error-budgets-and-maintenance-windows
  • https://www.atlassian.com/incident-management/kpis/error-budget
  • https://devopsinstitute.com/choosing-the-right-service-level-indicators/
  • https://www.observability.splunk.com/en_us/infrastructure-monitoring/guide-to-sre-and-the-four-golden-signals-of-monitoring.html
  • https://www.enov8.com/blog/site-reliability-engineering-sre-top-10-best-practice/
  • https://www.blameless.com/blog/5-best-practices-nailing-postmortems

推薦



深入探究 K8S ConfigMap 和 Secret

Linkerd、Consul、Istio、Kuma、Traefik、AWS App服務網格全方位對比

Kubernetes入門培訓(內含PPT)

從Ice到Kubernetes容器技術,微服務架構經歷了什麼?


隨手關注或者”在看“,誠摯感謝!

本文分享自微信公衆號 - 雲原生技術愛好者社區(programmer_java)。
如有侵權,請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”,歡迎正在閱讀的你也加入,一起分享。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章