作為一個(gè)搞運(yùn)維的，你真的了解SRE么？
0、為什么誕生 SRE？
- 原因一：企業(yè)成本的增長(zhǎng)同用戶的增長(zhǎng)不成線性變化。但是隨著系統(tǒng)的復(fù)雜度提升，組建越來(lái)越多，用戶的流量壓力也越來(lái)越大，相關(guān)的變更也會(huì)越來(lái)越多，各模塊之間的變更順序也會(huì)越來(lái)越復(fù)雜。在這樣的情況下，單純的靠運(yùn)維人力的數(shù)量提升無(wú)法滿足業(yè)務(wù)的發(fā)展需求，而且會(huì)提升企業(yè)的成本；
- 原因二：傳統(tǒng)的研發(fā)團(tuán)隊(duì)和運(yùn)維團(tuán)隊(duì)天然具有沖突。公司的IT人員的配置：研發(fā)（Dev）和運(yùn)維（Ops），研發(fā)部門聚焦在快速構(gòu)建和快速發(fā)布；運(yùn)維部門關(guān)注的是如何避免發(fā)生故障，從目標(biāo)上講就是矛盾的。且隨著 IT 技術(shù)的發(fā)展，對(duì) IT 從業(yè)者的要求也越來(lái)越高，既要懂得底層系統(tǒng)，也要懂得數(shù)據(jù)算法，同時(shí)對(duì)主流技術(shù)還要快速追趕，滿足這樣要求的人才太少；
- 原因三：生產(chǎn)工具為適配生產(chǎn)力發(fā)展的必然產(chǎn)物。為了提高IT行業(yè)的整體效率和質(zhì)量，使得從手工運(yùn)維時(shí)代，逐漸過(guò)度到腳本工具運(yùn)維，在發(fā)展到平臺(tái)數(shù)據(jù)運(yùn)維，再到平臺(tái)軟件運(yùn)維，在發(fā)展到智能自動(dòng)化運(yùn)維。通過(guò)一系列手段、工具、理念的進(jìn)步，將 Ops 技術(shù)發(fā)展到 DevOps、DataOps、AIOps 等；
一、什么是 SRE？
1.1 SRE 的基本了解
那么區(qū)別于研發(fā)同學(xué)和運(yùn)維同學(xué)，SRE 要做一些什么工作，又要具備什么樣的能力呢？
Google 試從解決 Dev 和 Ops 之間的矛盾出發(fā)，雇傭軟件工程師，創(chuàng)造軟件系統(tǒng)來(lái)維護(hù)系統(tǒng)運(yùn)行以替代傳統(tǒng)運(yùn)維模型中的人工操作。SRE 團(tuán)隊(duì)和產(chǎn)品研發(fā)部分在學(xué)術(shù)和工作背景上非常相似，從本質(zhì)上將，SRE 就是在用軟件工程的思維和方法論完成以前由系統(tǒng)管理員團(tuán)隊(duì)手動(dòng)完成的任務(wù)。
Google 的 SRE 具體會(huì)負(fù)責(zé)哪些？
SRE在Google不負(fù)責(zé)某個(gè)服務(wù)的上線、部署，SRE主要是保障服務(wù)的可靠性和性能，同時(shí)負(fù)責(zé)數(shù)據(jù)中資源分配，為重要服務(wù)預(yù)留資源，SRE并不負(fù)責(zé)某個(gè)業(yè)務(wù)邏輯的具體編寫，主要負(fù)責(zé)在服務(wù)出現(xiàn)宕機(jī)等緊急事故時(shí)，可以快速作出響應(yīng)，盡快恢復(fù)服務(wù)，減少服務(wù)掉線而造成的損失。
SRE 日常工作和職責(zé)包含哪些
一般來(lái)說(shuō)，SRE團(tuán)隊(duì)要承擔(dān)以下幾類職責(zé)：可用性改進(jìn)、延遲優(yōu)化、性能優(yōu)化、效率優(yōu)化、變更管理、監(jiān)控、緊急事物處理以及容量規(guī)劃與管理。
Tools Don’t create reliability. Humans do. But tools can help.
SRE 的使命
在減少資源消耗的同時(shí)，從可用性和性能層面，提升用戶的體驗(yàn)。
Operations should NOT be a part of SRE missions. Operation is a way to understand production.
1.2 SRE 的技能堆棧
語(yǔ)言和工程實(shí)現(xiàn)
- 深入立即開發(fā)語(yǔ)言（Java/Golang等）
業(yè)務(wù)部門使用開發(fā)框架
并發(fā)、多線程和鎖
資源模型理解：網(wǎng)絡(luò)、內(nèi)存、CPU
故障處理能力（分析瓶頸、熟悉相關(guān)工具、還原現(xiàn)場(chǎng)、提供方案）
常見業(yè)務(wù)設(shè)計(jì)方案，多種并發(fā)模型，以及相關(guān) Scalable 設(shè)計(jì)
各類底層數(shù)據(jù)庫(kù)和存儲(chǔ)系統(tǒng)的特性和優(yōu)化
問(wèn)題定位工具
- 容量管理
- Tracing 鏈路追蹤
- Metrics 度量工具
- Logging 日志系統(tǒng)
運(yùn)維架構(gòu)能力
- Linux 精通，理解 Linux 負(fù)載模型，資源模型
- 熟悉常規(guī)中間件（MySQL Nginx Redis Mongo ZooKeeper 等），能夠調(diào)優(yōu)
- Linux 網(wǎng)絡(luò)調(diào)優(yōu)，網(wǎng)絡(luò) IO 模型以及在語(yǔ)言里面實(shí)現(xiàn)
- 資源編排系統(tǒng)（Mesos / Kubernetes）
理論
- 機(jī)器學(xué)習(xí)中相關(guān)理論和典型算法
- 熟悉分布式理論（Paxos / Raft / BigTable / MapReduce / Spanner 等），能夠?yàn)閳?chǎng)景決策合適方案
- 資源模型（比如 Queuing Theory、負(fù)載方案、雪崩問(wèn)題）
- 資源編排系統(tǒng)（Mesos / Kubernetes）
二、SRE 是如何解決問(wèn)題的？
2.1 解耦中臺(tái)系統(tǒng)與應(yīng)用
研發(fā)同學(xué)為生產(chǎn)環(huán)境負(fù)責(zé)，而SRE為組件或集群的可服務(wù)能力和穩(wěn)定性負(fù)責(zé)
SRE工程師中大部分是標(biāo)準(zhǔn)的軟件工程師，他們擅長(zhǎng)使用系統(tǒng)工程的方法去解決基礎(chǔ)系統(tǒng)中的問(wèn)題，同時(shí)持續(xù)的、工程化的解決問(wèn)題，使得運(yùn)維的壓力不會(huì)隨著上層應(yīng)用的增加而線性增加（通常20人的SRE團(tuán)隊(duì)，可以支持上千研發(fā)同學(xué)的應(yīng)用開發(fā)）。同時(shí)SRE同學(xué)對(duì)Unix系統(tǒng)內(nèi)部細(xì)節(jié)、1～3層網(wǎng)絡(luò)比較了解，可以同研發(fā)一起分析應(yīng)用程序性能問(wèn)題。
SRE應(yīng)該更好的進(jìn)行系統(tǒng)元數(shù)據(jù)的管理
系統(tǒng)的元數(shù)據(jù)應(yīng)該是系統(tǒng)的架構(gòu)拓?fù)鋱D，通過(guò)動(dòng)態(tài)、準(zhǔn)確的更新元數(shù)據(jù)可以將采集到的Event、Message、Metric 等數(shù)據(jù)映射到真實(shí)環(huán)境中去，并能通過(guò)各種手段進(jìn)行系統(tǒng)健康程度的診斷，是的自動(dòng)化監(jiān)控和管理成為可能。
SRE通過(guò)穩(wěn)定性進(jìn)行抽象，可以通用的解決穩(wěn)定性問(wèn)題
為了讓龐大系統(tǒng)的運(yùn)行效率提高，要不斷的優(yōu)化系統(tǒng)中的熱點(diǎn)，并將系統(tǒng)中的熱點(diǎn)服務(wù)擴(kuò)展、升級(jí)、重構(gòu)成為一個(gè)組建化的服務(wù)，這也是SRE中解耦系統(tǒng)的方法。不僅如此，SRE對(duì)各個(gè)服務(wù)的可用性進(jìn)行標(biāo)準(zhǔn)化定義，將統(tǒng)一的標(biāo)準(zhǔn)應(yīng)用到不同的服務(wù)中去，將穩(wěn)定性作為各個(gè)服務(wù)的重要度量指標(biāo)，通過(guò)上述操作，收攏服務(wù)治理問(wèn)題，提供系統(tǒng)的魯棒性。
2.2 明確服務(wù)之間的可用性依賴
2.2.1 面向 SLO 編程標(biāo)準(zhǔn)的推行
針對(duì) SLO，我們舉一個(gè)例子來(lái)說(shuō)明以下，
為什么要有 SLO，設(shè)置 SLO 的好處是什么呢？
- 對(duì)于客戶而言，是可預(yù)期的服務(wù)質(zhì)量，可以簡(jiǎn)化客戶端的系統(tǒng)設(shè)計(jì)
- 對(duì)于服務(wù)提供者而言
可預(yù)期的服務(wù)質(zhì)量
更好的取舍成本/收益
更好的風(fēng)險(xiǎn)控制(當(dāng)資源受限的時(shí)候)
故障時(shí)更快的反應(yīng)，采取正確措施
注：
- 關(guān)于如何來(lái)定義SLO是一個(gè)相當(dāng)復(fù)雜的事情，這個(gè)使用往往跟用戶體驗(yàn)有直接的關(guān)系，推薦一個(gè)實(shí)際案例來(lái)展開，如何定制自己服務(wù)的SLO。
（Case Study: Implementing SLOs for a New Service - https://www.usenix.org/conference/srecon19americas/presentation/lawson）
- 推薦一篇文章，闡述請(qǐng)求延時(shí)的SLO如何指定的，具體可以參考鏈接《Latency SLOs Done Right》https://www.usenix.org/sites/default/files/conference/protected-files/srecon19apac_schlossnagle_latency_slides.pdf
- 推薦一篇文章，從請(qǐng)求在系統(tǒng)運(yùn)行中闡述了一些核型的SLO該如何制定，《How to trade off server utilization and tail latency》https://www.usenix.org/sites/default/files/conference/protected-files/srecon19apac_slides_plenz.pdf
2.2.2 面向 SLO 監(jiān)控的設(shè)計(jì)
SLO 結(jié)果導(dǎo)向的告警，而不是原因?qū)虻母婢?/strong>
- 四個(gè)黃金信號(hào)
服務(wù)不可用，或訪問(wèn)速度變慢時(shí)，往往會(huì)影響到產(chǎn)品的整體質(zhì)量，目前了解到的一些基礎(chǔ)監(jiān)控指標(biāo)就達(dá)到上百種，通常的做法是在這些指標(biāo)當(dāng)中需要選取平臺(tái)或業(yè)務(wù)比較關(guān)注的指標(biāo)進(jìn)行監(jiān)控報(bào)警；
Google的網(wǎng)站可靠性工程師小組（SRE）定義了四個(gè)需要監(jiān)控的關(guān)鍵指標(biāo)。
他們稱之為“四個(gè)黃金信號(hào)”：延遲（Latency），流量（Traffic），錯(cuò)誤（Errors）和飽和度（Saturation）。這四個(gè)信號(hào)應(yīng)該是服務(wù)級(jí)別非常關(guān)鍵部分，因?yàn)樗鼈儗?duì)于提供高可用性的服務(wù)至關(guān)重要。
- 如何定義高質(zhì)量的監(jiān)控：
明確業(yè)務(wù)服務(wù)的SLO（應(yīng)該與該業(yè)務(wù)提供給客戶的期望達(dá)成一致），并采用合理的SLI來(lái)描述；
比如計(jì)數(shù)信息（總量、成功量）、測(cè)量信息（同比、環(huán)比）；
主觀上監(jiān)控應(yīng)該有豐富的內(nèi)部狀態(tài)數(shù)據(jù)、具備高可觀測(cè)性條件；
客觀上具備業(yè)務(wù)視角，能夠快速定位是全局問(wèn)題還是局部問(wèn)題；
系統(tǒng)本身的魯棒性，不會(huì)因?yàn)槟硞€(gè)局部問(wèn)題影響監(jiān)控的權(quán)威性；
具備quota限制能力，防止出現(xiàn)容量的問(wèn)題；
報(bào)警清理和定期的規(guī)則優(yōu)化，定期進(jìn)行盤點(diǎn)告警，并優(yōu)化掉無(wú)SLO影響的規(guī)則；
2.3 完善的場(chǎng)景化演練
自動(dòng)化系統(tǒng)的建設(shè)中除了要考慮系統(tǒng)的能力外，還要考慮人在其中所發(fā)揮的重要作用，畢竟一旦一些突發(fā)的時(shí)事件若必須由人來(lái)處理，則這時(shí)刻人的穩(wěn)定性和準(zhǔn)確性也是需要保證的。微軟在SRE大會(huì)中提出了一個(gè)有意思的觀點(diǎn)：如果一個(gè)系統(tǒng)能夠比人做的更好，那人應(yīng)該知道如何監(jiān)控這個(gè)系統(tǒng)本身。
因此，在保證SLO的情況下，可以做一些攻防演練（關(guān)閉SRE系統(tǒng)的UI后，SRE該如何操作？）；或構(gòu)建一個(gè)模擬系統(tǒng)，讓人來(lái)執(zhí)行系統(tǒng)；并學(xué)習(xí)故障的復(fù)盤報(bào)告等。
三、淺談 SRE 的觀察
3.1 從 SRE 2019 觀察
SRE CONF 2019 傳送門：
- Conference Report：
SRECON AMERICAS 2019 ：
https://noidea.dog/blog/srecon-americas-2019
- Conference Program：
SRECON Asia/Pacific 2019 ：
https://www.usenix.org/conference/srecon19asia/program
3.2 幾個(gè)應(yīng)該多花精力關(guān)注的點(diǎn)
- 系統(tǒng)的可觀測(cè)性，換句話說(shuō)是你真的了解你的系統(tǒng)么？你真的了解你的應(yīng)用么？（不僅是后臺(tái)系統(tǒng)、還有一些移動(dòng)端系統(tǒng)和應(yīng)用）要從 Logs 中索取更多的知識(shí)，挖掘出更多的內(nèi)容供 SRE 使用。
- 隨著觀測(cè)性要求的不斷提供，靈活、新穎的可視化工具被大家越來(lái)越認(rèn)可，單獨(dú)使用線圖進(jìn)行可視化指標(biāo)是遠(yuǎn)遠(yuǎn)不夠了，需要更加新穎和便捷的可視化方案；同時(shí)要讓數(shù)據(jù)產(chǎn)生價(jià)值，而不是簡(jiǎn)單的可視化，越來(lái)越多的公司使用Pipeline來(lái)解決相關(guān)任務(wù)的創(chuàng)建和管理，讓數(shù)據(jù)清洗和規(guī)整后變的更優(yōu)價(jià)值，使得算法產(chǎn)生最大的效用。
- SRE 不僅僅要發(fā)現(xiàn)系統(tǒng)中存在的熱點(diǎn)問(wèn)題，也要能快速解決這些熱點(diǎn)問(wèn)題，并在以后的架構(gòu)演進(jìn)中消除這樣的問(wèn)題，則系統(tǒng)的自愈能力應(yīng)該成為每個(gè)公司都關(guān)注的問(wèn)題。
