阿里技术专家对 SRE 的解读
前言
在技術(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)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 究竟什么是云原生DevOps呢?
- 下一篇: 消息队列之延时消息应用解析及实践