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

前言

Randy Shoup 曾協助領導 eBay 和 Google 的工程師團隊，他是少數能將「建造高效產出 DevOps 與世界級可靠性系統需要怎樣領導特質」描述清楚的人之一：

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

• 能力1：在問題發生時馬上就能發現；
• 能力2：一旦發現問題立刻叢集式解決（Swarming），並將此記錄下來儲備成新知識；
• 能力3：在整個公司範圍內傳播新知；
• 能力4：以開發為主導。

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

本文主要介紹其中的能力1和能力2，關於其他兩大能力，請詳見後續文章。

能力1：在問題發生時立刻就能發現

Dr. Spear 寫道：

高效率公司會針對已有知識庫，制定詳細規則並設計捕獲問題的方法，使用內建測試以發現問題。

無論個體還是團隊工作，無論是否有裝置，高效率公司不願意接受模稜兩可。他們提前對以下內容進行詳細說明：

• 預期產出；
• 誰負責什麼工作，順序如何；
• 產品、服務與資訊如何從上一步的負責人手上，遞交到下一步的負責人手中；
• 完成每一部分工作的方法。

在 DevOps 領域，特別是在自動化測試領域，Google 應該是典範之一。我們看看Google 面臨的挑戰（資料截止2013年）：

• 1.5萬程式設計師（包括開發與運維）；
• 4000個同時進行的專案；
• 在同一個庫裡 check 所有的原始碼（數十億檔案！）；
• 5500次程式碼提交 via 1.5萬程式設計師；
• 自動測試每天執行7500萬次；
• 0.5%的工程師致力於開發工具。

是的，你沒看錯，整個Google 只有一個程式碼倉庫。

以下為本次訪談的精彩互動。請大家欣賞。

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

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

對所有人來說，設計測試通常是極具挑戰的。

一般不會有人花時間去寫測試來檢查自己認為會正常運作的功能，頂多去測試自己認為那些可能出錯的、有難度的地方。

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

這樣一來通過不斷地進行測試，可以找出元件不運作的地方。在每天實際進行的測試中，也許有百萬分之一、千萬分之一的機率這些元件執行不了：

比如，伺服器有兩個副本宕機了；在準備與提交階段之間有什麼東西出錯了；或者大半夜整個伺服器宕掉了。

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

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

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

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

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

1. 他們不僅要編寫程式碼，還要負責運營。
2. 等這些元件成熟了，他們不僅要向使用者提供相應服務，還得為他們提供客戶端檔案庫，使得服務更加便捷。使用現有的客戶端檔案庫，他們可以為客戶端測試模擬後臺服務，並注入各種失敗場景，比如：
   

   你可以使用 BigTable 生產程式庫，再加上一個模擬器，就會跟實際生產平臺的表現一樣。你想在寫入和ACK 階段注入失敗場景？直接做就成了！

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

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

能力2：一發現問題叢集式解決，並記錄下來，成為新知識。

Dr. Spear 寫道：高效率公司擅長在系統裡第一時間發現問題並找到問題。他們同樣擅長：

1. 在問題擴散之前找到它；
2. 找出並解決發生問題的原因，讓問題不再發生。

這樣一來，他們在如何管理解決實際工作問題系統方面，構建了更深層次的知識，將前期難以避免的疏漏轉化為知識。

在GK（本文原作者）的研究中，最令人驚訝的叢集式解決問題的例子有兩個：

1. 豐田的 Andon 拉繩，負責在工作偏離已知模式時讓它停下。有記錄表明，一個典型的豐田工廠，平均一天需要拉下 Andon 拉繩3500 次。
2. Alcoa CEO 為了降低工作場所事故發生，制定了相關政策：任何在工作場所發生的事故必須在24小時內通知他。誰需要負責報告？業務部門總經理。

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

完全一致，兩者都能引起我的共鳴。

在 Ebay 和谷歌，都有事後剖析免責文化（blame-free PostMortems，或稱 blameless post-mortem）。

事後剖析免責是一條非常重要的規定，只要有一個客戶受停機影響，我們都會舉行一個事後剖析會議。

就像 John Allspaw 和其它人員廣泛描述的那樣，事後剖析的目標並不是為了追責，而是創造學習的機會和跨公司的廣泛交流。

我發現，如果公司文化中事後剖析不會引發什麼責任性後果，那麼會產生驚人的動力，工程師互相“攀比”，看誰捅出過更大的婁子。比如：

「嗨，我們發現從沒測過的備份恢復程式」，或者「然後我們發現，我們沒有主動複製。」

也許對很多工程師來說，這一幕十分熟悉：「我希望沒停過機，不過現在我們終於有機會修復那個已經被抱怨了好幾個月的破系統了！」

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

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

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

你可能覺得難以置信，但是我相信最重要的部分就是組織事後剖析會議本身。

我們知道，DevOps 中最為重要的部分就是文化，能組織會議，即便沒有產出，都能對組織有系統性的提高。

它會成為我們日常規定的一部分，並證明我們的價值以及如何區分工作優先順序。

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

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

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

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

有趣的是，事後剖析文件還起到一個作用。谷歌有一個長期傳統，所有新服務需要開發人員自行管理至少六個月。

服務團隊在要求「畢業」時（也就是需要一個專門的 SRE 團隊，或者運營工程師來維護），他們基本上都會與 SRE 協商。他們請求 SRE 接管應用提交的相關職責（關於 Google SRE，可以參見高效運維微信公眾號之前的文章—編者注）。

SRE 會進行審查文件、部署機制、監控概況等等工作。

當然，SRE 往往首先會檢查事後剖析文件，這一步佔很大比重，決定他們是否能讓一個應用「畢業」。

Q：你在谷歌有看到過類似 Alcoa CEO 那樣的要求嗎？是否有通過改進措施不斷減少問題的例子？

Dr. Spear 描述了 Paul O’Neill（Alcoa CEO） 在美鋁公司，如何帶領團隊減少制鋁廠車間的受傷情況的（太驚人了，裡面都是高熱、高壓與腐蝕性的化學制劑），將事故率從每年2%降低到0.07%，使公司成為行業內最安全的公司。

令人驚訝的是，在車間事故率降低到一定數值時，O’Neill 讓員工在可能有差錯發生時通知他。

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

1. 你需要動員一切恢復服務所需的人員，他們要持續工作，直到問題解決（當然，這是標準流程）。
2. 我們也會舉行管理層的每週事故會議（在我的 App Engine 團隊裡，需要出席的有工程技術部主管——共兩人，我是其中之一；我們的老闆、我們團隊的領導、還有支援團隊和產品經理）。我們回顧在事後剖析會中所學的東西，檢查下一步所需行動，並確認已經妥當的解決了問題。如果必要的話，決定我們是否需要做一個面向客戶的事後剖析或者發個部落格。

有時候我們沒什麼要說的。不過一旦情況處於控制之下，團隊總是希望同級審查時出現的問題更少，並且更希望提高。

比如一個「不會影響客戶」的問題，我們會將它稱為「影響團隊」的問題。

大多數人都體驗過「差點出事」（near misses）的情況吧？佈置了六重保護措施，全都是為了防止使用者受失敗影響所設定，結果全掛了，幸好還剩一個能用。

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

這就是我們為什麼會有災難性恢復（Disaster Recovery）。

儘管谷歌做得不錯，我們學到了很多（這就是為什麼我們要有三個生產備份），我們認為亞馬遜做得要更好，他們的工作比其他人要提前五年。

Q：在美鋁公司，工作場地事故需要在24小時之內報告給 CEO。在谷歌是否有類似的垂直升級機制？

在 Google App Engine，我們有很小的團隊（全球100個工程師），裡面只有兩級：做事的工程師和管理者。

在發生了影響客戶的事故時，我們也曾在午夜把大家叫醒。每一個這樣的事故，有十分之一會升級到公司領導層。

Q：你對Swarming（叢集式解決問題的行為）如何發生怎麼描述？

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

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

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

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

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

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

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

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

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

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

關於其他兩大能力，我們將在下一篇繼續和大家分享，敬請期待。

原文出處：http://www.devops-master.com/?id=8