簡介：產品/基礎技術研發 和 sre 這兩類角色是相互協作、相互服務的關係，擁有共同的目標：滿足業務需求，更好服務業務。在技術工作中，對於產品/基礎技術研發和 sre 兩種角色，通常會有基於「是否側重編碼」的理解。對於產品研發轉做 sre ，經常會產生是否要「脫離編碼工作」的看法，或者認為是否要「偏離對產品/基礎技術的推進」。
基於過往的技術研發和穩定性保障的經驗，分享下個人對 sre 的理解，**「面向產品/基礎技術的研發」和「穩定性保障」兩種角色之間的協作關係，更好地為業務服務。
最早討論 sre **於 google 這本書《site reliability engineering: how google runs production systems》（豆瓣鏈結）。由 google sre 關鍵成員分享他們是如何對軟體進行生命週期的整體性關注，以及為什麼這樣做能夠幫助 google 成功地構建、部署、監控和運維世界上現存最大的軟體系統。
從 wikipedia: site reliability engineering中可了解到 sre 的定義：
其中有句形象描述 sre 工作的描述：
即 sre 的目標是構建可擴充套件和高可用的軟體系統，通過軟體工程的方法解決基礎設施和操作相關的問題。
基於上述描述，我對 sre 的理解是：
google sre 一書中，對軟體工程從生命週期角度有乙個很形象的描述：
軟體工程有的時候和養孩子類似：雖然生育的過程是痛苦和困難的，但是養育孩子**的過程才是真正需要花費絕大部分精力的地方。專案生命週期中，設計和構建軟體系統的時間精力佔比，通常是少於系統上線之後的維護管理。為了更好地維護系統可靠執行，需要考慮兩種型別的角色：乙個軟體系統的 40%~90% 的花銷其實是花在開發建設完成之後不斷維護過程中的。
第一類角色對應產品/基礎技術研發，第二類角色對應 sre，二者的共同目標均是為了達成專案目標，協同服務好業務。
針對穩定性的影響，直接參與處理客戶問題的同學會更有體感：
穩定性保障的價值由此凸顯：
穩定性問題通常會有這些特徵：
線上穩定性問題，人為操作不當導致的比例很高，集中在發布和線上運維兩個環節，均是高頻操作。對於複雜系統，這兩個環節對專家經驗有較強的依賴。
發生的穩定性問題通常具有系統性的特徵，即非單個功能元件缺陷導致，而是由一系列因素綜合作用導致，如缺少監控告警導致不能及時感知，缺少日誌不能有助於快速定位問題，缺少良好的問題排查流程導致依賴個人能力，缺少良好的協調溝通極致導致問題處理時長增加、客戶影響程度加劇等。
問題是不可避免的，流量的突增、伺服器/網路/儲存的損壞、未覆蓋的輸入等，均會誘發問題的出現。
業務對外有 sla，向客戶承諾一定程度的穩定性，未達到時按照協議進行賠付，同時問題又不可不免，在滿足內部 slo 標準的前提下繼續提公升穩定性，會帶來更高的實現成本，對業務的收益增量也會更小。
sre 需要對問題特徵有深入理解，系統性設計和實施解決方案，並抓住一段時間內的主要問題進行解決。
落地過程中，可先從如下三個抓手系統解決:
可控性方面，包括如下三個主要維度：
操作管理
設計評審
可觀測方面，包括如下幾個重要維度：日誌
巡檢 告警
穩定性保障最佳實踐，是從歷史問題和業界實踐方面抽象出意識、流程、規範、工具，在系統設計之初就融入其中，並在系統整個生命週期中加以使用，如通過模板固化最佳實踐：
乙個例子：
維度評估項
可觀測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 項形成分級，便於交流和進行專案穩定性評估：
級別標準
l01. 可觀測、可灰度、可回滾 均不滿足
l11. 可觀測、可灰度、可回滾 滿足 50% 以上要求
l21. 可觀測、可灰度、可回滾 滿足 90% 以上要求
l31. 可觀測、可灰度、可回滾 滿足 90% 以上要求
2. 可保護滿足 50% 以上要求
l41. 可觀測、可灰度、可回滾 滿足 90% 以上要求
2. 可保護滿足 90% 以上要求
3. 可控成本滿足 50% 以上要求
l51. 可觀測、可灰度、可回滾 滿足 90% 以上要求
2. 可保護滿足 90% 以上要求
3. 可控成本滿足 90% 以上要求
當最佳實踐可以通過文件進行規範化，接下來就可以提供工具或服務將其低成本應用，使得穩定性保障最佳實踐成為基礎設施。
sre 需要在穩定性相關的方**和實踐方面不斷迭代，自上而下設計，自下而上反饋，合理、可靠保障穩定性。
再回顧下軟體系統生命週期中的兩類角色：
這兩類角色是相互協作、相互服務的關係，擁有共同的目標：滿足業務需求，更好服務業務。
sre 通常會橫向支撐多個專案，對線上問題的型別、解決實踐有更為全面的理解和思考，基於此會形成最佳實踐的理論、工具或服務，為研發提供理論、工具的支援，也可以在此基礎上產品化穩定性保障解決方案，為更多的客戶服務，創造更大的價值。
產品/基礎技術研發對業務需求、功能/技術細節有更深入的理解，一方面直接帶來業務價值，一方面可通過實踐為穩定性保障帶來切合實際的需求，進一步和 sre 共同保障穩定性。
兩種型別的角色，需要朝著共同的目標並肩協作，與業務共同發展，實現共贏。
sre 由於工作的性質，在橫向方面會服務大量的業務，以實踐積累對穩定性保障問題域的深入理解和穩定性保障重要性的深刻認知，在縱向方面會通過技術手段將穩定性保障最佳實踐進行沉澱和應用；同時眼光又是與研發、業務一齊向前看，綜合技術和管理創造價值。
以上是從個人角度對 sre 及穩定性保障的理解，重點在於解決問題和創造更大的價值。
豆瓣 sre
wikipedia: site reliability engineering
wikipedia: controllability
wikipedia: observability
site: google sre
這是阿里技術專家對 SRE 和穩定性保障的理解
在技術工作中，對於產品 基礎技術研發和 sre 兩種角色，通常會有基於 是否側重編碼 的理解。對於產品研發轉做 sre 經常會產生是否要 脫離編碼工作 的看法，或者認為是否要 偏離對產品 基礎技術的推進 基於過往的技術研發和穩定性保障的經驗，分享下個人對 sre 的理解，面向產品 基礎技術的研發 和...
什麼是DevOps？阿里專家為你來解讀
近幾個月，運維事件頻發。從 爐石資料被刪 到 mongodb遭黑客勒索 從 gitlab資料庫被誤刪 到某家公司漏洞被組合攻擊。這些事件，無一不在吶喊 做好運維工作的重要性。然而，從傳統it部署到雲，人肉運維已經是過去式，雲上運維該怎麼開展？尤其是雲2.0時代，運維已經向全域性化 流程化和精細化模式...
技術專家的種類
技術專家主要可以分為如下2種 布道師型和科學家型 布道師型的特徵 熟悉各種程式設計規則，了解各種設計方案。他們可以侃侃而談，說起來頭頭是道。他們也了解很多技術細節。在面試過程中，這種人是最容易得到高分的。科學家型的特徵 在實際工作中，布道師更擅長當技術講師，也能解決很多技術難題。但是面臨涉及系統底層...