Dr. Spear的模型有如下四大能力：
Dr. Spear 寫道：
高效率公司會(huì)針對(duì)已有知識(shí)庫(kù)，制定詳細(xì)規(guī)則并設(shè)計(jì)捕獲問題的方法，使用內(nèi)置測(cè)試以發(fā)現(xiàn)問題。
無論個(gè)體還是團(tuán)隊(duì)工作，無論是否有設(shè)備，高效率公司不愿意接受模棱兩可。他們提前對(duì)以下內(nèi)容進(jìn)行詳細(xì)說明：
在 DevOps 領(lǐng)域，特別是在自動(dòng)化測(cè)試領(lǐng)域，Google 應(yīng)該是典范之一。我們看看Google 面臨的挑戰(zhàn)（數(shù)據(jù)截止2013年）：
在同一個(gè)庫(kù)里 check 所有的源代碼（數(shù)十億文件?。?/div>
5500次代碼提交 via 1.5萬(wàn)程序員；
自動(dòng)測(cè)試每天運(yùn)行7500萬(wàn)次；
0.5%的工程師致力于開發(fā)工具。
是的，你沒看錯(cuò)，整個(gè)Google 只有一個(gè)代碼倉(cāng)庫(kù)。
以下為本次訪談的精彩互動(dòng)。請(qǐng)大家欣賞。
Q：谷歌可能是自動(dòng)化測(cè)試的典范了，大家都想更多地了解你在那里的工作經(jīng)驗(yàn)。
A：的確如此，谷歌做了大量的自動(dòng)化測(cè)試——超過我工作過的其他所有典范?！敢磺小苟夹枰獪y(cè)試——不僅要測(cè)試 getter/setter 功能，并且，還要測(cè)試一切可能出問題的地方。
對(duì)所有人來說，設(shè)計(jì)測(cè)試通常是極具挑戰(zhàn)的。
一般不會(huì)有人花時(shí)間去寫測(cè)試來檢查自己認(rèn)為會(huì)正常運(yùn)作的功能，頂多去測(cè)試自己認(rèn)為那些可能出錯(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è)試中，也許有百萬(wàn)分之一、千萬(wàn)分之一的幾率這些組件運(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)。
等這些組件成熟了，他們不僅要向使用者提供相應(yīng)服務(wù)，還得為他們提供客戶端文件庫(kù)，使得服務(wù)更加便捷。使用現(xiàn)有的客戶端文件庫(kù)，他們可以為客戶端測(cè)試模擬后臺(tái)服務(wù)，并注入各種失敗場(chǎng)景，比如：
你可以使用 BigTable 生產(chǎn)程序庫(kù)，再加上一個(gè)模擬器，就會(huì)跟實(shí)際生產(chǎn)平臺(tái)的表現(xiàn)一樣。你想在寫入和ACK 階段注入失敗場(chǎng)景？直接做就成了！
我懷疑這些原則和實(shí)踐是來自”艱苦的磨練”，從那些你一直問”怎么避免停機(jī)”這樣的緊急情況中磨練出來的。
隨著時(shí)間過去，最終規(guī)則被完善，得到了一個(gè)堅(jiān)挺的架構(gòu)。
能力2：一發(fā)現(xiàn)問題集群式解決，并記錄下來，成為新知識(shí)。
Dr. Spear 寫道：高效率公司擅長(zhǎng)在系統(tǒng)里第一時(shí)間發(fā)現(xiàn)問題并找到問題。他們同樣擅長(zhǎng)：
在問題擴(kuò)散之前找到它；
找出并解決發(fā)生問題的原因，讓問題不再發(fā)生。
這樣一來，他們?cè)谌绾喂芾斫鉀Q實(shí)際工作問題系統(tǒng)方面，構(gòu)建了更深層次的知識(shí)，將前期難以避免的疏漏轉(zhuǎn)化為知識(shí)。
在GK（本文原作者）的研究中，最令人驚訝的集群式解決問題的例子有兩個(gè)：
豐田的 Andon 拉繩，負(fù)責(zé)在工作偏離已知模式時(shí)讓它停下。有記錄表明，一個(gè)典型的豐田工廠，平均一天需要拉下 Andon 拉繩3500 次。
Alcoa CEO 為了降低工作場(chǎng)所事故發(fā)生，制定了相關(guān)政策：任何在工作場(chǎng)所發(fā)生的事故必須在24小時(shí)內(nèi)通知他。誰(shuí)需要負(fù)責(zé)報(bào)告？業(yè)務(wù)部門總經(jīng)理。
Q：谷歌的遠(yuǎn)程文化與那些支持集群行為（Swarming Behaviors）的文化類似嗎，比如豐田安燈拉繩與 Alcoa CEO 對(duì)工作場(chǎng)所事故的向他通知的要求？
完全一致，兩者都能引起我的共鳴。
在 Ebay 和谷歌，都有事后剖析免責(zé)文化（blame-free PostMortems，或稱 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ā)什么責(zé)任性后果，那么會(huì)產(chǎn)生驚人的動(dòng)力，工程師互相“攀比”，看誰(shuí)捅出過更大的婁子。比如：
「嗨，我們發(fā)現(xiàn)從沒測(cè)過的備份恢復(fù)程序」，或者「然后我們發(fā)現(xiàn)，我們沒有主動(dòng)復(fù)制?！?/div>
也許對(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ì)？
你可能覺得難以置信，但是我相信最重要的部分就是組織事后剖析會(huì)議本身。
我們知道，DevOps 中最為重要的部分就是文化，能組織會(huì)議，即便沒有產(chǎn)出，都能對(duì)組織有系統(tǒng)性的提高。
它會(huì)成為我們?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è)長(zhǎng)期傳統(tǒng)，所有新服務(wù)需要開發(fā)人員自行管理至少六個(gè)月。
服務(wù)團(tuán)隊(duì)在要求「畢業(yè)」時(shí)（也就是需要一個(gè)專門的 SRE 團(tuán)隊(duì)，或者運(yùn)營(yíng)工程師來維護(hù)），他們基本上都會(huì)與 SRE 協(xié)商。他們請(qǐng)求 SRE 接管應(yīng)用提交的相關(guān)職責(zé)（關(guān)于 Google SRE，可以參見高效運(yùn)維微信公眾號(hào)之前的文章—編者注）。
SRE 會(huì)進(jìn)行審查文檔、部署機(jī)制、監(jiān)控概況等等工作。
當(dāng)然，SRE 往往首先會(huì)檢查事后剖析文檔，這一步占很大比重，決定他們是否能讓一個(gè)應(yīng)用「畢業(yè)」。
Q：你在谷歌有看到過類似 Alcoa CEO 那樣的要求嗎？是否有通過改進(jìn)措施不斷減少問題的例子？
Dr. Spear 描述了 Paul O’Neill（Alcoa CEO） 在美鋁公司，如何帶領(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）。
盡管谷歌做得不錯(cuò)，我們學(xué)到了很多（這就是為什么我們要有三個(gè)生產(chǎn)備份），我們認(rèn)為亞馬遜做得要更好，他們的工作比其他人要提前五年。
Q：在美鋁公司，工作場(chǎng)地事故需要在24小時(shí)之內(nèi)報(bào)告給 CEO。在谷歌是否有類似的垂直升級(jí)機(jī)制？
在 Google App Engine，我們有很小的團(tuán)隊(duì)（全球100個(gè)工程師），里面只有兩級(jí)：做事的工程師和管理者。
在發(fā)生了影響客戶的事故時(shí)，我們也曾在午夜把大家叫醒。每一個(gè)這樣的事故，有十分之一會(huì)升級(jí)到公司領(lǐng)導(dǎo)層。
Q：你對(duì)Swarming（集群式解決問題的行為）如何發(fā)生怎么描述？
像豐田工廠，并非出現(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)解決。
關(guān)于其他兩大能力，我們將在下一篇繼續(xù)和大家分享，就在下周，敬請(qǐng)期待。
第三十六屆CIO班招生
國(guó)際CIO認(rèn)證培訓(xùn)
首席數(shù)據(jù)官（CDO）認(rèn)證培訓(xùn)
責(zé)編：content
免責(zé)聲明：本網(wǎng)站（http://www.www.gypb.net/）內(nèi)容主要來自原創(chuàng)、合作媒體供稿和第三方投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準(zhǔn)確性及可靠性，但不保證有關(guān)資料的準(zhǔn)確性及可靠性，讀者在使用前請(qǐng)進(jìn)一步核實(shí)，并對(duì)任何自主決定的行為負(fù)責(zé)。本網(wǎng)站對(duì)有關(guān)資料所引致的錯(cuò)誤、不確或遺漏，概不負(fù)任何法律責(zé)任。
本網(wǎng)站刊載的所有內(nèi)容（包括但不僅限文字、圖片、LOGO、音頻、視頻、軟件、程序等）版權(quán)歸原作者所有。任何單位或個(gè)人認(rèn)為本網(wǎng)站中的內(nèi)容可能涉嫌侵犯其知識(shí)產(chǎn)權(quán)或存在不實(shí)內(nèi)容時(shí)，請(qǐng)及時(shí)通知本站，予以刪除。
搶沙發(fā)
