來自 Google 的 DevOps 理念及實踐

SRE（Site Reliability Engineering）是最早由Google提出，又經由Google發展完善的一個嶄新運維理念。如今SRE已成為一個涵蓋運維理念、思路、組織架構和具體實踐的完整體系。本文由前Google SRE、《SRE Google運維解密》的譯者孫宇聰線上分享整理而成。

今天與大家分享的內容是關于最近我翻譯的這本書——《SRE Google運維解密》，據說反響還不錯，今天借這個機會聊一聊書中的內容，并與大家分享一下我回國兩年多以來，Google經驗在國內的一些思考和落地實踐。

什么是SRE？

很多時候國內把DevOps的范圍定得有點狹窄， DevOps這件事情在國外更多是整個行業內的一個趨勢。DevOps是一種模式，主要是讓IT相關的東西與商業結合得更緊密一些，迭代速度變得更快一些，所以它適用于各個行業。今天說的SRE，我認為也是在運維行業上的一部分。

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

回到這本書的宗旨， SRE到底是什么？SRE是Google發明的一個詞語或者新定義的一個職業。以前這個運維角色，大家叫運維，美國叫Operation。現在Google把這個職位擴展為SRE，就是用軟件工程師的方法和手段，招了一些軟件工程師來解決運維的難題，這是SRE的官方定義。

傳統運維模式的弱點

現在傳統的計算機行業的運維方式，大部分都是采用系統管理員的模式。大家最熟悉的運維方式是這樣：招聘一些系統管理員，他們有負責采購機器的，有負責維護數據中心的，也有專門維護數據庫的等等。系統管理員模式有幾個特點，他們只是把一些現成的組件組裝起來，并不會自己開發和創造新的系統，比如拿了MySQL把它跑起來，或是研發部門開發出來的新代碼組裝成之后提供這樣一個服務。這是運維部門的一個特色，負責把這個東西運行好。

舉一個例子，在美國的時候我們經常自嘲，說自己是流水線上的工人。因為這個流水線實際上是別人設計出來的，總得有人去操作這個機器，而我們就是一線的操作流水線的工人。又比如，我們好像是發電站里的工作人員，又或者是飛機駕駛員。飛機駕駛員就是開別人造出來的飛機，這和運維部門的職責很像。

那么這樣一個運維部門的職責包括哪些呢？首先最重要的是應急事件的處理，這是重中之重，也是最唯一的職責。其次是常規更新，現在的業務發展越來越快，每周都有新的東西上線，比如說今天要買新機器，明天要改IP地址，大家可能80%的投入都是在這些事上，這就是系統管理員或者是現在運維行業的工作模式。

但是系統管理員模式有一個最大的弊端，按照傳統的組織架構模式或者是這種運維模式運行會導致這個團隊持續擴張，業務越來越多，需要不停的招人去應付各種各樣的事。剛開始接手生產的時候，也許一周就出一次事或者是需要更新一次。因為人的溝通能力總是有限的，招了五個人之后，這五個人之間的傳達問題就形成了一個困難。當你把一個精神傳達給這五個人，他們事后執行出來的結果都不一樣，這就是傳統模型一直想要解決的問題。但是這種模型也有好處，就是市場招聘比較容易。

Google有幾個比較重要的特點，首先它的部署規模非常大。Google到今天已經十八年了，剛開始前幾年公司所有的人平時寫代碼，周末去機房接機器。因為它擴展速度特別快，部署規模非常大。如果按照傳統的系統管理員的那種模式操作，這個機柜歸你，這個機柜歸他，再下一個歸另外一個人，那么Google招人的速度一定趕不上機器增加的速度，所以Google是被逼迫創造了這樣的職位，因為沒有辦法安排團隊做如此大規模的運維。

傳統的運維模式還有一個更大的問題，它過于強調專業化。比如一個人是做網絡的，他只做網絡其他都不管，全公司可能只有他懂網絡，因為他不停的在網絡上投入時間，集中力氣把這個事情做好。這樣一個結果就是會發現運維部門沒人能休假，一出事只有一個人能解決問題。不僅僅是網絡，特殊硬件、一些第三方服務都存在這個問題。這就導致了知識沒法共享，人靈活性受到限制，整個組織的靈活性也受限制。這個問題，我認為它最終形成了一個負反饋的循環，每個人之間越是互相隔離，越是沒有辦法提高，導致服務質量上不去。最大的問題是，招來更多的人其實也不解決問題，因為這個部署規模不斷擴大，人之間的知識不能共享，所以招來的人只能運維新的設備，舊的設備還是這些人在做。

這是一個怪圈。回國之后我與很多公司的朋友都聊過這個問題。以前大家講Oracle這樣的公司存在老DBA，說老DBA都是難得一見的，深居簡出，但是你有什么問題，只有他能解決，其實這在Google這個語境里這是一個比較不健康的狀態。SRE的一大特點就是想請假的時候隨時請假，每一個人都可以請假；當出現緊急情況的時候，當天值班的人真的可以處理他負責的這個服務所有的問題。

Google SRE的起源與特點

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

這些是SRE跟傳統的運維模式最不同的一點，就是招的人研發為主，做的事也是以研發為主。這是當時SRE成立背后的故事，這些年來我認為他們做得最好的一點是一直在維持了一種平衡。 將運維部門從傳統執行部門往上提升，打破了傳統的界限 。就像剛才說的DevOps，很多人理解為就是讓研發部門做運維的事，或者運維部門做研發的事情，但實際上DevOps在國外的定義更寬泛一點。DevOps的思想更多的是說把整個開發流程的界限打通，產品有的時候也要干一些研發的事，研發有時候把這個信息要很快的反饋給這個產品，開發和運維或者QA和運維之間的界限也打通。所以現在去搜DevOps的圖片，會發現IBM這些人都在講圈圈，說以前是產品研發都是一條線直著來，而現在都是轉圈的，這就是DevOps理論。

按照這個理論來說，SRE就是DevOps的思想在開發和運維之間的一個平衡。

SRE的工作職責

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

應急響應

應急響應是運維部門在公司最獨特的一點，表現為當公司出現問題時，應該找誰或者流程應該是怎樣的。我回國之后見了不少初創企業，他們網站出問題了，往往是CEO先發現，CEO打電話“哎，這個到底是怎么回事啊”，然后每一個人都說“不知道啊，不是我負責呀，我得找誰誰”。不管多大一件事都得傳遍整個公司，整個效率非常混亂。

我在Google待了八年時間，這樣的流程也經歷過，但是最近這幾年Google非常重視這一點，建立了一整套應急事件處理方式。首先要有全面監控，監控這件事情是持久不斷的，重中之重。SRE所有人都要非常了解整個監控系統在所有業務中的部署實施，其實這是我們平時花精力最多的地方。監控系統里面對整個系統所有方面都有監控，不光包括業務指標，也包括性能指標、效率指標。監控應該平臺化、系統化，不停的往上積累，多做一些模板，同質化的系統就可以用同樣的方法去做監控。

第二點是應急事務處理， 應急事務處理分兩部分，第一部分是演習，另外一部分是真正的處理流程 。如何把它做好？實際上就是要不停的去演習、去做這個事情。像剛才舉的例子，網站掛了，首先不應該CEO先發現，而應該是監控系統或者報警系統先告警，在發現之前就很應該明確這個東西應該誰排查，誰處理，這個信息應該早就發給合適的人去處理，甚至他應該早就在做了。如果發生特別大的，需要跨部門之間協作的問題，那不應該只是領導現場調配，而是整個組織每個人都明白這個流程應該是怎么樣的，直接就做。 Google甚至可以做到在一次事故中間兩地交班，某個團隊處理一半，然后我交接給另外一邊團隊，就下班回家了，持續不停的有人繼續跟蹤處理這件事情，而不會出現問題 。這樣一個模式是我覺得非常值得我們思考的。

處理完問題之后，要總結。之前聽過的一個故事是，某公司業務出現了一個事故，大家加班加點，十幾個小時沒睡覺把這事搞定，然后領導過來就說了一句“大家辛苦了，回家睡覺吧”。但是，其實在這個時候我要說，領導光說這個其實恰恰是不夠的。領導在這里應該問：為什么加班啊？這個事情為什么會發生啊，下次能不能不發生，大家能不能不加班，能不能不熬夜？這樣才對, 能做到事后總結這個事情很難，但只有把這個做好了，才能降低以后問題發生的幾率。

日常運維

日常運維做得最多的可能是變更管理。業務現在發展非常快，迭代速度、迭代周期非常快。其實這件事情能做好，能夠做到無縫、安全、不停的變更管理，是運維部門能給公司做的最大貢獻。

第二個，容量規劃，當規模大到一定程度的時候，就需要有人來回答這個問題——到底要買多少新機器，能否保證明年的性能、效率，那誰來負責這件事呢？SRE部門提出這些方案，然后要確保這些指標、這些東西是有數據支撐的，確實能解決問題的。

工程研發

工程研發雖然做得少，但是工作很關鍵。 SRE在工程研發上主要的工作，首先是幫產品部門確定一個SLO 。SLO是一個服務指標，每一個產品都有一個服務指標。任何系統都不可能是百分之百可靠的，也沒有必要做到百分之百可靠。這里得有一個目標，比如說可以每個月中斷幾分鐘。這件事情是要產品部門考慮清楚的。比如我之前在油Tube做視頻存儲、視頻點播的時候，要考慮每個視頻到底是存一份還是存兩份的問題，將這種問題放到一個非常大的部署規模里面的時候，只有產品部門能夠拍板。說到底是要不要花這個預算，要不要花這么多錢去提高0.1%的可靠性或者0.01%的可靠性。

另外一點是無人化運維。大家都看過《黑客帝國》吧？一醒來發現大家都是電池，都是為機器服務的。其實把這個比喻放在運維部門非常合適。因為如果不停的開發出需要人來操作運維的系統，結果大家最后都是電池，明顯是不可持續的。如果不停的產生這種需要人來操作的東西，不停的招人，最后就變成不停的運維這個東西。把整個流程自動化，建立一個能夠應對復雜業務的平臺，這就是工程研發上最需要的東西。

SRE模型成功的關鍵要素

SRE在Google有十幾年的歷史了。這個模型是如何成功的？我總結如下幾點：

職業化

運維行業從來都說不清楚自己是干嘛的，這是不對的。很多人認為會操作Linux，或者是DBA、會配網絡，就算運維了。實際上運維的范圍要比這個大得多。運維應該是負責公司業務正常運轉的角色，這才是真正的運維。在出問題的時候能解決問題，保障業務連續性，甚至避免問題發生，這才是運維職業的定義。

具體如何做呢？推演和演習。

推演是給你一套系統，你要分析出來它會有什么樣的失敗模式。我們當時經常在黑板上畫系統圖，大家一起討論如果這個組件出問題了會發生什么情況，用戶到底還能不能看視頻了，用戶購買流程還能不能走通。實際上這些過程很多時候軟件開發是不考慮的，但是如何拆分、如何去保證每個環節的可靠，這才反是運維這個行業最關鍵的一點，所以一定要做這種推演。只有這種推演才能輸出改變，讓系統更可靠。

第二點是演習。我們當時每周都會進行一次小型災難演習，例如把以前出現的問題拿出來一個，讓新加入團隊的人去演習，所有其他的人也都要去參加。這里主要是觀察新人到底是怎么思考這個系統的，新人做出的決定到底是不是正確的。因為一個人做出的決定是不是正確的實際上取決于系統給的反饋到底是不是對的。 Google認為運維復雜系統不是一個靠智商和記憶力就能解決的問題，不能依賴人一定要知道這段話或這個知識點，而是要知道一種方法，知道如何去排除問題或排查問題 。運維系統應該提供足夠的信息，讓輪值的人能夠用正確的方法去處理問題。這很像是背英語辭典和會用英語聊天的區別，你再怎么背辭典關鍵時刻也是要查辭典的，但是真正能運用這些信息解決問題，是比較難的。

此外，要區分責任和指責。責任和指責是兩個事情，但是很多公司的運維經常分不清楚。什么叫責任，就是這個事到底誰負責。但是指責是另外一回事。例如一個員工敲錯了一個命令，大家說 “都是因為他的錯，給他扣工資、扣獎金，讓他三天不吃飯”，但這其實并不真正解決問題。再例如，比如說一個系統設計電源插座，沒有仔細考慮，很容易被人踢到，結果有人真踢到了，整個機房斷電了出了很大的事故。那么從Google的理念來說這里不是人的問題，而是系統設計的問題。這里是不是應該有兩套電源，是不是應該有保護？只有從系統設計問題的角度出發才能真正解決問題，而指責這個踢到插座的人，讓他一個月不上班，甚至當時開除也并不能解決系統的設計問題，下回總會還有人踢到。

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

專業化

專業化體現在什么程度呢？要真正的去寫代碼，要能給業務系統或者給研發寫的東西挑出問題，提高可靠性。

第一，減少瑣事。運維中有很多虛假的工作。每天很忙，然而又不解決問題，做了很多假的工作。大家看起來好像很忙，一個屏幕上十幾個窗口，各種刷屏，但完全不解決問題。更好的方式是用自動化、系統化、工具化的方式去消除這種瑣事的存在。如果永遠靠人工，那永遠都閑不下來。

第二，回到SRE，SRE制度里有一條紅線，運維的人只能把一半的時間花在運維上，另外一半的時間必須搞工程上、研發上的東西。研發可以是寫工具，可以是參與系統設計，參與可靠性的提高，但是要保證運維不能只干運維。

第三點，我認為也是比較缺少的，運維部門光有責任沒有決策權，所以大家都說一出事故，運維就背黑鍋。怎么不背黑鍋呢？說改這兒、改那兒，然后發現沒有人批準改動，這是最大的問題。 SRE做的最好的一點是管理層對SRE的工作方式非常認可、非常支持，他們認為服務質量是服務的一個重要指標 。一旦上升到這個高度，SRE部門提出一些要求就比較容易理解，得到支持，因為他們是有事實根據的。當GoogleSRE發現生產出現問題的時候，標準的解決辦法就是暫停所有更新，確保業務穩定。舉個比較極端的例子，像剛才說的如果發現線上系統有問題的情況下，SRE是有權利拒絕接受業務更新的，只允許研發部門修bug，不允許加新功能。這個爭議我在過去八年見過為數不多的幾次，開發可以一直鬧到 VP，SVP 這個級別。每一次都是聽SRE的。

打通與產品團隊的反饋回路

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

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

SRE的最佳實踐

建設平臺化服務體系

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

所以回到Google這個平臺上，我認為它實際上是不停的在切分，就是橫向切分。首先最底下是所謂的資源供給層，就是相當于把數據中心這件事情真的當成了一個資源，可以服于用戶。就是用戶需要什么樣的機器，配置架構怎么樣，怎么設計數據中心，這些東西它都幫用戶做好。有一個專門的團隊去做這件事情，這個團隊也有自己的研發，也有自己的運維，也有自己的Operation、PM，什么都有。

往上是技術架構，技術架構是大家經常聽說的Borg系統等，讓一些比較通用的技術或者通用的架構都能形成平臺式的東西。

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

容量規劃和容量管理

然后大家會發現在做一個業務層運維的時候，可以關注更高級的東西，不是關心買什么樣機器，而是更多關心到底需要多少容量，這些容量應該在什么地方。在油Tube我們經常在辦公室擺一個世界地圖，大家經常會討論這里有一個數據中心，那里有一個數據中心，然后討論在這邊放多少容量，在那邊放多少容量，它們之間如何災備，我們可以考慮這些更高級的、更抽象的東西。這樣的好處是可以真正的做到容災，就是所謂的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的運維速度是固定的，甚至是越來越少的 。只有做到這一點，才相當于把運維這個事情做好，剩下的時間或者剩下的精力才能去接手更多的業務、做更多的技術研發。

 

 

 

來自：http://mp.weixin.qq.com/s?__biz=MzA5OTAyNzQ2OA==&mid=2649692520&idx=1&sn=7dfe3bdb8f29dabcd9b27d0998a1702e&chksm=8893260bbfe4af1d71cabd834c8fa63d89d6038a6b8dcefda3db7229410917c5a1746a2f2409&mpshare=1&scene=1&srcid=1116flE1AY9oyKmM2sMSF2WS#rd