簡介：產(chǎn)品/基礎(chǔ)技術(shù)研發(fā) 和 SRE 這兩類角色是相互協(xié)作、相互服務(wù)的關(guān)系，擁有共同的目標：滿足業(yè)務(wù)需求，更好服務(wù)業(yè)務(wù)。

前言

在技術(shù)工作中，對于產(chǎn)品/基礎(chǔ)技術(shù)研發(fā)和 SRE 兩種角色，通常會有基于「是否側(cè)重編碼」的理解。對于產(chǎn)品研發(fā)轉(zhuǎn)做 SRE ，經(jīng)常會產(chǎn)生是否要「脫離編碼工作」的看法，或者認為是否要「偏離對產(chǎn)品/基礎(chǔ)技術(shù)的推進」。

基于過往的技術(shù)研發(fā)和穩(wěn)定性保障的經(jīng)驗，分享下個人對 SRE 的理解，探討「面向產(chǎn)品/基礎(chǔ)技術(shù)的研發(fā)」和「穩(wěn)定性保障」兩種角色之間的協(xié)作關(guān)系，更好地為業(yè)務(wù)服務(wù)。

SRE 概述

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

從 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 的目標是構(gòu)建可擴展和高可用的軟件系統(tǒng)，通過軟件工程的方法解決基礎(chǔ)設(shè)施和操作相關(guān)的問題。

在 Google SRE 書中，對 SRE 日常工作狀態(tài)有個準確的描述：至多 50% 的時間精力處理操作相關(guān)事宜，50% 以上的精力通過軟件工程保障基礎(chǔ)設(shè)施的穩(wěn)定性和可擴展性。

基于上述描述，我對 SRE 的理解是：

• 職責：保障基礎(chǔ)設(shè)施的穩(wěn)定性和可擴展性
• 核心：解決問題
• 方法：通過操作類事務(wù)積累問題經(jīng)驗，通過編碼等方式提升問題的解決效率

軟件生命周期

Google SRE 一書中，對軟件工程從生命周期角度有一個很形象的描述：

軟件工程有的時候和養(yǎng)孩子類似：雖然生育的過程是痛苦和困難的，但是養(yǎng)育孩子成人的過程才是真正需要花費絕大部分精力的地方。

一個軟件系統(tǒng)的 40%~90% 的花銷其實是花在開發(fā)建設(shè)完成之后不斷維護過程中的。

項目生命周期中，設(shè)計和構(gòu)建軟件系統(tǒng)的時間精力占比，通常是少于系統(tǒng)上線之后的維護管理。為了更好地維護系統(tǒng)可靠運行，需要考慮兩種類型的角色：

• 專注于設(shè)計和構(gòu)建軟件系統(tǒng)
• 專注于整個軟件系統(tǒng)生命周期管理，包括從其設(shè)計到部署，歷經(jīng)不斷改進，最后順利下線

第一類角色對應(yīng)產(chǎn)品/基礎(chǔ)技術(shù)研發(fā)，第二類角色對應(yīng) SRE，二者的共同目標均是為了達成項目目標，協(xié)同服務(wù)好業(yè)務(wù)。

穩(wěn)定性保障價值

針對穩(wěn)定性的影響，直接參與處理客戶問題的同學會更有體感：

• 通過問題發(fā)生時客戶直接反饋的影響程度、緊急程度，感受到穩(wěn)定性給客戶帶來的焦慮
• 通過問題處理結(jié)束后客戶的反饋，感受到客戶對穩(wěn)定性保障的感謝或憤怒
• 通過事后在營收狀況、客戶規(guī)模變化，感受到穩(wěn)定性對業(yè)務(wù)營收的影響
• 通過產(chǎn)品規(guī)劃的的延期，感受到穩(wěn)定性對產(chǎn)品迭代的影響

穩(wěn)定性保障的價值由此凸顯：

• 保障客戶的產(chǎn)品體驗，滿足客戶對約定的可靠性訴求
• 加速業(yè)務(wù)迭代，滿足業(yè)務(wù)對穩(wěn)定性訴求，業(yè)務(wù)注意力集中在更快速推出滿足客戶需求的功能

SRE 如何保障穩(wěn)定性

穩(wěn)定性問題通常會有這些特征：

• 人為導(dǎo)致，依賴專家經(jīng)驗
• 一系列因素綜合導(dǎo)致
• 不可避免
• 100% 保障沒有必要

線上穩(wěn)定性問題，人為操作不當導(dǎo)致的比例很高，集中在 發(fā)布 和 線上運維 兩個環(huán)節(jié)，均是高頻操作。對于復(fù)雜系統(tǒng)，這兩個環(huán)節(jié)對專家經(jīng)驗有較強的依賴。

發(fā)生的穩(wěn)定性問題通常具有系統(tǒng)性的特征，即非單個功能組件缺陷導(dǎo)致，而是由一系列因素綜合作用導(dǎo)致，如缺少監(jiān)控告警導(dǎo)致不能及時感知，缺少日志不能有助于快速定位問題，缺少良好的問題排查流程導(dǎo)致依賴個人能力，缺少良好的協(xié)調(diào)溝通極致導(dǎo)致問題處理時長增加、客戶影響程度加劇等。

問題是不可避免的，流量的突增、服務(wù)器/網(wǎng)絡(luò)/存儲的損壞、未覆蓋的輸入等，均會誘發(fā)問題的出現(xiàn)。

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

SRE 需要對問題特征有深入理解，系統(tǒng)性設(shè)計和實施解決方案，并抓住一段時間內(nèi)的主要問題進行解決。

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

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

• 可控性
• 可觀測
• 穩(wěn)定性保障最佳實踐

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

• 發(fā)布管理

  • 重點解決發(fā)布導(dǎo)致的人為穩(wěn)定性問題
  • 包括發(fā)布前重要變更評審和發(fā)布中變更動作管理等

• 操作管理

  • 重點解決黑屏操作導(dǎo)致的人為穩(wěn)定性問題
  • 包括統(tǒng)一集群操作入口、集群操作權(quán)限管理、集群操作審計等

• 設(shè)計評審

  • 重點解決軟件系統(tǒng)設(shè)計階段應(yīng)用穩(wěn)定性保障最佳實踐
  • 包括集群方案評審和重要功能設(shè)計評審等

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

• 監(jiān)控

  • 重點解決軟件系統(tǒng)運行態(tài)的感知能力
  • 包括監(jiān)控收集/可視化系統(tǒng)的搭建和維護等

• 日志

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

• 巡檢

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

• 告警

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

穩(wěn)定性保障最佳實踐，是從歷史問題和業(yè)界實踐方面抽象出意識、流程、規(guī)范、工具，在系統(tǒng)設(shè)計之初就融入其中，并在系統(tǒng)整個生命周期中加以使用，如通過模板固化最佳實踐：

• 項目質(zhì)量驗收標準
• 項目安全生產(chǎn)標準
• 項目發(fā)布前 checklist
• 項目 TechReview 模板
• 項目 Kick-off 模板
• 項目管理規(guī)范
• etc.

一個例子：

維度評估項

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

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

級別標準

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% 以上要求

當最佳實踐可以通過文檔進行規(guī)范化，接下來就可以提供工具或服務(wù)將其低成本應(yīng)用，使得穩(wěn)定性保障最佳實踐成為基礎(chǔ)設(shè)施。

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

共贏，攜手服務(wù)業(yè)務(wù)

再回顧下軟件系統(tǒng)生命周期中的兩類角色：

• 產(chǎn)品/基礎(chǔ)技術(shù)研發(fā)：專注于設(shè)計和構(gòu)建軟件系統(tǒng)
• SRE：專注于整個軟件系統(tǒng)生命周期管理，包括從其設(shè)計到部署，歷經(jīng)不斷改進，最后順利下線

這兩類角色是相互協(xié)作、相互服務(wù)的關(guān)系，擁有共同的目標：滿足業(yè)務(wù)需求，更好服務(wù)業(yè)務(wù)。

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

產(chǎn)品/基礎(chǔ)技術(shù)研發(fā)對業(yè)務(wù)需求、功能/技術(shù)細節(jié)有更深入的理解，一方面直接帶來業(yè)務(wù)價值，一方面可通過實踐為穩(wěn)定性保障帶來切合實際的需求，進一步和 SRE 共同保障穩(wěn)定性。

兩種類型的角色，需要朝著共同的目標并肩協(xié)作，與業(yè)務(wù)共同發(fā)展，實現(xiàn)共贏。

小結(jié)

SRE 由于工作的性質(zhì)，在橫向方面會服務(wù)大量的業(yè)務(wù)，以實踐積累對穩(wěn)定性保障問題域的深入理解和穩(wěn)定性保障重要性的深刻認知，在縱向方面會通過技術(shù)手段將穩(wěn)定性保障最佳實踐進行沉淀和應(yīng)用；同時眼光又是與研發(fā)、業(yè)務(wù)一齊向前看，綜合技術(shù)和管理創(chuàng)造價值。

以上是從個人角度對 SRE 及穩(wěn)定性保障的理解，重點在于 解決問題 和 創(chuàng)造更大的價值。

References

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

---

掃碼了解更多技術(shù)內(nèi)容與客戶案例：

原文鏈接：https://developer.aliyun.com/article/780768?

版權(quán)聲明：本文內(nèi)容由阿里云實名注冊用戶自發(fā)貢獻，版權(quán)歸原作者所有，阿里云開發(fā)者社區(qū)不擁有其著作權(quán)，亦不承擔相應(yīng)法律責任。具體規(guī)則請查看《阿里云開發(fā)者社區(qū)用戶服務(wù)協(xié)議》和《阿里云開發(fā)者社區(qū)知識產(chǎn)權(quán)保護指引》。如果您發(fā)現(xiàn)本社區(qū)中有涉嫌抄襲的內(nèi)容，填寫侵權(quán)投訴表單進行舉報，一經(jīng)查實，本社區(qū)將立刻刪除涉嫌侵權(quán)內(nèi)容。

總結(jié)

以上是生活随笔為你收集整理的阿里技术专家对 SRE 的解读的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。