在技術工作中，對于産品/基礎技術研發和 SRE 兩種角色，通常會有基于「是否側重編碼」的了解。對于産品研發轉做 SRE ，經常會産生是否要「脫離編碼工作」的看法，或者認為是否要「偏離對産品/基礎技術的推進」。
作者 | 悟鵬
來源|阿裡巴巴雲原生公衆号
前言
基于過往的技術研發和穩定性保障的經驗，分享下個人對 SRE 的了解，探讨「面向産品/基礎技術的研發」和「穩定性保障」兩種角色之間的協作關系，更好地為業務服務。
SRE 概述
最早讨論 SRE 來源于 Google 這本書《Site Reliability Engineering: How Google Runs Production Systems》。由 Google SRE 關鍵成員分享他們是如何對軟體進行生命周期的整體性關注，以及為什麼這樣做能夠幫助 Google 成功地建構、部署、監控和運維世界上現存最大的軟體系統。
書的豆瓣連結：https://book.douban.com/subject/26875239/
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 及穩定性保障的了解，重點在于解決問題和創造更大的價值。
References
- 豆瓣 SRE
- wikipedia: Site reliability engineering
- wikipedia: Controllability
- wikipedia: Observability
- site: google sre