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

接下來聊一聊SRE的一些最佳實(shí)踐,我認(rèn)為Google做得比較好的幾點(diǎn).

SRE的最佳實(shí)踐

建設(shè)平臺(tái)化服務(wù)體系

首先, Google現(xiàn)在是一個(gè)六萬人的公司,涉及到的產(chǎn)品線可能一百多個(gè),各個(gè)部門之間差距很大,而且Google全球幾百個(gè)數(shù)據(jù)中心,有很多機(jī)器,它如何管理?如果按照國內(nèi)公司的方式去管理早就累死了.因?yàn)閲鴥?nèi)很多運(yùn)維部門從上到下什么都管,從買機(jī)器開始,一直到最上面安裝服務(wù)器、調(diào)試,配網(wǎng)絡(luò),所以業(yè)務(wù)線、運(yùn)維部門經(jīng)常好幾千人.Google做得比較好的一點(diǎn)就是它把一個(gè)東西橫向切分,因?yàn)樗茉缰熬鸵庾R(shí)到很多部門或者很多人之間有共性?像現(xiàn)在國內(nèi)有的公司也開始講的,運(yùn)維部門要輸出能力,公司內(nèi)部也要服務(wù)化,因?yàn)橹挥蟹?wù)化才能讓每個(gè)團(tuán)隊(duì)更加專業(yè)化.

所以回到Google這個(gè)平臺(tái)上,我認(rèn)為它實(shí)際上是不停的在切分,就是橫向切分.首先最底下是所謂的資源供給層,就是相當(dāng)于把數(shù)據(jù)中心這件事情真的當(dāng)成了一個(gè)資源,可以服于用戶.就是用戶需要什么樣的機(jī)器,配置架構(gòu)怎么樣,怎么設(shè)計(jì)數(shù)據(jù)中心,這些東西它都幫用戶做好.有一個(gè)專門的團(tuán)隊(duì)去做這件事情,這個(gè)團(tuán)隊(duì)也有自己的研發(fā),也有自己的運(yùn)維,也有自己的operation、PM,什么都有.

往上是技術(shù)架構(gòu),技術(shù)架構(gòu)是大家經(jīng)常聽說的Borg系統(tǒng)等,讓一些比較通用的技術(shù)或者通用的架構(gòu)都能形成平臺(tái)式的東西.

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

容量規(guī)劃和容量管理

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

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

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

實(shí)戰(zhàn)演習(xí)

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

其實(shí)說到Google在這一點(diǎn)上,也有所謂的運(yùn)動(dòng)式演練.每年1、2月份都會(huì)組織一次運(yùn)動(dòng)式演練,整個(gè)公司所有部門都要參與.在這一個(gè)星期的時(shí)間里實(shí)際上公司是不干什么正經(jīng)事的,所有人都想出各種各樣的方法去測(cè)試或者去提高系統(tǒng)的可靠性.

ONCALL的正確姿勢(shì)

剛才說的這種比較大的所謂實(shí)戰(zhàn)演習(xí),具體到工作的時(shí)候也有幾個(gè),就是我們的輪值制度值班.國內(nèi)小公司都是沒有輪值制度的,所有人手機(jī)24小時(shí)開機(jī),隨時(shí)打電話,隨時(shí)得解決問題,一個(gè)箭步從被窩里爬出來,趕緊上去解決問題.實(shí)際上這跟Google不一樣.Google的值班方式更多的是八個(gè)人每人值一個(gè)星期,值一個(gè)星期,剩下的時(shí)間你就自己去寫程序、做工程研發(fā).但是在這一個(gè)星期里,你必須能處理生產(chǎn)上發(fā)生的一切問題,這才是真正值班.只有你值班,別人休假了,這才是值班,否則就不叫休假,也不叫值班.所以Google有一個(gè)非常明確的規(guī)定,Google認(rèn)為一個(gè)事故的正確處理或從發(fā)生到解決到事后解決需要六個(gè)小時(shí),它認(rèn)為需要六個(gè)小時(shí).運(yùn)維人員每次值班一般都是值十二個(gè)小時(shí)的班,大概從早上五點(diǎn)到晚上五點(diǎn)或者是從早上十點(diǎn)到晚上十點(diǎn).因?yàn)樗械闹蛋喽际怯蓛傻鼗ハ嗟沟?在美國有一部分,在歐洲有一部分,我們上班的時(shí)候我們值班,他們上班的時(shí)候他們值班.Google認(rèn)為其實(shí)一天最多只能發(fā)生兩次事件.不管什么樣的系統(tǒng)問題,首先要保證一定要有足夠的時(shí)間去處理問題.因?yàn)槿绻麊栴}發(fā)生太頻繁了,就像有些互聯(lián)網(wǎng)公司,每天一上班這手機(jī)就開始“嗡嗡”在桌子上不停的響.一旦有一會(huì)兒不響了,就開始擔(dān)心說這個(gè)監(jiān)控系統(tǒng)到底是是不是壞了.

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

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

事后總結(jié)

接著是做總結(jié),寫一些事后總結(jié).Google的事后總結(jié)都是非常專業(yè)的,是非常對(duì)事不對(duì)人的,它會(huì)非常詳細(xì)地列出來在什么時(shí)間出現(xiàn)了什么問題,誰去操作的,他執(zhí)行了什么操作,這個(gè)操作到底是解決問題還是沒有解決問題,如果沒有解決問題的話該怎么去確保不會(huì)去執(zhí)行這個(gè)操作.這是一個(gè)循環(huán)往復(fù)的過程,是一個(gè)不停錘煉的過程.把解決問題當(dāng)成一個(gè)職業(yè)來對(duì)待的話,所有事情都很好辦了.這回出現(xiàn)這個(gè)問題,解決了一遍,然后發(fā)現(xiàn)執(zhí)行了某些地方可能是系統(tǒng)給出錯(cuò)誤的信號(hào),可能是文檔有問題,把它都一一解決了.下回再執(zhí)行的時(shí)候,可能換了一撥人來執(zhí)行這個(gè),也能保證不會(huì)出現(xiàn)問題.這就是事后總結(jié)帶來的最大利益.

SLO預(yù)估

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

SRE模型成功的標(biāo)志

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

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

轉(zhuǎn)載請(qǐng)注明本頁網(wǎng)址：
http://www.snjht.com/jiaocheng/4316.html