《SRE系列教程 | 孫宇聰：來自Google的DevOps理念及實踐（下）》要點：
本文介紹了SRE系列教程 | 孫宇聰：來自Google的DevOps理念及實踐（下），希望對您有用。如果有疑問，可以聯系我們。

接下來聊一聊SRE的一些最佳實踐,我認為Google做得比較好的幾點.

SRE的最佳實踐

建設平臺化服務體系

首先, Google現在是一個六萬人的公司,涉及到的產品線可能一百多個,各個部門之間差距很大,而且Google全球幾百個數據中心,有很多機器,它如何管理?如果按照國內公司的方式去管理早就累死了.因為國內很多運維部門從上到下什么都管,從買機器開始,一直到最上面安裝服務器、調試,配網絡,所以業務線、運維部門經常好幾千人.Google做得比較好的一點就是它把一個東西橫向切分,因為它很早之前就意識到很多部門或者很多人之間有共性?像現在國內有的公司也開始講的,運維部門要輸出能力,公司內部也要服務化,因為只有服務化才能讓每個團隊更加專業化.

所以回到Google這個平臺上,我認為它實際上是不停的在切分,就是橫向切分.首先最底下是所謂的資源供給層,就是相當于把數據中心這件事情真的當成了一個資源,可以服于用戶.就是用戶需要什么樣的機器,配置架構怎么樣,怎么設計數據中心,這些東西它都幫用戶做好.有一個專門的團隊去做這件事情,這個團隊也有自己的研發,也有自己的運維,也有自己的operation、PM,什么都有.

往上是技術架構,技術架構是大家經常聽說的Borg系統等,讓一些比較通用的技術或者通用的架構都能形成平臺式的東西.

再往上才是產品線,每一層實際上都有自己的SRE部門、運維部門,都是一個項目.所以把這個平臺搭起來之后,上層的人可以越來越少關心底下的細節問題,一定程度的減少了他很多精力、減少了很多官僚主義上的問題.需要計算資源的時候就給資源,不是還要先去審批又買機器,什么樣的機器,什么樣的配置都不一樣,所以整個公司是一個非常同質化的公司,很多業務底下共享的東西很多.工作在越底層的人如果能服務的人越多,就會產生一個所謂的放大效應.可能大公司都是這樣的,它有平臺化效應,底下的人可以搞出一個世界最好的數據中心,可以同時服務幾十個產品線的業務；搞出一個更好的數據庫,所有人都可以用,這是Google做得比較好的一點.

容量規劃和容量管理

然后大家會發現在做一個業務層運維的時候,可以關注更高級的東西,不是關心買什么樣機器,而是更多關心到底需要多少容量,這些容量應該在什么地方.在YouTube我們經常在辦公室擺一個世界地圖,大家經常會討論這里有一個數據中心,那里有一個數據中心,然后討論在這邊放多少容量,在那邊放多少容量,它們之間如何災備,我們可以考慮這些更高級的、更抽象的東西.這樣的好處是可以真正的做到容災,就是所謂的N+M.就是如果平時需要的峰值流量是N,M是作為災備流量或者是這個冗余流量.N和M到底是什么?很多公司連自己的N都不知道,從來沒有說過我們到底要處理多少流量,有些領導說我們“雙11”想來多大量的就來多大量,這怎么能搞好?

這個問題是運維部門獨特的功能或者獨特的角色,要負責將把這個東西確定下來,我們到底要承擔多大的流量,要有多少冗余.接下來就是驗證這件事情,到底有沒有這樣的能力,能不能處理這么大的流量或者這么大的需求? Google有一個內部指標就是130%,比如可以處理1秒交易量是一百萬,實際上集群的峰都是按照一百萬的130%來處理.130%是負載均衡或者是一些外界波動導致的,它實際上是不平均的.我們可以說它是一百萬條交易的負荷,但實際上不可能說一百萬零一條這個系統就崩潰了.可以留一下窗口,留一些冗余量來處理一些操作中的未知性,還有一些特殊意外情況,所以130%是一個我們常用的指標.

在Google里面已經很少提災備這件事情,就是對我們來說我們沒有災備容量,都是平均負載均衡的.可能有一些冗余,比如一個系統只能一千臺機器,這一千臺機器并不是說我有十臺是不接受業務處理的,而是我們所有機器都是接受業務處理,只不過他們處理能力可能沒有把所有的資源都用完.這也是Google有很多經驗教訓,如果一個東西老是不用的話,它就是壞的,你平時再怎么演習、怎么用,一到關鍵時刻它就過不去、它就是有問題,所以更多的時候壓根不討論災備的問題,所有東西永遠都是在線的,這也是為什么說想把Google.com給弄壞是一件非常困難的事情,得全球幾百個數據中心同時出問題,才可能會出現不可用的情況.所以Google全球業務是不可能中斷的,不管出現多大的自然災害,它這個業務都是不可能中斷的.可能只有局部地區受損,只有基礎設施受損的地方,它才會有一些問題,所以這就是災備.

實戰演習

另外一個更關鍵的一點是做實戰演習.剛才也提到了,SRE以業務小組為單位,每周都會做實戰演習,整個公司實際上每年也會做一次非常大的實戰演習.我可以舉幾個例子,Google很多地方都有辦公室,有一年某個辦公室食堂的菜有問題,導致所有人都拉肚子進了醫院.這是Google總部啊,一萬人、兩萬人這樣.于是我們就提出這樣一個問題,說如果這個地方沒有人來上班了,網站到底還能不能正常運行啊?我也曾經問過百度、騰訊,他們所有人都在一個大樓里,如果大樓突然斷網了,公司還運轉不運轉?這是一個很大的問題,不管是地質災害問題、自然災害、人文災害,這些雖然聽起來好像比較極端,但確實能考驗出一個組織的業務持續能力.實際上這是Google做得比較好的一點.剛才說的都是比較夸張的例子,是比較大范圍的.一些比較小的例子,比如這個系統就是你這個小組負責,你們這個小組到底有沒有單點故障,這個人是不是能休假,如果一旦出現問題是不是所有人都能去解決這個問題.我們經常互相出題去做這種測試,然后去分享一些知識.我想這更多是一種風氣吧.首先你認同這個目標,目標當然就是把這個系統建設得更可靠.認同了這個目標,接下來就是不停地去考驗還有哪些漏洞,并確保整個團隊其他人也有同樣的知識,同樣的技能去解決這個問題.

其實說到Google在這一點上,也有所謂的運動式演練.每年1、2月份都會組織一次運動式演練,整個公司所有部門都要參與.在這一個星期的時間里實際上公司是不干什么正經事的,所有人都想出各種各樣的方法去測試或者去提高系統的可靠性.

ONCALL的正確姿勢

剛才說的這種比較大的所謂實戰演習,具體到工作的時候也有幾個,就是我們的輪值制度值班.國內小公司都是沒有輪值制度的,所有人手機24小時開機,隨時打電話,隨時得解決問題,一個箭步從被窩里爬出來,趕緊上去解決問題.實際上這跟Google不一樣.Google的值班方式更多的是八個人每人值一個星期,值一個星期,剩下的時間你就自己去寫程序、做工程研發.但是在這一個星期里,你必須能處理生產上發生的一切問題,這才是真正值班.只有你值班,別人休假了,這才是值班,否則就不叫休假,也不叫值班.所以Google有一個非常明確的規定,Google認為一個事故的正確處理或從發生到解決到事后解決需要六個小時,它認為需要六個小時.運維人員每次值班一般都是值十二個小時的班,大概從早上五點到晚上五點或者是從早上十點到晚上十點.因為它所有的值班都是由兩地互相倒的,在美國有一部分,在歐洲有一部分,我們上班的時候我們值班,他們上班的時候他們值班.Google認為其實一天最多只能發生兩次事件.不管什么樣的系統問題,首先要保證一定要有足夠的時間去處理問題.因為如果問題發生太頻繁了,就像有些互聯網公司,每天一上班這手機就開始“嗡嗡”在桌子上不停的響.一旦有一會兒不響了,就開始擔心說這個監控系統到底是是不是壞了.

如果處理太多了,實際上就變成什么呢?兩個比較重要的因素,第一個因素是你沒有辦法好好處理,你處理相當于就是上去敲一個命令,沒有時間去想到底這個東西為什么會出現這個問題,以后怎么避免這個問題.所以這個叫(狼來了)效應,你on call的時候已經沒有時間去思考了.第二個會發生“狼來了”事件.本來可能是兩次完全不一樣的事故,但是你上一次處理的時候,你發現重啟就行了,下一次你就條件反射,出現這個問題的之后你又去重啟了,但它實際上可能是另外一個問題,可能是完全不相關的問題,你重啟可能導致這問題更糟糕.所以如果你總是用這種模式處理問題的話必然會出問題,早晚這個災難會升級.本來是一個很小的問題,結果可能變成一個很大的問題.

運維重要一點是解決線上問題.很多軟件工程師做運維會鉆牛角尖,這個線上系統出問題了,比如商城里不能購買了,這時候如果鉆到這個程序里考慮要這么寫還是那么寫,實際上是不解決線上的問題.作為運維這個職業或者作為運營這個職業來說,它唯一的目標就是要保證系統的正常.有的時候需要用一些比較low的手段或者是方式.比如在項目初期機器有問題,我們就把它們都停了,然后使用一些新的服務器重新搭起來.事實上也不知道這個東西為什么壞了,就把它放在這兒,先去解決生產上的實際問題.實際上我認為這是運維最大的價值.運維部門目標就是保證業務的持續性.

事后總結

接著是做總結,寫一些事后總結.Google的事后總結都是非常專業的,是非常對事不對人的,它會非常詳細地列出來在什么時間出現了什么問題,誰去操作的,他執行了什么操作,這個操作到底是解決問題還是沒有解決問題,如果沒有解決問題的話該怎么去確保不會去執行這個操作.這是一個循環往復的過程,是一個不停錘煉的過程.把解決問題當成一個職業來對待的話,所有事情都很好辦了.這回出現這個問題,解決了一遍,然后發現執行了某些地方可能是系統給出錯誤的信號,可能是文檔有問題,把它都一一解決了.下回再執行的時候,可能換了一撥人來執行這個,也能保證不會出現問題.這就是事后總結帶來的最大利益.

SLO預估

最后說說SLO.SLO是運維部門的一個關鍵工具.服務質量實際上是運維部門唯一負責的事情.公司要求員工達到某某指標,那員工怎么去達到這一點?第一,要先幫助制定SLO,要用事實、數據去說明白達到這個服務質量到底需要多少投入、需要多少流程改進、需要多少系統改進.第二,要確保達到這個服務質量不會影響創新速度.這要有一個平衡的取舍,要用數據去說話,一個每天只能down一分鐘的系統和一個每天可以down四個小時的系統,它所能承受的更新頻率是不一樣的,部署的要求和方式肯定都是不一樣的,所以要圍繞著這個去做,要把這些理念推行到研發部門和產品部門.最后就是把可靠性當成產品的一個重要組成部分,研發也得關心可靠性,他在寫代碼的時候得知道這個東西一定是要可靠的.把可靠性一直推到產品設計或者是業務層次去,它才能貫徹到底層的研發、運維,才能把它做好.

SRE模型成功的標志

最后就是說到底SRE成功還是不成功,實際上就是看這兩條曲線.上面這條線是部署規模,大家都知道互聯網的業務都是爆發式增長,它是指數型的.如果說按照常規的那種招聘曲線,直線性的,那么永遠趕不上這個規模,所以運維事務必須要把它壓下來.Google經常做這種統計,到底我們業務規模擴大之后,擴大了多少工單數量,然后出現了多少事故,造成了多大問題.實際上只有統計這個事情,才能知道你到底做得好不好.當這個系統成熟到一定程度之后,SRE的運維速度是固定的,甚至是越來越少的.只有做到這一點,才相當于把運維這個事情做好,剩下的時間或者剩下的精力才能去接手更多的業務、做更多的技術研發.

我分享的東西也到此結束了,謝謝大家!

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