作者 | 悟鵬
來源|阿里巴巴雲原生公衆號
前言
在技術工作中，對於產品/基礎技術研發和 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 需要對問題特徵有深入理解，系統性設計和實施解決方案，並抓住一段時間內的主要問題進行解決。一種可參考的整體解決方案如下：
落地過程中，可先從如下三個抓手系統解決:
- 可控性
- 可觀測
- 穩定性保障最佳實踐
可控性方面，包括如下三個主要維度：
-
發佈管理
- 重點解決發佈導致的人爲穩定性問題。
- 包括髮布前重要變更評審和發佈中變更動作管理等。
-
操作管理
- 重點解決黑屏操作導致的人爲穩定性問題。
- 包括統一集羣操作入口、集羣操作權限管理、集羣操作審計等。
-
設計評審
- 重點解決軟件系統設計階段應用穩定性保障最佳實踐。
- 包括集羣方案評審和重要功能設計評審等。
可觀測方面，包括如下幾個重要維度：
-
監控
- 重點解決軟件系統運行態的感知能力。
- 包括監控收集/可視化系統的搭建和維護等。
-
日誌
- 重點解決軟件系統的問題可排查能力。
- 包括日誌收集/存儲/查詢/分析系統的搭建和維護等。
-
巡檢
- 重點解決軟件系統功能是否正常的主動探測能力。
- 包括巡檢服務的搭建、通用巡檢邏輯的開發維護等。
-
告警
- 重點解決異常的及時觸達需求。
- 包括告警系統的搭建、告警配置管理、告警途徑管理、告警分析等。
穩定性保障最佳實踐，是從歷史問題和業界實踐方面抽象出意識、流程、規範、工具，在系統設計之初就融入其中，並在系統整個生命週期中加以使用，如通過模板固化最佳實踐：
- 項目質量驗收標準
- 項目安全生產標準
- 項目發佈前 checklist
- 項目 TechReview 模板
- 項目 Kick-off 模板
- 項目管理規範
- etc.
一個例子：
爲了便於理解，可以再針對 check 項形成分級，便於交流和進行項目穩定性評估：
當最佳實踐可以通過文檔進行規範化，接下來就可以提供工具或服務將其低成本應用，使得穩定性保障最佳實踐成爲基礎設施。SRE 需要在穩定性相關的方法論和實踐方面不斷迭代，自上而下設計，自下而上反饋，合理、可靠保障穩定性。
共贏，攜手服務業務
- 產品/基礎技術研發：專注於設計和構建軟件系統。
- SRE：專注於整個軟件系統生命週期管理，包括從其設計到部署，歷經不斷改進，最後順利下線。
這兩類角色是相互協作、相互服務的關係，擁有共同的目標：滿足業務需求，更好服務業務。
SRE 通常會橫向支撐多個項目，對線上問題的類型、解決實踐有更爲全面的理解和思考，基於此會形成最佳實踐的理論、工具或服務，爲研發提供理論、工具的支持，也可以在此基礎上產品化穩定性保障解決方案，爲更多的客戶服務，創造更大的價值。產品/基礎技術研發對業務需求、功能/技術細節有更深入的理解，一方面直接帶來業務價值，一方面可通過實踐爲穩定性保障帶來切合實際的需求，進一步和 SRE 共同保障穩定性。
兩種類型的角色，需要朝着共同的目標並肩協作，與業務共同發展，實現共贏。
小結
SRE 由於工作的性質，在橫向方面會服務大量的業務，以實踐積累對穩定性保障問題域的深入理解和穩定性保障重要性的深刻認知，在縱向方面會通過技術手段將穩定性保障最佳實踐進行沉澱和應用；同時眼光又是與研發、業務一齊向前看，綜合技術和管理創造價值。
以上是從個人角度對 SRE 及穩定性保障的理解，重點在於解決問題和創造更大的價值。