《代碼英雄》第二季（4）：更好的失敗

本文是《代碼英雄》系列播客第二季（4）：更好的失敗的音頻腳本。

導語：失敗是探索時的心跳。我們會在嘗試新事物時會多次跌倒。其中秘訣是放棄快速失敗，取而代之的是，更好地失敗。

本期節目關注在科技領域如何擁抱失敗。（對於科技領域來說）以好奇和開放的態度來對待失敗是過程中的一部分。Jennifer Petoff 分享了 Google 是如何建立起一種從失敗中學習和改進的文化；Jessica Rudder 通過視角的轉變，展示了擁抱錯誤如何能帶來意想不到的成功。而 Jen Krieger 則介紹了敏捷框架如何幫助我們為失敗做計劃。

失敗未必是終點。它可以是邁向更偉大事物中的一步。

00:00:00 - Saron Yitbarek：

如果你沒有聽過這個笑話 —— 兩個工程師在編譯他們的代碼。新手舉手喊道：「哇，我的代碼編譯好了！」；老手則會眯著眼睛喃喃道：「唔，我的代碼居然編譯好了」。

00:00:18：

如果你已經做過一段時間編程，當你開始思考失敗這件事，對有些事情的看法可能就會有所不同。那些過去無法解決的問題，如今開始看起來像一個更大的解決方案中的一個正常組成部分。那些你曾經稱之為「失敗」的東西，現在看起來像是變相的成功。

你開始希望你的代碼無法通過編譯。你希望可以一路擺弄和實驗它們，調試和修訂和重構這些代碼。

00:00:37：

你正在收聽的是紅帽公司的原創播客節目《代碼英雄》。我是主持人 Saron Yitbarek。

老實說，那句「 快速失敗 fail fast 」的口號經常被用來作為通往成功的捷徑。但是，如果我們不是告訴彼此加快速度並快速失敗，而是鼓勵彼此更好地失敗呢？

00:01:20：

《代碼英雄》的第二季將介紹的是開發工作中真實的體驗：「當我們生活在代碼中，到底感覺如何？又是如何變化的？這也是為什麼我們要用一整集的時間來討論失敗，因為正是這些失敗時刻促使我們適應它。我們稱之為「失敗」的東西，是進化的心跳，而開源開發者正在擁抱這種進化。當然，這說起來容易做起來難。

00:01:59：

想像一下，如果一首全新的莎士比亞的十四行詩被發現了。網路上會興起一陣熱潮，每個人都想去搜索它。但這時，有個小小的設計缺陷導致了所謂的「文件描述符耗盡」。這會造成一連串的失敗。突然之間，這所有的流量都在越來越少的伺服器之間流動。很快，在 Google 上的「莎士比亞」搜索崩潰了，並崩潰了一個多小時。

00:02:33：

現在，你丟掉了 12 億次搜索查詢。這是一場莎士比亞式的悲劇，所有的一切，在網站可靠性工程師（SRE）四處補救的同時上演。

00:02:45 - 配音：

還有你嗎，布魯特？那就倒下吧，凱撒！

00:02:54 - Saron Yitbarek：

不好意思，我打斷一下。但上面說的這個莎士比亞事件其實並不存在。事實上，這是一本書《SRE：Google 運維解密》中一系列災難性場景的一部分。從這本書中學到的重要的一課就是你必須超越災難本身。這就是我的意思。

00:03:13：

在這個莎士比亞的例子中，當流量被集火到一個被犧牲的單獨集群時，這個死亡查詢問題就解決了。這為團隊贏得了擴充容量的足夠時間。但你不能就此止步。儘管這個問題很糟糕，但解決它並不是真正的重點所在。因為失敗不一定以痛苦告終，失敗也可以引導你的學習。

00:03:38 - Jennifer Petoff：

嗨，我是 Jennifer Petoff。

00:03:41 - Saron Yitbarek：

Jennifer 在谷歌工作。她是 SRE（ 站點可靠性工程 site reliability engineering ）團隊的高級項目經理，領導谷歌的全球 SRE 教育計劃，她也是這本描述了莎士比亞場景的書的作者之一。對於 Jennifer 來說，鑽研這樣的災難才能使事情變得更好，但前提是你需要有一個擁抱錯誤和意外的文化。

00:04:08：

所以，讓我們再拿莎士比亞舉例子。有一個直接的辦法，減少負載可以讓你免於這種連鎖故障。但，真正的工作將在一切恢復正常之後開始，重點在於事後分析報告。

00:04:25 - Jennifer Petoff：

事件解決後，我們會創建一個事後分析報告。谷歌的每一個事件都需要有一個事後分析和相應的行動項目，以防止將來再次出現問題，以及更有效地檢測和緩解未來出現類似事件或整類問題的可能。

00:04:42 - Saron Yitbarek：

這是一個關鍵的區別。不僅僅是解決這個特定事件，而是看到這個事件告訴你的一系列問題。真正有效的事後分析，不只是告訴你昨天哪裡出現了問題。而是讓你對今天所做的工作以及對未來的計劃有深刻的見解。這種更廣泛的思想，灌輸了對所有這些事故和失敗的尊重，使它們成為日常工作生活中至關重要的一部分。

00:05:12 - Jennifer Petoff：

所以，一個真正好的事後分析不僅僅要解決手頭的單個問題，它還解決了整個問題。事後分析的重點是什麼地方作對了，什麼地方做錯了，在何處幸運的解決了問題，以及可以採取哪些優先行動來確保這種情況不會再次發生。如果你不採取行動，歷史必將重演。

00:05:32 - Saron Yitbarek：

在谷歌，人們關注的是 無責任的事後分析 blameless post-mortems ，這就造成了根本的不同。如果出了問題而沒有人要責怪，那麼每個人都可以誠實地挖掘錯誤，真正地從錯誤中吸取教訓，而不必掩蓋任何線索，也不必爭吵。這些無責任的事後分析已經成為谷歌文化的一個重要組成部分，其結果是一個不必害怕失敗的工作場所。這是一種正常情況。

00:06:01 - Jennifer Petoff：

谷歌如何看待失敗？100% 的在線時間是一個不可能的目標。如果你認為這是可以實現的，那就是在自欺欺人。所以，失敗會發生只是時間和方式的問題。在谷歌，失敗是值得慶祝的，因為我們可以從中吸取教訓，而事後分析也會在團隊中廣泛分享，以確保學到的東西可以廣泛使用。

00:06:23 - Jennifer Petoff：

錯誤是不可避免的，但你永遠不想以同樣的方式失敗兩次。犯錯是人之常情，但反覆犯錯是可以避免的。

00:06:34 - Saron Yitbarek：

聽到 Jennifer 討論失敗的方式，這真是太有趣了，因為就像她在犯那些錯誤一樣。比如，當事情出錯的時候，這意味著你已經走到了一個可以挖掘價值的地方。

00:06:50 - Jennifer Petoff：

你會現場處理這種情況，但事後花時間把發生的事情寫出來，讓別人可以從中學習。發生任何事件時，你都需要付出代價。如果你不寫出事後分析，並真正從這個經驗中吸取教訓，你就不會重新收回解決問題所花費的成本。在我看來，這是至關重要的一課。在谷歌，我們堅信無責任文化。你不會因為指責別人而獲得任何好處，那隻會讓人們去掩蓋失敗，而失敗，總是會發生。

00:07:27 - Saron Yitbarek：

這裡非常重要的一點是，要記住 Jennifer 之前說過的一些話，沒有錯誤的工作是一種幻想，總會有出錯的地方。歸根結底這是思想的轉變。我們可以拋棄那種認為只有一個單一的、可確定的最終目標，即一切最終都會按照我們想像的方式發展的想法。我們沒有人試圖達到這一目標，事實證明，這是非常強大和積極的東西。

谷歌擁抱失敗的做法很有意義。超級實用。但我想知道，這只是口頭上的么？我們是否有一些具體的讓事情變得更好的失敗例子，或者這只是一種當我們進行第 200 次編譯時，讓我們感覺更好的一種方法。

00:08:26：

事實證明，有人可以回答這個問題。

00:08:29 - Jessica Rudder：

我的名字叫 Jessica Rudder。我是 Github 的軟體工程師。

00:08:33 - Saron Yitbarek：

Jessica 在 Github 經歷過失敗。從某種意義上說，這是一個失敗的舞台，在這一過程中，她收集了一些關於失敗是通往巨大成功的故事。比如這個：

00:08:50 - Jessica Rudder：

90 年代有個遊戲開發公司正在開發一款全新的遊戲。從本質上說，這是一款賽車遊戲，但他們的轉折之處在於將其改為街頭賽車。所以當賽車手在街道上飆車時，他們不僅是在互相飆車，而且他們也是與在追趕他們的警車（非玩家角色）賽車。如果一輛警車抓住了你，它會讓你靠邊停車，然後你就輸掉了比賽。然後他們把這些代碼銜接起來，然後開始運行，他們發現他們完全調校錯了演算法：警車只是尖叫著從側街衝出來，直接撞向玩家的車，而不是追趕玩家的車。

00:09:37：

所以這裡簡直是一團糟。他們想，不要驚慌，讓我們繼續前進，看看人們如何看待它的，這樣我們就知道該怎麼調整演算法了。所以他們把它交給了遊戲測試人員，他們發現遊戲測試人員在逃離警察並試圖躲避被這些流氓暴力警車抓捕的過程中獲得了更多樂趣。而事實上，它是如此的有趣，以至於開發團隊改變了他們為遊戲打造的整個理念。

00:10:17 - Saron Yitbarek：

你能猜出這是怎麼回事嗎？

00:10:21 - Jessica Rudder：

所以我們才有了《 俠盜獵車手 Grand Theft Auto 》。我的意思是，它確實是有史以來最暢銷的電子遊戲，它能存在的全部原因都是因為當時他們沒有使用正確的演算法時所導致的失誤，他們想，好吧，讓我們來試試；看看我們得到了什麼，看看我們能從中學到什麼。

00:10:41 - Saron Yitbarek：

很神奇吧？但這裡有個技巧，《俠盜獵車手》團隊在遭遇失敗時必須保持寬容；他們必須保持好奇心。

00:10:52 - Jessica Rudder：

所以，如果這些開發者沒有開放的思想，並決定從這個錯誤中去學到什麼，我們將永遠不會有《俠盜獵車手》，我們只能玩一些無聊的、普通的街頭賽車遊戲了。

00:11:07 - Saron Yitbarek：

讓我們再就遊戲主題討論一分鐘，類似的事情也發生在《 寂靜嶺 Silent Hill 》的製作過程中。這是一個大型的、3A 級的大製作遊戲。但他們遇到了嚴重的彈出問題。局部景觀的處理速度不夠快，因此突然之間，你會突然發現一堵牆或一條小路突然冒出來。這是一個破壞性的問題，而且他們的開發已經到非常後期。他們是怎麼做的？完全放棄遊戲，舉手投降？還是將錯就錯。

00:11:42 - Jessica Rudder：

他們所做的就是讓這個世界充滿了非常濃郁、詭異的霧氣。因為事實證明，霧對處理器來說非常容易渲染，而且不會有任何延遲。而且另外，霧使你看不到遠處的東西，所以在現實中，那些建築物仍然會突然出現，但由於霧遮擋了你的視線，你看不到它們。所以當它們進入視野時，它們已經被渲染了，看起來它們是從霧中出來的。

00:12:15 - Saron Yitbarek：

霧是變得如此受歡迎，它基本上被認為是《寂靜嶺》系列中的一個特點。它限制了玩家的視野，使遊戲變得更加恐怖。甚至當處理器的速度快到不需要再掩蓋那些彈出的時候，他們也保留了霧氣。

00:12:33 - Jessica Rudder：

你無法在沒有霧的情況下玩《寂靜嶺》。而這些霧最初所做的一切都是在掩蓋一個錯誤。

00:12:40 - Saron Yitbarek：

我喜歡這個故事！他們擁抱失敗而不是逃避失敗，從而挽救了一個重大的發展。這條關於不怕失敗的原則也適用於個人的小事，而不僅僅是全公司的決策。從容面對失敗是我們一點一點地變得更好的方法。

00:13:01 - Jessica Rudder：

很多時候人們腦子裡想的太多了，他們認為失敗意味著我不擅長某樣東西。並不是代碼壞了我還不知道如何修復它，而是「我不知道如何編寫 JavaScript」。而且，你永遠不會通過說「我不知道如何編寫 JavaScript」來學習所需的知識。但是如果你能確定，「哦，我不知道如何在 JavaScript 中實現這個循環」，那麼你可以通過 Google 找到答案，而且效果很好。我是說，你仍然需要努力，但你遇到的麻煩會少的多。

00:13:36 - Saron Yitbarek：

因此，無論你是新開發人員還是大型工作室的負責人，我們的錯誤將我們推向更大的領域，那些實驗，那些失敗，那些英勇的嘗試，它們佔據了旅程的大部分。在我所熟悉和喜愛的開源社區里，這是最真實的情況了。失敗在開源中可能是一件美好的事情，這就是我們接下來的故事。

00:14:14：

我們在前面看到了失敗是如何帶來驚喜 —— 那些我們甚至不知道自己想嘗試的事情。在最好的情況下，開源開發文化正好符合這一點。它讓失敗變得正常。為了理解這種願意失敗的想法是如何被引入開源開發的，我和 Jen Krieger 聊了聊。她是 Red Hat 的首席敏捷架構師。我們討論了對開源失敗的態度，以及這些態度是如何塑造無限可能的。請聽：

00:14:47：

我想談談這個口號，我覺得這也許是一個很好的表達方式。「 快速失敗，打破現狀 fail fast and break things 」，這幾乎是為我們社區所設計的一個巨大的召集口號。你怎麼看？

00:15:04 - Jen Krieger：

我對此有很多想法。

00:15:06 - Saron Yitbarek：

我也覺得你會有。

00:15:06 - Jen Krieger：

快速失敗，在失敗中前進，所有這些都是一個意思。所以，在我剛剛參加工作的時候，我在一家沒有失敗空間的公司工作。如果你做錯了什麼事情，你就可以準備辭職了。任何人都不能做錯事，沒有任何空間、途徑允許你犯錯。這令人們困擾。你絕對沒有失敗的餘地，導致我們幾乎陷入一場文化運動。願意的話，這會催生出一個很棒詞 —— 敏捷，以及催生出另一個很棒的詞 —— DevOps。當我看到這些詞的時候，我看到的是我們只是要求團隊做一系列非常小的實驗，幫助他們修正方向。

00:16:02：

這是個，哦，你已經做出了選擇，而這實際上是一件積極的事情。你可能會做一個冒險的決定，然後你贏了，因為你做出了正確的決定。或者反之，就是你做了錯誤的決定，然後你明白了，那不是正確的方向。

00:16:18 - Saron Yitbarek：

是的，這是有道理的。所以，當你把「快速失敗，打破現狀」當成這個運動的時候，感覺在如何失敗，如何以正確的方式失敗上還是有一些方式，有一些最佳的實踐的。那麼，如何以一種正確的方式失敗，有哪些最佳實踐和原則呢？

00:16:44 - Jen Krieger：

我總是喜歡告訴工程師，他們需要儘早和儘可能多地破壞構建。如果他們正在破壞他們的構建，並且他們意識到他們已經破壞了構建，他們在當下還有機會真正修復它。而這一切都圍繞著「 反饋循環 feedback loops 」這個概念，並確保你在工作中得到的反饋循環儘可能小。

00:17:08：

所以在開源開發中，我提交了一個補丁，然後有人說，「出於這九個原因，我不會接受你的補丁」，或者「我認為你的補丁很棒，繼續吧」。或者，你提交了一個補丁，但是機器人告訴你它失敗了，因為它沒有正確構建。有各種不同類型的反饋。

00:17:25：

然後在開源開發中，你可能會遇到更長的反饋循環，你可能會說，「我想設計這個新功能，但我不確定所有的規則應該是什麼。有人能幫我設計嗎？」因此，你進入了一個漫長的過程，在這個過程中，你要進行長時間和詳細的對話，而人們參與進來，提出最好的想法。

00:17:45：

所以有各種各樣的反饋循環可以幫助你完成這個。

00:17:50 - Saron Yitbarek：

Jennifer 認為，每個公司的反饋循環看起來都不一樣。它們是可定製的，人們可以使它們以 100 種不同的方式工作。但重點是，她甚至沒有把它們稱為失敗或錯誤。她只是稱它們為「反饋循環」。這是一個有機系統，這是一種思考整個過程的健康方式。

00:18:11：

與此同時，對這些小毛病的另外一種態度卻產生了完全相反的效果。

00:18:18 - Jen Krieger：

有些組織所做的事情是完全錯誤的。

00:18:23 - Saron Yitbarek：

嗯是啊。

00:18:24 - Jen Krieger：

讓你的領導團隊（或者，在一個很高的層面上，比如組織）認為，羞辱做錯事情的人，或者在績效結果方面灌輸恐懼；就像是，「如果你工作做得不好，就拿不到獎金」或者「如果你工作做得不好，我會把你列入績效計劃。」這些都是會產生敵意的事情。

00:18:50 - Saron Yitbarek：

她描述的是一個不正確的失敗。不能接受失敗就是失敗。她也在呼應 Jennifer Petoff 的態度，對吧？就是我們在這集開頭提到的那個無責任的事後分析？

00:19:07：

是的，這很有趣。就好像如果我們在如何一起工作上要求更嚴格一點，或者只是更用心，更有目的性的在一起工作，我們幾乎就會被迫在失敗中表現得更好。

00:19:23 - Jen Krieger：

是的。有一些公司已經學會了這一點，而且他們很久以前就學會了，豐田就是一個很好的例子，它接受了這種不斷學習和改進的理念，這是我在其他公司很少看到的。就是這樣一種想法，任何人在任何時候都可以指出某些東西不能正常工作。不管他們是誰，在公司的哪個級別。在他們的文化中，認為這是對的。這種持續學習和改進的環境，我想說，是一種領先的實踐，這是我希望公司能夠做到的事情，能夠適應失敗並允許它發生。

00:20:06 - Saron Yitbarek：

嗯，沒錯。

00:20:07 - Jen Krieger：

如果你問的是為什麼事情進展不順利，而不是指責或試圖隱藏事情，或責怪別人，這就會造成完全不同的情況。那就是改變對話方式。

00:20:23 - Saron Yitbarek：

這很有趣，因為你之前提到過「快速失敗，打破現狀」這句話是這種文化，這種對過去做事方式的反擊。 但這聽起來似乎是一種口頭禪，也許也創造了一種在公司內部、技術團隊內部的不同的團隊工作方式。再給我講講這個問題，它是如何改變了開發人員看待自己角色的方式，以及他們與公司其他人互動的方式?

00:20:55 - Jen Krieger：

我早期和工程師一起工作的時候差不多是這樣的，工程師們都坐在一個小區域，他們互相交談。他們從未真正與任何商業人士進行過交流。他們從來沒有真正理解他們的任何需求，我們花了很多時間真正專註於成功所需的東西，而不一定是企業實際完成工作所需的東西。所以，它更像是，「我是一個工程師，我需要什麼才能編寫這個功能片段？」我觀察到，今天在幾乎每一個和我一起工作的團隊中，對話方式已經發生了巨大的變化，「作為工程師我需要什麼才能完成工作」變成了「客戶是誰，或者用戶需要什麼才能真正感覺到這我做的這塊功能對他們來說是成功的？他們如何使用產品？我該怎樣做才能讓他們更輕鬆？」

00:21:56：

很多這樣的對話已經改變了，我認為這就是為什麼如今公司在提供有意義的技術方面做得更好的原因。我還想說的是，我們發布的速度越快，我們就越容易知道我們的假設和決定是否真正實現了。所以，如果我們對用戶可能想要什麼做了假設，在此之前，我們需要等待，比如，一年到兩年才能確定這是不是真的。

00:22:25：

而現在，如果你看看亞馬遜或奈飛的模式，你會發現，他們每天會發布數百次假設的客戶需求。他們從使用他們的應用程序的人們那裡得到的反饋，會告訴他們他們是否在做用戶需要他們做的事情。

00:22:46 - Saron Yitbarek：

是的，這聽起來需要更多的合作，因為即使是你之前提出的關於構建、破壞構建、經常破壞它的建議，這就需要工程團隊或開發人員與 DevOps 保持步調一致，以便他們能夠破壞它，並了解儘早發布並經常發布是什麼樣子的。聽起來這需要雙方更多的合作。

00:23:15 - Jen Krieger：

是的，對於擁有敏捷教練這個頭銜的人來說，或者以我作為首席敏捷架構師看來，總是很有趣，因為《敏捷宣言》的初衷是讓人們從不同的角度來考慮這些事情。我們通過開發和幫助別人開發來發現更好的開發軟體的方法。它確實是敏捷所要做的的核心、根本和基礎。因此，如果你將 10 年，15 年以上的時間快速推進到 DevOps 的到來，並堅持我們需要持續進行集成和部署。我們有監控，我們開始以不同的方式思考如何將代碼扔出牆外。

00:23:56：

所有這些東西都是我們最初開始討論敏捷時應該想到的。

00:24:03 - Saron Yitbarek：

嗯。絕對是的。所以，不管人們如何實踐這種失敗的理念，我認為我們都可以接受失敗，將失敗規範化只是過程的一部分，是我們需要做的事情，是我們可以管理的事情，是我們可以用「正確的方式」做的事情，這是一件好事。它對開源有好處。跟我說說這個新運動的好處，這種接受失敗是過程的一部分的新文化的一些好處。

00:24:36 - Jen Krieger：

看著這個過程發生是一件美妙的事情。對一個人來說，從一個他們害怕可能發生事情的環境，到一個他們可以嘗試實驗、嘗試成長、嘗試找出正確答案的環境。真的很高興，就像它們已經盛開花朵。他們的士氣提高了，他們真正意識到他們可以擁有的是什麼，他們可以自己做決定，而不必等待別人為他們做決定。

00:25:05 - Saron Yitbarek：

失敗即自由。啊，我喜歡! Jen Krieger 是紅帽公司的首席敏捷架構師。

00:25:19：

並不是所有的開源項目都像 Rails、Django 或 Kubernetes 那樣聲名鵲起。事實上，大多數都沒有。大多數都是只有一個貢獻者的小項目，解決一小群開發人員面臨的小問題的小眾項目，或者它們已經被拋棄，很久沒有人碰了。但它們仍然有價值。事實上，很多這樣的項目仍然非常有用，可以被回收、升級，被其他項目蠶食。

00:25:54：

而另一些人通過他們的錯誤啟發我們，教導我們。因為在一個健康的、開放的舞台上，失敗會帶給你比勝利更好的東西。它給了你洞察力。還有一點。儘管有那些死胡同，儘管有各種冒險的嘗試和驚呼，但開源項目的數量每年都在翻倍；我們的社區正在繁榮，事實證明，儘管因失敗我們沒有繁榮，但因失敗我們正在繁榮。

下一集預告，DevOps 世界中的安全性如何變化。持續部署意味著安全正在滲透到開發的每個階段，這正在改變我們的工作方式。同時，如果你想了解更多關於開源文化的知識，以及我們如何改變圍繞失敗的文化，請訪問 redhat.com/commandlineheroes ，免費資源等著你。

00:26:54 - Saron Yitbarek：

《代碼英雄》是紅帽的原創播客。你可以在 Apple Podcast、Google Podcast 或是其他你喜歡的途徑免費收聽。我是 Saron Yitbarek，堅持編程，下期再見。

什麼是 LCTT SIG 和 LCTT LCRH SIG

LCTT SIG 是 LCTT 特別興趣小組 Special Interest Group ，LCTT SIG 是針對特定領域、特定內容的翻譯小組，翻譯組成員將遵循 LCTT 流程和規範，參與翻譯，並獲得相應的獎勵。LCRH SIG 是 LCTT 聯合紅帽（Red Hat）發起的 SIG，當前專註任務是《代碼英雄》系列播客的腳本漢化，已有數十位貢獻者加入。敬請每周三、周五期待經過我們精心翻譯、校對和發布的譯文。

歡迎加入 LCRH SIG 一同參與貢獻，並領取紅帽（Red Hat）和我們聯合頒發的專屬貢獻者證書。

via: https://www.redhat.com/en/command-line-heroes/season-2/fail-better

作者：Red Hat 選題：bestony 譯者：bestony 校對：wxy

本文由 LCRH 原創編譯，Linux中國 榮譽推出

本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive