接下來聊一聊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在這一點上，也有所謂的運動式演練。每年1、2月份都會組織一次運動式演練，整個公司所有部門都要參與。在這一個星期的時間裡實際上公司是不幹什麼正經事的，所有人都想出各種各樣的方法去測試或者去提高系統的可靠性。

ONCALL的正確姿勢

剛才說的這種比較大的所謂實戰演習，具體到工作的時候也有幾個，就是我們的輪值制度值班。國內小公司都是沒有輪值制度的，所有人手機24小時開機，隨時打電話，隨時得解決問題，一個箭步從被窩裡爬出來，趕緊上去解決問題。實際上這跟Google不一樣。Google的值班方式更多的是八個人每人值一個星期，值一個星期，剩下的時間你就自己去寫程式、做工程研發。但是在這一個星期裡，你必須能處理生產上發生的一切問題，這才是真正值班。只有你值班，別人休假了，這才是值班，否則就不叫休假，也不叫值班。所以Google有一個非常明確的規定，Google認為一個事故的正確處理或從發生到解決到事後解決需要六個小時，它認為需要六個小時。運維人員每次值班一般都是值十二個小時的班，大概從早上五點到晚上五點或者是從早上十點到晚上十點。因為它所有的值班都是由兩地互相倒的，在美國有一部分，在歐洲有一部分，我們上班的時候我們值班，他們上班的時候他們值班。Google認為其實一天最多隻能發生兩次事件。不管什麼樣的系統問題，首先要保證一定要有足夠的時間去處理問題。因為如果問題發生太頻繁了，就像有些網際網路公司，每天一上班這手機就開始“嗡嗡”在桌子上不停的響。一旦有一會兒不響了，就開始擔心說這個監控系統到底是是不是壞了。

如果處理太多了，實際上就變成什麼呢？兩個比較重要的因素，第一個因素是你沒有辦法好好處理，你處理相當於就是上去敲一個命令，沒有時間去想到底這個東西為什麼會出現這個問題，以後怎麼避免這個問題。所以這個叫（狼來了）效應，你on call的時候已經沒有時間去思考了。第二個會發生“狼來了”事件。本來可能是兩次完全不一樣的事故，但是你上一次處理的時候，你發現重啟就行了，下一次你就條件反射，出現這個問題的之後你又去重啟了，但它實際上可能是另外一個問題，可能是完全不相關的問題，你重啟可能導致這問題更糟糕。所以如果你總是用這種模式處理問題的話必然會出問題，早晚這個災難會升級。本來是一個很小的問題，結果可能變成一個很大的問題。

運維重要一點是解決線上問題。很多軟體工程師做運維會鑽牛角尖，這個線上系統出問題了，比如商城裡不能購買了，這時候如果鑽到這個程式裡考慮要這麼寫還是那麼寫，實際上是不解決線上的問題。作為運維這個職業或者作為運營這個職業來說，它唯一的目標就是要保證系統的正常。有的時候需要用一些比較low的手段或者是方式。比如在專案初期機器有問題，我們就把它們都停了，然後使用一些新的伺服器重新搭起來。事實上也不知道這個東西為什麼壞了，就把它放在這兒，先去解決生產上的實際問題。實際上我認為這是運維最大的價值。運維部門目標就是保證業務的持續性。

事後總結

接著是做總結，寫一些事後總結。Google的事後總結都是非常專業的，是非常對事不對人的，它會非常詳細地列出來在什麼時間出現了什麼問題，誰去操作的，他執行了什麼操作，這個操作到底是解決問題還是沒有解決問題，如果沒有解決問題的話該怎麼去確保不會去執行這個操作。這是一個迴圈往復的過程，是一個不停錘鍊的過程。把解決問題當成一個職業來對待的話，所有事情都很好辦了。這回出現這個問題，解決了一遍，然後發現執行了某些地方可能是系統給出錯誤的訊號，可能是文件有問題，把它都一一解決了。下回再執行的時候，可能換了一撥人來執行這個，也能保證不會出現問題。這就是事後總結帶來的最大利益。

SLO預估

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

SRE模型成功的標誌

最後就是說到底SRE成功還是不成功，實際上就是看這兩條曲線。上面這條線是部署規模，大家都知道網際網路的業務都是爆發式增長，它是指數型的。如果說按照常規的那種招聘曲線，直線性的，那麼永遠趕不上這個規模，所以運維事務必須要把它壓下來。Google經常做這種統計，到底我們業務規模擴大之後，擴大了多少工單數量，然後出現了多少事故，造成了多大問題。實際上只有統計這個事情，才能知道你到底做得好不好。當這個系統成熟到一定程度之後，SRE的運維速度是固定的，甚至是越來越少的。只有做到這一點，才相當於把運維這個事情做好，剩下的時間或者剩下的精力才能去接手更多的業務、做更多的技術研發。

我分享的東西也到此結束了，謝謝大家！