【編者按】本文是 Gene Kim 總結(jié)自對 Randy Shoup 兩個(gè)小時(shí)的采訪，主要關(guān)注谷歌 DevOps 的提升之道。本文系 OneAPM 聯(lián)合高效運(yùn)維編譯整理。
Randy Shoup 曾協(xié)助領(lǐng)導(dǎo) eBay 和 Google 的工程師團(tuán)隊(duì)，他是筆者見過少數(shù)能將「建造高效產(chǎn)出 DevOps 與世界級可靠性系統(tǒng)需要怎樣領(lǐng)導(dǎo)特質(zhì)」描述清楚的人之一。其兩個(gè)演講（2013 Flowcon 演講、2000s 早期他在轉(zhuǎn)化 eBay 架構(gòu)時(shí)驚人的工作）深受筆者喜愛。
本文由 Gene Kim 根據(jù)對 Randy Shoup 的采訪整理，深入討論和講解谷歌 DevOps 的提升之道，下面一起深入了解。本文系 OneAPM 聯(lián)合高效運(yùn)維編譯整理。
Dr. Spear的模型有如下四大能力：
能力1：在問題發(fā)生時(shí)馬上就能發(fā)現(xiàn)；
能力2：一旦發(fā)現(xiàn)問題立刻集群式解決（Swarming），并將此記錄下來儲(chǔ)備成新知識(shí)；
能力3：在整個(gè)公司范圍內(nèi)傳播新知；
能力4：以開發(fā)為主導(dǎo)。
這也是采訪 Randy Shoup 的基礎(chǔ)，此次采訪還揭示了一些在谷歌與 eBay
中未曾廣泛討論過的實(shí)踐案例。
（筆者從 Randy Shoup 那里學(xué)到了太多東西，難以言喻。如果想了解更多信息，并用于公司實(shí)踐的話，不妨通過 Randy LinkedIn 的個(gè)人主頁聯(lián)系他，他目前正從事咨詢工作）。
能力1：在問題發(fā)生時(shí)立刻就能發(fā)現(xiàn)
Dr. Spear 寫道：
高速率的公司會(huì)針對已有知識(shí)庫制定詳細(xì)規(guī)則和設(shè)計(jì)捕獲問題，并使用內(nèi)置測試以發(fā)現(xiàn)問題。
無論個(gè)體還是團(tuán)隊(duì)工作，無論是否有設(shè)備，高速率公司不愿意接受模棱兩可。他們提前對以下內(nèi)容進(jìn)行詳細(xì)說明：
（a）預(yù)期產(chǎn)出；（b）誰負(fù)責(zé)什么工作，順序如何；（c）產(chǎn)品、服務(wù)與信息如何從上一步的負(fù)責(zé)人手上遞交到下一步的負(fù)責(zé)人手中；（d）完成每一部分工作的方法。
GK（作者）：在 DevOps 領(lǐng)域，谷歌應(yīng)該是典范之一，特別是在自動(dòng)化測試領(lǐng)域。
Google SCM 團(tuán)隊(duì) Eran Messeri 在2013年的 GOTOcon Aarhus 大會(huì)的某環(huán)節(jié)上表示：「在成千上萬名工程師分享同一個(gè)持續(xù)構(gòu)建時(shí)，出現(xiàn)了什么問題？」（演講筆記可以查看這里）
他列出了一些值得注意的統(tǒng)計(jì)資料（截止到2013年），并介紹了他們是如何創(chuàng)建在能力范圍內(nèi)最迅速、最及時(shí)且成本最低的程序員反饋機(jī)制：
1.5萬程序員（包括開發(fā)與運(yùn)維）
- 4000個(gè)同時(shí)進(jìn)行的項(xiàng)目
- 在同一個(gè)庫里 check 所有的源代碼（數(shù)十億文件！）
- 5500次代碼提交 via 1.5萬程序員
- 自動(dòng)測試日運(yùn)行7500萬次
0.5%的工程師致力于開發(fā)工具
這里有一份2010年 Ashish Kumar 做的 QConSF PPT
，在這里你可以查看到更多關(guān)于 Google 開發(fā)團(tuán)隊(duì)所實(shí)現(xiàn)的驚人數(shù)字。
Q：谷歌可能是自動(dòng)化測試的典范了，大家都想更多地了解你在那里的工作經(jīng)驗(yàn)。
A：的確如此，谷歌做了大量的自動(dòng)化測試——超過我工作過的其他所有典范。「一切」都需要測試——不僅要測試 getter/setter 功能，還要測試一切可能出問題的地方
。
對所有人來說，設(shè)計(jì)測試通常是極具挑戰(zhàn)的。也不會(huì)有人花時(shí)間去寫測試來檢查自己認(rèn)為會(huì)正常運(yùn)作的功能，相反通常是去測試那些可能出錯(cuò)的、有難度的地方。
實(shí)際中，這代表著團(tuán)隊(duì)需要進(jìn)行可靠性測試。通常希望單獨(dú)測試某個(gè)組件，其他部分使用模擬組件，從而在一個(gè)半真實(shí)的世界中測試自己的組件，但更重要地是可以在模擬測試中注入故障（inject failures）。
這樣一來通過不斷地進(jìn)行測試，可以找出組件不運(yùn)作的地方。在每天實(shí)際進(jìn)行的測試中，也許有百萬分之一、千萬分之一的幾率這些組件運(yùn)行不了（比如，服務(wù)器有兩個(gè)副本宕機(jī)了；在準(zhǔn)備與提交階段之間有什么東西出錯(cuò)了；或者大半夜整個(gè)服務(wù)器宕掉了）。
所有這些都令促使需要在日常工作中構(gòu)建恢復(fù)性測試，并一直運(yùn)行這些測試，工作量巨大。
Q：谷歌現(xiàn)有的自動(dòng)測試規(guī)則是怎么來的？
A：我不知道谷歌公司的相關(guān)規(guī)則是怎么演化出來的，我去的時(shí)候就已經(jīng)有了。確實(shí)十分驚人，這個(gè)大規(guī)模分布式系統(tǒng)中的所有組件都用這些復(fù)雜的方法持續(xù)不斷地測試。
作為新人，我并不想寫出些沒經(jīng)過足夠測試的蹩腳玩意兒。作為負(fù)責(zé)人，我特別想給團(tuán)隊(duì)樹立一個(gè)壞榜樣。
下面是個(gè)具體案例，展示了一些這樣團(tuán)隊(duì)的優(yōu)點(diǎn)。大家在著名的論文中可能都讀到過（Google File System，BigTable，Megastore 等等），常見的谷歌基礎(chǔ)設(shè)施服務(wù)是各個(gè)團(tuán)隊(duì)獨(dú)立運(yùn)作的——通常是一個(gè)令人驚訝的小團(tuán)隊(duì)。
他們不僅要編寫代碼，還要負(fù)責(zé)運(yùn)營。等這些組件成熟了，他們不僅要向使用者提供相應(yīng)服務(wù)，還得為他們提供客戶端文件庫，使得服務(wù)更加便捷。使用現(xiàn)有的客戶端文件庫，他們可以為客戶端測試模擬后臺(tái)服務(wù)，并注入各種失敗場景。比如：你可以使用 BigTable 生產(chǎn)程序庫，再加上一個(gè)模擬器，就會(huì)跟實(shí)際生產(chǎn)平臺(tái)的表現(xiàn)一樣。你想在寫入與 ack 階段注入失敗？直接做就成了！
我懷疑這些原則和實(shí)踐是來自「艱苦的磨練」，從那些你一直問「怎么避免停機(jī)」這樣的緊急情況中磨練出來的。
隨著時(shí)間過去，最終規(guī)則被完善，得到了一個(gè)堅(jiān)挺的架構(gòu)。
能力2：一發(fā)現(xiàn)問題集群式解決，并記錄下來，成為新知識(shí)。
Dr. Spear 寫道：
「高速率公司擅長在系統(tǒng)里第一時(shí)間發(fā)現(xiàn)問題并找到問題。他們同樣擅長：（1）在問題擴(kuò)散之前找到它（2）找出并解決發(fā)生問題的原因，讓問題不再發(fā)生。這樣一來，他們在如何管理解決實(shí)際工作問題系統(tǒng)方面構(gòu)建了更深層次的知識(shí)，將前期難以避免的疏漏轉(zhuǎn)化為知識(shí)。」
GK：在我的研究中，最令人驚訝的集群式解決問題的例子有兩個(gè)：
A：豐田的 Andon 拉繩，負(fù)責(zé)在工作偏離已知模式時(shí)讓它停下。有記錄，一個(gè)典型的豐田工廠，平均一天需要拉下 Andon 拉繩3500次。
Alcoa 的 CEO，受人尊敬的 Paul O’Neill，為了降低工作場所事故發(fā)生，制定了相關(guān)政策：任何在工作場所發(fā)生的事故必須在24小時(shí)內(nèi)通知他。誰需要負(fù)責(zé)報(bào)告？業(yè)務(wù)部門總經(jīng)理。
Q：谷歌的遠(yuǎn)程文化與那些支持集群行為（Swarming Behaviors）的文化類似嗎，比如豐田安燈拉繩與 AlcoaCEO 對工作場所事故的向他通知的要求？
A：完全一致，兩者都能引起我的共鳴。在 Ebay 和谷歌，都有事后剖析免責(zé)文化（blame-free PostMortems）。（GK：John Allspaw 又稱它為 blameless post-mortem。）
事后剖析免責(zé)是一條非常重要的規(guī)定，只要有一個(gè)客戶受停機(jī)影響，我們都會(huì)舉行一個(gè)事后剖析會(huì)。就像 John Allspaw 還有其他人廣泛描述的那樣，事后剖析的目標(biāo)并不是為了追責(zé)，而是創(chuàng)造學(xué)習(xí)的機(jī)會(huì)和跨公司的廣泛交流。
我發(fā)現(xiàn)，如果公司文化中事后剖析不會(huì)引發(fā)什么后果會(huì)產(chǎn)生驚人的動(dòng)力：工程師互相攀比，看誰捅出過更大的婁子。比如：「嗨，我們發(fā)現(xiàn)從沒測過的備份恢復(fù)程序」，或者「然后我們發(fā)現(xiàn)，我們沒有主動(dòng)復(fù)制。」也許對很多工程師來說，這一幕十分熟悉：「我希望沒停過機(jī)，不過現(xiàn)在我們終于有機(jī)會(huì)修復(fù)那個(gè)已經(jīng)被抱怨了好幾個(gè)月的破系統(tǒng)了！」
這將產(chǎn)生大規(guī)模的公司性學(xué)習(xí)，并且正如 Dr. Steven Spear
所描述的：這樣的做法使得我們在災(zāi)難性后果發(fā)生之前可以不斷找到并解決問題。
我認(rèn)為其有效原因在于，我們內(nèi)心里都是工程師，都喜歡建立并改善系統(tǒng)，而讓問題暴露出來的環(huán)境造就了激動(dòng)人心和令人滿意的工作環(huán)境。
問：事后剖析產(chǎn)生了什么結(jié)果？不能僅僅寫成文檔，然后丟進(jìn)垃圾桶，對不對？
Q：你可能覺得難以置信，但是我相信最重要的部分就是組織事后剖析會(huì)本身。我們知道，DevOps 中最為重要的部分就是文化，能組織會(huì)議，即便沒有產(chǎn)出，都能對系統(tǒng)有所提高。
A：它會(huì)成為一種 kata——成為我們?nèi)粘Ｒ?guī)定的一部分，證明我們的價(jià)值以及如何區(qū)分工作優(yōu)先級。
當(dāng)然，事后剖析之后，幾乎都是列出一大堆清單，寫著正常運(yùn)轉(zhuǎn)和出故障的內(nèi)容，然后你就有了一張待辦事項(xiàng)，需要安插到工作隊(duì)列中去（比如：backlog——所需功能列表；增強(qiáng)功能——改進(jìn)文檔等。）
當(dāng)你發(fā)現(xiàn)需要做新改進(jìn)時(shí)，最終得在什么地方做些修改。有時(shí)候是文檔、流程、代碼、環(huán)境或者其他什么。
不過即便沒有這些，只是單純的記錄下事后剖析文檔也會(huì)有巨大的價(jià)值，你可以想象一下，在谷歌，什么都搜得到，所有谷歌人都能看到每一個(gè)事后剖析文檔。
將來在類似事故發(fā)生時(shí)，事后剖析文檔永遠(yuǎn)是第一個(gè)會(huì)被讀到的。
有趣的是，事后剖析文檔還起到一個(gè)作用。谷歌有一個(gè)長期傳統(tǒng)，所有的新服務(wù)需要開發(fā)人員自行管理至少六個(gè)月。服務(wù)團(tuán)隊(duì)在要求「畢業(yè)」時(shí)（也就是需要一個(gè)專門的 SRE 團(tuán)隊(duì)，或者運(yùn)營工程師來維護(hù)），他們基本上都會(huì)與
SRE 協(xié)商。他們請求 SRE 接管應(yīng)用提交的相關(guān)職責(zé)。
（Gene：點(diǎn)擊查看視頻，Tom Limoncelli 將其稱為「切換到啟動(dòng)前檢驗(yàn)狀態(tài)」
的流程，SRE 會(huì)進(jìn)行審查文檔、部署機(jī)制、監(jiān)控概況等等工作。視頻非常棒！）
SRE 往往首先會(huì)檢查事后剖析文檔，這一步占很大比重，決定他們是否能讓一個(gè)應(yīng)用「畢業(yè)」。
Q：你在谷歌有看到過類似 Paul O’neill 和他的團(tuán)隊(duì)在 Alcoa 那樣的要求嗎？是否有通知/升級門檻怎樣不斷減少的例子？
A：GK：Dr. Spear 描述了 Paul O’Neill 在美鋁公司如何帶領(lǐng)團(tuán)隊(duì)減少制鋁廠車間的受傷情況的（太驚人了，里面都是高熱、高壓與腐蝕性的化學(xué)制劑），將事故率從每年2%降低到0.07%，使公司成為行業(yè)內(nèi)最安全的公司。令人驚訝的是，在車間事故率降低到一定數(shù)值時(shí)，O’Neill 讓員工在可能有差錯(cuò)發(fā)生時(shí)通知他。
確實(shí)有。當(dāng)然，在工作場地發(fā)生事故相當(dāng)于我們影響到用戶的停機(jī)事件。相信我，在出現(xiàn)影響客戶的大故障時(shí)，他們會(huì)收到通知。在事故發(fā)生時(shí)，會(huì)發(fā)生兩件事情：
你需要?jiǎng)訂T一切恢復(fù)服務(wù)所需的人員，他們要持續(xù)工作，直接問題解決（當(dāng)然，這是標(biāo)準(zhǔn)流程）。
我們也會(huì)舉行管理層的每周事故會(huì)議（在我的 App Engine 團(tuán)隊(duì)里，需要出席的有工程技術(shù)部主管——共兩人，我是其中之一；我們的老板、我們團(tuán)隊(duì)的領(lǐng)導(dǎo)、還有支持團(tuán)隊(duì)和產(chǎn)品經(jīng)理）。我們回顧在事后剖析會(huì)中所學(xué)的東西，檢查下一步所需行動(dòng)，并確認(rèn)已經(jīng)妥當(dāng)?shù)慕鉀Q了問題。如果必要的話，決定我們是否需要做一個(gè)面向客戶的事后剖析或者發(fā)個(gè)博客。
有時(shí)候我們沒什么要說的。不過一旦情況處于控制之下，團(tuán)隊(duì)總是希望同級審查時(shí)出現(xiàn)的問題更少，并且更希望提高。
比如一個(gè)「不會(huì)影響客戶」的問題，我們會(huì)將它稱為**「影響團(tuán)隊(duì)」的問題
**。
大多數(shù)人都體驗(yàn)過「差點(diǎn)出事」（near misses），布置了六重保護(hù)措施，全都是為了防止用戶受失敗影響所設(shè)置，結(jié)果全掛了，就剩一個(gè)能用。
在我的團(tuán)隊(duì)里（Google App Engine），我們可能每年會(huì)有一個(gè)大眾都知道的影響用戶的停機(jī)事件，不過想當(dāng)然，每一個(gè)這樣的情況背后都有幾個(gè)「差點(diǎn)出事」。
這就是我們?yōu)槭裁磿?huì)有災(zāi)難性恢復(fù)（Disaster Recovery），Kripa Krishnan 曾在這里討論過。
盡管谷歌做得不錯(cuò)，我們學(xué)到了很多（這就是為什么我們要有三個(gè)生產(chǎn)備份），這里亞馬遜做得要更好，他們的工作比其他人要提前五年。（Jason McHugh 是亞馬遜 S3 的架構(gòu)師，現(xiàn)在去了 Facebook，他做了這個(gè)演講
QCon 2009，主題是亞馬遜的故障管理。）
Q：在美鋁公司，工作場地事故需要在24小時(shí)之內(nèi)報(bào)告給 CEO。在谷歌是否有類似的向上升級（即問題升級到領(lǐng)導(dǎo)層）的時(shí)間線？
A：在 Google App Engine，我們有很小的團(tuán)隊(duì)（全球100個(gè)工程師），里面只有兩級：做事的工程師和管理者。在發(fā)生了影響客戶的事故時(shí)，我們曾在午夜把大家叫醒。每一個(gè)這樣的事故，有十分之一會(huì)升級到公司領(lǐng)導(dǎo)層。
Q：你對Swarming如何發(fā)生怎么描述？
A：像豐田工廠，并非出現(xiàn)所有問題時(shí)都能確保人人到位解決問題。但在文化上，我們的確會(huì)優(yōu)先考慮優(yōu)先級為0的那些問題的可靠性和質(zhì)量。
在很多方面都有這種情況，其中一些不算太明顯，比停機(jī)要微妙一些。
在你檢查打斷測試的代碼時(shí)，在修復(fù)之不會(huì)有其他工作，也不會(huì)發(fā)現(xiàn)還有打斷更多測試的問題急待解決。
與此相似，如果有人也出現(xiàn)了類似的問題需要幫助時(shí)，也會(huì)希望你放下一切提供幫助。為什么呢？這是我們安排優(yōu)先度的方式——就像「黃金法則」。我們希望幫助每個(gè)人推動(dòng)工作，從而也幫助到了所有人。
當(dāng)然，在你需要幫助時(shí)他們也會(huì)這樣對你。
從系統(tǒng)的角度來看，我認(rèn)為它就像棘齒或者過山車的中間齒輪——讓我們不會(huì)滑下去。
這不是流程中的正式規(guī)則，不過每個(gè)人都知道，如果有類似影響用戶的明顯不正常操作出現(xiàn)，我們會(huì)發(fā)出警報(bào)，發(fā)一些郵件等等。
信息通常是「嗨，大家好，我需要你們的幫助」，然后我們就去幫忙啦。
我認(rèn)為它總是奏效的原因在于，即便沒有正式說明或列出規(guī)則，大家都知道我們的工作不只是「寫代碼」，而是「運(yùn)行服務(wù)」。
甚至全球性的依賴（比如負(fù)載均衡器、全球基礎(chǔ)架構(gòu)配置錯(cuò)誤）都能在幾秒內(nèi)修復(fù)，事故會(huì)在5到10分鐘內(nèi)解決。
能力3：在整個(gè)公司里傳播新知識(shí)。
Dr. Spear 寫道：
高速率公司通過在全公司內(nèi)部（不僅是發(fā)現(xiàn)者）傳播知識(shí)，增加新知識(shí)的習(xí)得率。他們不僅分享問題的結(jié)論，還分享發(fā)現(xiàn)問題的流程——學(xué)到了什么，怎么學(xué)到的。盡管在大一些的系統(tǒng)中，他們的競爭對手在發(fā)現(xiàn)問題后仍然讓問題留在發(fā)現(xiàn)的地方，與解決方案放在一起，但在高速率公司中，負(fù)責(zé)者會(huì)將問題與發(fā)現(xiàn)進(jìn)行全公司的傳播。也就是說人們在開始工作時(shí)，會(huì)吸收公司里其他人的經(jīng)驗(yàn)。我們會(huì)看到乘數(shù)效應(yīng)的幾個(gè)案例。
Q：問題發(fā)生時(shí)，知識(shí)如何傳播？局部的發(fā)現(xiàn)如何轉(zhuǎn)化為全球性質(zhì)的進(jìn)步？
A：其中一部分，盡管不是最大的那部分，是來自事后剖析會(huì)的文檔。有這樣的跡象：谷歌與其他公司一樣頻繁出現(xiàn)事故。在谷歌一旦有引人注目的停機(jī)事件，你可以肯定幾乎公司里每個(gè)人都會(huì)讀到事后剖析報(bào)告。
也許預(yù)防未來故障的最強(qiáng)大機(jī)制就是全谷歌共同擁有的單一代碼庫。不過更重要的是，由于可以搜索整個(gè)代碼庫，利用別人的經(jīng)驗(yàn)就很簡單。不管文件多正式多有一致性，更好的辦法就是看看實(shí)踐中人們的做法——「去看看代碼」。
但是，也有消極的一面。一般來說，使用服務(wù)的第一個(gè)人可能會(huì)使用隨機(jī)的配置，然后在公司里瘋狂傳播。突然間毫無理由，像「37」這樣的隨意設(shè)置傳的到處都是。
只要你讓知識(shí)變得容易傳播又容易獲得，它就會(huì)到處傳播，并很有可能出現(xiàn)一些最優(yōu)設(shè)置。
Q：除了單一的源代碼庫和無責(zé)的事后剖析，還有什么其他的機(jī)制可以從局部學(xué)習(xí)轉(zhuǎn)化為全局改進(jìn)嗎？知識(shí)傳播還有什么辦法？
A：在谷歌源代碼庫中，最棒的事情之一就是你什么都能找到。所有問題最好的回答就是「看看代碼」。
其次，還有只要搜索就能找到的優(yōu)秀文檔。還有極好的內(nèi)部小組。就像任何外部服務(wù)一樣，寫個(gè)「foo」就能列出一個(gè)叫做「foo-user」的郵件列表。你向列表中的人問個(gè)問題。聯(lián)絡(luò)到開發(fā)者當(dāng)然很好，不過大部分情況下會(huì)是用戶給出回答。順帶一提，就像本行業(yè)大量成功的開源項(xiàng)目。
能力4：以開發(fā)為主導(dǎo)。
Dr. Spear 寫道：
高速率公司的管理者確認(rèn)：常規(guī)工作的一部分就是發(fā)布產(chǎn)品和服務(wù)，以及持續(xù)改進(jìn)產(chǎn)品與服務(wù)發(fā)布的流程。他們教人們?nèi)绾纬掷m(xù)改進(jìn)自己的那部分工作，并為他們提供充足的時(shí)間與資源。這樣一來，公司在可靠性與高適應(yīng)性方面都能夠自我改進(jìn)。這是他們與失敗的競爭對手最根本的不同。高速率公司的管理者并不負(fù)責(zé)通過一系列指標(biāo)來命令、控制、斥責(zé)、威脅或者評估別人，而是確保公司在以下方面有所提高：自診與自我改進(jìn)、發(fā)現(xiàn)問題的技巧、解決問題、通過全公司傳播解決方案來提高效率。
GK：我也很喜歡 David Marquet 的名言（《Turn This Ship Around
》的作者）：「真正的領(lǐng)導(dǎo)人的標(biāo)志就是在他/她之下還有多少領(lǐng)導(dǎo)者。」這位潛艇前指揮官比歷史上任何潛艇艦長帶出過的領(lǐng)導(dǎo)者更多。
他工作的要點(diǎn)是：一些領(lǐng)導(dǎo)者解決了問題，但一旦他們離開，問題又重新出現(xiàn)了，這是因?yàn)樗麄儧]能讓系統(tǒng)在離開自己的情況下繼續(xù)正常運(yùn)轉(zhuǎn)。
Q：谷歌的領(lǐng)導(dǎo)層是怎么發(fā)展的？
A：谷歌已經(jīng)實(shí)踐了你能在任何一家健康運(yùn)作公司中能找到的幾乎所有辦法。我們有兩類職業(yè)道路：工程師道路與管理者道路。任何一個(gè)在職位上有「管理者」字樣的人主要負(fù)責(zé)「讓事情成為可能」，并鼓勵(lì)他人進(jìn)行領(lǐng)導(dǎo)。
我將自己的職責(zé)視為創(chuàng)造每個(gè)人都很重要的小團(tuán)隊(duì)。每個(gè)團(tuán)隊(duì)都是一個(gè)交響樂團(tuán)，與工廠截然相反——每個(gè)人都能獨(dú)奏，但是更重要的是，他們都能彼此合作。我們都有過那樣的糟糕體驗(yàn)：團(tuán)隊(duì)成員沖著彼此吼叫，或者誰也不聽對方的。
在谷歌，我認(rèn)為領(lǐng)導(dǎo)者最強(qiáng)大的影響在于我們打造重要工程項(xiàng)目的文化愿景。大的文化規(guī)范之一，「每個(gè)人都寫很棒的測試；我們不想成為一個(gè)寫蹩腳測試的團(tuán)隊(duì)。」同樣，有這樣的文化「我們只雇參與者」——對我在情感上也很重要。
在谷歌，在評估與改進(jìn)過程中一些這樣的東西被寫進(jìn)法典——聽起來很糟糕，因?yàn)槟且馕吨覀冎还茏龊锰嵘璧哪且环莨ぷ鳌５橇硪环矫妫u估過程贊譽(yù)很高，幾乎公認(rèn)是可觀的——人們獲得提升知識(shí)因?yàn)樗麄冏鞒隽讼鄳?yīng)的貢獻(xiàn)，并且很擅長他們所做的工作。我從未聽過誰升職是因?yàn)樗麄儭副α舜笸龋膶α笋R屁」。
管理者和主管職位的主要標(biāo)準(zhǔn)就是領(lǐng)導(dǎo)力——也就是說，那個(gè)人是否作出了重大的影響，他的影響是否遠(yuǎn)超你工作的團(tuán)隊(duì)以及某個(gè)「只做自己事情的人」。
Google App Engine服務(wù)是在7年前成立的，在集群管理組中有著一群令人驚訝的工程師，他們認(rèn)為「嗨，我們擁有這些創(chuàng)造可擴(kuò)展系統(tǒng)的技術(shù)。是不是可以編一個(gè)，讓別人也能使用呢？」
「App Engine 創(chuàng)建工程師」的頭銜被授予給那些倍受內(nèi)部員工尊重的人，比如 Facebook 的創(chuàng)建者。
Q：新任管理者如何做事？如果領(lǐng)導(dǎo)者必須培養(yǎng)其他領(lǐng)導(dǎo)人，新任管理者或者一線管理者如何了解工作減輕的風(fēng)險(xiǎn)？
A：在谷歌，你只會(huì)得到「你已經(jīng)在做」的那份工作，這與其他大多數(shù)公司都不相同，在別的公司都是做「希望你能做的工作」。
也就是說，如果你想要成為首席工程師，那么就做首席工程師的工作。在谷歌，就像很多大公司一樣，有很多的培訓(xùn)資源。
但在大多情況下，如何完成工作的文化規(guī)范影響太大，可能確保文化規(guī)范延續(xù)就成了首要趨勢。就像是一個(gè)自我選擇的過程，增強(qiáng)文化規(guī)范與技術(shù)實(shí)踐。
當(dāng)然，這也跟公司高層的風(fēng)格有關(guān)。谷歌是兩個(gè)怪咖工程師創(chuàng)建的公司，在高層風(fēng)格的影響下，這種文化也在不斷增強(qiáng)。
如果你在一個(gè)命令與控制型的公司里，公司的領(lǐng)導(dǎo)者討厭別人，那么這種不良信息也會(huì)傳遞并在公司里強(qiáng)化。
結(jié)論
再次重申，我從 Randy Shoup 那里學(xué)到的太多了，難以言喻。如果你對此有興趣，想要了解更多并用于公司實(shí)踐的話，不妨直接通過 LinkedIn 詢問
Randy，他目前從事咨詢工作。訪問 Randy 的 LinkIn 頁面以獲得更多聯(lián)系方式。
原文鏈接：Uncovering The DevOps Improvement Principles At Google (Randy Shoup Interview)
本文系 OneAPM 工程師編譯整理。OneAPM 是應(yīng)用性能管理
領(lǐng)域的新興領(lǐng)軍企業(yè)，能幫助企業(yè)用戶和開發(fā)者輕松實(shí)現(xiàn)：緩慢的程序代碼和 SQL 語句的實(shí)時(shí)抓取。想閱讀更多技術(shù)文章，請?jiān)L問 OneAPM 官方博客
。
