【編者按】本文是 Gene Kim 總結(jié)自對(duì) 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 與世界級(jí)可靠性系統(tǒng)需要怎樣領(lǐng)導(dǎo)特質(zhì)」描述清楚的人之一篡九。其兩個(gè)演講（2013 Flowcon 演講堤撵、2000s 早期他在轉(zhuǎn)化 eBay 架構(gòu)時(shí)驚人的工作）深受筆者喜愛。
本文由 Gene Kim 根據(jù)對(duì) 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ì)針對(duì)已有知識(shí)庫制定詳細(xì)規(guī)則和設(shè)計(jì)捕獲問題艇搀，并使用內(nèi)置測(cè)試以發(fā)現(xiàn)問題。
無論個(gè)體還是團(tuán)隊(duì)工作求晶，無論是否有設(shè)備焰雕，高速率公司不愿意接受模棱兩可。他們提前對(duì)以下內(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)化測(cè)試領(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)測(cè)試日運(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)化測(cè)試的典范了绽快，大家都想更多地了解你在那里的工作經(jīng)驗(yàn)芥丧。
A：的確如此，谷歌做了大量的自動(dòng)化測(cè)試——超過我工作過的其他所有典范坊罢。「一切」都需要測(cè)試——不僅要測(cè)試 getter/setter 功能娄柳，還要測(cè)試一切可能出問題的地方
。
對(duì)所有人來說艘绍，設(shè)計(jì)測(cè)試通常是極具挑戰(zhàn)的。也不會(huì)有人花時(shí)間去寫測(cè)試來檢查自己認(rèn)為會(huì)正常運(yùn)作的功能秫筏，相反通常是去測(cè)試那些可能出錯(cuò)的诱鞠、有難度的地方。
實(shí)際中这敬，這代表著團(tuán)隊(duì)需要進(jìn)行可靠性測(cè)試航夺。通常希望單獨(dú)測(cè)試某個(gè)組件，其他部分使用模擬組件崔涂，從而在一個(gè)半真實(shí)的世界中測(cè)試自己的組件阳掐，但更重要地是可以在模擬測(cè)試中注入故障（inject failures）。
這樣一來通過不斷地進(jìn)行測(cè)試冷蚂，可以找出組件不運(yùn)作的地方缭保。在每天實(shí)際進(jìn)行的測(cè)試中，也許有百萬分之一蝙茶、千萬分之一的幾率這些組件運(yùn)行不了（比如艺骂，服務(wù)器有兩個(gè)副本宕機(jī)了；在準(zhǔn)備與提交階段之間有什么東西出錯(cuò)了隆夯；或者大半夜整個(gè)服務(wù)器宕掉了）钳恕。
所有這些都令促使需要在日常工作中構(gòu)建恢復(fù)性測(cè)試，并一直運(yùn)行這些測(cè)試蹄衷，工作量巨大忧额。
Q：谷歌現(xiàn)有的自動(dòng)測(cè)試規(guī)則是怎么來的？
A：我不知道谷歌公司的相關(guān)規(guī)則是怎么演化出來的愧口，我去的時(shí)候就已經(jīng)有了睦番。確實(shí)十分驚人，這個(gè)大規(guī)模分布式系統(tǒng)中的所有組件都用這些復(fù)雜的方法持續(xù)不斷地測(cè)試调卑。
作為新人抡砂，我并不想寫出些沒經(jīng)過足夠測(cè)試的蹩腳玩意兒。作為負(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)有的客戶端文件庫夹姥，他們可以為客戶端測(cè)試模擬后臺(tái)服務(wù)，并注入各種失敗場(chǎng)景辙诞。比如：你可以使用 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ā)生。這樣一來仔涩，他們?cè)谌绾喂芾斫鉀Q實(shí)際工作問題系統(tǒng)方面構(gòu)建了更深層次的知識(shí)忍坷，將前期難以避免的疏漏轉(zhuǎn)化為知識(shí)。」
GK：在我的研究中熔脂，最令人驚訝的集群式解決問題的例子有兩個(gè)：
A：豐田的 Andon 拉繩佩研，負(fù)責(zé)在工作偏離已知模式時(shí)讓它停下。有記錄霞揉，一個(gè)典型的豐田工廠旬薯，平均一天需要拉下 Andon 拉繩3500次。
Alcoa 的 CEO适秩，受人尊敬的 Paul O’Neill绊序，為了降低工作場(chǎng)所事故發(fā)生硕舆，制定了相關(guān)政策：任何在工作場(chǎng)所發(fā)生的事故必須在24小時(shí)內(nèi)通知他。誰需要負(fù)責(zé)報(bào)告骤公？業(yè)務(wù)部門總經(jīng)理抚官。
Q：谷歌的遠(yuǎn)程文化與那些支持集群行為（Swarming Behaviors）的文化類似嗎，比如豐田安燈拉繩與 AlcoaCEO 對(duì)工作場(chǎng)所事故的向他通知的要求阶捆？
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)從沒測(cè)過的備份恢復(fù)程序」，或者「然后我們發(fā)現(xiàn)靠粪，我們沒有主動(dòng)復(fù)制蜡吧。」也許對(duì)很多工程師來說占键，這一幕十分熟悉：「我希望沒停過機(jī)昔善，不過現(xiàn)在我們終于有機(jī)會(huì)修復(fù)那個(gè)已經(jīng)被抱怨了好幾個(gè)月的破系統(tǒng)了！」
這將產(chǎn)生大規(guī)模的公司性學(xué)習(xí)畔乙，并且正如 Dr. Steven Spear
所描述的：這樣的做法使得我們?cè)跒?zāi)難性后果發(fā)生之前可以不斷找到并解決問題君仆。
我認(rèn)為其有效原因在于，我們內(nèi)心里都是工程師牲距，都喜歡建立并改善系統(tǒng)返咱，而讓問題暴露出來的環(huán)境造就了激動(dòng)人心和令人滿意的工作環(huán)境。
問：事后剖析產(chǎn)生了什么結(jié)果牍鞠？不能僅僅寫成文檔咖摹，然后丟進(jìn)垃圾桶，對(duì)不對(duì)难述？
Q：你可能覺得難以置信楞艾，但是我相信最重要的部分就是組織事后剖析會(huì)本身参咙。我們知道，DevOps 中最為重要的部分就是文化硫眯，能組織會(huì)議蕴侧，即便沒有產(chǎn)出，都能對(duì)系統(tǒng)有所提高两入。
A：它會(huì)成為一種 kata——成為我們?nèi)粘Ｒ?guī)定的一部分净宵，證明我們的價(jià)值以及如何區(qū)分工作優(yōu)先級(jí)。
當(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é)商仿村。他們請(qǐng)求 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 那樣的要求嗎汗菜？是否有通知/升級(jí)門檻怎樣不斷減少的例子？
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)然斗这，在工作場(chǎ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ì)總是希望同級(jí)審查時(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：在美鋁公司柒巫，工作場(chǎng)地事故需要在24小時(shí)之內(nèi)報(bào)告給 CEO。在谷歌是否有類似的向上升級(jí)（即問題升級(jí)到領(lǐng)導(dǎo)層）的時(shí)間線谷丸？
A：在 Google App Engine堡掏，我們有很小的團(tuán)隊(duì)（全球100個(gè)工程師），里面只有兩級(jí)：做事的工程師和管理者刨疼。在發(fā)生了影響客戶的事故時(shí)泉唁，我們?cè)谖缫拱汛蠹医行选Ｃ恳粋€(gè)這樣的事故揩慕，有十分之一會(huì)升級(jí)到公司領(lǐng)導(dǎo)層游两。
Q：你對(duì)Swarming如何發(fā)生怎么描述？
A：像豐田工廠漩绵，并非出現(xiàn)所有問題時(shí)都能確保人人到位解決問題贱案。但在文化上，我們的確會(huì)優(yōu)先考慮優(yōu)先級(jí)為0的那些問題的可靠性和質(zhì)量。
在很多方面都有這種情況宝踪，其中一些不算太明顯侨糟，比停機(jī)要微妙一些。
在你檢查打斷測(cè)試的代碼時(shí)瘩燥，在修復(fù)之不會(huì)有其他工作秕重，也不會(huì)發(fā)現(xiàn)還有打斷更多測(cè)試的問題急待解決。
與此相似厉膀，如果有人也出現(xiàn)了類似的問題需要幫助時(shí)溶耘，也會(huì)希望你放下一切提供幫助。為什么呢服鹅？這是我們安排優(yōu)先度的方式——就像「黃金法則」凳兵。我們希望幫助每個(gè)人推動(dòng)工作，從而也幫助到了所有人企软。
當(dāng)然庐扫，在你需要幫助時(shí)他們也會(huì)這樣對(duì)你。
從系統(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)中糊肠，他們的競(jìng)爭(zhēng)對(duì)手在發(fā)現(xiàn)問題后仍然讓問題留在發(fā)現(xiàn)的地方辨宠，與解決方案放在一起，但在高速率公司中货裹，負(fù)責(zé)者會(huì)將問題與發(fā)現(xiàn)進(jìn)行全公司的傳播嗤形。也就是說人們?cè)陂_始工作時(shí)，會(huì)吸收公司里其他人的經(jīng)驗(yàn)弧圆。我們會(huì)看到乘數(shù)效應(yīng)的幾個(gè)案例赋兵。
Q：?jiǎn)栴}發(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)就很簡(jiǎ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)鹰椒。這是他們與失敗的競(jìng)爭(zhēng)對(duì)手最根本的不同锡移。高速率公司的管理者并不負(fù)責(zé)通過一系列指標(biāo)來命令、控制漆际、斥責(zé)淆珊、威脅或者評(píng)估別人，而是確保公司在以下方面有所提高：自診與自我改進(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ì)成員沖著彼此吼叫呢燥，或者誰也不聽對(duì)方的崭添。
在谷歌，我認(rèn)為領(lǐng)導(dǎo)者最強(qiáng)大的影響在于我們打造重要工程項(xiàng)目的文化愿景叛氨。大的文化規(guī)范之一呼渣，「每個(gè)人都寫很棒的測(cè)試；我們不想成為一個(gè)寫蹩腳測(cè)試的團(tuán)隊(duì)寞埠∑ㄖ茫」同樣，有這樣的文化「我們只雇參與者」——對(duì)我在情感上也很重要仁连。
在谷歌蓝角，在評(píng)估與改進(jìn)過程中一些這樣的東西被寫進(jìn)法典——聽起來很糟糕，因?yàn)槟且馕吨苟覀冎还茏龊锰嵘璧哪且环莨ぷ魇苟臁５橇硪环矫妫u(píng)估過程贊譽(yù)很高昌抠，幾乎公認(rèn)是可觀的——人們獲得提升知識(shí)因?yàn)樗麄冏鞒隽讼鄳?yīng)的貢獻(xiàn)并徘，并且很擅長他們所做的工作。我從未聽過誰升職是因?yàn)樗麄儭副?duì)了大腿扰魂，拍對(duì)了馬屁」麦乞。
管理者和主管職位的主要標(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ù)就成了首要趨勢(shì)护盈。就像是一個(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é)到的太多了校赤，難以言喻吆玖。如果你對(duì)此有興趣，想要了解更多并用于公司實(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ù)文章掷匠，請(qǐng)?jiān)L問 OneAPM 官方博客
。
