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

SRE(Site Reliability Engineering)是最早由Google提出,又經(jīng)由Google發(fā)展完善的一個嶄新運維理念.如今SRE已成為一個涵蓋運維理念、思路、組織架構(gòu)和具體實踐的完整體系.數(shù)人云推出SRE系列教程,由SRE經(jīng)驗豐富的技術(shù)大牛們?yōu)榇蠹曳窒磉\維一線的獨家干貨,揭示SRE背后的秘密.

今天為系列教程第一期,我們邀請了前Google SRE、《SRE Google運維解密》的譯者孫宇聰與大家進行了線上分享.本文為上篇,講述了SRE的基本概念和核心原理.與孫老師本人一樣風趣幽默的文章,小數(shù)希望大家閱讀愉快：)

今天與大家分享的內(nèi)容是關(guān)于最近我翻譯的這本書,據(jù)說反響還不錯,今天借這個機會聊一聊書中的內(nèi)容,并與大家分享一下我回國兩年多以來,Google經(jīng)驗在國內(nèi)的一些思考和落地實踐.

什么是SRE?

很多時候國內(nèi)把DevOps的范圍定得有點狹窄, DevOps這件事情在國外更多是整個行業(yè)內(nèi)的一個趨勢.DevOps是一種模式,主要是讓IT相關(guān)的東西與商業(yè)結(jié)合得更緊密一些,迭代速度變得更快一些,所以它適用于各個行業(yè).今天說的SRE,我認為也是在運維行業(yè)上的一部分.

概括來說,我認為《SRE Google運維解密》這本書是一個文集.GoogleSRE全球一千多人,這個組織在公司里相對比較小眾,但又是一個比較重要的部門,整個Google所有業(yè)務線的運維環(huán)境都由SRE來負責.SRE是一個非常分散的組織,每個業(yè)務線、每個部門其實都有自己的SRE小團隊.這本書里共有一百多個作者聯(lián)合寫成,其中也包括我以前所在的團隊,我們做過的一些Project也在書中也有提到,所以它是一本文集.我與原著的三個編輯聊天時,他們說成書最大的難處就是刪減內(nèi)容,當時征集來的內(nèi)容大概有一千多頁,最后刪到了五百多頁.這也是這本書比較有意思的一個花絮.

回到這本書的宗旨, SRE到底是什么?SRE是Google發(fā)明的一個詞語或者新定義的一個職業(yè).以前這個運維角色,大家叫運維,美國叫Operation.現(xiàn)在Google把這個職位擴展為SRE,就是用軟件工程師的方法和手段,招了一些軟件工程師來解決運維的難題,這是SRE的官方定義.

傳統(tǒng)運維模式的弱點

現(xiàn)在傳統(tǒng)的計算機行業(yè)的運維方式,大部分都是采用系統(tǒng)管理員的模式.大家最熟悉的運維方式是這樣：招聘一些系統(tǒng)管理員,他們有負責采購機器的,有負責維護數(shù)據(jù)中心的,也有專門維護數(shù)據(jù)庫的等等.系統(tǒng)管理員模式有幾個特點,他們只是把一些現(xiàn)成的組件組裝起來,并不會自己開發(fā)和創(chuàng)造新的系統(tǒng),比如拿了MySQL把它跑起來,或是研發(fā)部門開發(fā)出來的新代碼組裝成之后提供這樣一個服務.這是運維部門的一個特色,負責把這個東西運行好.

舉一個例子,在美國的時候我們經(jīng)常自嘲,說自己是流水線上的工人.因為這個流水線實際上是別人設計出來的,總得有人去操作這個機器,而我們就是一線的操作流水線的工人.又比如,我們好像是發(fā)電站里的工作人員,又或者是飛機駕駛員.飛機駕駛員就是開別人造出來的飛機,這和運維部門的職責很像.

那么這樣一個運維部門的職責包括哪些呢?首先最重要的是應急事件的處理,這是重中之重,也是最唯一的職責.其次是常規(guī)更新,現(xiàn)在的業(yè)務發(fā)展越來越快,每周都有新的東西上線,比如說今天要買新機器,明天要改IP地址,大家可能80%的投入都是在這些事上,這就是系統(tǒng)管理員或者是現(xiàn)在運維行業(yè)的工作模式.

但是系統(tǒng)管理員模式有一個最大的弊端,按照傳統(tǒng)的組織架構(gòu)模式或者是這種運維模式運行會導致這個團隊持續(xù)擴張,業(yè)務越來越多,需要不停的招人去應付各種各樣的事.剛開始接手生產(chǎn)的時候,也許一周就出一次事或者是需要更新一次.因為人的溝通能力總是有限的,招了五個人之后,這五個人之間的傳達問題就形成了一個困難.當你把一個精神傳達給這五個人,他們事后執(zhí)行出來的結(jié)果都不一樣,這就是傳統(tǒng)模型一直想要解決的問題.但是這種模型也有好處,就是市場招聘比較容易.

Google有幾個比較重要的特點,首先它的部署規(guī)模非常大.Google到今天已經(jīng)十八年了,剛開始前幾年公司所有的人平時寫代碼,周末去機房接機器.因為它擴展速度特別快,部署規(guī)模非常大.如果按照傳統(tǒng)的系統(tǒng)管理員的那種模式操作,這個機柜歸你,這個機柜歸他,再下一個歸另外一個人,那么Google招人的速度一定趕不上機器增加的速度,所以Google是被逼迫創(chuàng)造了這樣的職位,因為沒有辦法安排團隊做如此大規(guī)模的運維.

傳統(tǒng)的運維模式還有一個更大的問題,它過于強調(diào)專業(yè)化.比如一個人是做網(wǎng)絡的,他只做網(wǎng)絡其他都不管,全公司可能只有他懂網(wǎng)絡,因為他不停的在網(wǎng)絡上投入時間,集中力氣把這個事情做好.這樣一個結(jié)果就是會發(fā)現(xiàn)運維部門沒人能休假,一出事只有一個人能解決問題.不僅僅是網(wǎng)絡,特殊硬件、一些第三方服務都存在這個問題.這就導致了知識沒法共享,人靈活性受到限制,整個組織的靈活性也受限制.這個問題,我認為它最終形成了一個負反饋的循環(huán),每個人之間越是互相隔離,越是沒有辦法提高,導致服務質(zhì)量上不去.最大的問題是,招來更多的人其實也不解決問題,因為這個部署規(guī)模不斷擴大,人之間的知識不能共享,所以招來的人只能運維新的設備,舊的設備還是這些人在做.

這是一個怪圈.回國之后我與很多公司的朋友都聊過這個問題.以前大家講Oracle這樣的公司存在老DBA,說老DBA都是難得一見的,深居簡出,但是你有什么問題,只有他能解決,其實這在Google這個語境里這是一個比較不健康的狀態(tài).SRE的一大特點就是想請假的時候隨時請假,每一個人都可以請假；當出現(xiàn)緊急情況的時候,當天值班的人真的可以處理他負責的這個服務所有的問題.

Google SRE的起源與特點

回到最開始,Google SRE的VP叫Ben Treynor,他是一個資深的軟件開發(fā)經(jīng)理.2003年他加入公司第一個任務,是組建一個7人的“生產(chǎn)運維小組”.很快他發(fā)現(xiàn)如果想把這件事情做好,也就是把搜索服務運維好的話,按照Google機器增加的速度,傳統(tǒng)的模式絕對是不可能的.機器增加的速度,系統(tǒng)復雜度增加的速度遠比人增加的速度要多得多.所以他組建的團隊有以下三個特點,注意,這里我認為其實更多的是事后的總結(jié).首先,他的執(zhí)行方式是像組建一個研發(fā)團隊一樣來組建這個運維團隊.他招了很多他熟悉的研發(fā)工程師,這些研發(fā)工程師從開發(fā)能力上沒有任何問題,用現(xiàn)在流行的話就是全棧工程師,什么都會做.第二點,這些人對系統(tǒng)管理比較有熱情,懂一些Linux內(nèi)核知識、網(wǎng)絡層的知識.第三點,最關(guān)鍵的是這些人鄙視重復性勞動,碼農(nóng)最痛恨的是什么事,就是反復做同一件事.他把這些人聚到一塊,然后讓他們執(zhí)行以前傳統(tǒng)公司運維人員來做的事情,很自然這些人不愿意手動干,于是就寫程序干.多快好省,同時寫程序還有一個好處,就是可以把一些最佳實踐、方式、流程、方法都固化成代碼,用這種方式去應對規(guī)模性的擴張,去應對復雜度的上升.

這些是SRE跟傳統(tǒng)的運維模式最不同的一點,就是招的人研發(fā)為主,做的事也是以研發(fā)為主.這是當時SRE成立背后的故事,這些年來我認為他們做得最好的一點是一直在維持了一種平衡.將運維部門從傳統(tǒng)執(zhí)行部門往上提升,打破了傳統(tǒng)的界限.就像剛才說的DevOps,很多人理解為就是讓研發(fā)部門做運維的事,或者運維部門做研發(fā)的事情,但實際上DevOps在國外的定義更寬泛一點.DevOps的思想更多的是說把整個開發(fā)流程的界限打通,產(chǎn)品有的時候也要干一些研發(fā)的事,研發(fā)有時候把這個信息要很快的反饋給這個產(chǎn)品,開發(fā)和運維或者QA和運維之間的界限也打通.所以現(xiàn)在去搜DevOps的圖片,會發(fā)現(xiàn)IBM這些人都在講圈圈,說以前是產(chǎn)品研發(fā)都是一條線直著來,而現(xiàn)在都是轉(zhuǎn)圈的,這就是DevOps理論.

按照這個理論來說,SRE就是DevOps的思想在開發(fā)和運維之間的一個平衡.

SRE的工作職責

這個圖是我發(fā)明的,書中沒有提到.書里大概有二十多章的內(nèi)容是在講SRE的各種日常工作,簡單提了一下它的金字塔模型,于是我歸納總結(jié)了一下.這里是由下至上,下面的事份額比較大一點,上面的事份額比較小一點,分了三類.第一類,運維部門最重要的是應急響應這個問題,因為業(yè)務越來越大,與運營的結(jié)合越來越緊密,很多時候要處理的事情更多的是商業(yè)和運營上的事,也包括軟件上的問題,這個部門最特殊或者最唯一的職責就是應急響應.之上是日常運維,保證機器能夠正常更新、快速迭代.再往上是輸出一些工程研發(fā),無論是做工具,還是做高可用架構(gòu)、提高可靠性,這些都是最上層的東西,只有把底下全部做好了才能說到上面.

應急響應

應急響應是運維部門在公司最獨特的一點,表現(xiàn)為當公司出現(xiàn)問題時,應該找誰或者流程應該是怎樣的.我回國之后見了不少初創(chuàng)企業(yè),他們網(wǎng)站出問題了,往往是CEO先發(fā)現(xiàn),CEO打電話“哎,這個到底是怎么回事啊”,然后每一個人都說“不知道啊,不是我負責呀,我得找誰誰”.不管多大一件事都得傳遍整個公司,整個效率非常混亂.

我在Google待了八年時間,這樣的流程也經(jīng)歷過,但是最近這幾年Google非常重視這一點,建立了一整套應急事件處理方式.首先要有全面監(jiān)控,監(jiān)控這件事情是持久不斷的,重中之重.SRE所有人都要非常了解整個監(jiān)控系統(tǒng)在所有業(yè)務中的部署實施,其實這是我們平時花精力最多的地方.監(jiān)控系統(tǒng)里面對整個系統(tǒng)所有方面都有監(jiān)控,不光包括業(yè)務指標,也包括性能指標、效率指標.監(jiān)控應該平臺化、系統(tǒng)化,不停的往上積累,多做一些模板,同質(zhì)化的系統(tǒng)就可以用同樣的方法去做監(jiān)控.

第二點是應急事務處理,應急事務處理分兩部分,第一部分是演習,另外一部分是真正的處理流程.如何把它做好?實際上就是要不停的去演習、去做這個事情.像剛才舉的例子,網(wǎng)站掛了,首先不應該CEO先發(fā)現(xiàn),而應該是監(jiān)控系統(tǒng)或者報警系統(tǒng)先告警,在發(fā)現(xiàn)之前就很應該明確這個東西應該誰排查,誰處理,這個信息應該早就發(fā)給合適的人去處理,甚至他應該早就在做了.如果發(fā)生特別大的,需要跨部門之間協(xié)作的問題,那不應該只是領導現(xiàn)場調(diào)配,而是整個組織每個人都明白這個流程應該是怎么樣的,直接就做.Google甚至可以做到在一次事故中間兩地交班,某個團隊處理一半,然后我交接給另外一邊團隊,就下班回家了,持續(xù)不停的有人繼續(xù)跟蹤處理這件事情,而不會出現(xiàn)問題.這樣一個模式是我覺得非常值得我們思考的.

處理完問題之后,要總結(jié).之前聽過的一個故事是,某公司業(yè)務出現(xiàn)了一個事故,大家加班加點,十幾個小時沒睡覺把這事搞定,然后領導過來就說了一句“大家辛苦了,回家睡覺吧”.但是,其實在這個時候我要說,領導光說這個其實恰恰是不夠的.領導在這里應該問：為什么加班啊?這個事情為什么會發(fā)生啊,下次能不能不發(fā)生,大家能不能不加班,能不能不熬夜?這樣才對, 能做到事后總結(jié)這個事情很難,但只有把這個做好了,才能降低以后問題發(fā)生的幾率.

日常運維

日常運維做得最多的可能是變更管理.業(yè)務現(xiàn)在發(fā)展非常快,迭代速度、迭代周期非常快.其實這件事情能做好,能夠做到無縫、安全、不停的變更管理,是運維部門能給公司做的最大貢獻.

第二個,容量規(guī)劃,當規(guī)模大到一定程度的時候,就需要有人來回答這個問題——到底要買多少新機器,能否保證明年的性能、效率,那誰來負責這件事呢?SRE部門提出這些方案,然后要確保這些指標、這些東西是有數(shù)據(jù)支撐的,確實能解決問題的.

工程研發(fā)

工程研發(fā)雖然做得少,但是工作很關(guān)鍵.SRE在工程研發(fā)上主要的工作,首先是幫產(chǎn)品部門確定一個SLO.SLO是一個服務指標,每一個產(chǎn)品都有一個服務指標.任何系統(tǒng)都不可能是百分之百可靠的,也沒有必要做到百分之百可靠.這里得有一個目標,比如說可以每個月中斷幾分鐘.這件事情是要產(chǎn)品部門考慮清楚的.比如我之前在YouTube做視頻存儲、視頻點播的時候,要考慮每個視頻到底是存一份還是存兩份的問題,將這種問題放到一個非常大的部署規(guī)模里面的時候,只有產(chǎn)品部門能夠拍板.說到底是要不要花這個預算,要不要花這么多錢去提高0.1%的可靠性或者0.01%的可靠性.

另外一點是無人化運維.大家都看過《黑客帝國》吧?一醒來發(fā)現(xiàn)大家都是電池,都是為機器服務的.其實把這個比喻放在運維部門非常合適.因為如果不停的開發(fā)出需要人來操作運維的系統(tǒng),結(jié)果大家最后都是電池,明顯是不可持續(xù)的.如果不停的產(chǎn)生這種需要人來操作的東西,不停的招人,最后就變成不停的運維這個東西.把整個流程自動化,建立一個能夠應對復雜業(yè)務的平臺,這就是工程研發(fā)上最需要的東西.

SRE模型成功的關(guān)鍵要素

SRE在Google有十幾年的歷史了.這個模型是如何成功的?我總結(jié)如下幾點：

職業(yè)化

運維行業(yè)從來都說不清楚自己是干嘛的,這是不對的.很多人認為會操作Linux,或者是DBA、會配網(wǎng)絡,就算運維了.實際上運維的范圍要比這個大得多.運維應該是負責公司業(yè)務正常運轉(zhuǎn)的角色,這才是真正的運維.在出問題的時候能解決問題,保障業(yè)務連續(xù)性,甚至避免問題發(fā)生,這才是運維職業(yè)的定義.

具體如何做呢?推演和演習.

推演是給你一套系統(tǒng),你要分析出來它會有什么樣的失敗模式.我們當時經(jīng)常在黑板上畫系統(tǒng)圖,大家一起討論如果這個組件出問題了會發(fā)生什么情況,用戶到底還能不能看視頻了,用戶購買流程還能不能走通.實際上這些過程很多時候軟件開發(fā)是不考慮的,但是如何拆分、如何去保證每個環(huán)節(jié)的可靠,這才反是運維這個行業(yè)最關(guān)鍵的一點,所以一定要做這種推演.只有這種推演才能輸出改變,讓系統(tǒng)更可靠.

第二點是演習.我們當時每周都會進行一次小型災難演習,例如把以前出現(xiàn)的問題拿出來一個,讓新加入團隊的人去演習,所有其他的人也都要去參加.這里主要是觀察新人到底是怎么思考這個系統(tǒng)的,新人做出的決定到底是不是正確的.因為一個人做出的決定是不是正確的實際上取決于系統(tǒng)給的反饋到底是不是對的.Google認為運維復雜系統(tǒng)不是一個靠智商和記憶力就能解決的問題,不能依賴人一定要知道這段話或這個知識點,而是要知道一種方法,知道如何去排除問題或排查問題.運維系統(tǒng)應該提供足夠的信息,讓輪值的人能夠用正確的方法去處理問題.這很像是背英語辭典和會用英語聊天的區(qū)別,你再怎么背辭典關(guān)鍵時刻也是要查辭典的,但是真正能運用這些信息解決問題,是比較難的.

此外,要區(qū)分責任和指責.責任和指責是兩個事情,但是很多公司的運維經(jīng)常分不清楚.什么叫責任,就是這個事到底誰負責.但是指責是另外一回事.例如一個員工敲錯了一個命令,大家說 “都是因為他的錯,給他扣工資、扣獎金,讓他三天不吃飯”,但這其實并不真正解決問題.再例如,比如說一個系統(tǒng)設計電源插座,沒有仔細考慮,很容易被人踢到,結(jié)果有人真踢到了,整個機房斷電了出了很大的事故.那么從Google的理念來說這里不是人的問題,而是系統(tǒng)設計的問題.這里是不是應該有兩套電源,是不是應該有保護?只有從系統(tǒng)設計問題的角度出發(fā)才能真正解決問題,而指責這個踢到插座的人,讓他一個月不上班,甚至當時開除也并不能解決系統(tǒng)的設計問題,下回總會還有人踢到.

?說一個故事,故事的內(nèi)容是一個事故.某個數(shù)據(jù)中心有一排機器要斷電,數(shù)據(jù)中心的人發(fā)了一個工單告訴操作員要把這個開關(guān)給關(guān)了.然后這個操作員去關(guān),他關(guān)掉了開關(guān),但是發(fā)現(xiàn)這一排機器的燈沒滅,另外一排的燈卻滅了——按錯開關(guān)了.他檢查一下發(fā)現(xiàn)按錯了,“啪”把另外一個開關(guān)也關(guān)了,然后再把這一排機器給啟動,結(jié)果由于啟動時候過載導致整個數(shù)據(jù)中心都斷電了,擴大了問題.如果單純只是指責,這個人肯定完了,起碼獎金沒有了,能不能保證工作都不知道.但是Google 更關(guān)注的是這個東西為什么會容易出錯,要么是開關(guān)顏色不對,要么是相同機器的操作方式靠得太近了,會讓人產(chǎn)生這種錯誤的判斷.所以你看Google的機房里都是五顏六色的,因為這樣確實有用,比如熱水管是紅色的,制冷管是藍色的,所以查起來很容易,區(qū)分起來很容易,盡量減少了這個問題.這個設計的思想在SRE日常工作里貫徹得非常深,每人在流程或工作的時候都要考慮到有沒有被誤用的可能,然后如何避免誤用.

專業(yè)化

專業(yè)化體現(xiàn)在什么程度呢?要真正的去寫代碼,要能給業(yè)務系統(tǒng)或者給研發(fā)寫的東西挑出問題,提高可靠性.

第一,減少瑣事.運維中有很多虛假的工作.每天很忙,然而又不解決問題,做了很多假的工作.大家看起來好像很忙,一個屏幕上十幾個窗口,各種刷屏,但完全不解決問題.更好的方式是用自動化、系統(tǒng)化、工具化的方式去消除這種瑣事的存在.如果永遠靠人工,那永遠都閑不下來.

第二,回到SRE,SRE制度里有一條紅線,運維的人只能把一半的時間花在運維上,另外一半的時間必須搞工程上、研發(fā)上的東西.研發(fā)可以是寫工具,可以是參與系統(tǒng)設計,參與可靠性的提高,但是要保證運維不能只干運維.

第三點,我認為也是比較缺少的,運維部門光有責任沒有決策權(quán),所以大家都說一出事故,運維就背黑鍋.怎么不背黑鍋呢?說改這兒、改那兒,然后發(fā)現(xiàn)沒有人批準改動,這是最大的問題.SRE做的最好的一點是管理層對SRE的工作方式非常認可、非常支持,他們認為服務質(zhì)量是服務的一個重要指標.一旦上升到這個高度,SRE部門提出一些要求就比較容易理解,得到支持,因為他們是有事實根據(jù)的.當GoogleSRE發(fā)現(xiàn)生產(chǎn)出現(xiàn)問題的時候,標準的解決辦法就是暫停所有更新,確保業(yè)務穩(wěn)定.舉個比較極端的例子,像剛才說的如果發(fā)現(xiàn)線上系統(tǒng)有問題的情況下,SRE是有權(quán)利拒絕接受業(yè)務更新的,只允許研發(fā)部門修bug,不允許加新功能.這個爭議我在過去八年見過為數(shù)不多的幾次,開發(fā)可以一直鬧到 VP,SVP 這個級別.每一次都是聽SRE的.

打通與產(chǎn)品團隊的反饋回路

所有東西不都是百分之百穩(wěn)定的,穩(wěn)定性的提高要消耗成本,要增加更多的冗余,更多的容量,甚至只能花錢解決.運維部門的任務就是提供這些數(shù)據(jù)和方案.比如搞三個9、四個9,要如何達到,這在投入和系統(tǒng)設計上有很大區(qū)別.這個部分公司里沒有其他人可以提出,必須要由運維部門提出.如果沒有這個反饋回路的話,你會發(fā)現(xiàn)大家都很痛苦,很多時候做出的決定都是違背自然規(guī)律的.我看過很多這樣的案例,上面拍腦門決定某個業(yè)務要100%穩(wěn)定,完全不管下面怎么搞,由于反饋回路不存在或者這個反饋回路的信息流動不夠順暢,導致了這個東西最終實際做不好,這是SRE模型相當關(guān)鍵的一個地方.

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