代码英雄讲述了开发人员、程序员、黑客、极客和开源反叛者如何彻底改变技术前景的真实史诗。

什么是《代码英雄》

代码英雄 Command Line Heroes 是世界领先的企业开源软件解决方案供应商红帽（Red Hat）精心制作的原创音频播客，讲述开发人员、程序员、黑客、极客和开源反叛者如何彻底改变技术前景的真实史诗。该音频博客邀请到了谷歌、NASA 等重量级企业的众多技术大牛共同讲述开源、操作系统、容器、DevOps、混合云等发展过程中的动人故事。

本文是《代码英雄》系列播客第二季（5）：关于 DevSecOps 的故事的音频脚本。

导语：不良的安全和可靠性实践会导致影响数百万人的中断。现在是时候让安全加入 DevOps 运动了。并且，在 DevSecOps 的世界中，我们可以创造性的提升安全性。

每月发现一个漏洞曾经是常态。而现在，由于敏捷流程和 DevOps 团队，软件开发的进展迅速。Vincent Danen 告诉我们，这如何导致被认为是漏洞的东西急剧增加。前亚马逊灾难主管 Jesse Robbins 介绍了公司如何为灾难性故障和漏洞做好准备。而 Elastic 的产品安全主管 Josh Bressers 则展望了科技领域安全的未来。

我们不应该把安全团队当成脾气暴躁的妖怪。听听 DevSecOps 团队如何将英雄们聚集在一起，以实现更好的安全。

00:00:01 - 众议院小组委员会代表：

1991 年 6 月 26 日，在华盛顿特区，马里兰州和西弗吉尼亚州的大部分地区，以及我的家乡的大部分地区都因公共电话网络的大规模故障而瘫痪了。然而，随着技术变得越来越复杂，网络系统越来越相互依存，反复发生故障的可能性也会增加。似乎并没有警告说会发生这种情况。

00:00:23 - Saron Yitbarek：

在 20 世纪 90 年代初，有 1200 万美国人遭受了大规模的电话网络故障。人们不能给医院打电话，企业不能给客户打电话，父母不能打电话给托儿所。对于一个基础设施严重依赖于万物互联的计算机系统的国家来说，这是一场混乱也是一记警钟。这些计算机网络变得越来越大，然后当它们出现故障时，故障时间就会很长。

00:01:01：

电脑故障会导致电话系统崩溃。在今天代码中的一行小错误的后果比以往时候都要严重。

00:01:15：

我是 Saron Yitbarek，这里是是红帽公司的原创播客节目《代码英雄》。

00:01:24：

因此，软件安全性和可靠性比以往任何时候都重要。传统的瀑布式开发方法，安全性只是一个附加流程而已，已经不再适用。我们生活在一个 DevOps 的世界里，一切都变得更快、更敏捷、扩展性更强，这在电话网络崩溃时是他们无法想象的。这意味着我们的安全和可靠性标准必须不断改进，以应对这些挑战。

00:01:55：

在本集中，我们将研究如何将安全性集成到 DevOps 中，我们还将探索在运营中构建可靠性和弹性的新方法。即使在介绍了所有这些之后，我们知道还有很多东西可以讨论，因为在 DevSecOps 的世界里，对于开发人员和运营人员来说，事情都在快速变化。这些变化意味着不同的事情，这取决于你的立场，但这是我们的看法。我们也很想听到你们的消息——所以如果你认为我们错过了什么，不要害羞——在网上联系我们。

00:02:34：

好了，让我们开始探索这个全新的领域吧。

00:02:43：

事情就是这样，让安全性和可靠性跟上时代的步伐，并为 DevOps 世界做好准备，这意味着我们必须对工作方式进行一些关键的调整。第一，我们必须拥抱自动化。我的意思是，想想双因子认证的逻辑。想想那些难以想象的艰巨任务吧。很显然，你不能仅仅通过增加员工来解决问题，所以第一点就是拥抱自动化。

00:03:15：

然后，第二点，这个可能不是那么明显，那就是它真的改变了文化，使安全不再是一个祸害。稍后我将解释我所说的改变文化的含义。但是让我们一个一个的解释这两点。首先，拥抱自动化。

00:03:42：

以前，应用程序的部署在每个单独的发布之前都涉及到一个人为的安全审查，我不知道你是否注意到了，但是人为的审查可能会有点慢。这就是为什么自动化是在 DevOps 构建安全性的关键部分。以 Verizon 最近的数据泄露报告为例。他们发现，81% 的与黑客相关入侵涉及密码被盗或者弱密码。从表面上看，这是一个非常简单的问题，但是规模却很大。就像我之前所提及到的，你不能用工作人员去解决 3000 万个密码问题，对吧？问题在于解决大规模问题，而每次的答案都是一样的。那就是自动化，自动化。

00:04:36 - Vincent Danen：

如果你等待人参与进来，那么规模就不会扩大。

00:04:41 - Saron Yitbarek：

Vincent Danen 是红帽公司产品安全部门的主管，在过去的 20 年里，他见证了 DevOps 的快速发展。安全团队不得不竞相追赶。

00:04:56 - Vincent Danen：

刚开始的时候，每个月都有漏洞，后来变成了每隔一周，然后是每周都有。现在，每天都能找到几百个漏洞。

00:05:08 - Saron Yitbarek：

有趣的是，Vincent 说，随着安全团队的发展，实际上会出现更多的漏洞，而不是更少。

00:05:17 - Vincent Danen：

我们永远不会说，哦，我们现在安全了，我们做完了，我们的工作结束了。安全审计会一直存在，就像呼吸一样，这是必须要有的。

00:05:27 - Saron Yitbarek：

事实证明，对于安全性和可靠性团队来说，细节的问题变得越来越重要。

00:05:35 - Vincent Danen：

当我们在寻找这些漏洞时，我们会发现更多的东西，而且这个趋势还将继续。因为你会发现新的漏洞类型和一些我们可能认为不太重要的东西，或者以前甚至不知道它们存在的东西。我们会发现这些东西发展的速度很快，而且数量更多，因此规模爆炸性增长。知识、软件的数量、消费者的数量都促进了该领域安全性以及漏洞的增加。

00:06:06 - Saron Yitbarek：

一旦你将安全视为一个不断发展的问题，而不是随着时间的推移而 “得到解决” 的问题，那么自动化的理由就会变得更加充分。

00:06:18 - Vincent Danen：

嗯，我认为有了自动化，你可以以一种非常快的方式将这些东西集成到你的开发流水线中，这是其一。其二，你不需要人类来做这些工作，对吧？计算机不需要睡觉，所以你可以在处理器允许的情况下以最快速度浏览代码，而不是等待人类通过一些可能相当乏味的命令行来查找漏洞。

00:06:44：

然后通过模式匹配和启发式方法，甚至在开始编写代码的时候，你就可以知道代码中那些地方是易受攻击的。如果在你编写代码的时候，在你的 IDE 或者工具中有一个插件，它能告诉你。嘿，这看起来有点可疑，或者你刚刚引入了一个漏洞。在你提交代码之前你都可以纠正这些可疑点或者漏洞。

00:07:08 - Saron Yitbarek：

安全在进步。这真是一笔巨大的奖励。

00:07:12 - Vincent Danen：

每一天，甚至每一小时，都会有很多东西涌现出来。通过持续集成和持续部署，你写了代码，10 分钟后它就被部署了。因此，在代码被推送之前自动进行验证是非常关键的。

00:07:32 - Saron Yitbarek：

我们可以使用各种各样的工具来完成这个任务，不管是静态代码分析，还是 IDE 的插件，或者是一大堆其他选项。我们将在 redhat.com/commandlineheroes 上分享一些我们最喜欢的片段。

00:07:53：

一旦我们有了这些工具，它们将帮助我们把安全放在首位。结果就是，DevOps 被重新定义为 DevSecOps。安全被纳入到流程中。

00:08:08 - Vincent Danen：

就像开发人员和运维人员结合的方式一样，你将这两个规则合成到了一个规则。现在，你有了 DevOps，并将安全这第三个组件与开发和运维集成到一起，我认为这非常重要。因为事后才考虑安全性，这会使安全性变得非常被动、昂贵以及可能会损害消费者。当你一开始就把安全代入其中，你就可以完成开发工作，从头到尾进行安全检查并开始运作。

00:08:44 - Saron Yitbarek：

当然，就像我们在这一集的开头提到的，自动化只是一个大蛋糕的一半，而 Vincent 也明白这一点。

00:08:53 - Vincent Danen：

并不仅仅是一部分。不能仅仅在你的 CI/CD 流水线中随便引入一个工具就期望一切都变好。为了达到我们希望看到的最终有益结果，需要使用各种技术和行为。

00:09:15 - Saron Yitbarek：

自动化确实让我们做到了一半，但我们必须记住另一部分 —— 稍微模糊一点的那一部分。让我们一起来说，那就是文化部分，让开发者和运维人员都一起参与进来，这样这些问题就不再是可怕的问题。

00:09:33：

我们必须改变一种文化，而有些人正在学习以一种最不痛苦的方式，通过游戏的方式来做到这一点。

00:09:44：

现在让我们来看看事情的另一面。如今建立庞大的基础设施很容易，但这并不意味着我们应该做粗制滥造的工作。我们仍然应该努力改进我们的系统，确保可靠性，未雨绸缪。这就是 Jesse Robbins 正在努力实现的。

00:10:08：

如今，Jesse 是 Orion Labs 的 CTO，但在此之前，他因在亚马逊被称为灾难大师而名声大噪。在那里，Jesse 特别是在让大家至少意识到这些问题这件事上几乎是个奇才。他通过一个叫做 “游戏日” 的活动来做到这一点。让其中可能涉及成千上万的员工进行故障演练，通过灾难演练来习惯系统被破坏并了解发生的原因和方式。

00:10:39：

下面是 Jesse 和我在讨论，尤其是在运营方面如何建立可靠性和弹性。

00:10:47：

大家都知道你做了很多非常酷的事情，其中之一就是你在亚马逊做的活动 —— “游戏日”。那是什么? 是什么游戏?

00:10:58 - Jesse Robbins：

“游戏日” 是我创建的一个项目，通过大规模破坏来测试最脆弱系统的运行情况。如果你是 Netflix 的 “混乱猴子” 的粉丝，“游戏日” 则是我的一个可以实现类似的所有事情的东西。实际上，它非常专注于建立一种卓越的运营文化，建立大规模测试系统的能力，当系统崩溃时能了解它们是如何崩溃的以改进它们。然后还要建立一种文化，能够对事件做出反应并能恢复。它是按照事故指挥系统建模的，这是世界各地的消防部门用来处理任何规模事故的系统。

00:11:56：

它的诞生源于...

00:11:58 - Saron Yitbarek：

旁白，Jesse 早在 2005 年就经过训练成为一名消防员。在那儿，他了解了这个事故指挥系统，最终激发了 “游戏日” 的灵感。因此，所有做这些故障演练的开发人员，都要感谢 Jesse 对消防和应急管理的激情。好了，回到我们的谈话。

00:12:22 - Jesse Robbins：

弹性是一个系统的能力，这包括人和这些人建立的适应变化、应对失败和干扰的能力。而建立这种文化最好的方法之一 —— 建立一种文化，能够对这种类型的环境做出反应，并真正理解这些环境是如何工作的 —— 就是提供人员培训演习。这些演习可以很简单，比如重启服务器，也可以很复杂，比如关闭整个数据中心造成大规模故障等等。所以，“游戏日” 首先是一个过程。在这个过程中，你通过让整个组织聚集在一起，讨论系统如何发生故障，并思考人类对故障发生的预期。而这个演习本身就是 “游戏日” 开始时最有价值的部分之一。

00:13:24：

但是，当你实际对系统做了一个或大或小的破坏后。当你这样做的时候，你就可以看到每个人是如何反应的。你看到系统崩溃了，可能是之前安全的东西崩溃了，一个很容易理解的组件或者是某个东西暴露了一个潜在的缺陷。这些问题隐藏在软件、技术或者大规模的系统中，只有当你遇到极端或者意外事件时，我们才能发现。“游戏日” 的目的是为了训练员工并且建立系统让你了解他们如何在压力下工作。

00:14:12 - Saron Yitbarek：

所以当我听到 “游戏日” 的时候，我就会想，“这是对某个特定事件的回应吗? 它是从哪儿来的?”

00:14:20 - Jesse Robbins：

因此，“游戏日” 刚开始的一段时间内，因为我知道自己的角色以及作为消防员和应急管理人员的背景，因此将文化方法从注重预防失败的观念转变为拥抱失败非常重要，接受失败发生。激发我这样做的部分原因是我自己的经历，你知道，了解系统，比如建筑是如何倒塌的，市政基础设施是如何倒塌的，以及灾难是如何发生的，以及灾难给人们的压力。所以说，如果环顾我所在工作场所所具有的复杂性和运营规模就会知道，想要真的构建成一个高可靠性、持续在线环境的唯一办法就是拥抱消防服务的方法。我们知道失败会发生，这不是如果的问题，而是什么时候的问题。就像我之前的消防队长说的，不是你选择时机，而是时机选择你。你只需要在它发生的时候准备好即可。

00:15:28 - Saron Yitbarek：

哦，这个不错。所以当你第一次开始做 “游戏日” 并思考如何为灾难场景做准备时，每个人都同意了吗？你得到任何反对意见了吗？

00:15:40 - Jesse Robbins：

每个人都认为我疯了。因此，肯定有人反对。有趣的是，有一种非常简单的方法可以克服这种抵制，那就是首先创造出我称之为 “冠军” 的东西。你要教一小群人，如何以非常安全的方式工作，然后你能够使用一些信服的指标。你能够说，看，让我们只需衡量发生了多少分钟的中断，我的团队经过了这种培训并以这种方式进行操作的停机时间有多少分钟。相反，你的团队没有这个，并且似乎认为进行这种类型的培训和练习没有价值或者不重要。

00:16:25 - Jesse Robbins：

你一旦完成了这种事情，基本上就会有我所说的引人注目的事件。因此，经常会有断电或其他事情让组织突然意识到：哦，我的天哪，我们不能再像以前那样继续做事了。这就是你用来说服怀疑论者的方法。你一方面使用数据和性能数据，再结合指标，然后讲故事，然后等待一个大的故障或者可怕的事情发生。然后，你就可以说，如果我们要在 web 规模或者互联网规模上运维，整个组织都需要这种应变能力。

00:17:06 - Saron Yitbarek：

嗯嗯。所以我喜欢它的原因是它不只是停留在亚马逊内部。相反，它在传播。很多其他公司也在这么做。很多人最终接受了要为故障做好准备这个知识和过程。那下一步是要做什么？我们如何将从 “游戏日” 中学到的知识继续运用到未来的项目和公司中？

00:17:31 - Jesse Robbins：

我喜欢把它称为趋同进化。每个在 web 上运行的大型组织现在都采用了我提倡的事件管理基础的一个版本，并创建了他们自己的 “游戏日” 测试。比如，Netflix 将其称为 “混乱猴子”。谷歌有他们的 Dirt 计划。

00:17:57 - Saron Yitbarek：

那么你对未来的 “游戏日” 有什么寄望呢？

00:18:00 - Jesse Robbins：

首先让我感到兴奋的是，我们可以看到人们从闭门造车思维的转变。系统从根本上是相互联系，相互依赖的，而且由世界各地试图有所成就的聪明人构建和运行的。

00:18:22：

几年前，当我刚参加工作时，对运维工作毫不关心，我觉得那非常无趣。然后突然的，我们发现自己能够传播这样一种理念：开发人员和运营人员一起工作是在互联世界中构建和运行有意义的技术的唯一途径。

00:18:44：

所以我对未来的希望是，第一，我们看到越来越多的人接受这些想法并学习它。明白了当你建造了人们依赖的东西时，你有义务确保它是可信赖的、可用的、可靠的，它是人们可以作为日常生活的一部分来使用的东西。

00:19:05：

而且我们也看到了一种新的学科的诞生。“游戏日” 的这种思维模式正在被研究，也有博士正基于这个撰写博士学位论文。它正在不断建立中。

00:19:16 - Saron Yitbarek：

这真的是太棒了。

00:19:16 - Jesse Robbins：

也有写这方面的书，但是包含这些新资源的没有。只有少数人在会议上谈论他们认为世界应该怎么运转。所以我的那种鼓舞人心的希望是，你要明白如果你正在构建软件和技术，那么你真的成为了社会基础设施的一部分。所以作为一名消防员，我所努力贡献的一系列技能和正在出现的技术，这些技术将使它走得更远，它们是建造人们日常生活所依赖的东西的基础的一部分。

00:19:53 - Saron Yitbarek：

很好。这是一个很好的结束方式。Jesse，谢谢你抽出时间来。

00:19:56 - Jesse Robbins：

是的，谢谢。

00:11:59 - Saku Panditharatne：

我认为所有这些因素都不利于采用最佳软件。

00:20:02 - Saron Yitbarek：

在 Jesse 看来，像 “游戏日” 或者 “混乱猴子” 这样的演习是我们不断发展的科技文化的重要组成部分，但它们对于整个社会也至关重要。我很喜欢他很重视这个，因为他是对的。我们的世界取决于我们所做的工作。早在 90 年代，当电话网络开始崩溃时，这一点就很明显了。

00:20:26 - 众议院小组委员会代表：

我们所知道的现代生活几乎陷于停顿。

00:20:31 - Saron Yitbarek：

这是一种伴随的责任。我们有责任关心安全和可靠性，关心我们所建造东西的弹性。当然，当谈到在 DevOps 中的构建安全性时，我们才刚刚开始。

00:20:53 - Saron Yitbarek：

这是 Josh Bressers。他是数据搜索软件公司 Elastic 的产品安全主管。对 Josh 来说，尽管计算机行业已经成熟了半个世纪左右，但我们在这里讨论的安全问题却让人觉得它是刚刚才出现的。

00:21:11 - Josh Bressers：

实际上，就像我想说也行作为一个专业，安全仍然是非常新的东西，有很多事情我们还不是很了解。

00:21:19 - Saron Yitbarek：

但我们确实明白，在 DevSecOps 的世界中，有一些非常好的机会可以创造性的思考安全能达到什么成就。

00:21:29 - Josh Bressers：

我最近和一些人讨论了一个概念，他们利用用户行为来决定用户是否应该能够访问系统。每个人都有特定的行为，比如他们来自哪里，他们访问系统的时间，他们打字的方式，他们移动鼠标的方式。所以我认为，如果我们做得好，他们的这些行为，可以产生一些非常强大结果，如果我们能做到这一点，我们可以注意到有人在做什么。然后假设我表现的很奇怪，因为我刚刚扭伤了手臂。但你知道，另一端并不知道。

00:22:05 - Josh Bressers：

因此，它可能会说，这种行为就有些奇怪，我们就会希望你使用双因子认证登录，并且还会向您发送条短信或其他内容，对吧？这就从用户名和密码变成了更有趣的东西。所以我认为用新的和独特的方式来看待这些问题将是关键。在很多情况下，我们只是还没到那一步。

00:22:27 - Saron Yitbarek：

实现这一目标需要我们所描述的两大步骤。第一步，就是自动化，这很重要，因为……

00:22:35 - Josh Bressers：

人类很不擅长重复地做同一件事。

00:22:38 - Saron Yitbarek：

很公平。然后，我们有了第二步，就是文化，无论我们的职称是什么，我们所有人都有不安全感和责任感。

00:22:49 - Josh Bressers：

当大多数人想到安全团队时，他们不会认为那是一群快乐的好好先生，对吧? 一般来说，这些人都很可怕，脾气暴躁，令人讨厌，如果他们出现了，就会毁了你的一天。没有人想要这样，对吧?

00:23:10 - Saron Yitbarek：

但我认为我们可以克服这种偏见，因为我们必须这样想——每天都有更多的安全威胁发生，而且 IT 基础设施每天都在变得更大、更强。把这两个事实放在一起，你最好可以生活在一个被安全环绕的世界里。一个非常 DevSecOps 的世界，在这个世界里，开发人员和运营人员都在提升他们的安全，提高他们的可靠性。我所谈论的是一个自动化被整合到每个阶段的未来，每个人对这些问题的态度变得更加全面。这就是我们保护未来系统安全的方法。这是我们保持电话响，灯开，所有现代生活健康强壮的方法。如果你查一下《福布斯》全球 2000 家公司的名单，也就是前 2000 家上市公司，你会发现其中整整四分之一的公司都采用了 DevOps。集成的敏捷工作场所正在成为规则。并且在几年之内，关于 DevSecOps 的思考可能会成为第二天性。我们希望尽可能快，但是当团队中的每个成员都齐心协力时，长距离比赛实际上会更快。

00:24:40 - Saron Yitbarek：

下一集，我们将面临数据的大爆炸。人类已经进入了 泽字节 Zettabyte 时代。到 2020 年，我们将在服务器上存储大约 40 泽字节的数据，而这些信息大部分甚至现在还不存在。但是我们该如何让这些数据有用呢？我们如何使用高性能计算和开源项目让我们的数据为我们所用呢？我们会在 Command Line Heroes 第 6 集中找到答案。

00:25:13 - Saron Yitbarek：

提醒一下，我们整季都在致力于《代码英雄游戏》的开发。这是我们自己的开源项目，我们很喜欢看着它的诞生，但是我们需要你来帮助我们完成。如果你点击 redhat.com/commandlineheroes，你可以发现如何贡献。你也可以深入了解我们在这节课中讨论过的任何内容。

00:25:39 - 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/the-one-about-devsecops

作者：Red Hat 选题：bestony 译者：mrpingan 校对：bestony, wxy

本文由 LCRH 原创编译，Linux 中国 荣誉推出

代码英雄讲述了开发人员、程序员、黑客、极客和开源反叛者如何彻底改变技术前景的真实史诗。

什么是《代码英雄》

代码英雄 Command Line Heroes 是世界领先的企业开源软件解决方案供应商红帽（Red Hat）精心制作的原创音频播客，讲述开发人员、程序员、黑客、极客和开源反叛者如何彻底改变技术前景的真实史诗。该音频博客邀请到了谷歌、NASA 等重量级企业的众多技术大牛共同讲述开源、操作系统、容器、DevOps、混合云等发展过程中的动人故事。

本文是《代码英雄》系列播客第二季（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中国 荣誉推出