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

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

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

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

什么是SRE?

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

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

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

傳統(tǒng)運(yùn)維模式的弱點(diǎn)

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

舉一個(gè)例子,在美國(guó)的時(shí)候我們經(jīng)常自嘲,說(shuō)自己是流水線上的工人.因?yàn)檫@個(gè)流水線實(shí)際上是別人設(shè)計(jì)出來(lái)的,總得有人去操作這個(gè)機(jī)器,而我們就是一線的操作流水線的工人.又比如,我們好像是發(fā)電站里的工作人員,又或者是飛機(jī)駕駛員.飛機(jī)駕駛員就是開別人造出來(lái)的飛機(jī),這和運(yùn)維部門的職責(zé)很像.

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

但是系統(tǒng)管理員模式有一個(gè)最大的弊端,按照傳統(tǒng)的組織架構(gòu)模式或者是這種運(yùn)維模式運(yùn)行會(huì)導(dǎo)致這個(gè)團(tuán)隊(duì)持續(xù)擴(kuò)張,業(yè)務(wù)越來(lái)越多,需要不停的招人去應(yīng)付各種各樣的事.剛開始接手生產(chǎn)的時(shí)候,也許一周就出一次事或者是需要更新一次.因?yàn)槿说臏贤芰偸怯邢薜?招了五個(gè)人之后,這五個(gè)人之間的傳達(dá)問(wèn)題就形成了一個(gè)困難.當(dāng)你把一個(gè)精神傳達(dá)給這五個(gè)人,他們事后執(zhí)行出來(lái)的結(jié)果都不一樣,這就是傳統(tǒng)模型一直想要解決的問(wèn)題.但是這種模型也有好處,就是市場(chǎng)招聘比較容易.

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

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

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

Google SRE的起源與特點(diǎn)

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

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

按照這個(gè)理論來(lái)說(shuō),SRE就是DevOps的思想在開發(fā)和運(yùn)維之間的一個(gè)平衡.

SRE的工作職責(zé)

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

應(yīng)急響應(yīng)

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

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

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

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

日常運(yùn)維

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

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

工程研發(fā)

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

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

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

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

職業(yè)化

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

具體如何做呢?推演和演習(xí).

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

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

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

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

專業(yè)化

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

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

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

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

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

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

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