開發與維運

我對 SRE 的理解

2021-01-01

前言

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

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

SRE 概述

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

從 wikipedia: Site reliability engineering中可瞭解到 SRE 的定義：

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 需要對問題特徵有深入理解，系統性設計和實施解決方案，並抓住一段時間內的主要問題進行解決。

一種可參考的整體解決方案如下：

image.png

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

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

可控性方面，包括如下三個主要維度：

  • 發佈管理

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

  • 操作管理

    • 重點解決黑屏操作導致的人為穩定性問題
    • 包括統一集群操作入口、集群操作權限管理、集群操作審計等

  • 設計評審

    • 重點解決軟件系統設計階段應用穩定性保障最佳實踐
    • 包括集群方案評審和重要功能設計評審等

可觀測方面，包括如下幾個重要維度：

  • 監控

    • 重點解決軟件系統運行態的感知能力
    • 包括監控收集/可視化系統的搭建和維護等

  • 日誌

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

  • 巡檢

    • 重點解決軟件系統功能是否正常的主動探測能力
    • 包括巡檢服務的搭建、通用巡檢邏輯的開發維護等

  • 告警

    • 重點解決異常的及時觸達需求
    • 包括告警系統的搭建、告警配置管理、告警途徑管理、告警分析等

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

  • 項目質量驗收標準
  • 項目安全生產標準
  • 項目發佈前 checklist
  • 項目 TechReview 模板
  • 項目 Kick-off 模板
  • 項目管理規範
  • etc.

一個例子：

維度 評估項
可觀測 1. 是否提供了標準的 metrics API？
2. 是否可以將日誌持久化到日誌系統？
3. 是否配置了監控？
- a. 是否有對跌零因子的監控？
- b. 是否有服務降級的監控？
- c. 是否有限流的監控？
- d. 是否配置了對關鍵依賴方的可用性監控？
- e. 監控是否分級？
4. 是否配置了告警？
- a. 是否有對跌零因子的告警？
- b. 是否有服務降級的告警？
- c. 是否有限流的告警？
- d. 是否配置了對關鍵依賴方的可用性告警？
- e. 告警是否分級？
5. 是否可以配置巡檢？
6. 使用了 structured log 便於進行 log 的查詢、分析？
可灰度 是否使用了具有灰度能力的 workload？
可回滾 1. 是否使用了均有回滾能力的 workload？
2. 組件是否進行了版本控制？
3. 配置是否進行了版本控制？
可保護 1. 是否有限流措施？
2. 是否有降級措施？
3. 是否配置了探針？
- a. 是否配置了 livenessProbe？
- b. 可被訪問時，是否配置了 readinessProbe？
- c. 初始化耗時時，是否配置了 startupProbe？
4. 是否有快速失敗的能力？
- a. 是否有超時結束能力？
5. 依賴方不可用時:
- a. 是否會持續對依賴方帶來日常或更高壓力？
- b. 是否會對上游帶來反向壓力？(如連接數、處理延時)
6. 己方不可用時：
- a. 對上游的影響是否可控？
- b. 恢復時是否可以控制請求壓力？
7. 是否可以無損重建？
8. 是否多副本部署？
9. 是否配置了非親和性？
10. 是否跨 AZ 部署？
11. 是否有處理預案
12. 是否均有訪問管理？
13. 服務是否穩定性運行，是否會影響數據資產？
14. 服務是否穩定性運行，是否會洩露敏感信息？
15. 是否區分組件處於關鍵鏈路還是旁路？
16. 是否有「爆炸半徑」的整理？
17. 是否有「跌零因子」的整理？
可控成本 1. 是否配置了 limit resources？
2. 變更是增加還是降低用戶成本？
3. 變更是增加還是降低平臺成本？
易於運維 1. 是否可以做到變更配置時無需重建實例？
2. 是否有白屏化運維途徑？
3. 是否有「端到端管控鏈路」流程圖
4. 是否有「端到端數據鏈路」流程圖

為了便於理解，可以再針對 check 項形成分級，便於交流和進行項目穩定性評估：

級別 標準
L0 1. 可觀測、可灰度、可回滾 均不滿足
L1 1. 可觀測、可灰度、可回滾 滿足 50% 以上要求
L2 1. 可觀測、可灰度、可回滾 滿足 90% 以上要求
L3 1. 可觀測、可灰度、可回滾 滿足 90% 以上要求
2. 可保護滿足 50% 以上要求
L4 1. 可觀測、可灰度、可回滾 滿足 90% 以上要求
2. 可保護滿足 90% 以上要求
3. 可控成本滿足 50% 以上要求
L5 1. 可觀測、可灰度、可回滾 滿足 90% 以上要求
2. 可保護滿足 90% 以上要求
3. 可控成本滿足 90% 以上要求

當最佳實踐可以通過文檔進行規範化，接下來就可以提供工具或服務將其低成本應用，使得穩定性保障最佳實踐成為基礎設施。

SRE 需要在穩定性相關的方法論和實踐方面不斷迭代，自上而下設計，自下而上反饋，合理、可靠保障穩定性。

共贏，攜手服務業務

再回顧下軟件系統生命週期中的兩類角色：

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

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

SRE 通常會橫向支撐多個項目，對線上問題的類型、解決實踐有更為全面的理解和思考，基於此會形成最佳實踐的理論、工具或服務，為研發提供理論、工具的支持，也可以在此基礎上產品化穩定性保障解決方案，為更多的客戶服務，創造更大的價值。

產品/基礎技術研發對業務需求、功能/技術細節有更深入的理解，一方面直接帶來業務價值，一方面可通過實踐為穩定性保障帶來切合實際的需求，進一步和 SRE 共同保障穩定性。

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

小結

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

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

References

豆瓣 SRE
wikipedia: Site reliability engineering
wikipedia: Controllability
wikipedia: Observability
site: google sre

掃碼瞭解更多技術內容與客戶案例：

image.png

Leave a Reply

Your email address will not be published. Required fields are marked *