這是阿里技術專家對 SRE 和穩定性保障的理解

語言: CN / TW / HK

頭圖.png

作者 | 悟鵬
來源|阿里巴巴雲原生公眾號

前言

在技術工作中,對於產品/基礎技術研發和 SRE 兩種角色,通常會有基於「是否側重編碼」的理解。對於產品研發轉做 SRE ,經常會產生是否要「脫離編碼工作」的看法,或者認為是否要「偏離對產品/基礎技術的推進」。

基於過往的技術研發和穩定性保障的經驗,分享下個人對 SRE 的理解,探討「面向產品/基礎技術的研發」和「穩定性保障」兩種角色之間的協作關係,更好地為業務服務。

SRE 概述

最早討論 SRE 來源於 Google 這本書《Site Reliability Engineering: How Google Runs Production Systems》。由 Google SRE 關鍵成員分享他們是如何對軟體進行生命週期的整體性關注,以及為什麼這樣做能夠幫助 Google 成功地構建、部署、監控和運維世界上現存最大的軟體系統。

書的豆瓣連結:https://book.douban.com/subject/26875239/

最早討論 SRE 來源於 Google 這本書《Site Reliability Engineering: How Google Runs Production Systems》。由 Google SRE 關鍵成員分享他們是如何對軟體進行生命週期的整體性關注,以及為什麼這樣做能夠幫助 Google 成功地構建、部署、監控和運維世界上現存最大的軟體系統。

Site reliability engineering (SRE) is a discipline that incorporates aspects of software engineering and applies them to infrastructure and operations problems. The main goals are to create scalable and highly reliable software systems.

其中有句形象描述 SRE 工作的描述:

SRE is “what happens when a software engineer is tasked with what used to be called operations.”

即 SRE 的目標是構建可擴充套件和高可用的軟體系統,通過軟體工程的方法解決基礎設施和操作相關的問題。

在 Google SRE 書中,對 SRE 日常工作狀態有個準確的描述:至多 50% 的時間精力處理操作相關事宜,50% 以上的精力通過軟體工程保障基礎設施的穩定性和可擴充套件性。

基於上述描述,我對 SRE 的理解是:

  • 職責:保障基礎設施的穩定性和可擴充套件性。
  • 核心:解決問題。
  • 方法:通過操作類事務積累問題經驗,通過編碼等方式提升問題的解決效率。

軟體生命週期

Google SRE 一書中,對軟體工程從生命週期角度有一個很形象的描述:

軟體工程有的時候和養孩子類似:雖然生育的過程是痛苦和困難的,但是養育孩子**的過程才是真正需要花費絕大部分精力的地方。

一個軟體系統的 40%~90% 的花銷其實是花在開發建設完成之後不斷維護過程中的。

專案生命週期中,設計和構建軟體系統的時間精力佔比,通常是少於系統上線之後的維護管理。為了更好地維護系統可靠執行,需要考慮兩種型別的角色:

  • 專注於設計和構建軟體系統。
  • 專注於整個軟體系統生命週期管理,包括從其設計到部署,歷經不斷改進,最後順利下線。

第一類角色對應產品/基礎技術研發,第二類角色對應 SRE,二者的共同目標均是為了達成專案目標,協同服務好業務。

穩定性保障價值

針對穩定性的影響,直接參與處理客戶問題的同學會更有體感:

  • 通過問題發生時客戶直接反饋的影響程度、緊急程度,感受到穩定性給客戶帶來的焦慮。
  • 通過問題處理結束後客戶的反饋,感受到客戶對穩定性保障的感謝或憤怒。
  • 通過事後在營收狀況、客戶規模變化,感受到穩定性對業務營收的影響。
  • 通過產品規劃的的延期,感受到穩定性對產品迭代的影響。

穩定性保障的價值由此凸顯:

  • 保障客戶的產品體驗,滿足客戶對約定的可靠性訴求。
  • 加速業務迭代,滿足業務對穩定性訴求,業務注意力集中在更快速推出滿足客戶需求的功能。

SRE 如何保障穩定性

穩定性問題通常會有這些特徵:

  • 人為導致,依賴專家經驗
  • 一系列因素綜合導致
  • 不可避免
  • 100% 保障沒有必要

線上穩定性問題,人為操作不當導致的比例很高,集中在 釋出 和 線上運維 兩個環節,均是高頻操作。對於複雜系統,這兩個環節對專家經驗有較強的依賴。

發生的穩定性問題通常具有系統性的特徵,即非單個功能元件缺陷導致,而是由一系列因素綜合作用導致,如缺少監控告警導致不能及時感知,缺少日誌不能有助於快速定位問題,缺少良好的問題排查流程導致依賴個人能力,缺少良好的協調溝通極致導致問題處理時長增加、客戶影響程度加劇等。

問題是不可避免的,流量的突增、伺服器/網路/儲存的損壞、未覆蓋的輸入等,均會誘發問題的出現。

業務對外有 SLA,向客戶承諾一定程度的穩定性,未達到時按照協議進行賠付,同時問題又不可不免,在滿足內部 SLO 標準的前提下繼續提升穩定性,會帶來更高的實現成本,對業務的收益增量也會更小。

SRE 需要對問題特徵有深入理解,系統性設計和實施解決方案,並抓住一段時間內的主要問題進行解決。一種可參考的整體解決方案如下:

1.png

落地過程中,可先從如下三個抓手系統解決:

  • 可控性
  • 可觀測
  • 穩定性保障最佳實踐

可控性方面,包括如下三個主要維度:

  • 釋出管理

    • 重點解決釋出導致的人為穩定性問題。
    • 包括髮布前重要變更評審和釋出中變更動作管理等。
  • 操作管理

    • 重點解決黑屏操作導致的人為穩定性問題。
    • 包括統一叢集操作入口、叢集操作許可權管理、叢集操作審計等。
  • 設計評審
    • 重點解決軟體系統設計階段應用穩定性保障最佳實踐。
    • 包括叢集方案評審和重要功能設計評審等。

可觀測方面,包括如下幾個重要維度:

  • 監控

    • 重點解決軟體系統執行態的感知能力。
    • 包括監控收集/視覺化系統的搭建和維護等。
  • 日誌

    • 重點解決軟體系統的問題可排查能力。
    • 包括日誌收集/儲存/查詢/分析系統的搭建和維護等。
  • 巡檢

    • 重點解決軟體系統功能是否正常的主動探測能力。
    • 包括巡檢服務的搭建、通用巡檢邏輯的開發維護等。
  • 告警
    • 重點解決異常的及時觸達需求。
    • 包括告警系統的搭建、告警配置管理、告警途徑管理、告警分析等。

穩定性保障最佳實踐,是從歷史問題和業界實踐方面抽象出意識、流程、規範、工具,在系統設計之初就融入其中,並在系統整個生命週期中加以使用,如通過模板固化最佳實踐:

  • 專案質量驗收標準
  • 專案安全生產標準
  • 專案釋出前 checklist
  • 專案 TechReview 模板
  • 專案 Kick-off 模板
  • 專案管理規範
  • etc.

一個例子:

2.png

為了便於理解,可以再針對 check 項形成分級,便於交流和進行專案穩定性評估:

3.png

當最佳實踐可以通過文件進行規範化,接下來就可以提供工具或服務將其低成本應用,使得穩定性保障最佳實踐成為基礎設施。SRE 需要在穩定性相關的方法論和實踐方面不斷迭代,自上而下設計,自下而上反饋,合理、可靠保障穩定性。

共贏,攜手服務業務

  • 產品/基礎技術研發:專注於設計和構建軟體系統。
  • SRE:專注於整個軟體系統生命週期管理,包括從其設計到部署,歷經不斷改進,最後順利下線。

這兩類角色是相互協作、相互服務的關係,擁有共同的目標:滿足業務需求,更好服務業務。

SRE 通常會橫向支撐多個專案,對線上問題的型別、解決實踐有更為全面的理解和思考,基於此會形成最佳實踐的理論、工具或服務,為研發提供理論、工具的支援,也可以在此基礎上產品化穩定性保障解決方案,為更多的客戶服務,創造更大的價值。產品/基礎技術研發對業務需求、功能/技術細節有更深入的理解,一方面直接帶來業務價值,一方面可通過實踐為穩定性保障帶來切合實際的需求,進一步和 SRE 共同保障穩定性。

兩種型別的角色,需要朝著共同的目標並肩協作,與業務共同發展,實現共贏

小結

SRE 由於工作的性質,在橫向方面會服務大量的業務,以實踐積累對穩定性保障問題域的深入理解和穩定性保障重要性的深刻認知,在縱向方面會通過技術手段將穩定性保障最佳實踐進行沉澱和應用;同時眼光又是與研發、業務一齊向前看,綜合技術和管理創造價值。

以上是從個人角度對 SRE 及穩定性保障的理解,重點在於解決問題和創造更大的價值。

References