Google的DevOps理念及實(shí)踐

1、 Google的DevOps理念及實(shí)踐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背后的秘密。本文講述了SRE的基本概念和核心原理。什么是SRE？很多時(shí)候國(guó)內(nèi)把DevOps的范圍定得有點(diǎn)狹窄， DevOps這件事情在國(guó)外更多是整個(gè)行業(yè)內(nèi)的一個(gè)趨勢(shì)。DevOps是一種模式，主要是讓IT相關(guān)的東西與商業(yè)結(jié)合得更緊密一些，迭代速度變得更快一些，所

2、以它適用于各個(gè)行業(yè)。今天說(shuō)的SRE，我認(rèn)為也是在運(yùn)維行業(yè)上的一部分。概括來(lái)說(shuō)，我認(rèn)為SRE：Google運(yùn)維解密這本書(shū)是一個(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ì)。這本書(shū)里共有一百多個(gè)作者聯(lián)合寫(xiě)成，其中也包括我以前所在的團(tuán)隊(duì)，我們做過(guò)的一些Project也在書(shū)中也有提到，所以它是一本文集。我與原著的三個(gè)編輯聊天時(shí)，他們說(shuō)成書(shū)最大的難處就是刪減內(nèi)容，當(dāng)時(shí)征集來(lái)的內(nèi)容大概有一千多頁(yè)，最后刪到了五百多頁(yè)。這也是這本書(shū)比

3、較有意思的一個(gè)花絮?；氐竭@本書(shū)的宗旨， SRE到底是什么？SRE是Google發(fā)明的一個(gè)詞語(yǔ)或者新定義的一個(gè)職業(yè)。以前這個(gè)運(yùn)維角色，大家叫運(yùn)維，美國(guó)叫Operation?，F(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ì)自己開(kāi)發(fā)和創(chuàng)造新的系統(tǒng)，比如拿了My

4、SQL把它跑起來(lái)，或是研發(fā)部門開(kāi)發(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ī)駕駛員就是開(kāi)別人造出來(lái)的飛機(jī)，這和運(yùn)維部門的職責(zé)很像。那么這樣一個(gè)運(yùn)維部門的職責(zé)包括哪些呢？首先最重要的是應(yīng)急事件的處理，這是重中之重，也是最唯一的職責(zé)。其次是常規(guī)更新，現(xiàn)在的業(yè)務(wù)發(fā)展越來(lái)越快，每周都有新的東西上線，比如說(shuō)今天要買新機(jī)器，明天要改IP地址，大家

5、可能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)付各種各樣的事。剛開(kāi)始接手生產(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)十八年

6、了，剛開(kāi)始前幾年公司所有的人平時(shí)寫(xiě)代碼，周末去機(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ò)，特殊硬件、一些第三方服

7、務(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)的，深居簡(jiǎn)出，但是你有什么問(wèn)題，只有他能解決，其實(shí)這在Google這個(gè)語(yǔ)境里這是一個(gè)比較不健康的狀態(tài)。SRE的一大特點(diǎn)就是想請(qǐng)假的時(shí)候隨

8、時(shí)請(qǐng)假，每一個(gè)人都可以請(qǐng)假；當(dāng)出現(xiàn)緊急情況的時(shí)候，當(dāng)天值班的人真的可以處理他負(fù)責(zé)的這個(gè)服務(wù)所有的問(wèn)題。Google SRE的起源與特點(diǎn)回到最開(kāi)始，Google SRE的VP叫Ben Treynor，他是一個(gè)資深的軟件開(kāi)發(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)維

9、團(tuán)隊(duì)。他招了很多他熟悉的研發(fā)工程師，這些研發(fā)工程師從開(kāi)發(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)干，于是就寫(xiě)程序干。多快好省，同時(shí)寫(xiě)程序還有一個(gè)好處，就是可以把一些最佳實(shí)踐、方式、流程、方法都固化成代碼，用這種方式去應(yīng)對(duì)規(guī)模性的擴(kuò)張，去應(yīng)對(duì)復(fù)雜度的上升。這些是SRE跟傳統(tǒng)的運(yùn)維模式最不同的一點(diǎn)，就是招的人研發(fā)為主，做的事也是以研發(fā)

10、為主。這是當(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è)開(kāi)發(fā)流程的界限打通，產(chǎn)品有的時(shí)候也要干一些研發(fā)的事，研發(fā)有時(shí)候把這個(gè)信息要很快的反饋給這個(gè)產(chǎn)品，開(kāi)發(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è)理論

11、來(lái)說(shuō)，SRE就是DevOps的思想在開(kāi)發(fā)和運(yùn)維之間的一個(gè)平衡。SRE的工作職責(zé)這個(gè)圖是我發(fā)明的，書(shū)中沒(méi)有提到。書(shū)里大概有二十多章的內(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)、提高可靠性，

12、這些都是最上層的東西，只有把底下全部做好了才能說(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ó)之后見(jiàn)了不少初創(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ù)中的部署

13、實(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)題，那

14、不應(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é)。之前聽(tīng)過(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ā)生，大家能不能不加班，能不能

15、不熬夜？這樣才對(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。S

16、LO是一個(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)槿绻煌５拈_(kāi)發(fā)出需要人來(lái)操作運(yùn)維

17、的系統(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è)的定義。具體

18、如何做呢？推演和演習(xí)。推演是給你一套系統(tǒng)，你要分析出來(lái)它會(huì)有什么樣的失敗模式。我們當(dāng)時(shí)經(jīng)常在黑板上畫(huà)系統(tǒng)圖，大家一起討論如果這個(gè)組件出問(wèn)題了會(huì)發(fā)生什么情況，用戶到底還能不能看視頻了，用戶購(gòu)買流程還能不能走通。實(shí)際上這些過(guò)程很多時(shí)候軟件開(kāi)發(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)?/p>

19、一個(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ò)，給他

20、扣工資、扣獎(jiǎng)金，讓他三天不吃飯”，但這其實(shí)并不真正解決問(wèn)題。再比如，一個(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í)開(kāi)除也并不能解決系統(tǒng)的設(shè)計(jì)問(wèn)題，下回總會(huì)還有人踢到。說(shuō)一個(gè)故事，故事的內(nèi)容是一個(gè)事故。某個(gè)數(shù)據(jù)中心有一排機(jī)器要斷電，數(shù)據(jù)中心的人發(fā)了一個(gè)工單告訴操作員要把這個(gè)開(kāi)關(guān)給關(guān)了。然后這個(gè)操作員去關(guān)，他關(guān)掉了開(kāi)關(guān)，但是發(fā)現(xiàn)這一排機(jī)器的燈

21、沒(méi)滅，另外一排的燈卻滅了按錯(cuò)開(kāi)關(guān)了。他檢查一下發(fā)現(xiàn)按錯(cuò)了，“啪”把另外一個(gè)開(kāi)關(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ò)，要么是開(kāi)關(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í)候

22、都要考慮到有沒(méi)有被誤用的可能，然后如何避免誤用。專業(yè)化專業(yè)化體現(xiàn)在什么程度呢？要真正的去寫(xiě)代碼，要能給業(yè)務(wù)系統(tǒng)或者給研發(fā)寫(xiě)的東西挑出問(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ā)可以是寫(xiě)工具，可以是參與系統(tǒng)設(shè)計(jì)，參與可靠性的提高，但是要保證運(yùn)維不能只

23、干運(yù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è)

24、爭(zhēng)議我在過(guò)去八年見(jiàn)過(guò)為數(shù)不多的幾次，開(kāi)發(fā)可以一直鬧到 VP，SVP 這個(gè)級(jí)別。每一次都是聽(tīng)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)不夠

25、順暢，導(dǎo)致了這個(gè)東西最終實(shí)際做不好，這是SRE模型相當(dāng)關(guān)鍵的一個(gè)地方。接下來(lái)聊一聊SRE的一些最佳實(shí)踐，我認(rèn)為Google做得比較好的幾點(diǎn)。SRE的最佳實(shí)踐建設(shè)平臺(tái)化服務(wù)體系首先， Google現(xiàn)在是一個(gè)六萬(wàn)人的公司，涉及到的產(chǎn)品線可能一百多個(gè)，各個(gè)部門之間差距很大，而且Google全球幾百個(gè)數(shù)據(jù)中心，有很多機(jī)器，它如何管理？如果按照國(guó)內(nèi)公司的方式去管理早就累死了。因?yàn)閲?guó)內(nèi)很多運(yùn)維部門從上到下什么都管，從買機(jī)器開(kāi)始，一直到最上面安裝服務(wù)器、調(diào)試，配網(wǎng)絡(luò)，所以業(yè)務(wù)線、運(yùn)維部門經(jīng)常好幾千人。Google做得比較好的一點(diǎn)就是它把一個(gè)東西橫向切分，因?yàn)樗茉缰熬鸵庾R(shí)到很多部門或者很多人之間有共性？像

26、現(xiàn)在國(guó)內(nèi)有的公司也開(kā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)常聽(tīng)說(shuō)的Borg系統(tǒng)等，讓一些比較通用的技術(shù)或者通用的架構(gòu)都能形成平臺(tái)式的東西。再往上才是產(chǎn)

27、品線，每一層實(shí)際上都有自己的SRE部門、運(yùn)維部門，都是一個(gè)項(xiàng)目。所以把這個(gè)平臺(tái)搭起來(lái)之后，上層的人可以越來(lái)越少關(guān)心底下的細(xì)節(jié)問(wèn)題，一定程度的減少了他很多精力、減少了很多官僚主義上的問(wèn)題。需要計(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ù)庫(kù)，所有人都可以用，這是Google做得比較好的一點(diǎn)。容量規(guī)劃和容量

28、管理然后大家會(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ái)沒(méi)有說(shuō)過(guò)我們到底要處理多少流量，有些領(lǐng)導(dǎo)說(shuō)我們“雙11”想來(lái)多大量的就來(lái)多大量，這怎么

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

30、經(jīng)很少提災(zāi)備這件事情，就是對(duì)我們來(lái)說(shuō)我們沒(méi)有災(zāi)備容量，都是平均負(fù)載均衡的?？赡苡幸恍┤哂啵热缫粋€(gè)系統(tǒng)只能一千臺(tái)機(jī)器，這一千臺(tái)機(jī)器并不是說(shuō)我有十臺(tái)是不接受業(yè)務(wù)處理的，而是我們所有機(jī)器都是接受業(yè)務(wù)處理，只不過(guò)他們處理能力可能沒(méi)有把所有的資源都用完。這也是Google有很多經(jīng)驗(yàn)教訓(xùn)，如果一個(gè)東西老是不用的話，它就是壞的，你平時(shí)再怎么演習(xí)、怎么用，一到關(guān)鍵時(shí)刻它就過(guò)不去、它就是有問(wèn)題，所以更多的時(shí)候壓根不討論災(zāi)備的問(wèn)題，所有東西永遠(yuǎn)都是在線的，這也是為什么說(shuō)想把G給弄壞是一件非常困難的事情，得全球幾百個(gè)數(shù)據(jù)中心同時(shí)出問(wèn)題，才可能會(huì)出現(xiàn)不可用的情況。所以Google全球業(yè)務(wù)是不可能中斷的，不管出現(xiàn)多大

31、的自然災(zāi)害，它這個(gè)業(yè)務(wù)都是不可能中斷的?？赡苤挥芯植康貐^(qū)受損，只有基礎(chǔ)設(shè)施受損的地方，它才會(huì)有一些問(wèn)題，所以這就是災(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è)辦公室食堂的菜有問(wèn)題，導(dǎo)致所有人都拉肚子進(jìn)了醫(yī)院。這是Google總部啊，一萬(wàn)人、兩萬(wàn)人這樣。于是我們就提出這樣一個(gè)問(wèn)題，說(shuō)如果這個(gè)地方?jīng)]有人來(lái)上班了，網(wǎng)站到底還能不能正常運(yùn)行?。课乙苍?jīng)問(wèn)過(guò)百度、騰訊，他們所有人都在一個(gè)大樓里，如果大樓突然斷網(wǎng)了，公司還運(yùn)轉(zhuǎn)不運(yùn)轉(zhuǎn)？這是一

32、個(gè)很大的問(wèn)題，不管是地質(zhì)災(zāi)害問(wèn)題、自然災(zāi)害、人文災(zāi)害，這些雖然聽(tīng)起來(lái)好像比較極端，但確實(shí)能考驗(yàn)出一個(gè)組織的業(yè)務(wù)持續(xù)能力。實(shí)際上這是Google做得比較好的一點(diǎn)。剛才說(shuō)的都是比較夸張的例子，是比較大范圍的。一些比較小的例子，比如這個(gè)系統(tǒng)就是你這個(gè)小組負(fù)責(zé)，你們這個(gè)小組到底有沒(méi)有單點(diǎn)故障，這個(gè)人是不是能休假，如果一旦出現(xiàn)問(wèn)題是不是所有人都能去解決這個(gè)問(wèn)題。我們經(jīng)?；ハ喑鲱}去做這種測(cè)試，然后去分享一些知識(shí)。我想這更多是一種風(fēng)氣吧。首先你認(rèn)同這個(gè)目標(biāo)，目標(biāo)當(dāng)然就是把這個(gè)系統(tǒng)建設(shè)得更可靠。認(rèn)同了這個(gè)目標(biāo)，接下來(lái)就是不停地去考驗(yàn)還有哪些漏洞，并確保整個(gè)團(tuán)隊(duì)其他人也有同樣的知識(shí)，同樣的技能去解決這個(gè)問(wèn)題。其

33、實(shí)說(shuō)到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ì)剛才說(shuō)的這種比較大的所謂實(shí)戰(zhàn)演習(xí)，具體到工作的時(shí)候也有幾個(gè)，就是我們的輪值制度值班。國(guó)內(nèi)小公司都是沒(méi)有輪值制度的，所有人手機(jī)24小時(shí)開(kāi)機(jī)，隨時(shí)打電話，隨時(shí)得解決問(wèn)題，一個(gè)箭步從被窩里爬出來(lái)，趕緊上去解決問(wèn)題。實(shí)際上這跟Google不一樣。Google的值班方式更多的是八個(gè)人每人值一個(gè)星期，值一個(gè)星期，剩下的時(shí)間你就自己去寫(xiě)程序、做工程研發(fā)。但是在這一個(gè)星

34、期里，你必須能處理生產(chǎn)上發(fā)生的一切問(wèn)題，這才是真正值班。只有你值班，別人休假了，這才是值班，否則就不叫休假，也不叫值班。所以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)樗械闹蛋喽际怯蓛傻鼗ハ嗟沟?，在美?guó)有一部分，在歐洲有一部分，我們上班的時(shí)候我們值班，他們上班的時(shí)候他們值班。Google認(rèn)為其實(shí)一天最多只能發(fā)生兩次事件。不管什么樣的系統(tǒng)問(wèn)題，首先要保證一定要有足夠的時(shí)間去處理問(wèn)題。因?yàn)槿绻麊?wèn)題發(fā)生太頻繁了，就像有

35、些互聯(lián)網(wǎng)公司，每天一上班這手機(jī)就開(kāi)始“嗡嗡”在桌子上不停的響。一旦有一會(huì)兒不響了，就開(kāi)始擔(dān)心說(shuō)這個(gè)監(jiān)控系統(tǒng)到底是是不是壞了。如果處理太多了，實(shí)際上就變成什么呢？?jī)蓚€(gè)比較重要的因素，第一個(gè)因素是你沒(méi)有辦法好好處理，你處理相當(dāng)于就是上去敲一個(gè)命令，沒(méi)有時(shí)間去想到底這個(gè)東西為什么會(huì)出現(xiàn)這個(gè)問(wèn)題，以后怎么避免這個(gè)問(wèn)題。所以這個(gè)叫（狼來(lái)了）效應(yīng)，你on call的時(shí)候已經(jīng)沒(méi)有時(shí)間去思考了。第二個(gè)會(huì)發(fā)生“狼來(lái)了”事件。本來(lái)可能是兩次完全不一樣的事故，但是你上一次處理的時(shí)候，你發(fā)現(xiàn)重啟就行了，下一次你就條件反射，出現(xiàn)這個(gè)問(wèn)題的之后你又去重啟了，但它實(shí)際上可能是另外一個(gè)問(wèn)題，可能是完全不相關(guān)的問(wèn)題，你重啟可能導(dǎo)致這問(wèn)題更糟糕。所以如果你總是用這種模式處理問(wèn)題的話必然會(huì)出問(wèn)題，早晚這個(gè)災(zāi)難會(huì)升級(jí)。本來(lái)是一個(gè)很小的問(wèn)題，結(jié)果可能變成一個(gè)很大的問(wèn)題。運(yùn)維重要一點(diǎn)是解決線上問(wèn)題。很多軟件工程師做運(yùn)維會(huì)鉆牛角尖