Google的DevOps理念及實踐

1、 Google的DevOps理念及實踐SRE（Site Reliability Engineering）是最早由Google提出，又經(jīng)由Google發(fā)展完善的一個嶄新運維理念。如今SRE已成為一個涵蓋運維理念、思路、組織架構和具體實踐的完整體系。數(shù)人云推出SRE系列教程，由SRE經(jīng)驗豐富的技術大牛們?yōu)榇蠹曳窒磉\維一線的獨家干貨，揭示SRE背后的秘密。本文講述了SRE的基本概念和核心原理。什么是SRE？很多時候國內(nèi)把DevOps的范圍定得有點狹窄， DevOps這件事情在國外更多是整個行業(yè)內(nèi)的一個趨勢。DevOps是一種模式，主要是讓IT相關的東西與商業(yè)結合得更緊密一些，迭代速度變得更快一些，所

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

3、較有意思的一個花絮?；氐竭@本書的宗旨， SRE到底是什么？SRE是Google發(fā)明的一個詞語或者新定義的一個職業(yè)。以前這個運維角色，大家叫運維，美國叫Operation?，F(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)，比如拿了My

4、SQL把它跑起來，或是研發(fā)部門開發(fā)出來的新代碼組裝成之后提供這樣一個服務。這是運維部門的一個特色，負責把這個東西運行好。舉一個例子，在美國的時候我們經(jīng)常自嘲，說自己是流水線上的工人。因為這個流水線實際上是別人設計出來的，總得有人去操作這個機器，而我們就是一線的操作流水線的工人。又比如，我們好像是發(fā)電站里的工作人員，又或者是飛機駕駛員。飛機駕駛員就是開別人造出來的飛機，這和運維部門的職責很像。那么這樣一個運維部門的職責包括哪些呢？首先最重要的是應急事件的處理，這是重中之重，也是最唯一的職責。其次是常規(guī)更新，現(xiàn)在的業(yè)務發(fā)展越來越快，每周都有新的東西上線，比如說今天要買新機器，明天要改IP地址，大家

5、可能80%的投入都是在這些事上，這就是系統(tǒng)管理員或者是現(xiàn)在運維行業(yè)的工作模式。但是系統(tǒng)管理員模式有一個最大的弊端，按照傳統(tǒng)的組織架構模式或者是這種運維模式運行會導致這個團隊持續(xù)擴張，業(yè)務越來越多，需要不停的招人去應付各種各樣的事。剛開始接手生產(chǎn)的時候，也許一周就出一次事或者是需要更新一次。因為人的溝通能力總是有限的，招了五個人之后，這五個人之間的傳達問題就形成了一個困難。當你把一個精神傳達給這五個人，他們事后執(zhí)行出來的結果都不一樣，這就是傳統(tǒng)模型一直想要解決的問題。但是這種模型也有好處，就是市場招聘比較容易。Google有幾個比較重要的特點，首先它的部署規(guī)模非常大。Google到今天已經(jīng)十八年

6、了，剛開始前幾年公司所有的人平時寫代碼，周末去機房接機器。因為它擴展速度特別快，部署規(guī)模非常大。如果按照傳統(tǒng)的系統(tǒng)管理員的那種模式操作，這個機柜歸你，這個機柜歸他，再下一個歸另外一個人，那么Google招人的速度一定趕不上機器增加的速度，所以Google是被逼迫創(chuàng)造了這樣的職位，因為沒有辦法安排團隊做如此大規(guī)模的運維。傳統(tǒng)的運維模式還有一個更大的問題，它過于強調(diào)專業(yè)化。比如一個人是做網(wǎng)絡的，他只做網(wǎng)絡其他都不管，全公司可能只有他懂網(wǎng)絡，因為他不停的在網(wǎng)絡上投入時間，集中力氣把這個事情做好。這樣一個結果就是會發(fā)現(xiàn)運維部門沒人能休假，一出事只有一個人能解決問題。不僅僅是網(wǎng)絡，特殊硬件、一些第三方服

7、務都存在這個問題。這就導致了知識沒法共享，人靈活性受到限制，整個組織的靈活性也受限制。這個問題，我認為它最終形成了一個負反饋的循環(huán)，每個人之間越是互相隔離，越是沒有辦法提高，導致服務質(zhì)量上不去。最大的問題是，招來更多的人其實也不解決問題，因為這個部署規(guī)模不斷擴大，人之間的知識不能共享，所以招來的人只能運維新的設備，舊的設備還是這些人在做。這是一個怪圈?；貒笪遗c很多公司的朋友都聊過這個問題。以前大家講Oracle這樣的公司存在老DBA，說老DBA都是難得一見的，深居簡出，但是你有什么問題，只有他能解決，其實這在Google這個語境里這是一個比較不健康的狀態(tài)。SRE的一大特點就是想請假的時候隨

8、時請假，每一個人都可以請假；當出現(xiàn)緊急情況的時候，當天值班的人真的可以處理他負責的這個服務所有的問題。Google SRE的起源與特點回到最開始，Google SRE的VP叫Ben Treynor，他是一個資深的軟件開發(fā)經(jīng)理。2003年他加入公司第一個任務，是組建一個7人的“生產(chǎn)運維小組”。很快他發(fā)現(xiàn)如果想把這件事情做好，也就是把搜索服務運維好的話，按照Google機器增加的速度，傳統(tǒng)的模式絕對是不可能的。機器增加的速度，系統(tǒng)復雜度增加的速度遠比人增加的速度要多得多。所以他組建的團隊有以下三個特點，注意，這里我認為其實更多的是事后的總結。首先，他的執(zhí)行方式是像組建一個研發(fā)團隊一樣來組建這個運維

9、團隊。他招了很多他熟悉的研發(fā)工程師，這些研發(fā)工程師從開發(fā)能力上沒有任何問題，用現(xiàn)在流行的話就是全棧工程師，什么都會做。第二點，這些人對系統(tǒng)管理比較有熱情，懂一些Linux內(nèi)核知識、網(wǎng)絡層的知識。第三點，最關鍵的是這些人鄙視重復性勞動，碼農(nóng)最痛恨的是什么事，就是反復做同一件事。他把這些人聚到一塊，然后讓他們執(zhí)行以前傳統(tǒng)公司運維人員來做的事情，很自然這些人不愿意手動干，于是就寫程序干。多快好省，同時寫程序還有一個好處，就是可以把一些最佳實踐、方式、流程、方法都固化成代碼，用這種方式去應對規(guī)模性的擴張，去應對復雜度的上升。這些是SRE跟傳統(tǒng)的運維模式最不同的一點，就是招的人研發(fā)為主，做的事也是以研發(fā)

10、為主。這是當時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理論。按照這個理論

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

12、這些都是最上層的東西，只有把底下全部做好了才能說到上面。應急響應應急響應是運維部門在公司最獨特的一點，表現(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è)務中的部署

13、實施，其實這是我們平時花精力最多的地方。監(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é)作的問題，那

14、不應該只是領導現(xiàn)場調(diào)配，而是整個組織每個人都明白這個流程應該是怎么樣的，直接就做。Google甚至可以做到在一次事故中間兩地交班，某個團隊處理一半，然后我交接給另外一邊團隊，就下班回家了，持續(xù)不停的有人繼續(xù)跟蹤處理這件事情，而不會出現(xiàn)問題。這樣一個模式是我覺得非常值得我們思考的。處理完問題之后，要總結。之前聽過的一個故事是，某公司業(yè)務出現(xiàn)了一個事故，大家加班加點，十幾個小時沒睡覺把這事搞定，然后領導過來就說了一句“大家辛苦了，回家睡覺吧”。但是，其實在這個時候我要說，領導光說這個其實恰恰是不夠的。領導在這里應該問：為什么加班??？這個事情為什么會發(fā)生啊，下次能不能不發(fā)生，大家能不能不加班，能不能

15、不熬夜？這樣才對, 能做到事后總結這個事情很難，但只有把這個做好了，才能降低以后問題發(fā)生的幾率。日常運維日常運維做得最多的可能是變更管理。業(yè)務現(xiàn)在發(fā)展非?？欤俣?、迭代周期非?？臁Ｆ鋵嵾@件事情能做好，能夠做到無縫、安全、不停的變更管理，是運維部門能給公司做的最大貢獻。第二個，容量規(guī)劃，當規(guī)模大到一定程度的時候，就需要有人來回答這個問題到底要買多少新機器，能否保證明年的性能、效率，那誰來負責這件事呢？SRE部門提出這些方案，然后要確保這些指標、這些東西是有數(shù)據(jù)支撐的，確實能解決問題的。工程研發(fā)工程研發(fā)雖然做得少，但是工作很關鍵。SRE在工程研發(fā)上主要的工作，首先是幫產(chǎn)品部門確定一個SLO。S

16、LO是一個服務指標，每一個產(chǎn)品都有一個服務指標。任何系統(tǒng)都不可能是百分之百可靠的，也沒有必要做到百分之百可靠。這里得有一個目標，比如說可以每個月中斷幾分鐘。這件事情是要產(chǎn)品部門考慮清楚的。比如我之前在YouTube做視頻存儲、視頻點播的時候，要考慮每個視頻到底是存一份還是存兩份的問題，將這種問題放到一個非常大的部署規(guī)模里面的時候，只有產(chǎn)品部門能夠拍板。說到底是要不要花這個預算，要不要花這么多錢去提高0.1%的可靠性或者0.01%的可靠性。另外一點是無人化運維。大家都看過黑客帝國吧？一醒來發(fā)現(xiàn)大家都是電池，都是為機器服務的。其實把這個比喻放在運維部門非常合適。因為如果不停的開發(fā)出需要人來操作運維

17、的系統(tǒng)，結果大家最后都是電池，明顯是不可持續(xù)的。如果不停的產(chǎn)生這種需要人來操作的東西，不停的招人，最后就變成不停的運維這個東西。把整個流程自動化，建立一個能夠應對復雜業(yè)務的平臺，這就是工程研發(fā)上最需要的東西。SRE模型成功的關鍵要素SRE在Google有十幾年的歷史了。這個模型是如何成功的？我總結如下幾點：職業(yè)化運維行業(yè)從來都說不清楚自己是干嘛的，這是不對的。很多人認為會操作Linux，或者是DBA、會配網(wǎng)絡，就算運維了。實際上運維的范圍要比這個大得多。運維應該是負責公司業(yè)務正常運轉(zhuǎn)的角色，這才是真正的運維。在出問題的時候能解決問題，保障業(yè)務連續(xù)性，甚至避免問題發(fā)生，這才是運維職業(yè)的定義。具體

18、如何做呢？推演和演習。推演是給你一套系統(tǒng)，你要分析出來它會有什么樣的失敗模式。我們當時經(jīng)常在黑板上畫系統(tǒng)圖，大家一起討論如果這個組件出問題了會發(fā)生什么情況，用戶到底還能不能看視頻了，用戶購買流程還能不能走通。實際上這些過程很多時候軟件開發(fā)是不考慮的，但是如何拆分、如何去保證每個環(huán)節(jié)的可靠，這才反是運維這個行業(yè)最關鍵的一點，所以一定要做這種推演。只有這種推演才能輸出改變，讓系統(tǒng)更可靠。第二點是演習。我們當時每周都會進行一次小型災難演習，例如把以前出現(xiàn)的問題拿出來一個，讓新加入團隊的人去演習，所有其他的人也都要去參加。這里主要是觀察新人到底是怎么思考這個系統(tǒng)的，新人做出的決定到底是不是正確的。因為

19、一個人做出的決定是不是正確的實際上取決于系統(tǒng)給的反饋到底是不是對的。Google認為運維復雜系統(tǒng)不是一個靠智商和記憶力就能解決的問題，不能依賴人一定要知道這段話或這個知識點，而是要知道一種方法，知道如何去排除問題或排查問題。運維系統(tǒng)應該提供足夠的信息，讓輪值的人能夠用正確的方法去處理問題。這很像是背英語辭典和會用英語聊天的區(qū)別，你再怎么背辭典關鍵時刻也是要查辭典的，但是真正能運用這些信息解決問題，是比較難的。此外，要區(qū)分責任和指責。責任和指責是兩個事情，但是很多公司的運維經(jīng)常分不清楚。什么叫責任，就是這個事到底誰負責。指責是另外一回事，例如一個員工敲錯了一個命令，大家說 “都是因為他的錯，給他

20、扣工資、扣獎金，讓他三天不吃飯”，但這其實并不真正解決問題。再比如，一個系統(tǒng)設計電源插座，沒有仔細考慮，很容易被人踢到，結果有人真踢到了，整個機房斷電了出了很大的事故。那么從Google的理念來說這里不是人的問題，而是系統(tǒng)設計的問題。這里是不是應該有兩套電源，是不是應該有保護？只有從系統(tǒng)設計問題的角度出發(fā)才能真正解決問題，而指責這個踢到插座的人，讓他一個月不上班，甚至當時開除也并不能解決系統(tǒng)的設計問題，下回總會還有人踢到。說一個故事，故事的內(nèi)容是一個事故。某個數(shù)據(jù)中心有一排機器要斷電，數(shù)據(jù)中心的人發(fā)了一個工單告訴操作員要把這個開關給關了。然后這個操作員去關，他關掉了開關，但是發(fā)現(xiàn)這一排機器的燈

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

22、都要考慮到有沒有被誤用的可能，然后如何避免誤用。專業(yè)化專業(yè)化體現(xiàn)在什么程度呢？要真正的去寫代碼，要能給業(yè)務系統(tǒng)或者給研發(fā)寫的東西挑出問題，提高可靠性。第一，減少瑣事。運維中有很多虛假的工作。每天很忙，然而又不解決問題，做了很多假的工作。大家看起來好像很忙，一個屏幕上十幾個窗口，各種刷屏，但完全不解決問題。更好的方式是用自動化、系統(tǒng)化、工具化的方式去消除這種瑣事的存在。如果永遠靠人工，那永遠都閑不下來。第二，回到SRE，SRE制度里有一條紅線，運維的人只能把一半的時間花在運維上，另外一半的時間必須搞工程上、研發(fā)上的東西。研發(fā)可以是寫工具，可以是參與系統(tǒng)設計，參與可靠性的提高，但是要保證運維不能只

23、干運維。第三，我認為也是比較缺少的，運維部門光有責任沒有決策權，所以大家都說一出事故，運維就背黑鍋。怎么不背黑鍋呢？說改這兒、改那兒，然后發(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是有權利拒絕接受業(yè)務更新的，只允許研發(fā)部門修bug，不允許加新功能。這個

24、爭議我在過去八年見過為數(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)定，完全不管下面怎么搞，由于反饋回路不存在或者這個反饋回路的信息流動不夠

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

26、現(xiàn)在國內(nèi)有的公司也開始講的，運維部門要輸出能力，公司內(nèi)部也要服務化，因為只有服務化才能讓每個團隊更加專業(yè)化。所以回到Google這個平臺上，我認為它實際上是不停的在切分，就是橫向切分。首先最底下是所謂的資源供給層，就是相當于把數(shù)據(jù)中心這件事情真的當成了一個資源，可以服于用戶。就是用戶需要什么樣的機器，配置架構怎么樣，怎么設計數(shù)據(jù)中心，這些東西它都幫用戶做好。有一個專門的團隊去做這件事情，這個團隊也有自己的研發(fā)，也有自己的運維，也有自己的operation、PM，什么都有。往上是技術架構，技術架構是大家經(jīng)常聽說的Borg系統(tǒng)等，讓一些比較通用的技術或者通用的架構都能形成平臺式的東西。再往上才是產(chǎn)

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

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

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

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

31、的自然災害，它這個業(yè)務都是不可能中斷的?？赡苤挥芯植康貐^(qū)受損，只有基礎設施受損的地方，它才會有一些問題，所以這就是災備。實戰(zhàn)演習另外一個更關鍵的一點是做實戰(zhàn)演習。剛才也提到了，SRE以業(yè)務小組為單位，每周都會做實戰(zhàn)演習，整個公司實際上每年也會做一次非常大的實戰(zhàn)演習。我可以舉幾個例子，Google很多地方都有辦公室，有一年某個辦公室食堂的菜有問題，導致所有人都拉肚子進了醫(yī)院。這是Google總部啊，一萬人、兩萬人這樣。于是我們就提出這樣一個問題，說如果這個地方?jīng)]有人來上班了，網(wǎng)站到底還能不能正常運行??？我也曾經(jīng)問過百度、騰訊，他們所有人都在一個大樓里，如果大樓突然斷網(wǎng)了，公司還運轉(zhuǎn)不運轉(zhuǎn)？這是一

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

33、實說到Google在這一點上，也有所謂的運動式演練。每年1、2月份都會組織一次運動式演練，整個公司所有部門都要參與。在這一個星期的時間里實際上公司是不干什么正經(jīng)事的，所有人都想出各種各樣的方法去測試或者去提高系統(tǒng)的可靠性。ONCALL的正確姿勢剛才說的這種比較大的所謂實戰(zhàn)演習，具體到工作的時候也有幾個，就是我們的輪值制度值班。國內(nèi)小公司都是沒有輪值制度的，所有人手機24小時開機，隨時打電話，隨時得解決問題，一個箭步從被窩里爬出來，趕緊上去解決問題。實際上這跟Google不一樣。Google的值班方式更多的是八個人每人值一個星期，值一個星期，剩下的時間你就自己去寫程序、做工程研發(fā)。但是在這一個星

34、期里，你必須能處理生產(chǎn)上發(fā)生的一切問題，這才是真正值班。只有你值班，別人休假了，這才是值班，否則就不叫休假，也不叫值班。所以Google有一個非常明確的規(guī)定，Google認為一個事故的正確處理或從發(fā)生到解決到事后解決需要六個小時，它認為需要六個小時。運維人員每次值班一般都是值十二個小時的班，大概從早上五點到晚上五點或者是從早上十點到晚上十點。因為它所有的值班都是由兩地互相倒的，在美國有一部分，在歐洲有一部分，我們上班的時候我們值班，他們上班的時候他們值班。Google認為其實一天最多只能發(fā)生兩次事件。不管什么樣的系統(tǒng)問題，首先要保證一定要有足夠的時間去處理問題。因為如果問題發(fā)生太頻繁了，就像有

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