时间：2022-12-23 06:49:01
失败是探索时的心跳。 我们在尝试新事物时会多次跌倒。 其秘诀是放弃迅速的失败，取而代之的是更好的失败。
来源： linux.cn •作者： Red Hat •译者：白皇城(本文字数： 10656，阅读时间约： 18分钟) )。
代码英雄讲述了开发者、程序员、黑客、极客和开源反叛者如何彻底改变技术前景的真正史诗。
什么是《代码英雄》
代码英雄( Command Line Heroes )是由全球领先的企业开源软件解决方案提供商red hat )精心制作的原创音频播客，由开发者、程序员、黑客该音频博客邀请了谷歌、美国宇航局等重量级企业的多位技术人员，共同讲述了开源、操作系统、容器、DevOps、混合云等发展过程中的感人故事。
本文是比《代码英雄》系列播客第二季(4)更好的失败音频脚本。
导语：失败是探索时的心跳。 我们在尝试新事物时会多次跌倒。 其秘诀是放弃迅速的失败，取而代之的是更好的失败。
这次节目关注的是在科技领域如何接受失败。 以好奇心和开放的态度对待失败，在科技领域是过程的一部分。 Jennifer Petoff分享了谷歌是如何从失败中学习和改善的文化； Jessica Rudder通过视角的转换，展示了拥抱错误如何带来意想不到的成功。 Jen Krieger介绍了敏捷框架如何帮助您规划失败。
失败并不一定是终点。 那也可以是向更伟大的事物迈出的一步。
00:00:00 - Saron Yitbarek :没听过这个笑话的人，有——名工程师在编译代码。 初学者举手说：“哇，代码被编译了！ ”他喊道。 老手眯着眼睛嘟囔着“唔，我的代码被编译了”。 00:00:18 :编程一段时间后，当你开始思考失败的问题时，你对某些事情的看法可能会改变。 过去不能解决的问题，现在开始看起来像更大解决方案中的正常组成部分。 你曾称之为“失败”的东西，现在看起来像是变相的成功。 我开始希望代码不能编译。 你想摆弄它们，实验它们，调试它们，修订它们，重建它们。 00:00:37 :你正在收听的是红帽公司的原创播客节目《代码英雄》。 我是主持人Saron Yitbarek。 老实说，作为通往成功的捷径，那个“快速失败”的口号经常被使用。 但是，如果我们不告诉彼此加快速度快速失败，而是鼓励彼此更好地失败呢？ 00:01:20: 《代码英雄》的第二季介绍了开发工作中的真实体验。 “当我们住在代码里时，到底感觉如何？ 是怎么变化的呢？ 所以，我们必须在一次时间里讨论失败。 因为这些失败的瞬间会让我们适应它。 我们称之为“失败”的是进化的心跳，开源开发者接受了这种进化。 当然，这个说起来容易，做起来难。 00:01:59 :想象一下，如果发现了全新的莎士比亚十四行诗。 网络上掀起了热潮，每个人都想搜索它。 但是，此时，小的设计缺陷导致了所谓的“文件描述符枯竭”。 这将导致一系列的失败。 突然，这一切流量都在越来越少的服务器之间流动。 很快，谷歌上的“莎士比亚”搜索崩溃了，崩溃了一个多小时。 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-saronyitbarek:Jennifer在谷歌工作。 她是站点可靠性工程( SRE ) )团队的高级项目经理，领导着谷歌的全球SRE教育计划。 也是这本书描写莎士比亚场景的作者之一。 对Jennifer来说，研究这样的灾难才能让事情变得更好，但前提是你需要接受错误和意外的文化。 00:04:08 :所以，让我们以莎士比亚为例。 有直接的方法。 通过减少负荷，可以保护你免受这种连锁故障的影响。 但真正的工作都是从恢复正常开始的，重点是事后分析报告。 00:04:25 - Jennifer Petoff :事件解决后，制作事后分析报告。 谷歌的所有事件都需要事后分析和相应的措施项，以防止未来问题的再次发生，更有效地检测和缓解未来类似事件或问题的可能性。 00:04:42 - Saron Yitbarek :这是一个重要的区别。 不仅仅是解决这个特定的事件，而是看了这个事件告诉你的一系列问题。 真正有效的事后分析不仅仅是告诉你昨天哪里出了问题。 就是让他们对今天的工作和将来的计划有深刻的见解。 这种更广泛的思想灌输了对所有这些事故和失败的尊重，使它们成为日常工作生活中重要的一部分。 00:05:12 - Jennifer Petoff :所以，真正好的事后分析不仅解决了手头的一个问题，而且解决了整个问题。 事后分析的重点是，在哪里敌对，在哪里做了错误的事情，在哪里幸运地解决了问题，以及可以采取什么样的优先行动来防止它再次发生？ 如果你不采取行动，历史一定会重演。 00:05:32-saronyitbarek :不负责任的事后分析( blameless post-mortems )在谷歌备受关注，这带来了根本的区别。 出了问题谁也不怪，谁就能老老实实地挖掘错误，真正从错误中吸取教训，不用隐瞒线索，不用吵架。 这些不负责任的事后分析已经成为Google文化的重要组成部分，从而成为一个不必害怕失败的职场。 这是普通的情况。 00:06:01-jenniferpetoff :谷歌如何看待失败？ 100%的在线时间是不可能的目标。 如果你认为这能实现，那就是在欺骗自己。 所以，失败只会产生时间和方式的问题。 在谷歌，失败是值得庆祝的。 因为我们可以从中吸取教训。 此外，事后分析也可以在团队中广泛共享，确保所学知识得到广泛使用。 00:06:23 - Jennifer Petoff :错误是不可避免的，但我不想用同样的方法失败两次。 犯错误是人之常情，但犯错误是避免的。 00:06:34-saronyitbarek :听到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进行了交谈。 她是红帽的首席敏捷架构师。 讨论了对开源失败的态度，以及这些态度如何塑造无限可能性。 听着： 00:14:47 :我想谈谈这个口号，我觉得这可能是个好表现。 “快速失败，打破现状”几乎是为我们社区设计的一个响亮的召集口号。 你觉得呢？ 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 :我总是喜欢告诉工程师。 他们需要尽快，破坏尽可能多的构筑。 如果他们发现他们在破坏他们的构建，他们已经破坏了构建，他们现在也有机会真正修复它。 所有这些都以“反馈环”的概念为中心，保证工作中获得的反馈环尽可能小。 00:17:08，所以我在开源开发中提交了补丁。 然后，“由于这9个原因，我不接受你的补丁”，或者“我认为你的补丁很棒。 请继续。” 或者说，虽然提交了补丁，但是机器人因为没有正确构建而失败了。 有各种类型的反馈。 00:17:25 :而且在开源开发中，可能会遇到更长的反馈周期。 “我想设计这个新功能，但是我不知道所有的规则应该是什么。 有人能设计一下吗？”因此，你进入了一个漫长的过程。 在这个过程中，你必须进行长时间和详细的对话。 然后，人们参加进来，提出最好的想法。 00:17:45 )因此，有各种各样的反馈循环可以帮助你实现这一点。 00:17:50-saronyitbarek: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 :而现在，看看亚马逊和奈飞的模式，你会发现他们每天都会发表数百次设想的顾客需求。 他们从使用他们的APP软件的人们那里得到的反馈，会告诉他们用户是否在做他们需要的事情。 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是红帽公司的首席敏捷架构师。 0:25:19 :并非所有开源项目都像Rails、Django和Kubernetes一样享有声誉。 实际上，几乎没有。
大部分是只有一个贡献者的小项目，是解决小开发者面临的小问题的小项目。 或者它们被扔掉了，很久没人碰了。 但是，它们还是有价值的。 事实上，许多这样的项目仍然非常有用，可以被回收、升级，并被其他项目蚕食。 00:25:54 :别人通过他们的错误启发和教导了我们。 因为在健康开放的舞台上，失败会带来比胜利更好的东西。 那个给了你洞察力。 还有一个。 尽管有那些死胡同，尽管有各种冒险尝试和悲鸣，开源项目的数量每年都翻倍； 我们的社区很繁荣。 事实证明，尽管因失败而没有繁荣，但却因失败而繁荣。 下一集将预告DevOps在世界上的安全将如何变化。 持续部署意味着安全已经渗透到开发的每一个阶段，正在改变我们的工作方式。 您还可以访问redhat.com/commandlineheroes了解更多开源文化，以及如何改变围绕失败的文化。 免费资源在等着你。 00:26:54-saronyitbarek:《代码英雄》是红帽子的原创播客。 您可以通过Apple Podcast、Google Podcast或其他任何您喜欢的方式免费收听。 我是Saron Yitbarek。 继续编程，下期再见。
什么是LCTT SIG和LCTT LCRH SIG
LCTT SIG是一个LCTT特殊兴趣小组( Special Interest Group )，是一个针对特定领域和特定内容的翻译团队，翻译团队的成员遵循LCTT流程和规范参与翻译，并获得适当的报酬。 LCRH SIG是由LCTT联合红帽( Red Hat )发起的SIG，目前的集中任务是《代码英雄》系列播客的脚本汉化，已有数十位贡献者参与。 每周三、周五，我们都期待着我们精心翻译、校对和发表的译文。
加入LCRH SIG参与贡献，领取红帽子( Red Hat )和我们共同颁发的专属贡献者证书。
via: www.Red Hat.com作者： redhat选题： bestony译者： bestony校对： wxy本文由LCRH原创编译，Linux中国荣誉发售
单击“查看详细信息”可以访问内联链接
