前言

這幾天打算利用碎片時間讀了一下”SRE Google運維解密”這本書,目前讀了前幾章,感覺收獲頗多,結合自己的工作經歷和書中的要點,寫一些感悟和思考

SRE

有關SRE我就不多介紹了,是Site Reliability Engineering的英文縮寫,中文名字叫站點可靠性工程師,它的由來是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讀后感第一篇,后續再讀幾章,再寫點.

轉載請注明本頁網址：
http://www.snjht.com/jiaocheng/4326.html