讀SRE Google運維解密有感(一)

前言

這幾天打算利用碎片時間讀了一下"SRE Google運維解密"這本書，目前讀了前幾章，感受收穫頗多，結合本身的工做經歷和書中的要點，寫一些感悟和思考

SRE

有關SRE我就很少介紹了，中文名字叫站點可靠性工程師，它的由來是google想經過軟件工程師來解決複雜運維問題。 它裏面有不少有意思的點，好比:

• 運維工做只能佔比工做時間50%
• 另外50%要開發工具解決問題
• SRE和開發工程師會輪崗

這些相關概念網上不少都介紹了，我就不贅述了，我說下一些我感興趣的點

谷歌神話

谷歌一直在技術領域處於世界領先位置，從bigtable的三篇論文，開源的k8s，分佈式關係數據庫，谷歌的技術在IT領域能夠說是標杆。

有個傳說是谷歌內部使用的系統通常2-3年之後纔會出相關論文或者開源版本實現，出來了之後其它企業開始實踐還須要2-3年，等到你把這些實現了，谷歌又不知道實現了什麼黑科技。IT界若是是江湖的話，谷歌就像是少林派，有一種天下武功出少林的氣派。

因此SRE這本書自帶光環，不少人都以爲這是運維聖經，以爲這是拯救運維領域的不二法寶。

或許你也在讀這本書，你也想在內部嘗試SRE的一些方法和思想。

那麼首先我勸你先冷靜一下，它並非一個萬能的解藥，要先考慮下你的公司現狀，問題，結合實際國情，找到切實可行的方法。

我爲何這麼說呢？請往下看

谷歌的肌肉

首先本書一開始簡單說了下SRE的思想和方法論，而後介紹了谷歌的基礎設施，就好像一我的同樣，谷歌的基礎設施就是這我的的肌肉，有了強勁的肌肉才能跑得快，跳得高。

網絡設施

谷歌基於自研的交換機Clos，使用SDN技術，確保每一個數據中心可提供海量帶寬，而且能夠動態帶寬管理優化網絡鏈接。

調度系統

使用Borg負責在集羣層面管理任務編排工做

存儲

在物理機設施（磁盤）上構建了一套簡單可用，可靠的集羣存儲服務。

• Colossus GFS文件系統的改進白本
• Bigtable 鬆散存儲的，分佈式，有順序，持久化的NoSQL數據庫
• Spanner 分佈式的關係型數據庫

分佈式鎖

Chubby 提供一個能夠處理異地，跨機房級別鎖請求的集羣鎖服務

監控和報警

Borgmon 從監控對象抓取監控指標，這些指標能夠用來觸發報警，也能夠存儲起來供觀看。（開源實現是Prometheus）

RPC

全部谷歌服務之間使用RPC通訊，稱爲Stubby（開源實現gRPC），傳輸格式是Protobuf。

GSLB和BNS

• 利用地理位置進行負載均衡DNS請求
• 用戶服務層面負載均衡
• RPC層面負載均衡

經過各個層面的負載均衡將用戶流量導向健康的服務上面。

這些完善的基礎設施，給SRE中的方法和思想作了強有力的支撐。

故障不是洪水猛獸

SRE中定義了一個概念叫SLO(服務質量目標)，經過SLO合理評判一個服務要達成的服務質量。

首先我先說下」故障「這個詞，這個詞對運維人員來講，是很是不想聽到和遇到的。運維人員有一個重要任務是確保服務的穩定，換句話說就是沒有故障。

因此咱們或多或少談到「故障」就會色變，遇到故障立刻第一時間解決，爲了不下次還出現，咱們可能還會開「事故總結會」，優化流程和工具。

其實咱們不少時候對於「故障」的理解是簡單粗暴的，從一線員工到老闆都認爲「故障不能有」，「故障必須消除」，咱們耗費很大精力「消除了一切故障」，系統平穩運行了，本身也會萌生成就感，感受乾的還不賴。但是並無進一步去思考一下，故障存在的意義。

咱們常見的所謂「99.9%」，「99.99%」的服務可用性，可是並無使用科學方法來分析和規劃業務到底應該3個9仍是4個9。

SRE中說到一句話「100%穩定的系統是不存在的」，它把這個作爲一個前提，那也意味着系統是確定要出故障的。

SLO就是用來解決這個事情的，首先服務的故障不可避免，每一個服務的級別不一樣，不可能全部服務都是99.999999，要針對業務的不通特性制定不一樣的SLO。

好比： 谷歌的企業服務，針對企業用戶是有簽署服務中斷賠償協議的，那麼穩定性要求很高，因此它的SLO級別必須很高。 谷歌的youtube（當時），針對終端用戶且版本迭代很快，業務在不斷變化和創新，SLO級別能夠放低。

SLO的制定一般是產品經理，開發團隊，SRE一塊兒協商完成，你們根據業務的規模，產品特性，產品處於的階段制定。

SLO的制定，我以爲就是科學的面對「故障」這個問題，故障不可避免，不該該以消滅故障爲目的，合理的接受它，確保它在SLO標準的範圍內，高於這個標準會浪費人力和成本，低於這個標準就須要進行優化。

SLO的制定很大程度在於各個團隊之間的協商，你們都有基於數據的科學評判方法，好比產品預估的用戶數，產品發版週期，使用帶寬等。

中國的國情更多的是拍腦殼，老闆的態度，上面的一句話「不能有事故」，那就是99.999999999999999無限，沒有科學的進行評估。

SLO解決的問題

經過這樣一個SLO，以前不少使人頭疼的問題就迎刃而解了。

成本和收益的矛盾

你們都知道維護服務可用性的成本不是線性增加的，到必定程度，增長一個9可能須要10倍100倍的成本，經過SLO讓成本和收益取得很好的平衡，假設一個業務增長SLO等級，能夠計算一下須要的成本和帶來的收益，若是得不償失就能夠不用增長SLO等級。

科學的運維

有了SLO，對於運維工做有了可量化的標準，運維工程師不用天天提心吊膽，生怕出現故障，只要故障在SLO範圍內就是可接受的，節省出不少精力用在更重要的事情上。

穩定和創新的矛盾

你們都知道運維工程師最不喜歡的就是「線上變動」，一個服務若是不作變動通常都是很穩定的，問題每每出如今變動上。
但是一個新業務每每須要大量變動，不停的迭代創新。
這個時候運維會說：別作變動了，穩定是第一位的，出了故障，咱們得背鍋。
開發會說：咱們得變動，這樣纔有新功能，才能獲取更多用戶啊。
矛盾所以產生了。
經過SLO很好的解決了這個矛盾，咱們先一塊兒給這個業務制定好SLO的等級，若是是須要頻繁的變動的，可能SLO等級就會低一些。
這樣在知足業務創新的需求上，只要在SLO範圍內，就認爲業務是穩定的。
反之，若是變動太頻繁，使故障率超出了SLO可接受的範圍，能夠要求開發調低變動頻率，或者從新制定SLO等級。
這樣就解決了業務既要「穩定」又要「創新「的矛盾。

結語

SRE Google運維解密是很是好的一本書，它是谷歌運維體系的結晶，可是它也是創建在谷歌」健壯的肌肉「之上，創建在科學評估（非人治）之上，咱們能夠從中學習，也要冷靜思考。
這是SRE讀後感第一篇，後續再讀幾章，再寫點。

附一個360的招聘==>https://www.addops.cn/page/wanted