SRE系列教程 | 孫宇聰：來自Google的DevOps理念及實踐（下）

上一期孫宇聰老師關於SRE基本概念和核心原理的線上分享一經推出就引發了小夥伴們的熱烈關注，看來你們對SRE的相關內容很感興趣呀。

今天小數繼續爲你們帶來孫老師的第二次線上分享內容，探討SRE的一些最佳實踐和成功標準，但願你們閱讀愉快並持續關注咱們後續的SRE內容：）

接下來聊一聊SRE的一些最佳實踐，我認爲Google作得比較好的幾點。

SRE的最佳實踐

建設平臺化服務體系

首先， Google如今是一個六萬人的公司，涉及到的產品線可能一百多個，各個部門之間差距很大，並且Google全球幾百個數據中心，有不少機器，它如何管理？若是按照國內公司的方式去管理早就累死了。由於國內不少運維部門從上到下什麼都管，從買機器開始，一直到最上面安裝服務器、調試，配網絡，因此業務線、運維部門常常好幾千人。Google作得比較好的一點就是它把一個東西橫向切分，由於它很早以前就意識到不少部門或者不少人之間有共性？像如今國內有的公司也開始講的，運維部門要輸出能力，公司內部也要服務化，由於只有服務化才能讓每一個團隊更加專業化。

因此回到Google這個平臺上，我認爲它其實是不停的在切分，就是橫向切分。首先最底下是所謂的資源供給層，就是至關於把數據中心這件事情真的當成了一個資源，能夠服於用戶。就是用戶須要什麼樣的機器，配置架構怎麼樣，怎麼設計數據中心，這些東西它都幫用戶作好。有一個專門的團隊去作這件事情，這個團隊也有本身的研發，也有本身的運維，也有本身的operation、PM，什麼都有。

往上是技術架構，技術架構是你們常常據說的Borg系統等，讓一些比較通用的技術或者通用的架構都能造成平臺式的東西。

再往上纔是產品線，每一層實際上都有本身的SRE部門、運維部門，都是一個項目。因此把這個平臺搭起來以後，上層的人能夠愈來愈少關心底下的細節問題，必定程度的減小了他不少精力、減小了不少官僚主義上的問題。須要計算資源的時候就給資源，不是還要先去審批又買機器，什麼樣的機器，什麼樣的配置都不同，因此整個公司是一個很是同質化的公司，不少業務底下共享的東西不少。工做在越底層的人若是能服務的人越多，就會產生一個所謂的放大效應。可能大公司都是這樣的，它有平臺化效應，底下的人能夠搞出一個世界最好的數據中心，能夠同時服務幾十個產品線的業務；搞出一個更好的數據庫，全部人均可以用，這是Google作得比較好的一點。

容量規劃和容量管理

而後你們會發如今作一個業務層運維的時候，能夠關注更高級的東西，不是關心買什麼樣機器，而是更多關心到底須要多少容量，這些容量應該在什麼地方。在YouTube咱們常常在辦公室擺一個世界地圖，你們常常會討論這裏有一個數據中心，那裏有一個數據中心，而後討論在這邊放多少容量，在那邊放多少容量，它們之間如何災備，咱們能夠考慮這些更高級的、更抽象的東西。這樣的好處是能夠真正的作到容災，就是所謂的N+M。就是若是平時須要的峯值流量是N，M是做爲災備流量或者是這個冗餘流量。N和M究竟是什麼？不少公司連本身的N都不知道，歷來沒有說過咱們到底要處理多少流量，有些領導說咱們「雙11」想來多大量的就來多大量，這怎麼能搞好？

這個問題是運維部門獨特的功能或者獨特的角色，要負責將把這個東西肯定下來，咱們到底要承擔多大的流量，要有多少冗餘。接下來就是驗證這件事情，到底有沒有這樣的能力，能不能處理這麼大的流量或者這麼大的需求？ Google有一個內部指標就是130%，好比能夠處理1秒交易量是一百萬，實際上集羣的峯都是按照一百萬的130%來處理。130%是負載均衡或者是一些外界波動致使的，它其實是不平均的。咱們能夠說它是一百萬條交易的負荷，但實際上不可能說一百萬零一條這個系統就崩潰了。能夠留一下窗口，留一些冗餘量來處理一些操做中的未知性，還有一些特殊意外狀況，因此130%是一個咱們經常使用的指標。

在Google裏面已經不多提災備這件事情，就是對咱們來講咱們沒有災備容量，都是平均負載均衡的。可能有一些冗餘，好比一個系統只能一千臺機器，這一千臺機器並非說我有十臺是不接受業務處理的，而是咱們全部機器都是接受業務處理，只不過他們處理能力可能沒有把全部的資源都用完。這也是Google有不少經驗教訓，若是一個東西總是不用的話，它就是壞的，你平時再怎麼演習、怎麼用，一到關鍵時刻它就過不去、它就是有問題，因此更多的時候壓根不討論災備的問題，全部東西永遠都是在線的，這也是爲何說想把Google.com給弄壞是一件很是困難的事情，得全球幾百個數據中心同時出問題，纔可能會出現不可用的狀況。因此Google全球業務是不可能中斷的，無論出現多大的天然災害，它這個業務都是不可能中斷的。可能只有局部地區受損，只有基礎設施受損的地方，它纔會有一些問題，因此這就是災備。

實戰演習

另一個更關鍵的一點是作實戰演習。剛纔也提到了，SRE以業務小組爲單位，每週都會作實戰演習，整個公司實際上每一年也會作一次很是大的實戰演習。我能夠舉幾個例子，Google不少地方都有辦公室，有一年某個辦公室食堂的菜有問題，致使全部人都拉肚子進了醫院。這是Google總部啊，一萬人、兩萬人這樣。因而咱們就提出這樣一個問題，說若是這個地方沒有人來上班了，網站到底還能不能正常運行啊？我也曾經問過百度、騰訊，他們全部人都在一個大樓裏，若是大樓忽然斷網了，公司還運轉不運轉？這是一個很大的問題，無論是地質災害問題、天然災害、人文災害，這些雖然聽起來好像比較極端，但確實能考驗出一個組織的業務持續能力。實際上這是Google作得比較好的一點。剛纔說的都是比較誇張的例子，是比較大範圍的。一些比較小的例子，好比這個系統就是你這個小組負責，大家這個小組到底有沒有單點故障，這我的是否是能休假，若是一旦出現問題是否是全部人都能去解決這個問題。咱們常常互相出題去作這種測試，而後去分享一些知識。我想這更可能是一種風氣吧。首先你認同這個目標，目標固然就是把這個系統建設得更可靠。認同了這個目標，接下來就是不停地去考驗還有哪些漏洞，並確保整個團隊其餘人也有一樣的知識，一樣的技能去解決這個問題。

其實說到Google在這一點上，也有所謂的運動式演練。每一年一、2月份都會組織一次運動式演練，整個公司全部部門都要參與。在這一個星期的時間裏實際上公司是不幹什麼正經事的，全部人都想出各類各樣的方法去測試或者去提升系統的可靠性。

ONCALL的正確姿式

剛纔說的這種比較大的所謂實戰演習，具體到工做的時候也有幾個，就是咱們的輪值制度值班。國內小公司都是沒有輪值制度的，全部人手機24小時開機，隨時打電話，隨時得解決問題，一個箭步從被窩裏爬出來，趕忙上去解決問題。實際上這跟Google不同。Google的值班方式更多的是八我的每人值一個星期，值一個星期，剩下的時間你就本身去寫程序、作工程研發。可是在這一個星期裏，你必須能處理生產上發生的一切問題，這纔是真正值班。只有你值班，別人休假了，這纔是值班，不然就不叫休假，也不叫值班。因此Google有一個很是明確的規定，Google認爲一個事故的正確處理或從發生到解決到過後解決須要六個小時，它認爲須要六個小時。運維人員每次值班通常都是值十二個小時的班，大概從早上五點到晚上五點或者是從早上十點到晚上十點。由於它全部的值班都是由兩地互相倒的，在美國有一部分，在歐洲有一部分，咱們上班的時候咱們值班，他們上班的時候他們值班。Google認爲其實一天最多隻能發生兩次事件。無論什麼樣的系統問題，首先要保證必定要有足夠的時間去處理問題。由於若是問題發生太頻繁了，就像有些互聯網公司，天天一上班這手機就開始「嗡嗡」在桌子上不停的響。一旦有一下子不響了，就開始擔憂說這個監控系統究竟是是否是壞了。

若是處理太多了，實際上就變成什麼呢？兩個比較重要的因素，第一個因素是你沒有辦法好好處理，你處理至關於就是上去敲一個命令，沒有時間去想到底這個東西爲何會出現這個問題，之後怎麼避免這個問題。因此這個叫（狼來了）效應，你on call的時候已經沒有時間去思考了。第二個會發生「狼來了」事件。原本多是兩次徹底不同的事故，可是你上一次處理的時候，你發現重啓就好了，下一次你就條件反射，出現這個問題的以後你又去重啓了，但它實際上多是另一個問題，多是徹底不相關的問題，你重啓可能致使這問題更糟糕。因此若是你老是用這種模式處理問題的話必然會出問題，遲早這個災難會升級。原本是一個很小的問題，結果可能變成一個很大的問題。

運維重要一點是解決線上問題。不少軟件工程師作運維會鑽牛角尖，這個線上系統出問題了，好比商城裏不能購買了，這時候若是鑽到這個程序裏考慮要這麼寫仍是那麼寫，其實是不解決線上的問題。做爲運維這個職業或者做爲運營這個職業來講，它惟一的目標就是要保證系統的正常。有的時候須要用一些比較low的手段或者是方式。好比在項目初期機器有問題，咱們就把它們都停了，而後使用一些新的服務器從新搭起來。事實上也不知道這個東西爲何壞了，就把它放在這兒，先去解決生產上的實際問題。實際上我認爲這是運維最大的價值。運維部門目標就是保證業務的持續性。

過後總結

接着是作總結，寫一些過後總結。Google的過後總結都是很是專業的，是很是對事不對人的，它會很是詳細地列出來在什麼時間出現了什麼問題，誰去操做的，他執行了什麼操做，這個操做究竟是解決問題仍是沒有解決問題，若是沒有解決問題的話該怎麼去確保不會去執行這個操做。這是一個循環往復的過程，是一個不停錘鍊的過程。把解決問題當成一個職業來對待的話，全部事情都很好辦了。這回出現這個問題，解決了一遍，而後發現執行了某些地方多是系統給出錯誤的信號，多是文檔有問題，把它都一一解決了。下回再執行的時候，可能換了一撥人來執行這個，也能保證不會出現問題。這就是過後總結帶來的最大利益。

SLO預估

最後說說SLO。SLO是運維部門的一個關鍵工具。服務質量其實是運維部門惟一負責的事情。公司要求員工達到某某指標，那員工怎麼去達到這一點？第一，要先幫助制定SLO，要用事實、數據去說明白達到這個服務質量到底須要多少投入、須要多少流程改進、須要多少系統改進。第二，要確保達到這個服務質量不會影響創新速度。這要有一個平衡的取捨，要用數據去說話，一個天天只能down一分鐘的系統和一個天天能夠down四個小時的系統，它所能承受的更新頻率是不同的，部署的要求和方式確定都是不同的，因此要圍繞着這個去作，要把這些理念推行到研發部門和產品部門。最後就是把可靠性當成產品的一個重要組成部分，研發也得關心可靠性，他在寫代碼的時候得知道這個東西必定是要可靠的。把可靠性一直推到產品設計或者是業務層次去，它才能貫徹到底層的研發、運維，才能把它作好。

SRE模型成功的標誌

最後就是說到底SRE成功仍是不成功，實際上就是看這兩條曲線。上面這條線是部署規模，你們都知道互聯網的業務都是爆發式增加，它是指數型的。若是說按照常規的那種招聘曲線，直線性的，那麼永遠趕不上這個規模，因此運維事務必需要把它壓下來。Google常常作這種統計，到底咱們業務規模擴大以後，擴大了多少工單數量，而後出現了多少事故，形成了多大問題。實際上只有統計這個事情，才能知道你到底作得好很差。當這個系統成熟到必定程度以後，SRE的運維速度是固定的，甚至是愈來愈少的。只有作到這一點，才至關於把運維這個事情作好，剩下的時間或者剩下的精力才能去接手更多的業務、作更多的技術研發。

我分享的東西也到此結束了，謝謝你們！

SRE系列教程 | 孫宇聰：來自Google的DevOps理念及實踐（上）