SRE Google 運(yùn)維解密，是 SRE 領(lǐng)域的啟蒙之作，講述了 Google 的 SRE 實(shí)踐，SRE 就是從 Google 流傳出來的。本文是讀書筆記，第一篇，概述 SRE 方法論。幫大家把書讀薄，當(dāng)然，也加入了一些我的個(gè)人理解，希望對你有幫助。

為何需要 SRE

傳統(tǒng)的 sysadmin 的方式，偏手工運(yùn)維，機(jī)器越多所需運(yùn)維工程師越多，對于 Google 的體量（毛估估現(xiàn)在大概有幾百萬臺(tái)機(jī)器）和增長速度，成本（人工成本、管理成本等）不可承受。

因?yàn)槟繕?biāo)不同、技術(shù)背景不同、對可靠性理解不同，傳統(tǒng)運(yùn)維和產(chǎn)品研發(fā)團(tuán)隊(duì)之間，很容易形成巨大的鴻溝，有時(shí)會(huì)上升到部門之間的信任和尊重層面。比如拿變更舉例，研發(fā)部門想要：“隨時(shí)隨地發(fā)布新功能，沒有任何阻攔”，傳統(tǒng)的運(yùn)維團(tuán)隊(duì)想要的則是：“一旦一個(gè)東西在生產(chǎn)環(huán)境中正常工作了，就不要再做任何改動(dòng)”。這樣的兩個(gè)團(tuán)隊(duì)，是沒法很好的合作的，尤其是在 Google 的體量和增速下，得改。解法就是 SRE。

Google SRE 概述

Google SRE 的創(chuàng)始人是 Benjamin Treynor Sloss，研發(fā)出身，2003 年加入 Google，被任命領(lǐng)導(dǎo)一個(gè) 7 人小組（現(xiàn)在，SRE 團(tuán)隊(duì)已經(jīng)上千人了），負(fù)責(zé)“生產(chǎn)環(huán)境維護(hù)”。Google 當(dāng)時(shí)的增速是非常快的，如果按照傳統(tǒng)的玩法，招人的速度完全無法匹配機(jī)器增速，怎么做這個(gè)“生產(chǎn)環(huán)境維護(hù)”的工作呢？

Benjamin Treynor 是資深研發(fā)，自然就會(huì)考慮用軟件工程的手段來解決遇到的各類問題，所以 Google SRE 首先，得具備研發(fā)技能，用研發(fā)技能來解決各類生產(chǎn)維護(hù)重復(fù)工作。他們具備如下特質(zhì)：

• 對重復(fù)性、手工性的操作有天然的排斥感

• 有足夠的技術(shù)能力快速開發(fā)出軟件系統(tǒng)以替代手工操作

但是，做過運(yùn)維的人都知道，總有一些日常運(yùn)維的工作無法避免，有時(shí)根本沒時(shí)間寫代碼，比如處理工單、手工操作，尤其是在基礎(chǔ)設(shè)施平臺(tái)工程不完備的情況下。這可咋整？

Google 提出了 50% 的原則，即日常運(yùn)維的時(shí)間不能超過 50%，即需要至少拿出一半以上的時(shí)間來做工程研發(fā)，釜底抽薪，用工程手段解決手工操作。那有的時(shí)候，日常運(yùn)維工作繁重，超過了 50% 時(shí)間分配原則，怎么辦？把相關(guān)工作交給產(chǎn)品研發(fā)團(tuán)隊(duì)的 leader，讓他來幫忙消化掉一部分工作。研發(fā) leader 一看，運(yùn)維側(cè)的工作好多啊，是不是我們的軟件不夠魯棒、很多應(yīng)該自動(dòng)處理的邏輯沒有自動(dòng)處理，就會(huì)去改進(jìn)，形成正向循環(huán)。當(dāng)然，這個(gè)機(jī)制需要公司管理層強(qiáng)力推動(dòng)。如果遇到一個(gè)研發(fā)團(tuán)隊(duì)說，運(yùn)維的活你們運(yùn)維干不完，干不完可以招人啊，管理層也不作為，就完了。

DevOps 還是 SRE

Benjamin Treynor 認(rèn)為，SRE 是 DevOps 模型在 Google 的具體實(shí)踐，帶有一些特別的擴(kuò)展。

SRE 技能組成

實(shí)際的人員組織來看， SRE 團(tuán)隊(duì)分兩類人，一類就是純研發(fā)，一類是具備八九成研發(fā)能力，同時(shí)還懂一些 UNIX 知識(shí)、網(wǎng)絡(luò)知識(shí)。如果國內(nèi)運(yùn)維團(tuán)隊(duì)想要轉(zhuǎn)型為 SRE 組織，就這個(gè)技能要求就很難達(dá)成（其實(shí)除了 Google，其他國外的公司也很難做到）。咋辦？

國內(nèi)的組織的做法：一個(gè)人能力有限，弄個(gè)團(tuán)隊(duì)來頂上，團(tuán)隊(duì)里既有只懂研發(fā)的人，又有只懂網(wǎng)絡(luò)的人，又有只懂操作系統(tǒng)的人，應(yīng)該就可以了吧。個(gè)人的看法是，這個(gè)做法基本是對的，但是不完全夠。因?yàn)殡m然是一個(gè)團(tuán)隊(duì)，但是不同的小組或個(gè)人的知識(shí)仍然是無法完全共享的，這使得在做工程決策、實(shí)踐的時(shí)候，沒法做到像 Google SRE 那樣如臂指使。

稍微改進(jìn)一下的做法是：團(tuán)隊(duì)里仍然要招聘一兩個(gè) SRE 專家，姑且稱為 SRE COE，既懂開發(fā)又懂運(yùn)維的那種，統(tǒng)籌所有工作，然后那些單方面的技能人才，輔助 SRE COE 來完成工作，相對會(huì)更靠譜一些。

SRE 方法論

SRE 團(tuán)隊(duì)的職責(zé)：可用性改進(jìn)，廷遲優(yōu)化，性能優(yōu)化，效率優(yōu)化，變更管理，監(jiān)控，緊急事務(wù)處理以及容量規(guī)劃與管理。要轉(zhuǎn)型的團(tuán)隊(duì)注意了，用軟件工程的手段達(dá)成以上目標(biāo)，就說明你們團(tuán)隊(duì)轉(zhuǎn)型成功了:)

在保障服務(wù) SLO 的前提下最大化迭代速度

變更是萬惡之源，生產(chǎn)環(huán)境中的故障，大概有 70% 都是變更引起的。屁股決定腦袋，運(yùn)維團(tuán)隊(duì)就希望盡量別有變更，研發(fā)團(tuán)隊(duì)要上線新 feature，那就需要頻繁變更，咋整？Google 提出了 “錯(cuò)誤預(yù)算” 的理念。

產(chǎn)品首先得確定 SLO，比如某個(gè)服務(wù)的季度 SLO 目標(biāo)是 99.99%，那不可用的 Quota 預(yù)算就是 0.01%，每個(gè)月按照 30 天來算，一個(gè)季度 90 天，允許的不可用分鐘數(shù)是：

90 * 24 * 60 * 0.01% = 12.96 分鐘 ≈ 13 分鐘

只要服務(wù)的季度不可用時(shí)長低于 13 分鐘，隨便折騰，但是一旦超過了 13 分鐘，說明 Quota 用光了，就不能隨意上線了，非得要上線，行么？也行，VP 審核通過吧。那意思就是：你看這個(gè)研發(fā)團(tuán)隊(duì)，上線老是出問題，不可信賴，現(xiàn)在又要上線了，SRE 是不準(zhǔn)備放行了，VP 大佬來決策吧，VP 大佬也非要允許上，那就上。

咋樣，這個(gè)方法聽著不錯(cuò)吧。貴司可以試試。這里要注意，服務(wù)要想減少故障時(shí)長，是需要有良好的基礎(chǔ)設(shè)施保障的，比如研發(fā)上線發(fā)現(xiàn)問題，想回滾，結(jié)果部署系統(tǒng)不可靠，這找誰說理去。所以，錯(cuò)誤預(yù)算這個(gè)方法可以用，但是不同的公司，SLO 的閾值得謹(jǐn)慎制定，沒有金剛鉆不攬瓷器活，基礎(chǔ)設(shè)施很爛，SLO 就定低點(diǎn)吧。

SLO 誰來定？

SLO 應(yīng)該是業(yè)務(wù)來定，但是?SRE 要提供一些信息，告訴業(yè)務(wù)達(dá)成什么樣的 SLO 要付出什么樣的成本，業(yè)務(wù)有了這些信息了，再來確定制定什么樣的 SLO。比如某個(gè)業(yè)務(wù)不盈利，就是個(gè)實(shí)驗(yàn)性質(zhì)的業(yè)務(wù)，SLO 低一點(diǎn)很正常，具體要看業(yè)務(wù)本身的決策，所以 SLO 的制定需要業(yè)務(wù)拍板。

監(jiān)控系統(tǒng)

核心要學(xué)習(xí)的是：每個(gè)需要通知到人的告警，必須對應(yīng) Runbook，即預(yù)案手冊。如果一個(gè)告警發(fā)出來，沒有人響應(yīng)，沒有相應(yīng)的動(dòng)作執(zhí)行，這個(gè)告警就是無效的。Runbook 鏈接一般配置在告警規(guī)則里，比如 Grafana、Nightingale、Datadog 的告警規(guī)則配置，都支持這么干。告警規(guī)則的 Runbook 預(yù)置率是一個(gè)很好的告警治理指標(biāo)。

有些告警可以不用立即處理，但是至少得創(chuàng)建個(gè)工單留待后續(xù)處理。

應(yīng)急事件處理

提前準(zhǔn)備好 Runbook，即預(yù)案手冊，比即興發(fā)揮，效果好 3 倍。

變更管理

要自動(dòng)化！要自動(dòng)化！要自動(dòng)化！自動(dòng)化完成以下項(xiàng)目：

• 采用漸進(jìn)式發(fā)布機(jī)制

• 有良好的監(jiān)控系統(tǒng)，可以快速發(fā)現(xiàn)問題

• 當(dāng)問題發(fā)生時(shí)，可以安全回滾

需求預(yù)測和容量規(guī)劃

要考慮的點(diǎn)包括：

• 自然增量：隨著用戶自然增長帶來的增量

• 非自然增量：比如市場活動(dòng)

• 周期性壓測：這點(diǎn)很關(guān)鍵，這點(diǎn)很關(guān)鍵，這點(diǎn)很關(guān)鍵，通過壓測才知道你的系統(tǒng)瓶頸在哪個(gè)微服務(wù)，才能把系統(tǒng)原始資源和業(yè)務(wù)容量對應(yīng)起來

資源部署

擴(kuò)容需要部署資源，變更也需要，這就是 Borg 的作用，其他公司可以采用類似 Kubernetes 的方案。不管使用什么方案，能夠快速、正確的完成部署，最大化資源使用，就可以了。

效率與性能

SRE 也需要關(guān)注服務(wù)性能，提升了性能，其實(shí)就是提高了資源利用效率，同樣的硬件可以支撐更大量的客戶。NetFlix 有專門的 Performance 工程師，Google 的話 SRE 一并干了這個(gè)事情。

小結(jié)

SRE 團(tuán)隊(duì)的職責(zé)：可用性改進(jìn)，廷遲優(yōu)化，性能優(yōu)化，效率優(yōu)化，變更管理，監(jiān)控，緊急事務(wù)處理以及容量規(guī)劃與管理。我們要用軟件工程的思維來解決這些問題，完活。留個(gè)問題：

SRE 要不要修改業(yè)務(wù)代碼？

比如增加一些監(jiān)控埋點(diǎn)，或者優(yōu)化一個(gè)算法提升軟件性能，或者換了一個(gè)更合理的存儲(chǔ)？歡迎大家留言討論 :)