摘要：作者在領域，谷歌應該是典范之一，特別是在自動化測試領域。谷歌有一個長期傳統，所有的新服務需要開發人員自行管理至少六個月。

【編者按】本文是 Gene Kim 總結自對 Randy Shoup 兩個小時的采訪，主要關注谷歌 DevOps 的提升之道。本文系 OneAPM 聯合高效運維編譯整理。

Randy Shoup 曾協助領導 eBay 和 Google 的工程師團隊，他是筆者見過少數能將「建造高效產出 DevOps 與世界級可靠性系統需要怎樣領導特質」描述清楚的人之一。其兩個演講（2013 Flowcon 演講、2000s 早期他在轉化 eBay 架構時驚人的工作）深受筆者喜愛。

本文由 Gene Kim 根據對 Randy Shoup 的采訪整理，深入討論和講解谷歌 DevOps 的提升之道，下面一起深入了解。本文系 OneAPM 聯合高效運維編譯整理。

Dr. Spear的模型有如下四大能力：

能力1：在問題發生時馬上就能發現；

能力2：一旦發現問題立刻集群式解決（Swarming），并將此記錄下來儲備成新知識；

能力3：在整個公司范圍內傳播新知；

能力4：以開發為主導。

這也是采訪 Randy Shoup 的基礎，此次采訪還揭示了一些在谷歌與 eBay 中未曾廣泛討論過的實踐案例。

（筆者從 Randy Shoup 那里學到了太多東西，難以言喻。如果想了解更多信息，并用于公司實踐的話，不妨通過 Randy LinkedIn 的個人主頁聯系他，他目前正從事咨詢工作）。

Dr. Spear 寫道：

高速率的公司會針對已有知識庫制定詳細規則和設計捕獲問題，并使用內置測試以發現問題。

無論個體還是團隊工作，無論是否有設備，高速率公司不愿意接受模棱兩可。他們提前對以下內容進行詳細說明：
（a）預期產出；（b）誰負責什么工作，順序如何；（c）產品、服務與信息如何從上一步的負責人手上遞交到下一步的負責人手中；（d）完成每一部分工作的方法。

GK（作者）：在 DevOps 領域，谷歌應該是典范之一，特別是在自動化測試領域。

Google SCM 團隊 Eran Messeri 在2013年的 GOTOcon Aarhus 大會的某環節上表示：「在成千上萬名工程師分享同一個持續構建時，出現了什么問題？」（演講筆記可以查看這里）

他列出了一些值得注意的統計資料（截止到2013年），并介紹了他們是如何創建在能力范圍內最迅速、最及時且成本最低的程序員反饋機制：

1.5萬程序員（包括開發與運維）

4000個同時進行的項目

在同一個庫里 check 所有的源代碼（數十億文件！）

5500次代碼提交 via 1.5萬程序員

自動測試日運行7500萬次

0.5%的工程師致力于開發工具

這里有一份2010年 Ashish Kumar 做的 QConSF PPT，在這里你可以查看到更多關于 Google 開發團隊所實現的驚人數字。

Q：谷歌可能是自動化測試的典范了，大家都想更多地了解你在那里的工作經驗。

A：的確如此，谷歌做了大量的自動化測試——超過我工作過的其他所有典范。「一切」都需要測試——不僅要測試 getter/setter 功能，還要測試一切可能出問題的地方。

對所有人來說，設計測試通常是極具挑戰的。也不會有人花時間去寫測試來檢查自己認為會正常運作的功能，相反通常是去測試那些可能出錯的、有難度的地方。

實際中，這代表著團隊需要進行可靠性測試。通常希望多帶帶測試某個組件，其他部分使用模擬組件，從而在一個半真實的世界中測試自己的組件，但更重要地是可以在模擬測試中注入故障（inject failures）。

這樣一來通過不斷地進行測試，可以找出組件不運作的地方。在每天實際進行的測試中，也許有百萬分之一、千萬分之一的幾率這些組件運行不了（比如，服務器有兩個副本宕機了；在準備與提交階段之間有什么東西出錯了；或者大半夜整個服務器宕掉了）。

所有這些都令促使需要在日常工作中構建恢復性測試，并一直運行這些測試，工作量巨大。

Q：谷歌現有的自動測試規則是怎么來的？

A：我不知道谷歌公司的相關規則是怎么演化出來的，我去的時候就已經有了。確實十分驚人，這個大規模分布式系統中的所有組件都用這些復雜的方法持續不斷地測試。

作為新人，我并不想寫出些沒經過足夠測試的蹩腳玩意兒。作為負責人，我特別想給團隊樹立一個壞榜樣。

下面是個具體案例，展示了一些這樣團隊的優點。大家在著名的論文中可能都讀到過（Google File System，BigTable，Megastore 等等），常見的谷歌基礎設施服務是各個團隊獨立運作的——通常是一個令人驚訝的小團隊。

他們不僅要編寫代碼，還要負責運營。等這些組件成熟了，他們不僅要向使用者提供相應服務，還得為他們提供客戶端文件庫，使得服務更加便捷。使用現有的客戶端文件庫，他們可以為客戶端測試模擬后臺服務，并注入各種失敗場景。比如：你可以使用 BigTable 生產程序庫，再加上一個模擬器，就會跟實際生產平臺的表現一樣。你想在寫入與 ack 階段注入失敗？直接做就成了！

我懷疑這些原則和實踐是來自「艱苦的磨練」，從那些你一直問「怎么避免停機」這樣的緊急情況中磨練出來的。

隨著時間過去，最終規則被完善，得到了一個堅挺的架構。

Dr. Spear 寫道：

「高速率公司擅長在系統里第一時間發現問題并找到問題。他們同樣擅長：（1）在問題擴散之前找到它（2）找出并解決發生問題的原因，讓問題不再發生。這樣一來，他們在如何管理解決實際工作問題系統方面構建了更深層次的知識，將前期難以避免的疏漏轉化為知識。」

GK：在我的研究中，最令人驚訝的集群式解決問題的例子有兩個：

A：豐田的 Andon 拉繩，負責在工作偏離已知模式時讓它停下。有記錄，一個典型的豐田工廠，平均一天需要拉下 Andon 拉繩3500次。

Alcoa 的 CEO，受人尊敬的 Paul O’Neill，為了降低工作場所事故發生，制定了相關政策：任何在工作場所發生的事故必須在24小時內通知他。誰需要負責報告？業務部門總經理。

Q：谷歌的遠程文化與那些支持集群行為（Swarming Behaviors）的文化類似嗎，比如豐田安燈拉繩與 AlcoaCEO 對工作場所事故的向他通知的要求？

A：完全一致，兩者都能引起我的共鳴。在 Ebay 和谷歌，都有事后剖析免責文化（blame-free PostMortems）。（GK：John Allspaw 又稱它為 blameless post-mortem。）

事后剖析免責是一條非常重要的規定，只要有一個客戶受停機影響，我們都會舉行一個事后剖析會。就像 John Allspaw 還有其他人廣泛描述的那樣，事后剖析的目標并不是為了追責，而是創造學習的機會和跨公司的廣泛交流。

我發現，如果公司文化中事后剖析不會引發什么后果會產生驚人的動力：工程師互相攀比，看誰捅出過更大的婁子。比如：「嗨，我們發現從沒測過的備份恢復程序」，或者「然后我們發現，我們沒有主動復制。」也許對很多工程師來說，這一幕十分熟悉：「我希望沒停過機，不過現在我們終于有機會修復那個已經被抱怨了好幾個月的破系統了！」

這將產生大規模的公司性學習，并且正如 Dr. Steven Spear 所描述的：這樣的做法使得我們在災難性后果發生之前可以不斷找到并解決問題。

我認為其有效原因在于，我們內心里都是工程師，都喜歡建立并改善系統，而讓問題暴露出來的環境造就了激動人心和令人滿意的工作環境。

問：事后剖析產生了什么結果？不能僅僅寫成文檔，然后丟進垃圾桶，對不對？

Q：你可能覺得難以置信，但是我相信最重要的部分就是組織事后剖析會本身。我們知道，DevOps 中最為重要的部分就是文化，能組織會議，即便沒有產出，都能對系統有所提高。

A：它會成為一種 kata——成為我們日常規定的一部分，證明我們的價值以及如何區分工作優先級。

當然，事后剖析之后，幾乎都是列出一大堆清單，寫著正常運轉和出故障的內容，然后你就有了一張待辦事項，需要安插到工作隊列中去（比如：backlog——所需功能列表；增強功能——改進文檔等。）

當你發現需要做新改進時，最終得在什么地方做些修改。有時候是文檔、流程、代碼、環境或者其他什么。

不過即便沒有這些，只是單純的記錄下事后剖析文檔也會有巨大的價值，你可以想象一下，在谷歌，什么都搜得到，所有谷歌人都能看到每一個事后剖析文檔。

將來在類似事故發生時，事后剖析文檔永遠是第一個會被讀到的。

有趣的是，事后剖析文檔還起到一個作用。谷歌有一個長期傳統，所有的新服務需要開發人員自行管理至少六個月。服務團隊在要求「畢業」時（也就是需要一個專門的 SRE 團隊，或者運營工程師來維護），他們基本上都會與 SRE 協商。他們請求 SRE 接管應用提交的相關職責。

（Gene：點擊查看視頻，Tom Limoncelli 將其稱為「切換到啟動前檢驗狀態」的流程，SRE 會進行審查文檔、部署機制、監控概況等等工作。視頻非常棒！）
SRE 往往首先會檢查事后剖析文檔，這一步占很大比重，決定他們是否能讓一個應用「畢業」。

Q：你在谷歌有看到過類似 Paul O’neill 和他的團隊在 Alcoa 那樣的要求嗎？是否有通知/升級門檻怎樣不斷減少的例子？

A：GK：Dr. Spear 描述了 Paul O’Neill 在美鋁公司如何帶領團隊減少制鋁廠車間的受傷情況的（太驚人了，里面都是高熱、高壓與腐蝕性的化學制劑），將事故率從每年2%降低到0.07%，使公司成為行業內最安全的公司。令人驚訝的是，在車間事故率降低到一定數值時，O’Neill 讓員工在可能有差錯發生時通知他。

確實有。當然，在工作場地發生事故相當于我們影響到用戶的停機事件。相信我，在出現影響客戶的大故障時，他們會收到通知。在事故發生時，會發生兩件事情：

你需要動員一切恢復服務所需的人員，他們要持續工作，直接問題解決（當然，這是標準流程）。

我們也會舉行管理層的每周事故會議（在我的 App Engine 團隊里，需要出席的有工程技術部主管——共兩人，我是其中之一；我們的老板、我們團隊的領導、還有支持團隊和產品經理）。我們回顧在事后剖析會中所學的東西，檢查下一步所需行動，并確認已經妥當的解決了問題。如果必要的話，決定我們是否需要做一個面向客戶的事后剖析或者發個博客。

有時候我們沒什么要說的。不過一旦情況處于控制之下，團隊總是希望同級審查時出現的問題更少，并且更希望提高。
比如一個「不會影響客戶」的問題，我們會將它稱為「影響團隊」的問題。

大多數人都體驗過「差點出事」（near misses），布置了六重保護措施，全都是為了防止用戶受失敗影響所設置，結果全掛了，就剩一個能用。

在我的團隊里（Google App Engine），我們可能每年會有一個大眾都知道的影響用戶的停機事件，不過想當然，每一個這樣的情況背后都有幾個「差點出事」。

這就是我們為什么會有災難性恢復（Disaster Recovery），Kripa Krishnan 曾在這里討論過。

盡管谷歌做得不錯，我們學到了很多（這就是為什么我們要有三個生產備份），這里亞馬遜做得要更好，他們的工作比其他人要提前五年。（Jason McHugh 是亞馬遜 S3 的架構師，現在去了 Facebook，他做了這個演講 QCon 2009，主題是亞馬遜的故障管理。）

Q：在美鋁公司，工作場地事故需要在24小時之內報告給 CEO。在谷歌是否有類似的向上升級（即問題升級到領導層）的時間線？

A：在 Google App Engine，我們有很小的團隊（全球100個工程師），里面只有兩級：做事的工程師和管理者。在發生了影響客戶的事故時，我們曾在午夜把大家叫醒。每一個這樣的事故，有十分之一會升級到公司領導層。

Q：你對Swarming如何發生怎么描述？

A：像豐田工廠，并非出現所有問題時都能確保人人到位解決問題。但在文化上，我們的確會優先考慮優先級為0的那些問題的可靠性和質量。

在很多方面都有這種情況，其中一些不算太明顯，比停機要微妙一些。

在你檢查打斷測試的代碼時，在修復之不會有其他工作，也不會發現還有打斷更多測試的問題急待解決。

與此相似，如果有人也出現了類似的問題需要幫助時，也會希望你放下一切提供幫助。為什么呢？這是我們安排優先度的方式——就像「黃金法則」。我們希望幫助每個人推動工作，從而也幫助到了所有人。

當然，在你需要幫助時他們也會這樣對你。

從系統的角度來看，我認為它就像棘齒或者過山車的中間齒輪——讓我們不會滑下去。

這不是流程中的正式規則，不過每個人都知道，如果有類似影響用戶的明顯不正常操作出現，我們會發出警報，發一些郵件等等。

信息通常是「嗨，大家好，我需要你們的幫助」，然后我們就去幫忙啦。

我認為它總是奏效的原因在于，即便沒有正式說明或列出規則，大家都知道我們的工作不只是「寫代碼」，而是「運行服務」。

甚至全球性的依賴（比如負載均衡器、全球基礎架構配置錯誤）都能在幾秒內修復，事故會在5到10分鐘內解決。

Dr. Spear 寫道：

高速率公司通過在全公司內部（不僅是發現者）傳播知識，增加新知識的習得率。他們不僅分享問題的結論，還分享發現問題的流程——學到了什么，怎么學到的。盡管在大一些的系統中，他們的競爭對手在發現問題后仍然讓問題留在發現的地方，與解決方案放在一起，但在高速率公司中，負責者會將問題與發現進行全公司的傳播。也就是說人們在開始工作時，會吸收公司里其他人的經驗。我們會看到乘數效應的幾個案例。

Q：問題發生時，知識如何傳播？局部的發現如何轉化為全球性質的進步？

A：其中一部分，盡管不是最大的那部分，是來自事后剖析會的文檔。有這樣的跡象：谷歌與其他公司一樣頻繁出現事故。在谷歌一旦有引人注目的停機事件，你可以肯定幾乎公司里每個人都會讀到事后剖析報告。

也許預防未來故障的最強大機制就是全谷歌共同擁有的單一代碼庫。不過更重要的是，由于可以搜索整個代碼庫，利用別人的經驗就很簡單。不管文件多正式多有一致性，更好的辦法就是看看實踐中人們的做法——「去看看代碼」。

但是，也有消極的一面。一般來說，使用服務的第一個人可能會使用隨機的配置，然后在公司里瘋狂傳播。突然間毫無理由，像「37」這樣的隨意設置傳的到處都是。

只要你讓知識變得容易傳播又容易獲得，它就會到處傳播，并很有可能出現一些最優設置。

Q：除了單一的源代碼庫和無責的事后剖析，還有什么其他的機制可以從局部學習轉化為全局改進嗎？知識傳播還有什么辦法？

A：在谷歌源代碼庫中，最棒的事情之一就是你什么都能找到。所有問題最好的回答就是「看看代碼」。

其次，還有只要搜索就能找到的優秀文檔。還有極好的內部小組。就像任何外部服務一樣，寫個「foo」就能列出一個叫做「foo-user」的郵件列表。你向列表中的人問個問題。聯絡到開發者當然很好，不過大部分情況下會是用戶給出回答。順帶一提，就像本行業大量成功的開源項目。

Dr. Spear 寫道：

高速率公司的管理者確認：常規工作的一部分就是發布產品和服務，以及持續改進產品與服務發布的流程。他們教人們如何持續改進自己的那部分工作，并為他們提供充足的時間與資源。這樣一來，公司在可靠性與高適應性方面都能夠自我改進。這是他們與失敗的競爭對手最根本的不同。高速率公司的管理者并不負責通過一系列指標來命令、控制、斥責、威脅或者評估別人，而是確保公司在以下方面有所提高：自診與自我改進、發現問題的技巧、解決問題、通過全公司傳播解決方案來提高效率。

GK：我也很喜歡 David Marquet 的名言（《Turn This Ship Around》的作者）：「真正的領導人的標志就是在他/她之下還有多少領導者。」這位潛艇前指揮官比歷史上任何潛艇艦長帶出過的領導者更多。

他工作的要點是：一些領導者解決了問題，但一旦他們離開，問題又重新出現了，這是因為他們沒能讓系統在離開自己的情況下繼續正常運轉。

Q：谷歌的領導層是怎么發展的？

A：谷歌已經實踐了你能在任何一家健康運作公司中能找到的幾乎所有辦法。我們有兩類職業道路：工程師道路與管理者道路。任何一個在職位上有「管理者」字樣的人主要負責「讓事情成為可能」，并鼓勵他人進行領導。

我將自己的職責視為創造每個人都很重要的小團隊。每個團隊都是一個交響樂團，與工廠截然相反——每個人都能獨奏，但是更重要的是，他們都能彼此合作。我們都有過那樣的糟糕體驗：團隊成員沖著彼此吼叫，或者誰也不聽對方的。

在谷歌，我認為領導者最強大的影響在于我們打造重要工程項目的文化愿景。大的文化規范之一，「每個人都寫很棒的測試；我們不想成為一個寫蹩腳測試的團隊。」同樣，有這樣的文化「我們只雇參與者」——對我在情感上也很重要。

在谷歌，在評估與改進過程中一些這樣的東西被寫進法典——聽起來很糟糕，因為那意味著，我們只管做好提升所需的那一份工作。但是另一方面，評估過程贊譽很高，幾乎公認是可觀的——人們獲得提升知識因為他們作出了相應的貢獻，并且很擅長他們所做的工作。我從未聽過誰升職是因為他們「抱對了大腿，拍對了馬屁」。

管理者和主管職位的主要標準就是領導力——也就是說，那個人是否作出了重大的影響，他的影響是否遠超你工作的團隊以及某個「只做自己事情的人」。

Google App Engine服務是在7年前成立的，在集群管理組中有著一群令人驚訝的工程師，他們認為「嗨，我們擁有這些創造可擴展系統的技術。是不是可以編一個，讓別人也能使用呢？」

「App Engine 創建工程師」的頭銜被授予給那些倍受內部員工尊重的人，比如 Facebook 的創建者。

Q：新任管理者如何做事？如果領導者必須培養其他領導人，新任管理者或者一線管理者如何了解工作減輕的風險？

A：在谷歌，你只會得到「你已經在做」的那份工作，這與其他大多數公司都不相同，在別的公司都是做「希望你能做的工作」。

也就是說，如果你想要成為首席工程師，那么就做首席工程師的工作。在谷歌，就像很多大公司一樣，有很多的培訓資源。

但在大多情況下，如何完成工作的文化規范影響太大，可能確保文化規范延續就成了首要趨勢。就像是一個自我選擇的過程，增強文化規范與技術實踐。

當然，這也跟公司高層的風格有關。谷歌是兩個怪咖工程師創建的公司，在高層風格的影響下，這種文化也在不斷增強。

如果你在一個命令與控制型的公司里，公司的領導者討厭別人，那么這種不良信息也會傳遞并在公司里強化。

再次重申，我從 Randy Shoup 那里學到的太多了，難以言喻。如果你對此有興趣，想要了解更多并用于公司實踐的話，不妨直接通過 LinkedIn 詢問 Randy，他目前從事咨詢工作。訪問 Randy 的 LinkIn 頁面以獲得更多聯系方式。

原文鏈接：Uncovering The DevOps Improvement Principles At Google (Randy Shoup Interview)

本文系 OneAPM 工程師編譯整理。OneAPM 是應用性能管理領域的新興領軍企業，能幫助企業用戶和開發者輕松實現：緩慢的程序代碼和 SQL 語句的實時抓取。想閱讀更多技術文章，請訪問 OneAPM 官方博客。