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

什么是《代码英雄》

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

本文是《代码英雄》系列播客第一季（7）：开启未来的音频脚本。

想象一下，在这个世界上，开源从来没有流行过，没有人认为将源代码提供给别人是个好主意。在本期节目中，我们将想象这种奇异的可能性。而我们也会庆祝那些让我们走到今天的开源工具和方法论。

加入我们，我们将对第一季进行总结，高屋建瓴地来了解开源世界是如何形成的。下一季，我们将把镜头放大，聚焦于当今的代码英雄们的史诗般的奋斗。

配音：

在一个没有开源的世界里，来自未来的执法者穿越时空去摧毁 Linus Torvalds 的计算机。

Saron Yitbarek：

天啊。我又做了那个噩梦。在梦里，我有一些很棒的想法，但我不能上手开发，因为没有相应的开源技术可以使用。

Tristram Oaten：

我认为一个没有开源的世界几乎注定是邪恶的。

00:00:30 - Saron Yitbarek：

我想，如果软件（LCTT 译注：这里的软件指 MINIX）在 20 世纪 80 年代遭到闭源，而源代码再也没有被打开过，肯定会少很多创新。

Steven Vaughan-Nichols：

那将是一个落后的世界。

Hannah Cushman：

我认为智能冰箱肯定会变得更少。

配音：

在一个没有智能冰箱的世界中。

00:01:00 - Saron Yitbarek：

好吧，好吧。你懂的。我们正在想象一个没有开放源代码技术的世界，这并不特别美好。想象一下：你的在线生活由一些大型私有公司管理，为此你得向它们缴费。网络中的每一处都被它们看守着。对于我们开发人员来说，没有开源的世界意味着更少的自由和影响力。

00:01:30：

在整整一季中，我们一直在纪录开发人员在开源世界中的角色。随着开源技术与工具的不断涌现，我们的工作也不断演进和扩展。无论是敏捷宣言，DevOps 的兴起，还是容器编排，我们宣称的力量和自由都与开源哲学紧密相关。

在本季的最后一集，我们将会回顾前几集中的内容。随着世界走向开源，这个词的原始含义能剩下多少呢？而我们，接下来，则将何去何从？

00:02:00：

我是 Saron Yitbarek，这里是《代码英雄》，一款红帽公司原创的播客节目。第 7 集：开启未来。

Steven Vaughan-Nichols：

没有开源的世界不是我想要的世界，也不是绝大多数人想在其中生活的世界。

00:02:30 - Saron Yitbarek：

这位是 Steven Vaughan-Nichols。你可能在第一集和第二集里谈论操作系统战争的时候记住了他。他是 哥伦比亚广播集团互动媒体公司 CBS Interactive 的特约编辑，从快速调制解调器的速度还是 300 比特每秒时以来，他就一直关注着科技。

Steven Vaughan-Nichols：

除了 Linux 之外，你可能无法叫出任何一个开源程序的名字，但是你当前的生活是建立在开源之上的。

00:03:00 - Saron Yitbarek：

如果不使用开源技术，绝大多数人甚至无法上网。开源技术几乎存在于地球上的每台超级计算机中。它运行在 物联网 Internet of Things （IoT）中。它存在于你的手机、你的 Web 服务器，你的社交媒体———以及，大型强子对撞机中。而且，并非只有我们开发人员了解开源的诸多益处。开源态度现在已经超越了技术的范畴，影响了其它行业，例如经济学、音乐、科学和新闻业。

00:03:30：

如果建筑师以我们分享代码的同样方式分享建筑的蓝图会发生什么？如果一个记者打开她的档案，让任何人不仅可以检查她发表的文章，还能检查她的研究和采访记录，会发生什么？我们不应为此而惊讶，因为开发人员培育这份哲学已有多年。每个人都可以看到代码、注释代码、复制代码、提供补丁，这实际上是一件非常基础的事情，对吧？这就是分享。

00:04:00：

自最早的人类分享膳食食谱以来，我们就知道公开分享指令集，或者说算法，对人类有净收益。在某些方面，开源技术现在能使我们重温这个基本事实。

Hannah Cushman：

我认为，使更多的事物开源会促进和鼓励人们查阅原始资源，这总是很好的。

00:04:30 - Saron Yitbarek：

这位是 Hannah Cushman，她是 DataMade 的一位开发人员，他们一直在努力使城市变得更加开放。将来自政府的大量公开数据进行整理并合理地处理，就可以让普通市民使用它来采取行动。他们使用的技术是开源的，同时他们对政治的态度也是如此。

00:05:00 - Hannah Cushman：

我们在芝加哥与一个叫做 City Bureau 的组织进行了一个项目，和他们一起为公立学校测试铅含量。我们测试了这些学校中几乎全部的供水设备。这些全部公布的测试结果有 500 份 PDF 文件之多。

Saron Yitbarek：

是的，这太好了。但这并不完全是一种使数据公开的有效方式。

00:05:30 - Hannah Cushman：

在整个系统中，很难看到例如哪里发现了铅，以及哪里的铅含量更高。我们使用了另一个叫做 Tablua 的开源工具，可以在终端上运行；它能从 500 多个 PDF 文件中提取数据并将其放在一起，帮助我们把巨量信息转储到一个对人们有用的上下文中。

我认为查询源数据是一种非常有效的方式，这使人们可以了解信息的来源并验证其正确性。

00:06:00 - Saron Yitbarek：

市民可以访问健康报告的详细信息，获取游说者的数据，还可以查看城市政治的整个组织结构，DataMade 为此提供了浏览门户。这使芝加哥人有更多机会对市政的方方面面作出改变。

加州州立理工大学 Cal Poly 的研究软件工程师 Carol Willing 认为，这种不断扩展的开源态度将给世界带来更广泛的变化。

00:06:30 - Carol Willing：

就个人而言，我认为开源将从开源软件发展到开放硬件、开放政府、开放教育、开放协作、开放创新等等。开源会不断进化。

Saron Yitbarek：

现在，开源逐渐变得更像是自然法则，而不仅仅是科技界的产物。

00:07:00 - Carol Willing：

人们慷慨奉献自己时间的事迹古而有之。但令人耳目一新的是，开源深刻地改变了世界，因为它使不同的小群体联合起来，一起致力于他们中任何一组都无法单独处理的大型项目。

00:07:30 - Saron Yitbarek：

“用全新的技术来践行古老的理念”——这个主意我喜欢。但先别急着高兴。随着开源这个词被越来越广泛地使用，它的定义可能会变得模糊。在某些场合下，它开始意味着“免费”，或者“众包”，甚至仅仅是“可定制”。

例如，如果我只是允许你选择在冰淇淋上哪撒些糖粉，这不代表我的冰淇淋是开源甜点。但是，如果我告诉你如何制作糖粉，让你改进我的糖粉配方——然后，如果你也想与他人分享糖粉制作的秘密，那么，恭喜你，我们得到了一些美味的开源。

00:08:00：

那么，开源的原始定义又是什么？它很简单，但我们应当恪守。要实现真正的开源，你需要公开代码，或者蓝图，或者你的菜谱。换句话说，就是使任何人都可以随意研究、修改和重新分发原始数据。这种哲学将带来变革，不过对于命令行外的世界，一切才刚刚开始。

00:08:30 - Thomas Cameron：

这是一种非常惊人的技术开发方式。无论是它的成功，还是我已经参与其中的这一事实，都让我感到震惊。

Saron Yitbarek：

Thomas Cameron 在 1998 年“开源”这个词被发明之前就一直从事开源工作。今天，他是 Red Hat 的高级首席云推广人员。他完全有资格谈论开源在如今的进展，以及其发展的过程中发究竟生了多少斗争。

00:09:00 - Thomas Cameron：

你知道，经理们不想承担风险，这是巨大的阻力。因为它是免费的，所以他们会想，“我没办法打电话寻求技术支持”，“我不得不依靠特定的开源软件”之类。这一类斗争还算简单，在部门服务器、群组服务器、小型 Web 服务器、小型文件服务器和打印服务器上，我们也赢过不少。随着时间的推移，在赢得这些简单的战斗之后，更艰难的战斗出现了。在每次“作战”中，你会发现，系统管理员和系统工程师对开源越来越着迷。

00:09:30 - Saron Yitbarek：

尽管有这些斗争，你也无法否认一直以来的进展。

00:10:00 - Thomas Cameron：

我目睹了开源给 IT 行业带来的改变，它最开始时用在某些系统管理员办公桌下私搭乱建的服务器里，并最终传播到家喻户晓的大公司之中——英特尔、IBM、AMD，每个你能想到的组织都开始为开源项目做出贡献。这绝对是一场斗争，我在不同的企业职位上都参加过如此多的相关争论；我曾说过，“我们需要把 Linux，或其他开源技术，引入数据中心。”

00:10:30 - Saron Yitbarek：

Thomas 观察到，开源软件开发正逐步占据市场。但对于某些人来说，这很令人不安。

Thomas Cameron：

我们能够分享信息与分析结果，这让那些一直占有信息并从中牟利的人感到害怕。这种模式使他们无法轻易获取利润，也难以哪怕得到对一个组织的完全控制，这是巨大的变化，随之而来的是恐惧。

00:11:00 - Saron Yitbarek：

我们在本季开始时描述的支持开源的反叛者们现在领导着这个行业。但从更长远的角度来看，故事绝不会在这里结束。Christopher Tozzi 是 Fixate IO 的高级编辑。他将开源带来的颠覆视为某种根本性转变的开始，这种转变将使世界各地的人们都能协同合作——而不仅是在软件开发行业中。

00:11:30 - Christopher Tozzi：

我认为，在过去的二十年里，开源变得如此强大的原因之一就是人们对去中心化一直保有兴趣。我认为，这也解释了开源如何影响其它技术创新。比如，区块链也建立在这样的思想上：如果我们摆脱集中的生产方式，去中心化的数据库或交易方式可能会更高效、更安全。重申一次，我认为今天的开源，自从 Torvalds 出现以来，就与开发工作的去中心化息息相关。

00:12:00 - Saron Yitbarek：

全面的分权意味着整个世界都在走向开源。体现了这一理念的开发人员，他们是最能想象未来的人。

这是 Tristram Oaten，他是伦敦的一位开发者，他肯定在考虑这场漫长的比赛。

00:12:30 - Tristram Oaten：

就像是 3D 打印机将通过在家生产零件来使我们的生活更轻松——而且多半能更环保一样。无论什么时候有东西坏了，你都可以在家里新制造一个。这是 星际迷航 Star Trek 式的未来的复制器，就和理想中一模一样。希望这样的生产方式能真正投入使用，这样，说不定，整座房子都能变得开源了。

Saron Yitbarek：

Tristram 设想了一个世界，在这个世界上，开源是各个领域都遵守的规则。这意味着，开发者即使不是大师，至少也会成为人们的向导——这种向导是至关重要的。

00:13:00 - Tristram Oaten：

在未来，我们作为开发人员的角色将越加重要，我们会变得越来越像“魔法师”——如果我们现在还不够像的话。

Saron Yitbarek：

好吧，魔法师。我们会成为魔法师。

00:13:30 - Tristram Oaten：

我们能用奇怪的语言驱使机器做奇妙的事，于是，我们会被高薪雇来做宫廷魔法师，或者公司魔法师。当每个人的身体中都有设备，并且无处不在的设备都可以通过互联网访问，还能被远程控制时，我们则需要作为一个团体，一个行会，以最好的信念行事，就像医疗行业要有不伤害他人的宪章等等。这非常重要。

我认为，开发人员需要共同决定不要制造杀手机器人，也不要在每个人的路由器和每个人的助听器中安置间谍软件。我们需要彼此确认，并向所有人保证，我们将为更大的利益而努力，而非为了伤害人类。

00:14:00 - Saron Yitbarek：

让我们现在保证不会造机器人杀手，对吧？好。在此之上，我确实认为 Tristram 说得对。在某些方面，我们开发者已经看到了未来，这代表我们有机会在塑造未来上出一份力。

10 年后，开源开发的道德标准将会是什么样子的？

00:14:30 - Tristram Oaten：

我们现在有着极大的特权，因此，我们有责任做正确的事。

Saron Yitbarek：

那么，魔法师们，我们将去向何方？我们能为开源创造一个健康的未来吗？我想和一个对这一切进行了深入思考的人谈谈，于是，我找到了这一位。Safia Abdalla 是一名软件工程师，她一直在为 交互计划 Interact Project 做开源贡献。我们将会讨论，真正的“可持续的、广泛的开源”会是什么样子。听听看。

在你心里，未来的开源会是怎么样的，和现在有什么不同之处？

00:15:00 - Safia Abdalla：

嗯，我想，我所看到的最大的新兴趋势之一就是对开源可持续性的高度关注，也就是关于如何让开源项目一直得到良好维护和更新的讨论。有一些项目对整个技术界生态都至关重要，讨论也集中于它们。我认为，在该领域，已经有了许多有趣的进展。

00:15:30 - Saron Yitbarek：

Safia 让我思考，如果我们能够建立她所描述的可持续发展的方法，如果公司能够贡献时间、代码和资源，我们的工作能够得到多少改善？又会发生多少变化？所以我问她，这样可持续的方式会给我们所创造的产品，和我们建构的工具，带来怎么样的改变？

00:16:00 - Safia Abdalla：

可悲的现实是，当你没有精力，时间和金钱来为每个人打造好东西时，你就会倾向于只为自己做好它。

Saron Yitbarek：

嗯，确实。

Safia Abdalla：

在这种情况下，你构建的产品会将把很多人排除在用户之外。因此，我相信，如果我们发现开放源代码的更具可持续性的模型，那么我们实际上将开始构建可供盲人、听障者或以其它方式残障的个人使用的软件。

00:16:30 - Saron Yitbarek：

有趣，我喜欢。考虑到开放源代码的原则、流程、文化和社区，以及你提到的所有这些内容该如何适用于技术之外、软件开发之外的行业时，你认为真正可以从开源中受益的领域是哪些？你认为接下来开源可能会出现在哪里？

00:17:00 - Safia Abdalla：

喔，这是个有趣的角度。我第一个想到的是，开源思维可以被用于科学界，使科学变得更加开放。之所以我会想到这一点，是因为，当你以开放方式分享软件时，你所分享的并不是一行行的代码 —— 好吧，你确实在分享代码 —— 但，更重要的是，你在分享知识和细节，在与其他人交流该如何做事。因此，你真正分享的是知识。

00:17:30：

开源的方式可以相当直接地应用于科学界，因为研究人员也会花费大量的时间来探究特定课题，随后就此课题发表论文。而且，我认为，我们需要向科学界倡议更加开放的科研方式，以确保科研成果能够对所有人开放，使所有人都能理解、分享和参与，这将会提高社会对科学的理解，并在一定程度上促进科学研究本身。

00:18:00 - Saron Yitbarek：

当我上大学时，我从事生物化学研究；我非常习惯于带着热情进行实验、研究、尝试新事物。然而，同时，你也不能让人随意插手研究，因为你需要做通讯作者。你需要信誉。这是学术界进步的一个很重要、很重要的组成部分。

00:18:30：

因此，开源的原则——即分享原始数据、贡献劳动，以及将未完成的产品公之于众，依靠集体智慧将其完工的这些原则——和某些更具保护意识的行业必然发生冲突。你如何看待这种冲突？

00:19:00 - Safia Abdalla：

这是个好问题。我认为这涉及一个更大、更复杂的问题。为了成功地将开源引入其他行业，外在的动机和鼓励在很大程度上是必要的。你不能依赖于鼓励人们只专注于自己的目标的现有体系，因为那样会牺牲他人的利益和社会的更大利好。

00:19:30：

我认为，我们必须根本地改变我们看待很多事情的方式，并更改许多体系的运作方式，以使它们关注集体利益而非单一利益。很难撤销像终身教职这样对大学有很多负面影响的制度。很难消除其它可能损害生态、损害他人，或者阻碍社会进步的激励机制。不管是采用开源的思维方式，还是主动取消这些体系，我们都有极长的路要走。

00:20:00 - Saron Yitbarek：

确实。如果你可以从头重新创造开源，那么，属于你的开源版本又会是什么样的？

00:20:30 - Safia Abdalla：

哇噻。关于开源，我要改变的第一件事是它的公共关系和形象。我可能会尝试建立一种开源文化或社区，让人们认识到，你即使不是精英，或者精湛的开发人员，也能活跃并取得成功。现有开源文化中的精英倾向使我感到震慑。

00:21:00：

另外，我也要重点关注开源的可持续性，增加公司的责任感和开源体系的健康程度。我认为很多人没有意识到的事情之一是，许多受欢迎的技术公司和平台都包含了开源要素。例如，有很多 Rails Web 应用程序是极其成功的，盈利能力可观。而且，我认为，对我们来说，重要的是确保这些公司对开源社区有管理权，认识到其价值所在，并给予回馈。

00:21:30 - Saron Yitbarek：

好的，在 Safia 的开源中，企业将会负起责任，并对开源的可持续性做出贡献。项目的贡献者和维护者可能会因为自己所做的工作而获得报酬。这样的开源多半会是更加开放、更具有关怀之心的模式。

Safia Abdalla：

是的。

Saron Yitbarek：

听起来像是一个很棒的开源的版本，我喜欢它。

Safia Abdalla：

谢谢。

00:22:00 - Saron Yitbarek：

Safia Abdalla 是 交互计划 Interact Project 的软件工程师和贡献者。她是一位新一代开发人员。而她在平时也对开源抱有自己的期望。所以，我想向这支新的代码英雄军队大声呼喊：“你们都将会向我们展示未来，因为你们现在正生活在未来之中，而你们也将负责领导我们走向明天。”

00:22:30：

现在，尽管我对开源革命心怀热情，但我也不想成为一个盲目乐观的人。开源也将会受到挑战。开源的存在越广泛，我们就越需要确保它的可持续性。我们找到了一种可扩展的方式来维护开源项目吗？我的意思是，虽然 Linux 内核的贡献者中有一些是全职员工，但是大多数的开源项目仍然是由志愿者维护的。

00:23:00：

开源的工作并不会因为我们不再“反叛”而终结。市值数十亿美元的公司都在运行 Linux，而开源先锋们现在是技术领袖。我们需要跟随这条道路，并试着想象接下来会发生什么。

尤其是，可能会出现什么问题？Christopher Tozzi 告诉我们，曾经作为规则破坏者的开源并不对破坏本身免疫。

00:23:30 - Christopher Tozzi：

开源革命尚未结束，因为挑战并没有停止。即使今天基本上地球上每个使用计算机的人都在以这样或那样的方式使用开源软件，但这并不代表开源必然是绝对安全的。尤其是从致力于开源社区最初目标的人们的角度来看，诸如云计算之类的事物确实使情况变得复杂了。

00:24:00 - Saron Yitbarek：

开源能有多开源呢？Christopher 提到了云计算，而在第六集中，我们描述了依赖于别人的数据中心肯定会使开源最初的目标复杂化。

这是一个棘手的领域，我们仍在了解这个领域的情况。在前进的过程中，我们必须不忘初心。

00:24:30：

每个年轻的反叛者都需要 欧比旺·克诺比 Obi Wan 的原力全息仪。他们会从过去吸取经验教训吗？ 林纳斯·托瓦兹 Linus Torvalds 曾经说过，“在真正的开源中，你有权掌握自己的命运。” 如果开发人员能够在更大的世界中宣扬这种精神，那么，干得漂亮。

00:25:00：

到此为止，这是第一季的最后一集，真不敢相信。这一季过得很快。在着手编写这一系列播客之前，我从没有想过，是谁创造了 DevOps、敏捷开发和云计算；我从没有想过它们从何而来。我从没想过它们会有自己的家，有团队贡献才能、照顾它们，帮助它们成长。它们只是我工具箱里的一堆工具。但我现在不是这样看待它们的。

00:25:30：

它们不仅仅是随机的工具，而是我生活环境的一部分。在我之前，开发者们已经花了几十年的时间来塑造这一局面。现在，我要致力于塑造未来。真是棒极了。

00:26:00：

第一季即将结束，但好消息是，我们已经在准备第二季了。在这七集中，我们专注于开源工具和方法论，这些工具和方法使我们有了今天。这有点像是从 3 万英尺的高度看开源世界的形成史。在第二季中，我们将着眼于细节，并关注当今代码英雄们史诗般的奋斗。我们将跟随每一集，看看开发者如何挑战常规。这些都是塑造我们行业未来的真实故事。

00:26:30：

当我们寻找这些故事的时候，我们很希望收到您的来信。告诉我们，你的代码故事是什么？你参与过哪些史诗般的开源战役？访问 redhat.com/command-line-heroes 留下你的故事。我们正在倾听。

00:27:00：

如果现在你还在听的话，你可能想要看看将于 5 月 8 日至 10 日在旧金山举行的 2018 红帽峰会的阵容。峰会包括为期三天的分组会议、动手实验和主题演讲，其中包括了有关开源的主题演讲，而你也可以参与其中。希望能在那里见到你。

00:27:30：

代码英雄是红帽的原创播客。请确保你订阅了该节目，以在您的设备上免费获取第一季中的所有剧集，并在第二季开始时收到通知。只要在苹果播客、Spotify、Google Play、CastBox 和其他播客平台中搜索《代码英雄》，然后点击订阅，你就可以第一时间收听新一期。我是 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-1/days-of-future-open

作者：Red Hat 选题：bestony 译者：LaingKe 校对：Northurland

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

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

什么是《代码英雄》

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

本文是《代码英雄》系列播客第一季（6）：揭秘云计算的音频脚本。

“没有什么云。这只是别人的电脑。”确切地说，还是服务器。大型云提供商提供了一种相对简单的方式来扩展工作负载。但真正的成本是什么？

在本期节目中，我们将讨论云中的战斗，说谁是赢家还很早。Major Hayden、微软的 Bridget Kromhout 等人会帮我们了解这场正在酝酿的风暴，以及它给开源开发者带来的影响。

Saron Yitbarek：

Ingrid Burrington 想要走进云的世界。不是真实的“一朵云”哟，而是“云计算”的世界。

Ingrid Burrington：

我不知道互联网真正的样子，我也不认为互联网是我想象中的那样，所以我想尝试找出它真实的模样。

00:00:30 - Saron Yitbarek：

Ingrid 是一名记者。在她为《 大西洋 Atlantic 》撰写的系列报道中，她讲述了自己参观一个数据中心的经历，一个我们网络生活越来越依赖的地方。她在那里并不是走马观花逛一圈，而是浸入式的复杂体验。首先，她要拍照登记，申请访客身份卡。然后，要通过安检站，签署一份保密协议。最后，她才能去看机房。机房基本上就像个仓库，就像超市的那样，但比它大得多。

00:01:00：

整个机房看起来有种别样的美，所有的东西都整齐陈列着。一堆光鲜靓丽的服务器上，连接着通往世界各地的光缆，光缆沿着天花板上的轨道整齐布线。正在通讯的光电信号闪烁着点点神秘的蓝光，仿佛粒子加速器一样。但本质上，它是一排排如猛兽般动力强劲的服务器。

00:01:30：

数据中心每年消耗的能源比整个英国还要多。这就意味着它会释放惊人的巨大热量，这就是为什么当 Ingrid 环顾四周时……

Ingrid Burrington：

对的，我发现这座建筑主要的设计理念，是建造最理想最完美的暖通系统（HAVC）。

00:02:00 - Saron Yitbarek：

Ingrid 发现围绕数据中心的一切都强调经济实用，简单说就是一堆主机、一摞风扇、一大块租金便宜的地皮、用很多便宜的用来冷却的工业用水。完全没有“云”这个词本身散发的浪漫，但另一方面，我们的生活、我们的工作以及我们的话语，都在这个服务器的仓库里搏动着。

00:02:30 - Ingrid Burrington：

是的，这有点超现实主义。并不是说我就知道那台机器里存有某人的电子邮件，这台机器又存有别的东西，而是我意识到周围有很多看不见的事情正在发生，我能听到服务器的呼呼声和大量运算产生的微小噪声。说来奇怪，我开始对工业充满敬畏……

00:03:00 - Saron Yitbarek：

时刻要记住，在我们使用服务的时候，它们的基础，这些建筑都在某个隐蔽的角落嗡嗡运作着。以前，当我们谈论在云上存储东西，或创建应用程序时，我们有时会自欺欺人地认为它就像天上的云，是没有人能触碰的存在。但现实恰恰相反，一旦我们认识到云数据中心真实存在于某地，我们就会开始思考谁拥有着云了。那么是谁在控制这些服务器、线缆和风扇呢？

00:03:30 - Saron Yitbarek：

它们是如何改变开发者构建未来的方式的呢？云让我们紧密地连接在一起。

我是 Saron Yitbarek，这里是《代码英雄》，一档由红帽公司推出的原创播客栏目，第六集，揭秘云计算。

Chris Watterston：

没有所谓的“云”。那只是别人的电脑。

00:04:00 - Saron Yitbarek：

Chris Watterston 是一名设计师，他对围绕云产生的误解很是恼火。这个词模糊了数据中心的形象，就像 Ingrid 参观过的那个一样。当 Chris 把这句口号做成贴纸时，他因此成为了网红。“没有所谓的‘云’，那只是别人的电脑。”这句话现在出现在 T 恤、帽衫、咖啡杯、海报、杯垫和许多主题演讲上。

00:04:30 - Chris Watterston：

人们完全不理解云是什么，还用的很欢乐又心安。他们可能完全误解了云，不明白他们的数据实际上是穿过铜轴电缆、或者光纤，来到某一个实际上由他人管理和拥有的存储设备。显然，对于一些有需要隐藏的私人内容的人来说，这是相当可怕的隐患。

00:05:00：

所以，下次你想把东西扔到云上的时候，想想 Chris 的贴纸吧。想想你到底要扔到哪里去。在 App 上工作也是同样道理，声称 App 跟服务器无关的说法都是骗人的，根本没有无服务器的 App。云就是别人的服务器、别人的电脑。不过云这件事情从某种意义上说，是一种成长。说到成长，在整一季节目里，我们会一直追溯开源的成长与变革。

00:05:30：

从最初的自由软件运动到 Linux 的诞生，直至今天，开源工具和方法把我们带到了远离家园的云端。可以打个比方，一个人找房东租房，他需要签合同、搬进去、把房子整理成自己的居所。当开发者寻找云供应商时，他们也在做着同样的事情。这就是我们现在所处的情况，全世界的开发者都在转向各种云上线产品，然后开始明白租赁的真实含义。

00:06:00：

严肃地发问一句，为什么我们一开始就急着跳上云端呢？

Brandon Butler：

因为开发者不想维护 App 运行所需的设备。

Saron Yitbarek：

这位是 Brandon Butler，《 网络世界 Network World 》的高级编辑，多年来致力于研究云计算。

00:06:30 - Brandon Butler：

开发者想要开发 App，部署 App，并只在乎 App 能不能正常运行。我们已经看到云孕育的，越来越多的服务，例如无服务器计算、功能即服务、容器和容器管理平台，如 Kubernetes。

Saron Yitbarek：

顺便打个广告，想了解容器和 Kubernetes，请看我们的上期节目。

Brandon Butler：

所有的这些成果都有助于抽象化 App 运行时所需要的底层基础设施。这将是一个可以在未来可预见的持续发展的趋势。

00:07:00 - Saron Yitbarek：

云拥有巨大吸引力的部分原因，可以用“超大规模”这个词来解释。通过云为你提供的所有基础设施，你可以根据自己的需求，快速创建和定制自己的服务器。你不再需要购买自己的设备，你只需要租赁你想要的规模的云。Brandon 解释了“超大规模”对初创公司的具体帮助。

00:07:30 - Brandon Butler：

使用公有云进行 App 开发的整套模型，对开发者来说是一个巨大的进步。它曾经成就了一系列全新的初创公司，这些初创公司也已经成长为大众都喜欢投资的公司。想想 Netflix 这样的公司，它的大部分后端都运行在亚马逊的以及其他的云上。

00:08:00 - Brandon Butler：

这些公司现在如此壮大的原因，正是因为他们在使用云。因此，云对开发者的影响是不可轻视的。云已经成为过去十年，App 开发领域的主要转变。

Saron Yitbarek：

Nick Bash 是 Meadowbrook 保险公司的一位系统管理员，他还记得在云计算诞生之前，调整基础设施是多么痛苦的事。

00:08:30 - Nick Bush：

以前，有些人想出新项目的点子，我们会说，“这需要硬件支持，而我们没有。”他们会问，“那么我们该怎么办？”我们以前总是受到内存的限制，尤其是运行虚拟机软件，通常是最困难的部分。我们经常需要在任意时间启动虚拟机，但能随时启动的虚拟机数量总是不多。所以我们不得不花很多钱买新处理器、新内存、新硬件，或者花 5000 美元加新的东西。一旦我们从几个不同的供应商得到报价，就得报给管理层，他们要花时间审核。这样，仅仅是购买硬件都需要漫长的过程。

00:09:00：

更不要说构建虚拟机，再反复考虑和测试等等。所以其实我的意思是，有了云，我们可以在几个小时内完成以往需要几个月完成的前期工作。让虚拟机运行起来，第二天就交付给其他人。所以这是一个很大的转变。

00:09:30 - Saron Yitbarek：

在拓展性、速度和价格这些方面，云计算相当吸引人。还是拿租房作比喻，云就像可以让你免费得到一个管家和司机的服务，你很难对云计算说不。如今市场上有主要的四家壮志雄心的云供应商在开疆拓土。他们都想成为你在云上的“新房东”。但是且慢，每个租过房子的人都知道，租房和买房不一样。你不能自己拆掉一堵墙，或者安装一个新的按摩浴缸，你得通过房东来干这些事。

00:10:00：

那么 Brandon Butler 先生，我们使用私有云，在某种程度上会受制于一家独资公司。这会不会对我们不利？

00:10:30 - Brandon Butler：

当你使用云供应商的私有云时，你有不同的使用方法：你可以拥抱开源标准和开源平台，并且在云上运行开源软件，即便这是个私有云；你也可以使用不是开源的原生工具，这些工具可能在公有云上有更好的集成。因此，这是终端用户必须考虑的一个重大问题：我是想使用云供应商的原生工具，这些工具可能与这个云供应商提供的服务，以及其他服务更好的集成；还是拥抱开源标准，使用一个开源平台，享受更大的自由度，在自己和其他提供商的平台上也能运行？

00:11:00 - Saron Yitbarek：

随着我们所依赖的云技术不断发展，四大云供应商相互竞争，我们作为开发者有了新选择。我们是放弃一些独立性，依靠单一的云供应商来保护我们的工作，还是选择另一条路，在保持独立性的同时最大化云的拓展性?

00:11:30：

换句话说，我们能否在租房合同上写明，“房客有权任意处置该房 ，例如拆墙或其他装修”？

00:12:00：

那么，放弃一点点独立性又有什么问题呢？如果你是一名开发者，可能没受到什么影响。因为大多数时候都有运维团队在背后监督开发者们小心行事，他们格外留心于具体细节。这位是 Major Hayden，他是 Rackspace 的首席架构师。

00:12:30 - Major Hayden：

有些时候，开发者经常发现他们有各种不同的需要，比如某些专门化的存储，或者可能想要一定大小的虚拟机，或者想要一种云供应商未能提供的东西。还有一些东西可能开发者没有第一时间想要，但你认为他们需要的，对这些东西你还要进行成本效益分析。好吧，虽然使用公有云我们有很大的灵活性，但我们到底付出了什么代价？

Saron Yitbarek：

Major 指出了另一个问题，这个问题超越了实用性，并且触及了像我这样的开发人员所信奉的核心，那就是开源实践。即使云供应商允许你使用自己的开源工具，但云本身并不是开源的

00:13:00 - Major Hayden：

因此，开源对于云来说是一个需要处理的有趣议题，因为有大量的开源技术支持用户去高效地利用公有云，但并不是所有公有云都把它们的基础设施开源了。举个例子，如果你使用亚马逊，你无法知道他们使用的什么技术来构建虚拟机和其他服务。所以，你不可能对这些东西做点调整，或者很难了解幕后的机理和运作方法。

00:13:30 - Saron Yitbarek：

如果你听过我们之前关于 DevOps 的节目，你会知道打破开发者和运维之间的壁垒会让我们获益良多。架构师 Major 刚给了我们一些真知灼见，接下来的这位是系统管理员 Nick Bush，他所在的团队正准备向云端迁移。开发者们已经厌倦了每五年一次硬件换代，每个人都喜欢尽可能快地扩展，而 Nick 想指出一些开发者可能没有考虑到的东西。

00:14:00 - Nick Bush：

是的。我想说的是，云是存在延迟的。举个例子，就像远在蒙大拿的数据库服务器，对比我在街上用着 10-gig 的网络，本地数据库调用还是会花费更长的时间。要达到低延迟的云内数据库调用还有很长的路要走，还有其他的安全问题，因此我们暂时不需要担心物理上的前提。在本地，我们尚可以控制我们的硬件和其他类似的东西。一旦你进入了云端，你就得考虑连接问题。

00:14:30：

我认为，你也得稍微担心一下安全问题，虽然这更多也是一个成本问题。你想要按月租一个云端虚拟机，要求网速快并且带有充足的存储空间。每千兆的传输和存储都是要花钱的，以前我们都是一次性买断一个机器，我们只要买好了一个云端虚拟机，就可以存储和使用。只要余额和储存空间都还足够，我们就不用付更多钱。

00:15:00 - Saron Yitbarek：

声明一下，Nick 确实认为此事利大于弊。他只是不想让我们认为这是个完美的系统。如果你的云供应商宕机，而你想在其他云中重新部署应用程序，会发生什么情况？或者，如果在不同事务上使用不同的云能带来价格优势呢？运维人员提出的这些问题都可以被总结于一个词汇下，也就是 供应商依赖 vender lock-in 。你可能很熟悉这个词。

00:15:30：

供应商锁定的意思是，在别人的服务器上构建业务会让你越来越依赖于他们的平台。你被绑定在这个平台了。可能突然之间，你被迫升级系统、付出更多成本、接受新限制，你变得身不由己。你懂的。

00:16:00：

当我们都戴上 DevOps 的帽子时，我们开发者和运维就可以一起工作，面对供应商锁定，对症下药，但当我们沉浸在自己的代码中时，我们有时会忘记观览全局。为什么不找个折中方法，同时在公共和私有云上工作呢？终极解决方案可能是混合云，对于两方而言这都是最佳选择。我给 Bridget Kromhout 打了电话，询问她的看法。她是微软员工中的头号云开发提倡者，对这方面非常了解。

00:16:30：

如果我们考虑一种混合的解决方案，既包含一些公有云，也包含一些私有云，这是两者之间的完美平衡吗？对于开发者，这是理想的解决方案吗？如果云是混合的，那么我就能想做什么就做什么，想用什么工具就用什么，同时仍然可以从大型公有云提供商那里获得一些好处。

00:17:00 - Bridget Kromhout：

当然是的。举个例子，我有朋友在制造业中从事高性能计算研究工作，他们有各种各样的绝密资料，像 NDA 这样的东西，不适合放在公有云上。于是，他们可能会在自己的数据中心跟这些资料打交道，处理客户数据，或者研究数据，等等，也可能有其他的……

00:17:30：

他们也有适合放在公有云上的其他工作资料，不过我想这个问题就……有时也会有这样的问题，公有云是否适合某些工作资料，比如，如果你计划使用 InfiniBand 同步你的不同笔记，你能在公有云中做到什么程度呢?

Saron Yitbarek：

但这并不一定是完美的解决方案。Bridget 认为混合云也有自身的弊端。

00:18:00 - Bridget Kromhout：

混合云的问题在于，有时，人们欺骗自己，认为他们可以接受一些实际上不工作的东西，所以如果他们之前等待两周来获得一个虚拟机，如果有人经历过一个完整的这样的情况，并且这个虚拟机还不能正常工作的话，就会有一堆的人由于失望而开始和他们的公有云提供商谈论信用卡问题了，然后他们会试着把这些东西粘合在一起，但是还是有数据来源和延迟的问题，我不是很确定，脱同步的数据集有很多出错的方式。我认为，如果你和云服务提供商合作，你可以有一些可用的直接沟通这样你就可以更好地同步数据，这样是很有帮助的。

00:18:30 - Saron Yitbarek：

是的。当我们在开源的语境下谈到云的时候，我觉得，作为开发者，可能大多数人，都喜欢开源；如果你还在听我们的播客节目，就更是这样。对吧？你希望一切都是开放的，透明的，还向大众共享代码；但我觉得，当我们谈到云计算，因为它不会给人感觉是代码库，不会让人觉得云本身是个项目，它是环境，是可以用来帮助我们运行代码的东西，开发人员们还会坚持要让它像是传统的项目和代码库一样开源、透明吗？

Bridget Kromhout：

我觉得这是一个非常合理的问题，我觉得这可能也会归结到你到底要注目于技术栈的哪一部分。想一想，你对芯片的了解有多少？你又能在何种程度上操控它们？

Saron Yitbarek：

是的，这是真的。你说得不错。

Bridget Kromhout：

他们坐在那里，他们有硅，他们也有秘密。他们不一定会将后者给你。

00:19:30 - Saron Yitbarek

是啊，硅和秘密。顺便说一句，这是个好播客的名字。

Bridget Kromhout：

对吧？也许问题不在于是否一切都是开放的，而在于你需要开放的一切是否都是开放的，以及，当服务没有完全按照正确的方式运行时，你的服务提供者是否会对你保持信息透明，因为不该出的错误就是不该出。

00:20:00 - Saron Yitbarek：

所以，我得到了 Bridget 作为一个公有云提供商的观点，她提出了一个有趣的观点。开发者在云上的控制需要多细？至于我，我的看法不一样。我不想为了一点公有云的优势而牺牲的是什么呢？比如说，一个应用在公有云上运行，然后，等一下，现在我已经扩大了规模，或者有新的合规要求，我的应用在私有云上更合适。

00:20:30：

把应用从一个地方迁移到另一个地方之前，我需要知道它在迁移之后仍能工作。我需要知道它是以原先同样的方式打包，以同样的方式配置。换句话说，我需要知道从一个云跳到另一个云总是可能的。

除此之外，我们还有什么选择？仅仅锁定在一家云提供商？一个甚至可能完全垄断整个行业的供应商？不能选择迁移到另一个环境的话，这就像把一只手绑在背后写代码一样。

00:21:00：

所以，我们不想欠下任何一朵云的人情，并且被它困住。我们希望在合适的时候能够在云间跳转。用摇滚传奇 皇后乐队 Queen 的名言来说，“我想要挣脱束缚”。我们希望能够获得公有云的绝佳拓展性，但又不放弃使用开源工具和方法所带来的自由。

00:21:30：

有个好消息。混合云的建设正在顺利进行中。Mike Ferris，红帽公司的的业务架构副总裁，他给出了一个很好的解释，说明了混合云是如何帮助我们保持开源精神的。

00:22:00 - Mike Ferris：

开源是世界上几乎每一个云服务的基础，现在即便不是大多数，也有许多世界上应用程序的基础设施和工具是从这里发展出来的，管理能力，以及人们用于构建、部署应用程序（无论是任务关键型，还是非任务关键型应用程序）的工具都是基于开源的。

00:22:30：

混合云的概念和这一点非常兼容，这代表着，我们可以在混合云中处处使用开源工具，也可以最大程度地发挥出基础设施的优势。这是基于以下的一点事实：开源通过其在当今的强大影响力，能够在一定程度上定义下一代的开发模式。

Saron Yitbarek：

我认为云计算本身具有开放的意愿。在本季节目中，我们花了很多时间讨论开源的起源。你甚至可以证明，某些版本的混合云是这些相同理想的延伸。

00:23:00 - Mike Ferris：

在过去几十年里，开源开发活动的变化是越来越多的人参与进来了，包括像微软、IBM 这样的行业巨头。你知道，举个大公司的例子，他们要么使用开源软件来提供产品，要么构建开源软件并将其回馈给社区，或者两项都参与。

00:23:30：

这些来自客户的重要需求通过那些大公司涌入，确实帮助了开源世界的发展，使之从最初设想中 Solaris 和 UNIX 的替代方案，发展为不仅是社区和业余爱好者使用，而且肯定也是部分任务关键型企业使用的基础。

00:24:00 - Saron Yitbarek：

开源正在快速成长。现在，我们有机会确保我们记住我们从哪里来。当我们跃上云时，我们可以为自己声明开源的部分，以此来保持云的开放。幸运的是，由于有了 OpenStack® 平台这样的工具，在云之间构建开源桥梁变得更加容易了。Rackspace 的首席架构师 Major Hayden 描述了它的起源。

00:24:30 - Major Hayden：

OpenStack® 来自于 Rackspace 和 NASA 的合作：“你看，这是一种构建基础设施的新方式，我们应该公开进行。我们应该得到更多的投入，应该和更多的人交流。我们应该得到更多的用例。” OpenStack® 是一组应用，它能很好地协同创建基础设施，并全面管理基础设施。无论你需要复杂的虚拟机、复杂的网络，还是有奇怪的存储要求，OpenStack® 通常可以满足大部分的要求。

Saron Yitbarek：

Major 指的是，加入一些开源知道如何提供的东西：也就是适应性。

00:25:00 - Major Hayden：

在我看来，OpenStack® 是一组相互连接的开放源码应用程序，它允许你构建你想要的基础设施。如果它不能建立你想要的，那么你可以进入社区，对它做出改变。我喜欢我去和顾客交谈时他们的反应，他们说，“我们想改变这个。我们想要改变这一切。”我们会说，“嗯，你可以。”

Saron Yitbarek：

我们如何确保这样的的适应性被包含在明天的云中呢？就像我们在之前的节目中谈到的许多问题一样，这需要强大的社区。有请 Brandon Butler，《网络世界》的高级编辑。

00:25:30 - Brandon Butler：

例如，我们已经看到了云原生计算基金会的成立，这个基金会制定标准，推广应用容器的使用，并创造了 Kubernetes。我们也看到了 OpenStack 基金会的成立，好将 OpenStack® 用户聚集在一起，讨论创建开源基础设施服务云时的最佳实践。

00:26:00：

支撑这些开源社区的社群对于开发下一波开源工具，学习如何最好地使用这些开源平台的，以及鼓励公有云厂商接受这些开源标准都非常重要。

Saron Yitbarek：

一旦我们开始构建混合云，并使其尽可能地开放，潜力似乎真的无穷无尽。Major，请说。

00:26:30 - Major Hayden：

最让我兴奋的是看到更多的东西可以聚集在不同的云之上。例如，OpenStack® 提供了一个很好的基础设施基础层，但是你可以在它之上做很多事情。我想有时候不同的公司会采用 OpenStack®，然后说:“伙计，我现在该怎么办？我的自由程度太高了。我不知道该怎么办。”这就像你有一个装满食物的冰箱，你会想，“啊，我不知道该做什么菜。”

00:27:00 - Saron Yitbarek：

我喜欢这个问题。Chris Watterson 告诉我们的可能是对的。

Chris Watterston：

没有所谓的“云”，那只是别人的电脑。

00:27:30 - Saron Yitbarek：

但故事并未在此结束。我们要与混合云一起跨入下一章。创建混合云应用的关键可能还没有被破解。跨多云管理任务，对于今天的代码英雄们来说将是一项艰巨的任务。会有很多尝试和错误，但这是值得的，因为我们知道的唯一的一件事是，保持开源意味着开发人员总是可以构建他们想要工作的世界。这种灵活性正是紧紧抓住开源最擅长的叛逆精神的诀窍。

00:28:00：

下一集是我们本季的最后一集，我们将以一种让你惊讶的方式，从宏观角度来看开源作为一种全球现象是什么样的。我们也将展望开源的未来，我们的开发人员如何保持像 Linus Torvalds 这样的英雄的精神，即使当他们正在重塑他们的行业时。

00:28:30：

《代码英雄》是一档红帽公司推出的原创播客。想了解更多关于本期和往期节目的信息，请访问 RedHat.com/CommandLineHeroes 。在那里你也可以注册我们的新闻通讯。想免费获得新一期节目推送，请务必订阅我们。只要在苹果播客、Spotify、Google Play、CastBox 和其他播客平台中搜索《代码英雄》，然后点击订阅，你就可以第一时间收听新一期。我是 Saron Yitbarek。感谢你的聆听，编程不止。

OpenStack® 和 OpenStack 标志是 OpenStack 基金会在美国和其他国家的注册商标/服务标志或商标/服务标志，并经 OpenStack 基金会许可使用。我们不是 OpenStack 基金会或 OpenStack 社区的附属机构，也没有得到 OpenStack 基金会或 OpenStack 社区的认可或赞助。

什么是 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-1/crack-the-cloud-open

作者：Red Hat 选题：bestony 译者：LikChung 校对：acyanbird

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

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

什么是《代码英雄》

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

本文是《代码英雄》系列播客第一季（5）：容器竞赛的音频脚本。

容器的兴起为开发者们打开了一道新的大门，它简化了在机器与机器之间传递项目的成本。随着它变得广受欢迎，一场大战也悄悄拉开帷幕。这场战斗的奖品是容器编排的控制权，参赛者包括这个行业最快最强的玩家。

容器是开源运动中最重要的一项突破之一。在这一集里，特邀嘉宾 Kelsey Hightower、Laura Frank 和 Clayton Coleman 将告诉我们容器如何为未来添砖加瓦，以及编排技术为何如此重要。

Saron Yitbarek：

你有看过赛马吗？赛马们排成一行，蹄子刨着脚下的土壤。你可以想象出这么一副画面。比赛即将开始，在这些竞争者中脱颖而出的将是优胜者。

00:00:30：

不同的是，比赛的不是马。而是科技世界的诸侯。那么是什么让比赛如此重要？是怎样的珍贵的奖励，才会让这些参赛者们排着队，迫不及待地想要得到它? 这是一场赢家将掌握容器编排技术规则的竞赛，而且胜利者只有一个。重要的是，不同于其他的比赛，赢得这场比赛，你不仅仅会成为今天的冠军，更有可能在来持续领先。

00:01:30:

我是 Saron Yitbarek，这里是代码英雄，一款红帽公司原创的博客。

第五集，容器竞赛。上一集我们见证了 DevOps 的崛起，以及一组新工具如何影响了其他人对开发者这一概念的看法。在这一集栏目中，我们会追溯容器技术崛起的历史，讲述容器技术如何通过拥有支持全新工作的可能性，来进一步扩展开发者这一角色的概念。然后我们会一起见证容器标准化是如何为容器编排奠定比赛基础的。

00:01:30：

这是一场严肃的比赛，也是一场全球性的比赛，吸引了行业里最快，最强大的选手。他们都准备好了为冲刺终点线而奋力一搏。准备好了吗? 比赛开始了！

现在，随着这些“赛马”离开起点，也许我们应该弄清楚为什么这场比赛如此重要。谁会关心容器呢？好吧，算我一个。但是实际上，一开始我也并不知道容器是什么。以下我将讲述一个小故事 —— 我是如何醒悟容器之美的。

00:02:00：

不久之前，我还在为我网站写代码，然后有天我让我的朋友 Nadia 过来实现一些新的功能。我在保持代码干爽和可读性方面做得很好，当然，代码也经过了很好的测试。所以再加入一个新的网站开发者也不是一件难事。对吗？如果你也这样以为，那就错了。这是一个非常繁琐的过程，特别是当我们跑规范化测试时，这个问题尤为明显。

00:02:30：

代码运行正常，但我们不能在两台电脑上同时通过所有测试。我们有很奇怪的电脑时区设置问题，而且她的 Ruby on Rails 版本跟我的不同。就是一个很经典的问题：“我的电脑上可以代码运行”，“可是在我的电脑上就是不行”。我只好对代码做一些修改，直到它在我这里正常运行，但当我把它发送给 Nadia 时，程序又会崩溃。

00:03:00：

我很清楚，我和 Nadia 所碰到的这些问题，对于所有的开发者来说都或多或少经历过，甚至他们把这种经历当作玩笑来讲。有时候，我只能把这个当做是在我工作时必须要忍受的一部分。我没有意识到的是，这个问题有个最终解决办法。想象有一种方式可以降低人与人之间的隔阂；想象有一种方法可以让我们在开发中使用任意喜欢的工具，并且在传递工作成果时毫无阻碍；想象一下有一种办法，无论有多少人同时进行一个项目的开发，不管这些人散布在世界何地，都可以让项目从开发到测试，再到生产环境，保持连贯性。如果在我浪费好几周，用最笨的方式传递工作成果前就想到了容器该多好。

00:03:30 - Liz Rice：

一个容器实际上就是一个进程。

Saron Yitbarek：

Liz Rice 是 Aqua Security 的一名技术布道师。她描述了为何容器会如此实用。事实上容器把一切打包到了一个整洁、并且可以迁移的包中。

00:04:00 - Liz Rice：

这就像任何其他的进程一样，不同的是容器的世界非常小。比如，如果你启动一个容器，进程会被授予它自己的根目录。然后它认为自己在查看的是整台计算机的根目录，但实际上它只是在查看这个文件系统很小的一个子集。

00:04:30 - Saron Yitbarek：

通过打包一个可执行文件及其所有的依赖，容器可以在任何笔记本或者云中的虚拟机上运行。带着它自己的执行文件、库和依赖。所有的一切都包含在了容器中。所以，这就是容器神奇之处，容器在每个环境中的运行都会完全一样。这也就意味着开发者可以轻松地分享并协作应用开发，而不用担心计算机之间相互不兼容这个老问题。

00:05:00：

举一个类比的例子希望能够帮助你理解。你有听说过 蓝围裙 Blue Apron 这个服务吗？该服务提供你做饭所需的一切，包括精心按照菜谱卡片搭配好的，所有做饭需要的原料。好的，想象一下如果蓝围裙所能带给你的不仅仅只是还没有处理过的食材，而是一整个厨房，有煤气灶，还有你所需要的全部餐具，一切你需要的都会装到小盒子里，放在门阶上。这就是一个容器。在我提到的那种情况下，容器技术就可以很好地解决 Nadia 加入进来时所碰到的问题，简单到像使用蓝围裙服务做一顿晚餐一样。虚拟机同样也可以提供一个预装好的环境。但要解释这个，我们就不得不抛弃蓝围裙这个比喻，让我们来看一看具体的细节。

00:05:30 - Liz Rice：

许多人都认为容器是某种轻量级的虚拟化技术、轻量级的虚拟机，事实上并不是。容器与虚拟机有很大不同。虚拟机有独属于自己的一整个操作系统，相比起来容器是共享操作系统的。一个计算机上的所有容器共享同一个操作系统的。

00:06:00 - Saron Yitbarek：

最后一点，容器和虚拟机可以并肩工作。容器不能替代虚拟机。虚拟化技术仍然可以提高过时系统的效率，并且对于服务器整合非常关键。但容器技术的兴起也为我们打开了新的大门。不妨这样想，如果我们全部依靠虚拟机的话，运行所有仿真服务器将产生大量的额外负担。

00:06:30：

一台虚拟机的大小至少是以 G 为单位的，然而一个容器可能也就只有 20 M 左右。一台虚拟机可能会需要若干分钟来启动，如果我尝试用它部署一个网页应用的话，这可不是一个好消息。很长时间以来，人们都期盼一个轻量级的、更快速的完整机器虚拟化替代方案出现。

00:00:07：

回顾一下历史，1979 年就出现了容器的原型。Unix V7 的开发者们设计了一种根系统调用，使环境中只包括特定的程序。该突破为我们现在看到的容器技术指明了道路。另一个巨大的进展来源于 2008 年的 Linux 容器技术。现在，我们有了操作系统级的虚拟化技术。

00:07:30：

我们终于可以在一个单独的 Linux 内核上运行多个容器，而无需使用完整的虚拟机。这也就意味着程序对于基础架构的需求逐渐减少，但不是每一个人都能立马看到容器技术的潜力。

Laura Frank：

容器化真的是前所未有的、崭新的一个天才般的想法。

Saron Yitbarek：

Laura Frank 是 CloudBees 的技术总监。

00:08:00 - Laura Frank：

只有少部分人了解容器技术的来龙去脉，并可以运用它。不过相信随着时间的推移越来越多的人会接触到容器化的概念，随着越来越多的人开始使用这项技术，并且这些知识通过工程团队和工程组织，通过社区进行传播，就会变得更容易获得。

Saron Yitbarek：

因为和我们之前提到的与虚拟机的相似性，Laura 认为，因为我们之前提到的容器技术与虚拟机的相似性，容器的潜力被低估了。

00:08:30 - Laura Frank：

我在回想我的职业生涯，那是我还只是个普通的日常技术人员。如果你不是一个系统管理员或者 Linux 资深用户的话，容器还是一个你刚刚了解到的全新概念。我把它理解为使用一台虚拟机模式类似的东西，我可以去建立一个可以用完即弃的环境，而且这个环境完全独立，清理之后不留痕迹。

Saron Yitbarek：

容器除了能保持系统整洁之外，其实还大有可为。容器将会革新整个行业，并且随着开源项目和社区的兴起，在不久之后，容器标准化的充分实施将变为可能。

00:09:00 - Scott McCarty：

整个界面已经变得非常简单。

Saron Yitbarek：

Scott McCarty 是红帽的一名资深的容器策略顾问。他称得上是这个行业的资深人士，他在容器出现前，甚至是虚拟机出现前，就在做这方面的工作了。

00:09:30 - Scott McCarty：

在互联网 1.0 时代，我在一家线上零售商工作，我们有上千台实体机，我们用不同的方式，在所有这些不同的服务器上一遍又一遍地安装相同的软件。我们尝试了所有的方法。当你从原始的操作系统迁移到虚拟机，然后再到 Linux 容器、Solaris 容器，同样的问题一再出现，你仍然不得不在不同的虚拟机，或者类似操作系统实例的结构体之间管理配置。

Saron Yitbarek：

一旦容器变的规范化，一切都将改变。

00:10:00 - Scott McCarty：

比如，有了很多非常标准化的方式可以去处理现在这些打包好的应用，我认为容器技术的出现，从根本上改变了一切。它使得那些应用非常容易使用，而且容器还不会对系统本身造成损害，同时相比虚拟机更加小巧快捷。

00:10:30 - Saron Yitbarek：

借助 Linux 容器带来的进步，这些新的开源项目和社区使得开发者们可以更好地携手合作。很多我们对于后端的焦虑都被一扫而光。突然间，容器和由它促进的微服务变得十分有吸引力。一旦一种共同的容器语言出现了，障碍就消失了，与此同时容器技术改变了我们的工作方式，也改变了我们学习新技术的步伐。

00:11:00：

还记得之前我和同事 Nadia 遇到的反复出现的问题吗？“在我这代码能跑”的场景？在容器的世界，这个问题将不复存在。相比于我们之前使用的标准的操作系统，开发者社区见证了容器是如何变得更加快速，成本低廉，并且容易使用的 —— 比传统操作系统更加容易。容器技术被采纳的速度十分惊人。但是要记得：容器标准的出现仅仅是容器编排这场竞赛的热身。

赛马们已经整齐排列好，随着信号枪一声令下，它们为了这场比赛的冠军而拼尽全力。竞争的不是容器本身，而是我们部署和管理容器所使用的工具。

00:11:30：

我是 Saron Yitbarek，这里是代码英雄。在这场标准容器编排竞赛中，哪位会胜出成为管理所有容器的平台呢？起初有两位竞争者处于领先地位。

00:12:00：

由 Apache 驾驭的 Swarm，和 Docker 驾驭的 Mesos。但是等等，怎么？现在出现了一匹黑马改变了这个格局，那就是谷歌。Linux 设立了云原生计算基金会（CNCF），随后 CNCF 推动了谷歌开源的编排引擎 Kubernetes。

00:12:30：

现在，相比 Kubernetes，Mesos 和 Swarm 已经抢占了先机，对吗？它们得到了 Apache 和 Docker 的支持，已经入场了一段时间了。但是 Kubernetes 有其他的“赛马”所不具备的优势。Clayton Coleman 会告诉我们这个秘密是什么。Clayton 是红帽负责 Kubernetes 和 OpenShift 的一名架构师。

00:13:00 - Clayton Coleman：

在 Kubernetes 诞生之初，谷歌就在项目的开放上做的很好，它降低了项目的贡献和参与的难度。谷歌极其关注让开发者和运维人员能更加容易地开展工作。有这样一个强烈的关注点，就是要做一个能让大多数开发者和运维的生活更轻松的东西。我觉得 Kubernetes 和围绕着Kubernetes 的社区找到了一个足够好的方式，让大部分人参与进来，他们让 Kubernetes 具有足够的可扩展性，还可以解决一些极端的用例。

Saron Yitbarek：

在早期，来自于红帽、CoreOS 和谷歌的工程师们都参与到了 Kubernetes 的开发中。随着 Kubernetes 开发到 1.0，不管是初创公司还是大公司都参与其中，一起构建和完善它。关键的是，所有这些增长从来都不是只归功于谷歌或者任何一方。

00:13:30 - Clayton Coleman：

在这个例子中，我喜欢以 Linux 打比方。Linux 并不是始于 Linus 开始编写内核，然后告诉所有人，在用户空间如何写 GCC，如何去建立 NGINX 或者 Apache。相反，内核团队专注于建立一个高效的操作系统内核，并与其他诸如 GNU 项目的开源社区合作，并且将可以在其他 Unix 系统上工作的工具引入 Linux。

00:14:00：

因此，我们如今所使用的许多工具，都不是 Linux 核心团队交付的。

但是 Linux 作为一个整体，相比于其内核涵盖的范围要宽泛得多，而且我认为这种模式的优势是 Kubernetes 取得现在成就所不可或缺的。当我们建立社区并且专注于 Kubernetes 范围时，我们可以试图从“Kubernetes 内核”的角度来考虑它，这是分布式集群操作系统的内核。

00:14:30 - Saron Yitbarek：

Kubernetes 证明了自己在开源世界中建立社区的能力，令人难以置信。正如我们在操作系统之战中谈到的 Linux 崛起一样，现如今这场关于容器的战争中，获胜者往往懂得如何借助社区力量。事实上，尽管谷歌可能开创了 Kubernetes，但目前它属于每一位开发者，并由云原生计算基金会（CNCF）管理。

00:15:00：

在 GitHub 上，Kubernetes 有大约 3 万的星标数，而 Swarm 和 Mesos 只有数千，这已经很能说明问题了。这就是由社区所生，为社区所用的技术。

我想了解谷歌的态度，一个如此庞大并且以效益为导向的大公司，是怎么做到如此擅长跟其他开发者合作的呢？我找到了很适合回答这个问题的人 —— Kelsey Hightower，他是谷歌负责容器技术支持的技术专家。

00:15:30：

想想谷歌的地位：它在分布式系统领域具备丰富的经验，还运行着分布在世界各地的许许多多的服务器，因此它开发的 Kubernetes 似乎有着很大的优势，并且有信心一定能在这场容器竞赛中胜出。那么，当你想到 Kubernetes 和开源时，你是如何看待这种关系的？

00:16:00 - Kelsey Hightower：

我想当谈到基础架构工具，甚至编程语言时，大家没有什么选择 —— 你不可能用个专有工具，即使它很棒。如果它不是开源的，大多数人可能甚至都不会想去了解。而且我认为这也是大多数人会采用像 Kubernetes 这样的基础架构工具的原因，你可能会对自己说：“好吧，我们就要坚持使用这个版本四、五年，也可能我们需要根据自己的一些独特需求来对其进行修改。”

00:16:30：

一旦走到这一步，就很难说服企业接受，“嘿，每台服务器使用程序的价格是 200 美元，而且你看不到源代码，所以有需要的话也必须等我们来修改”。

那样的日子一去不复返了，所以我不确定是否真的可以在没有开源的情况下建立基础架构。开源的另一个意味是拥有一个与项目紧密联合的社区，所以我认为 Kubernetes 一开始就锁定了胜利。

Saron Yitbarek：

让我们回到这场容器竞赛。在这里不仅仅有你提到的 Kubernetes，还有 Docker 的 Swarm Apache 的 Mesos……

00:17:00 - Kelsey Hightower：

所以，我想当人们谈论容器竞赛时，我不确定竞争是否发生在我们和 Mesos、Docker 使用者之间。我认为，真正的竞争发生在争取目前没有使用容器的潜在用户身上。是的，你还在使用原生 Bash 脚本，你迷茫着，不知道自己该归属何方。这些尚未选择编排工具和平台之人的市场，比起已选择了 Mesos 或 Swarm 的一方，要多得多。

00:17:30：

这就是容器战争存在并将继续的原因，真正的关键点在于如何帮助最终用户。Mesos、Kubernetes 或 Docker Swarm 是否会成为寻求更好解决方案的人们的首选？这一切都还悬而未决（SIG 译注：现在已经尘埃落定，Kubernetes 取得了全胜），但我会告诉你，像我一样，在这个领域工作的工程师来说，如果你不考虑市场营销和供应商，我会使用这个短语“不同的公司，相同的团队。”

00:18:00：

我们为彼此开发了许多工具，最终以某种方式出现在其他产品中。没错吧？好主意就是好主意。没有理由说，“哦，这是 Mesos 的人正在做的事情，那就忽略吧”，这有点愚蠢。所以从技术和社区的角度来看，我们的想法需要交流。同时也需要竞争来迫使我们来进行独立思考，然后最棒的点子就会浮出水面，接着我们再选择采用哪种方式来正确满足用户的需要。

00:18:30：

因此，就这场竞赛而言，仍处于初期阶段，而且这个事情本身不会带来利润。明白我的意思吗？我们不是直接向任何人销售这个产品，这更像是一个平台之间的游戏，对所有人开放，然后用户会选择满足他们需求的那个，这就是我认为 Kubernetes 在社区方面做得很好的地方，真正开放，真正能解决实际问题。

Saron Yitbarek：

听起来很棒啊。我喜欢这个想法：在同一个球队踢球，而不要管球队是在什么地方。你对于容器和编排工具，还有 Kbubernetes 的未来有什么展望吗？

00:19:00 - Kelsey Hightower：

是的，我在 KubeCon 上做了一次主题演讲。所有这些工具都很棒，它们就像是乐高积木，我们有 Kubernetes，你可以选择一种产品用于安全，选择另一种产品用于网络，但最终，作为开发人员而言，你所想要的只是检查你的代码，并希望你的代码可以某种方式以呈现在客户面前。而我认为 Kubernetes 还有容器都会作为底层技术或者成为类似 Serverless 这种技术的基础平台。

00:19:30：

这是我的代码片段，已经打包完毕了。所有的平台都会把你的代码片段，用容器包装起来，然后帮你运行，但是不需要向你公开所有这些过程。因此，在未来，我认为随着 Kubernetes 变得普及，容器的应用场景将从大大小小的供应商或个人，提升到云供应商，因为这些事情往往需要专业知识和软件投资。容器将会遍布各个角落，但同时也就此隐藏起来。它会随着应用场景的扩展而渐渐隐形。

00:20:00 - Saron Yitbarek：

Kelsey Hightower 是 Google 的员工开发人员。在 2017 年秋天，Docker 宣布支持 Kubernetes。他们并不是说就放弃 Swarm 了，只是决定与容器编排竞赛的明显赢家和解。

00:20:30：

并不只有它一方，Azure 和 AWS 都宣布了对 Kubernetes 的支持。与此同时，像 OpenShift 这样的 Kubernetes 发行版仍在不断发展。我们得到的是一个可以扩展，支持新的用例的 Kubernetes 内核，这些用例包括微服务或持续集成项目。

00:21:00 - Clayton Coleman：

这个生态系统在类似 Linux 的模式下能得到最好的发展，而且我认为我们正朝着这条道路迈进。因此，就像所有优秀的开源项目一样，相对于单打独斗，让每个人都能够参与进来构建更好的东西，那就算是成功了。

00:21:30 - Saron Yitbarek:

所有这一切都在快速发生着，毕竟，这是一场竞赛，而这正是我们期望能从开源中获得的东西。在我们才刚刚理解什么是容器时，第一轮几乎就结束了，

这是来自 Red Hat 的 Scott McCarty。

Scott McCarty：

回想一下两年前，容器镜像格式还是一个巨大的战场，然后回到六个月至一年前，容器编排就成为了下一个巨大的战场。紧接着，如果你看看 2017 年的 KubeCon 及前几周，几乎每个主要供应商都宣布支持 Kubernetes。因此，很明显 Kubernetes 在这一方面上获胜了。

00:22:00 - Saron Yitbarek：

这章关于容器战争的故事即将结束。就像容器技术的开始一样迅速。

Scott McCarty：

因此，Kubernetes 已经成为标准，其美妙之处是，现在的应用定义已经变得标准化了。因此，任何人都可以在这些 YAML 文件中使用 Kubernetes 对象并定义应用，这就是我们共同所追求的事情。事实上，对于容器技术足够处理处理大型扩展系统这件事，我已经期待了 20 年。

00:22:30 - Saron Yitbarek：

Kubernetes 的成功看起来板上钉钉，但即使竞赛尘埃落定，我们仍然面临更大的一些问题。容器是否会成为未来几年的默认选择？是否会促使更多的云原生开发？这些转变将促生哪些工具和服务上？以下是我们目前所知道的。

00:23:00：

社区将通过 CNCF 继续改进 Kubernetes，并作为它最重要的使命之一，我们将建立一套全新的容器技术。

容器已经催生了大量新的基础设施，伴随而来的是全新的服务的需求。举个例子让你感受下容器的整合程度和发展速度，仅 Netflix 每周就运行超过一百万个容器。毫不夸张得说，容器是未来的构件。

00:23:30：

这一整季的栏目中，我们一直在追踪开源运动的演变。首先看到 Linux 如何主导战场，以及开源理念是如何改变商业、工作流程和每日使用的工具。容器真的是开源运动中最重要的里程碑之一。它们具有很好的迁移性、轻量、易于扩展。

00:24:00：

容器技术很好地体现了开源的优势，开源项目自然而然也推动了容器技术的发展。这是一个全新的世界，我们不用再担心从不同计算机或者云间的迁移产生的隔阂。

00:24:30：

容器的标准化比任何人预测的都要快。接下来的一集，我们将转向另一场悬而未决的战争。这场云间战争史无前例地催生者行业重量级人物。微软、阿里巴巴、谷歌和亚马逊四家云供应商的摩擦正在升温，随之而来的将是一场暴风骤雨。我们将会追随它们激发的闪电，和广受欢迎的几位代码英雄一起探讨云间战争。

00:25:00：

《代码英雄》是红帽公司推出的原创播客栏目。想要了解更多关于本期节目和以往节目的信息，请访问 redhat.com/commandlineheroes 。在那里，你还可以注册我们的新闻资讯。想免费获得新剧集的自动推送，请务必订阅该节目。

只要在苹果播客、Spotify、Google Play、CastBox 中搜索 “Command Line Heroes”，或者通过其他方式收听，并点击订阅，这样你就能在第一时间知道最新剧集。我是 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-1/the-containers-derby

作者：Red Hat 选题：bestony 译者：lujun9972 校对：acyanbird

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

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

什么是《代码英雄》

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

本文是《代码英雄》系列播客第一季（4）：DevOps，拆掉那堵墙的音频脚本。

当应用开发的争斗暂告一段落，横亘在开发者与运维之间的那堵墙开始崩塌。在墙彻底倒塌的时候，墙两边的人都应该学会如何合作，彼此变得亲密无间。

不过到底什么是 DevOps？开发者一方的嘉宾，包括来自微软的 Scott Hanselman 和 Cindy Sridharan（即 @copyconstruct），他们从开发者的角度认为 DevOps 是一种惯实践。而来自运维一方的成员则他们一直在努力捍卫的东西。双方依然存在差异，不过因为 DevOps 的诞生，大家的合作效率会比之前更上一层楼。这集节目讲述了这种方法的诞生对于大家有多重要。

Saron Yitbarek： 请你想象这样一堵墙：这堵墙从你目之所及的最右侧延伸到最左侧。墙比你高，你无法看见墙背后。你知道墙的另一侧有很多很多人，但你不清楚他们是否和你一样，不清楚他们是敌是友。

00:00:30 - Gordon Haff： 开发者创造代码，然后把代码扔过墙丢给运维，之后发生的问题都是运维的责任了。

Richard Henshall： 他们随心所欲，并不真正关心服务质量。

Sandra Henry-Stocker： 墙这两面的人几乎做着相反的工作 —— 一方做出改变，另一方尽可能抵制那些改变。

Richard Henshall： 但对于他们到底想共同达成什么，却没有在同一幅蓝图中规划过。

00:01:00 - Saron Yitbarek： 我是 Saron Yitbarek，这里是《代码英雄》，由红帽公司推出的原创播客栏目。第四期，我们的标题是《DevOps，拆掉那堵墙》。

是的，数十年来，IT 界划分为各种角色。一边是开发者，他们要尽可能快地去创造更多变化。然后另一边是运维团队，他们要去阻止太多改变发生。与此同时，代码在没有充分共鸣和沟通的条件下，被盲目扔过两方之间的墙。怎样才能拆掉这堵墙呢？这需要一个重大的转变。

00:01:30 - Saron Yitbarek： 开源运动震撼了整个战场。上一期，我们看到了新的敏捷方法论，它重视不间断的迭代改进，而这种对速度的要求将迫使我们改变彼此的工作方式。一群彼此孤立的人工作的速度是有极限的，而这个极限是一个问题，因为……

00:02:00 - Richard Henshall： 因为都是为了更快的将产品推向市场、提高敏捷性、更多的迭代，而不是长期而大量的工作。

Saron Yitbarek： Richard Henshall 是 Ansible 的一位产品经理。

Richard Henshall： 是的。还记得你以前下单购买服务器，四个月后到货。所有东西都整合在一起，所以整个堆栈是一个整体，要花几年时间来设计和建造那些东西。现在这种情况已经不存在了，对于很多组织来说，这种方法已经……已经寿终正寝，偶尔拿过来试试，然后放弃它。

00:02:30 - Saron Yitbarek： 如今，像亚马逊这样的公司每分钟都会部署几次新的代码。想象一下，用按部就班的瀑布式工作流，简直不可能完成这些工作。所以为了继续快速完成工作，那些关于稳定性、安全性、可靠性的顾虑都会被运维丢到一边不管。

00:03:00 - Saron Yitbarek： 同时，开发者也没有意识到他们的责任是创造真实环境可用的代码。开发者对稳定性和安全性毫无兴趣，但这些恰恰是我们需要解决的问题。所以，我们最终会有很多无谓的修改，在双方之间来来回回。

想象一下过度分工会如何拖慢公司效率，但开发法者很少被鼓励思考除代码之外的其他事务。

Sandra Henry-Stocker： 他们的目录规模只会越来越臃肿，但他们从不清理。除非已经无法工作才不得不清理。

00:03:30 - Saron Yitbarek： Sandra Henry-Stocker 是位退休的系统管理员，为 IDG 杂志撰稿。

Sandra Henry-Stocker： 我过去经常劝说别人，说，“嘿，你看，你用了这么多的磁盘空间。是不是有什么东西你可以整理一下，这样我们就有更多的存储空间来运行了 —— 因为服务器上的存储空间快用完了。”是的，我们经常经历这些事。

Saron Yitbarek： 归根结底，这是一个心态问题。这种开发者和运维之间的态度分裂，一方不必去理解另一方的担忧。好吧，在过去这还没太大问题，但随着开发速度成为一种重要的优势，这种分裂的文化急需改进。孤立在自己的工作圈子里，效率太低了。

Jonah Horowitz 在 Stripe 的可靠性工程团队工作。他描述了即使开发人员和运维人员想一起工作，他们也无法做到。因为从某种意义上说，他们被安排在对立的团队中。

00:04:30 - Jonah Horowitz： 运维团队经常以正常运行时间和可靠性来衡量，而提高正常运行时间的最大方法之一，就是减少系统的变化量。当然，发布新功能就是在改变系统，而做产品工作的软件工程师有动力去尽快发布尽可能多的功能。所以，当开发和运维的职责不同时，他们自然有了冲突。

00:05:00 - Saron Yitbarek： 开发者致力于新建功能，运营致力于维持运行，两者目标相互矛盾。但就像我说的，由于对速度的需求越来越大，对快速迭代发布的需求越来越大，开发和运维之间的脱节已经到了一个临界点，必须要有所改变。

00:05:30 - Saron Yitbarek： 在 2009 年左右，将开发和运维分开的那堵墙看起来像是监狱的墙。我们需要的是一种新的方法论，它能使开发和运维之间的隔阂顺畅过度，让双方以更快、更整体化的方式工作。

视频平台 Small Town Heroes 的首席技术官 Patrick Debois 为想要拆掉这堵墙的人发起了一场会议。他把这个的脑洞叫做 DevOps Days（开发运维日）。为了便利，他将其缩短为 DevOps，于是这场改革就有了名字。

00:06:00 - Saron Yitbarek： 不过名字并不代表改革的一步，我们知道为什么我们需要 DevOps，但究竟该如何做？我们应该如何将开发和运维结合起来而不引发战争？幸运的是，我有 Scott Hanselman 来指导我。Scott 是微软 .NET 和 ASP.NET 的首席项目经理。

所以，Scott，我认识你确实有几年了，但感觉还是相见恨晚啊。

00:06:30 - Scott Hanselman： 我也是，相见恨晚哈。

Saron Yitbarek： 我想和你聊聊你如何成为一个开发者，和 DevOps 这些年的变化。觉得如何？

Scott Hanselman： 嗯，听上去挺有意思。

00:07:00 - Saron Yitbarek： 好的。我认为究竟什么是 DevOps 是一个好的开场问题。你会怎么定义它呢？

Scott Hanselman： 在 2008 年，维基百科有个关于 DevOps 的定义确实很棒。它说，这是一套“惯例”，目的是在保证质量的前提下，缩短提交变更和变更投入生产之间的时间。所以，如果你想想，假如今天是周二，我检查了一些代码，而这些代码将在 6 月的版本中上线。这就很糟糕了，因为这不是持续集成，而是一年几次的集成。

00:07:30 - Scott Hanselman： 如果你有一个健康的 DevOps 体系，如果你已经有“ 设置 - 上线 set - up ”的惯例，那么你就可以不断地将代码集成到生产中去。那么，你能做什么？你可以定义、创造怎样是最佳“惯例”，这将决定你能否成功。所以，我在周二检查的一些代码，周四就上线了。那么现在，为了保证高质量，最重要的事情就会是 —— 谨慎上线。

00:08:00 - Saron Yitbarek： 这个定义真的很有趣呢，是个“惯例”。但我觉得当我听人们谈论 DevOps 时，它具体一点。他们谈论它就像它是一个角色、一个工作、一个职位或一个头衔。你觉得这与它是一套“惯例”的观点是否有冲突？

Scott Hanselman： 我认为，当一套新的方法或一个新的流行语出现时，人们喜欢把它加在名片上。我不是不尊重那些正在收听这个播客，并且感到被我冒犯、正骂骂咧咧把名片掏出来看的人们。虽然，他们现在可能正要怒盖笔电、退出这个播客。

00:08:30 - Scott Hanselman： 有一个帖子写得非常好，作者是 Brian Guthrie，他是一个脑力劳动者，在 SoundCloud 工作。他是一个超级聪明的人，几天前他在 Twitter 上的帖子中说到 DevOps。他说 DevOps 就是一套惯例，不是一个工作头衔、不是一个软件工具、不是一个你安装的东西、也不是一个团队的名字。

00:09:00 - Scott Hanselman： 他的原话是：“DevOps 不是神奇的‘企业万能药’”。如果你没有好的惯例，如果你没有良好的习惯，你就没有 DevOps。所以，这更多的是一种心态，而不是摆出一个工作头衔，然后“我们要雇佣一个 DevOps 工程师，然后我们要把这些神奇的 DevOps 工程师撒到组织中。虽然整个组织没有意志力，也没有信奉 DevOps 的想法。” 所以，如果你认为 DevOps 是一个工具或者是用来安装的东西，那么你就完全理解错了。

00:09:30 - Saron Yitbarek： 好吧，让我们回到过去，在 DevOps 这个名词出现之前，在我们往名片上写 DevOps 或者把它作为一套“惯例”来讨论之前。在 10 年前，你会如何描述开发者和那些运维人员之间的关系？

Scott Hanselman： 那是相当的水火不容。举个例子，运维控制着生产，但开发人员从来没有接近过生产。我们站在一堵不透明的墙的两侧。我们在开发部的时候，尽可能地去做一些看起来像生产环境能用的东西，但实际上从来没有……从来没有像样的产品。

00:10:00 - Scott Hanselman： 我们有相当多问题。我们的开发环境从各个方面来说都不像生产环境，所以你不可避免地会遇到那些 “嘿，它在生产环境中的工作方式和在开发环境中的不同” 的问题。然后，从开发到投入生产之间的间距是几周几周的长久间隔，所以你的大脑甚至不在正确的频道上。比如说，我在一月份的时候就在研究这个功能，现在四月份才刚刚上线，那么当 bug 不可避免地出现的时候，要等到六月份才能修复，我甚至不记得我们之前在干嘛。

所以运维团队的人，他们的工作是……他们的工作几乎就是有意识地让我们慢下来。好像他们的存在是为了让开发人员更慢，然后他们还觉得我们随时会让生产环境崩坏。

00:11:00 - Saron Yitbarek： 那么为什么会这样呢？是对开发者想要做什么和他们做了什么不了解？还是信任问题？为什么会有这么大的冲突？

Scott Hanselman： 我觉得你已经回答了，而且回答得很到位。你说的很对，确实是信任的问题。我觉得开发人员认为他们是特殊的，或者某些方面比 IT 人员更优越，而 IT 人员认为开发人员不尊重生产。

00:11:30 - Scott Hanselman： 我认为这种文化的产生，一部分来源于高层。他们认为我们是不同的组织，并且我们的目标也不同。我认为软件业正在走向成熟，因为我们都意识到，无论业务是什么，我们写软件都是为了推动业务发展。

所以现在有种 “我们都在往正确的方向推进” 的感觉，就像他们说的，“专注一件产品并做到极致”。但这是需要绝对的信任，可 DevOps 工程师不信任产品工程师来部署代码，对吧？

00:12:00 - Scott Hanselman： 但 DevOps 工程师传统上并不写代码，所以他们并不了解什么被修改了。所以他们对于在各个层面的人都缺乏信任。没有人理解部署过程，人们只信任自己，他们的心态……举个例子，就像“我只信任自己的工作。我不能相信 Saron 的工作，她甚至不知道她在干些什么。我会做完所有的事情。”

00:12:30 - Scott Hanselman： 所以如果没有人真正理解这个系统，那么 全栈工程师 full stack engineer 的概念就是一个神话。但是现在，我们开始将一整个组织称之为全栈。我们已经有了 全产品所有权 full product ownership 这样的名词，敏捷方法论也出现了，也就是说每个人都应该拥有产品。社区对于软件所有权和对于代码的想法都慢慢发生了变化，这种改变带来了一个充满信任的环境。

00:13:00 - Saron Yitbarek： 我是 Saron Yitbarek，你现在收听的是《代码英雄》，来自红帽公司的一档原创播客栏目。所以，要想让 DevOps 发挥出它的潜力，我们就需要双方都有更多的信任，这就意味着要有更多的沟通。回到 Richard Henshall 身上，他认为双方的共情是 DevOps 的基石 。

00:13:30 - Richard Henshall： 一些 DevOps 的从业者，一群真正优秀的从业者，都参与过这两种角色。我认为这才是真正的力量所在 —— 当人们真正做过了两种角色，而不是只看到其中一种。所以，你不该保持孤立，你实际上……你应该去和双方都一起工作一段时间。我想这才是让人恢复同理心的方法。

Saron Yitbarek： 现在，这不仅仅是为了温情的沟通。Richard Henshall 所描述的是行业重点的转向 —— Scott 刚刚提到过。

00:14:00 - Saron Yitbarek： 一个关于 持续集成 continuous integration （CI）的观点。软件不仅要以小批量快速编写和发布，还要以小批量进行快速测试。这意味着，开发人员需要即时反馈他们正在编写的代码在现实世界中的表现。

随着上市时间从几个月缩短到几天，再到几个小时，我们四处寻找一套新的工具，可以将任何可以自动化的元素自动化。

00:14:30 - Gordon Haff： 你需要一个全新的生态系统和工具，来最有效地进行 DevOps。

Saron Yitbarek： Gordon Haff 是一位红帽公司高级工程师。

Gordon Haff： 我们看到有很多巨大的、DevOps 可以利用的新种集合工具和平台，它们都诞生于开源。

Saron Yitbarek： Gordon 是对的。新的集合工具是很庞大，关于开源这点他说的也对。在一个严格的专有系统中，自动化工具是不可能发展的。

00:15:00 - Gordon Haff： 其中有很多监控工具，Prometheus 是其中一个常见的工具。它开始引起很多人兴趣，用于编排服务的 STO 也出自这里。

Saron Yitbarek： GitHub 让你跟踪变化，PagerDuty 管理数字业务，NFS 可以跨网络挂载文件系统，Jenkins 让你自动测试你的构建。

00:15:30 - Saron Yitbarek： 这么多工具，这么多自动化流程。最终的结果是，开发人员可以将他们的变更直接推送到生产现场，自动创建构造，实行经过严格管理的编译与针对性的自动测试。Sandra Henry-Stocker 描述了这是怎样的变化。

Sandra Henry-Stocker： 所以，我可以把我正在工作编写的东西快速部署。我可以只在一个系统上，通过命令行控制许多系统，而不是必须在在很多不同的系统上工作，也不用学习就可以利用网络，将代码部署到其他机器上。

00:16:00 - Sandra Henry-Stocker： 现在，在计算机系统中进行改动更容易了。坐在一个地方，就能实行一切操作。

Saron Yitbarek： 自动化工具已经解决了速度问题。但我不希望我们只赞美工具，而忽略了实际的方法论，文化的转变。Scott Hanselman 和我谈到了这个微妙的界限。

00:16:30 - Saron Yitbarek： 你在这次谈话开始时说，DevOps 是一套惯例，是一种心态，是一种思维方式。听起来，我们创造的工具是我们应该思考和操作方式的具体代码实现。

Scott Hanselman： 我喜欢这句话，你真是个天才。没错，我们以前让产品开发在 Word 文档中写下这些代码是如何工作的。他们写的是规范，对吧？这些文档过期了吗？

00:17:00 - Saron Yitbarek： 没错。（答非所问）

Scott Hanselman： 哈？

Saron Yitbarek： 好吧，我只是很高兴 Scott 刚才说我是天才。但我也确实认为，这些工具几乎是我们文化转变的象征。它们鼓励我们拓宽我们的角色定义。我们开发者已经被迫，至少偶尔关注代码的运行。这样一来，开发和运维的主要职责就部分统一了。事实上，DevOps 的兴起告诉我们的是，在一个速度不断提升的世界里，没有人能够保持孤岛状态。

00:17:30 - Saron Yitbarek： Jonah Horowitz 曾在湾区多家公司工作，包括 Quantcast 和 Netflix。他说即使是世界上一些最大的公司，也从这个角度重新塑造了他们的文化。

Jonah Horowitz： 我们在文化上得到了整个公司的认同，就像，“这就是我们要部署软件的方式，我们将以小批量的方式进行部署，我们将使用这些程序帮助部署。” 如果 DevOps 只是被运营团队所驱动，我不认为它可以……我不认为它可以成功。

00:18:00 - Jonah Horowitz： 这必须成为公司的管理层和领导层所认同的东西才能发挥作用，而这件事很大程度上，意味着一种文化转变。

Saron Yitbarek： 当 MacKenzie 对 800 名 CIO 和 IT 高管进行调查时，80% 的人表示，他们正在规划让自己的一部分下属组织实施 DevOps，超过一半的人计划到 2020 年，在全公司范围内实施。高管们意识到，自动化工具可以提升交付速度。

00:18:30 - Saron Yitbarek： 这些人过去也是这样的人，他们习惯于让一个货板先到达数据中心，然后在新机器上线之前让它在那里放上整整一个月。不过在今天，如果你等待的时间超过 10 分钟，就说明你做错了什么。随着竞争对手的速度增加，没有人能够承受得起落后。

00:19:00 - Saron Yitbarek： 我可以想象，运维团队一定很紧张，因为他们把所有的工具都交给开发人员。运维团队习惯了做成年人，而现在叫他们把车钥匙交给一贯的孩子 —— 开发人员？呀，我想我们开发人员正在学习，如何在不破坏东西的前提下快速移动。但随着 DevOps 革命的尘埃落定，变化最大的可能是运维团队。

00:19:30 - Saron Yitbarek： DevOps 是否真的威胁到了运维的存在？开发是否在用它闪亮的新工具来吃掉运维？Cindy Sridharan 是一位开发者，她写了一篇长篇调查文章来讨论这些问题。在你的文章和博客中，你提到运维人员对事情这样的发展并不一定满意。到底发生了什么？你会说什么？

Cindy Sridharan： 这么说吧，DevOps 的理想是责任共享。开发者和运维将有，就像你知道的，更多的是五五分成，以真正确保软件的整体交付。

00:20:00 - Cindy Sridharan： 我认为很多运维工程师的不快乐源于这样一个事实，那就是这些改变都没有实际功效。他们仍然是总被鸡蛋挑骨头的人，他们仍然是总做苦力工作的那些人，他们还是那些主要肩负着实际运行应用的责任的人，而开发者不一定要做得足够好。

Saron Yitbarek： 这个问题在未来几年将至关重要。DevOps 的作用到底有多大？随着我们的自动化进程，运维的作用是会被削弱，还是会发生转变？

00:20:30 - Saron Yitbarek： 但是我们要记住，DevOps 不仅仅是工具和新技术的应用。这种方法论实际上是在塑造技术，反过来技术也在塑造方法论，这样就有了一个神奇的反馈循环。文化造就了工具，而工具又强化了文化。

00:22:00 - Saron Yitbarek： 最后，我们在节目开头描述的那堵墙，也就是把开发和运维划分开来的那堵墙，我甚至不知道五年后“把你的代码扔过墙”的比喻对一个开发者来说是否有意义，如果五年后大家都听不懂这个比喻，那真是一件大好事。不过目前为止的访谈很有价值，我听到了很多新的故事。

现在说话的是云架构师 Richard Henshall。

Richard Henshall： 我觉得 DevOps 开始让人们意识到对方关心的是什么，我看到了更多对彼此的理解。

00:23:00 - Saron Yitbarek： 现在是系统管理员 Jonah Horowitz。

00:23:00 - Jonah Horowitz： 我认为你需要很棒的技巧来写出真正好的软件，我在与我合作过最棒的开发者身上看到了一件事，那就是他们真的，他们贡献了关于的软件工程新技巧，或者说他们推动了软件开发这个行业的发展。

Saron Yitbarek： 最后一个是系统管理员 Sandra Henry-Stocker。

Sandra Henry-Stocker： 我认为，开发者会变得更加精明、更加谨慎。他们始终要提升自己的技能，我知道这需要很多辛苦的学习。

00:23:30 - Saron Yitbarek： DevOps 是个爱的结晶。原来，在那堵墙的另一边还有一些朋友，很高兴认识你们。所以，坦白一下，我以前总觉得 DevOps 很无聊，就是一堆硬核的自动化脚本和扩展问题。我的抵触情绪有一部分是出于它的实践难度。作为开发者，我每周都要面对一些新出来的工具，一些新的框架。DevOps 一直是那些可怕的、快速变化的一部分。但现在，尤其是听了这些故事之后，我明白了。

00:24:00 - Saron Yitbarek： DevOps 不仅仅是其工具。它是教导我们如何合作，更快地构建更好的产品的方法。

好消息是，随着为你我这样的开发者准备的新平台出现，我们的工作变得更好、更快、更能适应不同的环境，我的业务圈也可以不断扩大。你会看到人们将 DevOps 扩大到安全部分，所以我们能得到 Sec DevOps。或者他们开始包含商务，那我们就得到了 Business DevOps。我们现在要辩论的话题是：对于一个开发者来说，不仅要了解如何使用这些工具，还有了解所有 DevOps 的东西是如何工作的必要吗？以及我们需要所有开发者都去了解这个新世界吗？

00:24:30 - Saron Yitbarek： 这场辩论的结果将决定未来一期《代码英雄》的内容。

你可能已经注意到，在所有关于工具和自动化的谈话中，我漏掉了一些工具。好吧，我把这些留到下一期，当所有这些 DevOps 自动化达到光速时，我们将追踪容器的崛起。

00:25:00 - Saron Yitbarek： 是的，这些都会留到第五期。

《代码英雄》是红帽公司推出的原创播客栏目。想要了解更多关于本期节目和以往节目的信息，请访问 redhat.com/commandlineheroes 。在那里，你还可以注册我们的新闻资讯。想免费获得新剧集的自动推送，请务必订阅该节目。

00:25:30 - Saron Yitbarek： 只要在苹果播客、Spotify、Google Play、CastBox 中搜索《代码英雄》，或者通过其他方式收听，并点击订阅，这样你就能在第一时间知道最新剧集。我是 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-1/devops-tear-down-that-wall

作者：Red Hat 选题：bestony 译者：LikChung 校对：acyanbird

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

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

什么是《代码英雄》

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

本文是《代码英雄》系列播客第一季（3）：敏捷革命 的音频脚本。

现在是 21 世纪之交，开源软件正在改变着科技的格局，现在已经需要一种新的工作模式了。开发者们在寻找一种革命性的方法，让开源开发蓬勃发展。一群开发者在犹他州的一个滑雪场召开了会议，形成的是一份改变一切的宣言。

《 敏捷软件开发宣言 Manifesto for Agile Software Development 》的作者之一 戴夫·托马斯 Dave Thomas 将我们带回了那个现在著名的静修之地，敏捷革命就是在那里第一次组织起来的。不过，并不是每个人都那么快就签下了这种新方法，在这一集里，我们听听原因。

Saron Yitbarek： 有些故事的走向和结局会重新定义一个行业。在这些故事中也传唱着，我们来自哪里，我们是谁，我们正在做什么。上一集中，我们追溯了 Linux ^® 开源技术的崛起。但这一集我要讲的，是紧接着发生的故事。操作系统之战结束后，开发者们成为了战争争夺的对象和核心。

00:00:30： 在那个新的战场，开发者们将要重塑自己的工作。本集播客，我们将深入了解以开发人员为核心，产生的一种全新的软件开发方法论。这种新颖的工作流程产生了哪些远超我们屏幕上显示的代码所能控制的、意想不到的事情。

我是 Saron Yitbarek，欢迎收听红帽的原创播客《代码英雄 第三集 敏捷革命》。今天的故事始于 2001 年 2 月，发生在美国犹他州的滑雪小屋里。

00:01:00 - Dave Thomas： 我们面前有个小屋，眼前是松树梁和壁炉，还有进入屋子的小门。我们前一天晚上到达这里时，然后基本上只是围坐在一起，讨论谈我们准备探讨的内容。紧接着第二天，我们都起床，并来到了预定的会议室。先把桌子移到边上去，然后将椅子摆放成一圈，确切地说是一个椭圆，这样一来我们就可以面对面交流，一定程度上也让人感觉到可以敞开心扉，畅所欲言 。

00:01:30 - Saron Yitbarek： 刚才提到的这群人都是开源开发人员，所以保持开放是他们的特点。Dave Thomas 和其他的 16 个人，在那个冬天集聚在雪鸟滑雪场。但是他们的目的并不是滑雪，而是探讨在 90 年代开发者的世界所面临的问题。在这里我用“探讨”，但实际上用“辩论”更准确。他们最初是在 面向对象编程、语言及系统 Object-Oriented Programming, Languages and Systems （OOPSLA）的会议上认识的，这个会议主要议题是面向对象程序设计、编程、语言和系统。

00:02:00： 实际上正是那次会议，让他们意识到当前的软件开发方式很混乱，只是对于该怎么办没有达成一致。

所以此次在雪鸟山上的开会，试图寻找解决这个问题的方法。那么究竟是这个问题具体该怎么描述？于是我询问 Dave，开发人员之前的使用方式到底出现了什么问题。

Dave Thomas： 所以，我不知道……你有没有装饰过房间？

Saron Yitbarek： 我有。

00:02:30 - Dave Thomas： ……好。如果我先告诉你，“我想让你坐下来，然后给你一张白纸。接着我希望你能描绘下来这个房间完成后大概的样子。”可以想象吗？

Saron Yitbarek： 嗯嗯（肯定的语气）。

Dave Thomas： 你能做到吗？

Saron Yitbarek： 实际上，我的办公室就是这么布置出来的。首先，我画了一个简单的草图，然后加上一些修饰，最后把所有架子摆放在我觉得合适的位置。不过这种方式没有真正起到作用，我的计划也没有实现。

Dave Thomas： 但是，即使你尝试了这种方式，你都做了什么？先把架子放起来，然后说，“哦……这样放不行，因为会挡道。”所以，你又紧接着把架子移到其它地方，或者你会说，“你知道吗，我真的不能把地毯放在那里，因为我的椅子脚会陷进去。”状况频发。

00:03:00 -Dave Thomas： 遇到未知的情况，你总需要一种“迭代”的方式去应对。人类的大脑无法准确地对现实世界的发展进行预判，从而提前预知哪里需要改变。所以，软件开发也是一样的，人们不知道他们的需求会怎么改变。对吗？

Saron Yitbarek： 嗯嗯（肯定的语气）。

00:03:30 - Dave Thomas： 我经历过太多这样的情况，当我从客户那里拿到了详细的要求，然后我已经很好地完成了每一条细则，但却总是吵得不欢而散。“这不是我们想要的。” 但我想说的是，“这就是你要求的啊。”他们说，“是的，但这不是我的意思。”你懂这种情况吗？

Saron Yitbarek： 嗯嗯（肯定的语气）。

Dave Thomas： 所以说，理想情况是，你可以详细说明流程的每一步，然后通过非常机械的步骤就可以完成一切。

Saron Yitbarek： 是啊。

00:04:00 - Dave Thomas： 但是在软件行业可行不通。这种方式不适用于有任何模棱两可的情况，也不适用于需要判断的情况。就像任何艺术尝试一样，这种方式就是行不通。总是缺失了关键的一步：反馈。

Saron Yitbarek： 也许你已经听说过上世纪 90 年代的软件危机。当时的软件开发一团糟。相比于开发软件的费用，公司在修复软件上的钱花的多得多。与此同时，你我这样的开发人员进退不得。有时候，我们每隔好几年时间才能推出新的软件。

00:04:30： 我们疲于应付这些缓慢、陈旧、瀑布式开发的工作流程。从 A 到 B 到 C，完全都是提前确定好的。因此，那时的时间消耗主要在寻找新的流程，寻找更好的软件开发方式上。事实上，每个月似乎都有新的开发者，对如何改善软件开发的过程提出宏伟的设想。

00:05:00： 其中就有极限编程、有 Kanban、还有统一软件开发过程等，不胜枚举。在这些方法论的激烈竞争中，也催生出了新的观点和改进方法。那就是 Dave Thomas 和他在雪鸟滑雪场的朋友们迫不及待开始探讨的领域。

值得让这群人齐声欢呼喝彩的就是《敏捷软件开发宣言》。当时的开发速度正在以前所未有的速度保持增长 —— 而开源使开发人员变得更强大。另一方面，开发人员也需要一种新的敏捷的开发模式。

00:05:30： 顺便提一下，那些在雪鸟滑雪场会面的人，在经过一番你来我往的争论后，才确定用这个词。 敏捷 Agile ，这个词非常切题。这种方式就好像国家地理描述大型猫科动物的方式，一个与瀑布式开发预设路径正好相反的词。随着新的信息层出不穷，这个词让那些愿意改变航向的人看到了一线曙光。请注意这可不是一个名词，而是一个形容词。

00:06:00： 敏捷将会是一种习惯，而不是一种具体的说辞。那么，那些采用敏捷的开发者提供了什么呢？他们的总体解决方案是什么？现在很多人都认为敏捷是一个复杂的集合，包括不同的角色和是系统。会有一个 项目经理 scrum master ，一个 项目 scrum 团队，一个产品负责人。同时他们都要进行一到两周的冲刺工作。

00:06:30： 与此同时，工作都堆积在“冰盒”和“沙盒”中。好吧，听起来感觉流程很多。但一开始的时候是没有这些流程的。撰写该敏捷宣言的人,目标是简单和清晰。实际上，简单是它制胜的法宝。从那时起，它就具有定义几乎每个开发人员命运之路的能力。

Dave Thomas： 我们已经提到了，我们更喜欢某种方式，而不是另一种方式。事实上，在午餐这段时间，我们就写下了几乎所有的观点，现在都是敏捷宣言的一部分。

00:07:00 - Saron Yitbarek： 这是可以管理开发的四个奇思妙想。如果你尚且还不熟悉那些敏捷的诫命，他们会这样解释：

个体和互动胜过流程和工具；可工作的软件胜过文档；客户协作胜过合同谈判；响应变化胜过遵循计划。

00:07:30： 我记得第一次看到这个宣言时的情形。我刚开始学习编程，老实说，当时我并没有觉得这个想法有多棒。一直到我了解到那些支持敏捷开发的工具和平台。对我来说，这只是一些模糊的概念。但是，对于长期以来一直被这些问题纠缠的开发人员来说，这是一个很好的行动方案。

该宣言是一盏灯，可以激发更多奇思妙想。这四点宣言和一些支持材料都发布在 Agilemanifesto.org 网站上，并且呼吁其他开发者签名以表示支持。

00:08:00 - Dave Thomas： 很快获得了 1000 个签名，接着 10,000 个，然后签名数一直在增长，我想我们都惊呆了。这基本上变成了一场革新运动。

Saron Yitbarek： 他们从来没有计划过把这份敏捷宣言带出滑雪小屋。这只是一群热衷于软件开发的人，并且对帮助他人更好地发展充满热情。但很明显，“敏捷” 本身像长了腿一样。红帽公司首席开发倡导者 Burr Sutter 谈到了“敏捷”对于还困在“瀑布”中的开发人员来说是一种解脱。

00:08:30 - Burr Sutter： 因此，敏捷的概念从根本上引起了人们的共鸣，基本上是在说：“看，我们专注于人员而不是流程。我们专注于交互和协作而不是工具和文档。我们认为工作软件高于一切，我们宁愿人们通过小批量的工作，实现高度互动、快速迭代。”

00:09:00 - Saron Yitbarek： 而对于一些人来说，这个开发者的革新走得太远。敏捷甚至被视为是给那些不负责任的黑客心态的合理说辞。早期反对敏捷最重要的声音之一是 Steve Rakitin。他是一名软件工程师，拥有超过 40 年的行业经验。

00:09:30： 当他大学毕业时，Rakitin 就开始建造第一个核电站数字控制系统。几十年来，他一直致力于研发电力软件和医疗设备软件。这些都是对安全很注重的软件。没错。你可以预料到，他可不会对这种手忙脚乱的开发方式感兴趣。

因此，在方法论战争的尾声，敏捷横空出世，Rakitin 对此翻了个白眼。

Steve Rakitin： 就像是，“好吧，我们换种方式说，如同一群人围坐着喝着啤酒，就想出了开发软件的其他办法。”顺便提一下，敏捷宣言中许多已经得到进一步发展，并应用于早期的开发方法里了。

00:10:00 - Saron Yitbarek： 他这么想其实也没有什么错。实际上你可以在 “雪鸟峰会” 前几十年就追溯到敏捷哲学的踪迹。例如，像 看板 Kanban 这样的精益工作方法可以追溯到 20 世纪 40 年代，当时丰田受到超市货架存货技术的启发……

他们的精益制造理念最终被用于软件开发。不过 Rakitin 有另外一个担忧。

00:10:30 - Steve Rakitin： 这篇宣言发表时我非常怀疑它，因为它基本上是为了让软件工程师花更多的时间编写代码，花更少的时间搞清楚需要做什么，同时记录文档的时间少了很多。

Saron Yitbarek： 对于 Rakitin 来说，这不仅仅是提出新的工作流程创意。这也关乎到他职业生涯的清白声誉。

00:11:00 - Steve Rakitin： 长期以来，相比于电气工程和所有其他工程学科，软件工程并未被视为正规的工程学科。在我看来，部分原因是因为普遍缺乏软件工程师认可的公认实践。

00:11:30： 当我们经历了 90 年代的十年，逐渐开始明晰其中的一些流程。似乎其中一些已经在事实上被实施，而且也很合理。

然后敏捷宣言的出现了。如果软件工程将成为正规的工程学科，那么你就需要流程化的东西。其他所有工程学科都有流程，为什么软件工程就没有？

00:12:00 - Saron Yitbarek： 我是 Saron Yitbarek，你正在收听的是红帽的原创播客代码英雄。那么，如果我们把在核电站工作的人士的观点放在一边，转而关注更广阔的企业界，我们发现敏捷已经逐渐广受认可。但这件事不是自然而然，没有丝毫阻力就发生的。

Darrell Rigby： 我想我们在采用敏捷开发中，受到的最大阻力来自中高级管理层。

00:12:30 - Saron Yitbarek： 这位是 Bain＆Company 的合伙人 Darrell Rigby。他们一直尝试在软件开发公司中推行敏捷开发。不仅如此，还包括产品开发、新闻服务开发、广告计划和忠诚度计划等。不管他们要做什么，项目管理者都会面临点压力。

Darrell Rigby： 敏捷改变了他们的价值，因为他们正在逐步退出细节上的管理或干预。现在团队被赋予权力，对他们加以指导。

00:13:00 - Saron Yitbarek： 现在，敏捷并不能保证阻止中间轻微的干预。我承认，我第一次看到一个敏捷管理委员会时，我认为这是一个永无止境的待办事项清单，我有了点压迫感。但后来当我开始真正使用敏捷产品管理工具时，我完全变成了它们的粉丝。我是一个编码培训营的新人，我试图弄清楚如何确定功能的优先级并做出产品决策。

00:13:30： 那些看起来很可怕的工具让我有了所有这些想法，然后给它们命名、顺序和结构。从而可以帮助我更好地管理我的项目。所以，我确实同意 Rigby 的观点。有些人可能会看到这些工具产生的影响并认为，如果敏捷赋予开发人员权力，那么就会剥夺经理们的管理权。

但是，它的价值比任何一个职位都要大，敏捷开发的发展势如破竹。更重要的是，它正在证明自己。

00:14:00 - Darrell Rigby： 目前，成千上万的团队已经采用敏捷开发。因此，我们有很多关于此数据。答案是，无论何时你开始创新，相比你现在使用的方式，敏捷团队能更好实现目标。

00:14:30： 有许多更大的、知名的公司都在变革自身。亚马逊是敏捷方法的重要用户。奈飞、Facebook 和 Salesforce —— 他们都是敏捷的重度用户，实际上敏捷方法不仅重新定义了工作方式，更是重新定义了行业的运作方式。

Saron Yitbarek： 当 Rigby 第一次听说 敏捷 agile 时，他认为这是一种奇怪的语言。他当时正在与许多大型零售商的 IT 部门合作。无意间听到他们谈论 “time boxes”、“sprint” 和 “scrum master” 。起初，他并不懂他们在说什么。他告诉我他实际上是试图忽略任何有关敏捷的字眼，就像这是他不需要学习的另一种语言。毕竟，他本人不是开发人员。

00:15:00： 但是如今，他却成为了敏捷信徒，把敏捷带到他的家里，带入他的教堂。

Darrell Rigby： 我不一定每天早上都和家人坐在一起，和他们一起参加敏捷开发式的会议。但是，我已经非常擅长为我要做的事情排优先级。

00:15:30 - Saron Yitbarek： 十多年来，敏捷已经从边缘走向主流。但是，企业认同还是有代价的。在某些情况下，这种同化甚至会使敏捷宣言的最初意图变得模糊。Dave Thomas 让我想起了这一点。他说，当他和其他 16 位雪鸟会议上的伙伴第一次写下宣言时，根本没有既定的指示。

00:16:00： 因此，即使宣言中没有告诉你如何应用这些条例，我猜想你已经对大概会发生什么，还有人们会怎么做，有一些大概的思路了吧？

Dave Thomas： 老实说啊，我还真没有。

Saron Yitbarek： 听到这里，你可能会感到惊讶。因为敏捷现在看起来很有说服力。有书籍、认证、工具、课程和产品的整个市场，向你展示如何“实现敏捷”。

Dave Thomas 表示，尽管有成千上万的手册和专业人士想要向你展示“唯一真理”，他们却错过了重点。

Dave Thomas： 实际上它是一组价值观。

00:16:30 - Saron Yitbarek： 嗯嗯（肯定的语气）。

Dave Thomas： 我想这就像黄金法则。你知道，如果你要做一些邪恶恶毒的事情，你会想，“好吧，如果有人这样做，我又怎么会喜欢。”你知道吗，这种场合也适合用黄金法则。

好吧，敏捷宣言也是如此。它并没有告诉你该做什么，不该做什么，它只是告诉你，你做的一切是否符合这个价值观。

00:17:00 - Saron Yitbarek： 是的。我想只要回到敏捷软件开发宣言的名称、真正脱颖而出并且经久不衰的一个词，也是人们真正关注的就是“敏捷”。那么现在使用“敏捷”这个词又出了什么问题呢？

00:17:30 - Dave Thomas： “敏捷”这个词的问题在于，在我们刚开始提出的时候，它是描述软件开发的形容词。但接下来人们就产生了疑问：“我该怎么着手实施敏捷呢？”

00:18:00： 突然之间，涌出了一大批咨询顾问，他们看到了 极限编程 Extreme Programming （XP）的成功，看到了宣言的成功，“嘿，那里有座金山。” 然后就开始告诉人们如何“做敏捷”。这是一个问题，因为你不能“做”敏捷。敏捷不是你要“做”的事情，而是你如何做事情的方式。

然而，有些公司会乐意卖给你敏捷相关的套装。我觉得这很讽刺。这里的咨询就好像是进入一家财富 1000 强企业，然后帮助他们设定“敏捷”。然后带走了 500 万美元。你懂吗？太棒了，钱真好赚。

00:18:30： 但是，现实情况是，这就像告诉要老虎如何变得敏捷一样，说：“先走七步，然后左脚迈出来，然后再走两步，然后迈出右脚。”嗯，实际上只有瞪羚做同样的事情，这才会是有用的。你猜怎么着？没有人告诉瞪羚这样做。瞪羚基本都会跑到地平线尽头上大笑起来，因为老虎在“邯郸学步”。

00:19:00： 当你告诉团队如何敏捷时，会发生同样的事情。如果你对他们说，“这是你必须遵循的规则，这是你必须遵循的流程”，然后他们唯一能做的就是跟随职责，因为他们已被设定好该执行的程序。管理层将根据他们服从原则或程序的程度，而不是开发软件的水平来判断表现如何。

00:19:30 - Saron Yitbarek： 所以，回顾一下，宣言发布之前和之后的开发者的角色，是如何因为你的宣言本身改变或扩展的呢？

00:20:00 - Dave Thomas：我认为大多数程序员都能理解到关键点，这值得肯定。我觉得敏捷宣言给了许多开发人员按照这种方法去做的授权，某种程度上是他们以前就知道该如何，但从来没有权利这样做。像测试收集反馈，缩短迭代周期之类的事情。因此，在许多方面，工作变得更有趣，更充实。

同时我认为，程序员也可能会感到有点害怕，因为现在他们有了责任。过去，他们只是遵循命令。这个程序不起作用？好吧，但我遵循了规范。而如今，程序员肩负着责任。

00:20:30： 所以，我觉得这个职业因敏捷宣言而有所成长。我认为人们开始意识到，他们对自己所开发东西负有点对点的责任。

00:21:00 - Saron Yitbarek：敏捷取得了如此广泛得成功，改变了工作流程和态度，远远超出了开发者世界的范畴 —— 当然也超越了雪鸟会议召开的小木屋。我们不禁要问，“相比于 2001 年撰写宣言时，今天成为敏捷开发人员意味着什么？”

最初的敏捷精神是否仍然存在？如果确实发生了变化，这是一件坏事吗？对于谷歌的多元化业务合作伙伴 Ruha Devanesan 来说，敏捷的思维方式，可能已经发展到影响公平性和在工作场所中的平等性了。

00:21:30 - Ruha Devanesan：让团队具有包容性的部分原因，是他们在进行非常基础的工作时，可以评价和反思自己。当大多数团队一起工作时，他们没有足够的时间这么做。没有足够的动力停下来思考他们团队宗旨，是否每个人都在能桌上发表意见，关于是否有人在推动其他人，或者是否有人在一直都保持沉默。如果他们保持沉默，为什么他们保持沉默？

00:22:00： 因此，在考虑包容性时，我认为敏捷团队使用的一些工具在为团队创建架构，或更具包容性的框架方面非常有用。所以多样性包括性别、种族，还有功能多样性。功能多样性为团队带来了复杂性。

00:22:30 - Saron Yitbarek： 但是，我们在这里要声明他们的不同。Ruha 并不是说敏捷就等于多样性。她的意思是，“敏捷加多样性等于更好的团队。”Ruha 的想法在她写的一篇名为《论通过敏捷方法解锁多样性》的文章中得到了体现。我们将在演示笔记中添加一个链接 —— 这可是值得一读的文章。

在这篇文章中，她会引导你去了解，多元化不仅仅是人力资源部门一直在谈论的模糊概念。这里提供了一个强有力的商业案例。利用敏捷工具，可以创建一个包容性的工作场所，和创新效率提升。多样性可以与敏捷相辅相成。

00:23:00 - Ruha Devanesan： 这篇介绍复杂性的文章，最终目的是让大家从不同的角度看待你的结果或产品。当我们说为团队增加多样性可以带来更好的结果，带来更多的创新和创造力时，我们持有的是基本同样的观点。因为当你从多个角度去看待并协作解决工作中的问题时，你更有可能得出一个更好的结果。

00:23:30 - Saron Yitbarek： 团队中的每个人，甚至可以对日常会议这样简单的事情提出反馈，这会让内向的人或其他不爱说话的人发表自己的见解。

Ruha Devanesan： 我真正喜欢敏捷的原因是，有一些内置的机制来帮助团队停下来进行思考。这可能是因为敏捷开发是如此之快，并且有为时两周的冲刺任务。如果你没有建立这些机制，你可能会偏离轨道，没法再回到正轨。

00:24:00： 但是，我觉得，“停止并反馈”这种价值观非常重要。这对于团队的包容性增加也非常重要，因为让大家都能提出工作反馈，并借此不断改善，这是团队能够包容的基本表现。

Saron Yitbarek： 既然我们谈论的是包容性，现在可能是指出那些敏捷宣言的 17 位创始人的好时机，是的……他们都是白人。

00:24:30 - Dave Thomas： 实际上那个房间没有多样性。这是对该组织的一种非常普遍的批评，而且我对此深表同情。

Saron Yitbarek： 如果敏捷宣言创始人采用了这些敏捷原则，并将其应用于他们自己的会议，那么他们可能在完成部分工作后，会问他们自己……“嘿，你注意到我们没有邀请任何女性参加这次会议吗？”我在想会不会有一个有色人种会持有不同意见。

00:25:00 - Ruha Devanesan： 物以类聚，人以群分。所以，如果考虑敏捷宣言的第一个人是白人，他邀请到桌上的人也是白人也就不足为奇了。但是，我们有机会在那方面做得更好，我们有机会停下来说：“让我们退后一步，让我们扩大我们的视野，寻找我们现在拥有的关系网络之外的人。谁可以带来不同的视角并帮助我们更好地改进这种开发方式。”

00:25:30 - Saron Yitbarek： 对我来说这很有道理，因为敏捷开发正是如此……好吧，敏捷，我们可以将它应用于不同的问题和行业。敏捷的应用方面，以及其在现实生活中出现时候的样子，是不断变化、不断扩展的。我想它正在将宣扬的内容付诸实践。没有最正确的答案，没有最后的终点。这是我们有时会忘记的事情：硬规则是敏捷的敌人。

00:26:00： 因此，如果一个敏捷团队告诉你敏捷的一部分意味着你必须每两周开发一个新的版本，或者你必须做什么事，那么，根据定义，这可不是敏捷。你老是说“总是”，你也不再是敏捷了。

00:26:30： 那些在犹他州雪鸟会议碰面的 17 名男子，最后宣称成立敏捷联盟。该联盟成为一个非营利组织，每年都举办一次会议。这个联盟的成长和发展，催生了更多全新的理论和方法。

这正是我感觉非常有趣的东西。在 2008 年的会议上，比利时开发人员 Patrick Debois 参加了并开始引领一条道路，他发明了一种全新的软件开发实践 DevOps。我从未想到与敏捷的一系列原则与 DevOps 和整个行业是都紧密相关。

00:27:00： 但是，现在我在想，“敏捷的兴起与 DevOps 的发明之间有多少关联？一个突破是否孕育了另一个突破？”我们会一起去探索，因为我们的下一集是正是 DevOps，对！一整集的内容。

00:27:30： 《代码英雄》是红帽的原创播客。有关我们的播客和其他更多信息，请访问 Redhat.com/commandlineheroes 。在那里，你也可以关注我们的消息订阅。想要免费听取最新内容，请订阅我们的节目。也可以在 Apple Podcast、Spotify、 Google Play、CastBox 中搜索 “Command Line Heroes”，然后点击“订阅”，你将在第一时间获得我们的内容更新。

我是 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）和我们联合颁发的专属贡献者证书。

关于重制版

本系列第一季的前三篇我们已经发布过，这次根据新的 SIG 规范重新修订发布。

via: https://www.redhat.com/en/command-line-heroes/season-1/agile-revolution

作者：RedHat 选题：bestony 译者：redhat 校对：acyanbird

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

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

什么是《代码英雄》

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

本文是《代码英雄》系列播客第一季（2）：操作系统战争（下） 的音频脚本。

Saron Yitbarek： 这玩意开着的吗？让我们播放一段跟星球大战电影一样的开场字幕吧，第二集开始了！

00:00:30 - 配音： OS 战争第二部分：Linux 的崛起。微软帝国控制着 90％ 的用桌面用户，操作系统的完全标准化似乎是板上钉钉的事了。所以公司们把它们的注意力从桌面端的个人用户，转移到了专业人士上，它们为了服务器的所有权打得不可开交。但是一个有点让人意想不到的英雄出现在开源“反叛组织”中。戴着眼镜，固执的 林纳斯·托瓦兹 Linus Torvalds 免费发布了他的 Linux® 程序。微软摔了个趔趄，并且开始重新调整战略。

00:01:00 - Saron Yitbarek： 哦，我们极客们就是喜欢那样。上一次我们讲到哪了？苹果和微软互相攻伐，试图在争夺桌面用户的战争中占据主导地位。在第一集的结尾，我们看到微软获得了大部分的市场份额。很快，互联网的兴起以及随之而来的开发者大军，让整个市场都经历了一场地震。互联网将战场从在家庭和办公室中的个人电脑用户转移到拥有数百台服务器的大型商业客户中。

00:01:30 - Saron Yitbarek： 这意味着巨量资源的迁移。突然间，所有相关企业不仅被迫为服务器空间和网站建设付费，还必须集成软件来进行资源跟踪和数据库监控等工作。至少那时候大家都是这么做的，你需要很多开发人员来帮助你。

在操作系统之战的第二部分，我们将看到固有优势的巨大转变，以及像林纳斯·托瓦兹和 理查德·斯托尔曼 Richard Stallman 这样的开源反叛者，是如何成功地在微软和整个软件行业的核心引发恐惧的。

00:02:00 - Saron Yitbarek： 我是 Saron Yitbarek，你现在收听的是代码英雄，一款红帽公司原创的播客节目。每一集，我们都会给你带来“从码开始”，用技术改变科技的人，他们的故事。

00:02:30 - Saron Yitbarek： 好。想象一下你是 1991 年时的微软。你自我感觉良好，对吧？你满怀信心，确立了全球主导地位的感觉真不错。你已经掌握了与其他企业合作的艺术，但是仍然将大部分开发人员、程序员和系统管理员排除在联盟之外，而他们才是真正的武装力量。这时出现了一个叫林纳斯·托瓦兹的芬兰极客。他和一帮信奉开源的程序员开始发布 Linux，这个操作系统内核是由他们一起编写出来的。

00:03:00 - Saron Yitbarek： 坦白地说，如果你是微软公司，你并不会太在意 Linux，甚至不太关心开源运动，但是最终，Linux 的规模变得如此之大，以至于微软不可能不注意到。Linux 第一个版本出现在 1991 年，当时大概有 1 万行代码。十年后，则是 300 万行代码。如果你想了解知道现在的 Linux 怎么样了 —— 它有 2000 万行代码。

00:03:30 - Saron Yitbarek： 让我们在 90 年代初停留一会儿，那时 Linux 还没有成为我们现在所知道的庞然大物。这只是一个正在蔓延的，拥有病毒一般感染力的奇怪操作系统，不过全世界的极客和黑客都爱上了它。那时候我还太年轻，但有点希望我曾经历过那个年代。在那个时候，发现 Linux 就如同进入了一个秘密社会，程序员与朋友们分享刻录的 Linux CD 集，就像其他人分享地下音乐混音带一样。

00:03:40： 开发者 Tristram Oaten 讲讲你 16 岁时第一次接触 Linux 的故事吧。

00:04:00 - Tristram Oaten： 我和我的家人去了红海的 Hurghada 潜水度假，那是一个美丽的地方，强烈推荐。也许我妈妈跟我说过不要这么做，但第一天，我还是喝了自来水。所以我整个星期都病得很厉害，没法离开旅馆房间。当时我只带了一台新安装了 Slackware Linux 的笔记本电脑，我只是听说过这玩意，现在却要尝试使用它。我手上没有其他的应用程序，我能接触的所有东西只有刻录在 8 张 CD 上的代码。这种情况下，我整个星期能做的事情，就是了解这个外星造物一般的系统。我阅读手册，摆弄着终端。我记得当时我甚至不知道一个点（表示当前目录）和两个点（表示前一个目录）之间的区别。

00:04:30 - Tristram Oaten： 我一点头绪都没有。犯过很多错误。但慢慢的，在这种被迫造成的孤独中，我突破了障碍，开始明白并理解命令行到底是怎么回事。假期结束时，我没有看过金字塔、尼罗河等任何埃及遗址，但我解锁了现代世界的一个奇迹。我接触了 Linux，接下来的事大家都知道了。

Saron Yitbarek： 你会从很多人那里听到关于这个故事的不同版本，访问 Linux 命令行是一种革命性的体验。

00:05:00 - David Cantrell： 它提供了源代码。我当时的感觉是，“太神奇了。”

Saron Yitbarek： 我们正在参加一个名为 Flock to Fedora 的 2017 年 Linux 开发者大会。

David Cantrell： ……非常有吸引力。我觉得随着我掌控这个系统越深，它就越吸引我。我想，从 1995 年我第一次编译 Linux 内核那时起，我就迷上了它。

Saron Yitbarek： 这是开发者 David Cantrell 与 Joe Brockmire。

00:05:30 - Joe Brockmeier： 我在 Cheap Software 转的时候发现了一套四张 CD 的 Slackware Linux。它看起来会非常令人兴奋而且很有趣，所以我把它带回家，安装在我的第二台电脑上，开始摆弄它，有两件事情让我感到很兴奋：一个是我运行的不是 Windows，另一个是 Linux 的开源特性。

00:06:00 - Saron Yitbarek： 某种程度上来说，使用命令行的人总是存在的。在开源真正开始流行起来的二十年前，人们（至少在开发人员是这样）总是希望能够做到完全控制机器。让我们回到操作系统大战之前的那个时代，在苹果和微软为他们的 GUI 而战之前，那时也有代码英雄。 保罗·琼斯 Paul Jones 教授（在线图书馆 ibiblio.org 的负责人）就是一名那个古老年代的开发人员。

00:06:30 - Paul Jones： 从本质上讲，互联网在那个时候客户端-服务器架构还是比较少的，而更多的是点对点架构的。确实，我们会说，某种 VAX 到 VAX 的连接（LCTT 译注：DEC 的一种操作系统），某种科学工作站到科学工作站的连接。这并不意味着没有客户端-服务端的架构及应用程序，但这的确意味着，最初的设计是思考如何实现点对点，它与 IBM 一直在做的东西相对立。IBM 给你的只有哑终端，这种终端只能让你管理用户界面，却无法让你像真正的终端一样为所欲为。

00:07:00 - Saron Yitbarek： 当图形用户界面在普通用户中普及的同时，在工程师和开发人员中总是存在着一股相反的力量。早在 Linux 出现之前的二十世纪七八十年代，这股力量就存在于 Emacs 和 GNU 中。斯托曼的自由软件基金会中的某些人想要使用完全命令行，但直到上世纪 90 年代的 Linux 出现，才提供了前所未有的东西。

00:07:30 - Saron Yitbarek： Linux 和其他开源软件的早期爱好者是都是先驱。我正站在他们的肩膀上，我们都是。

你现在收听的是代码英雄，一款由红帽公司原创的播客。这是操作系统大战的第二部分：Linux 崛起。

Steven Vaughan-Nichols： 1998 年的时候，情况发生了变化。

00:08:00 - Saron Yitbarek： Steven Vaughan-Nichols 是 zdnet.com 的特约编辑，他已经写了几十年从商业方面论述技术的文章了。他将向我们讲述 Linux 是如何慢慢变得越来越流行，直到自愿贡献者的数量远远超过了工作于 Windows 上的微软开发人员的数量。不过，Linux 桌面版本从未真正追上 Windows，这也许就是微软最开始时忽略了 Linux 及其开发者的原因。Linux 真正大放光彩的地方是服务器机房，当企业开始线上业务时，每个企业都需要一个满足其独特需求的解决方案。

00:08:30 - Saron Yitbarek： WindowsNT 于 1993 年问世，当时它已经在与其他的服务器操作系统展开竞争了，但是许多开发人员都在想，“既然我可以通过 Apache 构建出基于 Linux 的廉价系统，那我为什么要购买 AIX 设备或大型 Windows 设备呢？”鉴于这个优点，Linux 代码已经开始渗透到几乎所有的在线机器中。

00:09:00 - Steven Vaughan-Nichols： 让微软开始意识到并感到惊讶的是，Linux 实际上已经有了一些商业应用，不是在桌面环境，而是在商业服务器上。因此，他们发起了一场运动，我们称之为 FUD - 恐惧、不确定和怀疑 fear, uncertainty and double 。他们说，“哦，Linux 这玩意，真的没有那么好。它不太可靠，你根本不能相信它”。

00:09:30 - Saron Yitbarek： 这种软宣传式的攻击持续了一段时间。微软也不是唯一一个对 Linux 感到紧张的公司，整个行业其实都在对抗这个奇怪新人的挑战。例如，任何与 UNIX 有利害关系的人都可能将 Linux 视为篡夺者。有一个案例很著名，那就是 SCO 组织（它发行过一种 UNIX 版本）在过去 10 多年里发起一系列的诉讼，试图阻止 Linux 的传播，而 SCO 最终失败而且破产了。与此同时，微软一直在寻找机会，他们必须要采取动作，只是不清楚具体该怎么做。

00:10:00 - Steven Vaughan-Nichols： 第二年，真正让微软担心的事情发生了。在 2000 年的时候，IBM 宣布，他们将于 2001 年投资 10 亿美元在 Linux 上。现在，IBM 已经不再涉足个人电脑业务。那时他们还没有走出那一步，但他们正朝着这个方向前进，他们将 Linux 视为服务器和大型计算机的未来，在这一点上 —— 剧透警告，IBM 是正确的。

00:10:30 - Steven Vaughan-Nichols： Linux 将主宰服务器世界。

Saron Yitbarek： 这已经不再仅仅是一群黑客所钟爱的，对命令行绝地武士式的控制了。金钱的投入对 Linux 助力极大。 Linux 国际 Linux International 的执行董事 John “Mad Dog” Hall 有一个可以解释为什么事情会变成这样的故事分享，我们通过电话与他取得了联系。

00:11:00 - John Hall： 我有一个名叫 Dirk Holden 的朋友，他是德国德意志银行的系统管理员，他也参与了个人电脑上早期 X Windows 系统图形项目的工作。有一天我去银行拜访他，我说：“Dirk，你银行里有 3000 台服务器，用的都是 Linux。为什么不用 Microsoft NT 呢？”

00:11:30 - John Hall： 他看着我说：“是的，我有 3000 台服务器，如果使用微软的 Windows NT 系统，我需要 2999 名系统管理员。”他继续说道：“而使用 Linux，我只需要四个。”这真是完美的答案。

00:12:00 - Saron Yitbarek： 程序员们着迷的这些东西恰好对大公司也极具吸引力。但由于 FUD 的作用，一些企业对此持谨慎态度。他们听到开源，就想：“开源。这看起来不太可靠，很混乱，充满了 BUG”。但正如那位银行经理所指出的，金钱有一种有趣的魔力，可以说服人们不再踌躇。甚至那些只需要网站的小公司也加入了 Linux 阵营。与一些昂贵的专有选择相比，使用一个廉价的 Linux 系统在成本上是无法比拟的。如果你是一家雇佣专业人员来构建网站的商店，那么你肯定想让他们使用 Linux。

00:12:30 - Saron Yitbarek： 让我们快进几年。Linux 充当着几乎所有网站的服务器，Linux 已经征服了服务器世界，然后智能手机也随之诞生。当然，苹果和他们的 iPhone 占据了相当大的市场份额，而且微软也希望能进入这个市场。但令人惊讶的是，Linux 已经等在那里并做好准备，迫不及待要大展拳脚。

这是作家兼记者 James Allworth。

00:13:00 - James Allworth： 肯定还有容纳第二个竞争者的空间，那本可以是微软，但是实际上却是 Android，而 Andrid 是基于 Linux 的。众所周知，Android 被谷歌所收购，现在运行在世界上大部分的智能手机上，谷歌在 Linux 的基础上创建了 Android。Linux 使他们能够以零成本，基于一个非常复杂的操作系统构建一个新的东西。他们盘算着推广这个系统，并最终成功地实现了这一目标。至少从操作系统的角度来看是这样，他们将微软挡在了下一代手机竞争之外。

00:13:30 - Saron Yitbarek： 这可是个大地震，很大程度上，微软有被埋没的风险。John Gossman 是微软 Azure 团队的首席架构师。他还记得当时公司的迷茫。

00:14:00 - John Gossman： 像许多公司一样，微软也非常担心知识产权污染。他们认为，如果允许开发人员使用开源代码，即使只是将一些代码复制粘贴到某些产品中，也会让某种病毒式的许可证生效从而引发未知的风险……他们也很困惑，我认为，这跟公司文化有关，很多公司，包括微软，都对开源开发的意义和商业模式之间的分歧感到困惑。有一种观点认为，开源意味着你所有的软件都是免费的，人们永远不会付钱。

00:14:30 - Saron Yitbarek： 任何习惯于投资于旧的、专有软件模式的人都会觉得这里发生的一切对他们构成了威胁。当你威胁到像微软这样的大公司时，是的，他们一定会做出反应。他们推动所有这些 FUD —— 恐惧、不确定性和怀疑是有道理的。当时，商业运作的方式基本上就是相互竞争。不过，如果是其他公司的话，他们可能还会一直怀恨在心，抱残守缺，但到了 2013 年的微软，一切都变了。

00:15:00 - Saron Yitbarek： 微软的云计算服务 Azure 上线了，令人震惊的是，它从第一天开始就提供了 Linux 虚拟机。 史蒂夫·鲍尔默 Steve Ballmer ，这位把 Linux 称为癌症的首席执行官，已经离开了，代替他的是一位新的有远见的首席执行官 萨提亚·纳德拉 Satya Nadella 。

John Gossman： 萨提亚有不同的看法，他属于另一个世代。比保罗、比尔和史蒂夫更年轻的世代，他对开源有不同的看法。

Saron Yitbarek： 这是John Gossman，他还是来自微软 Azure 团队。

00:15:30 - John Gossman： 大约四年前，出于实际需要，我们在 Azure 中添加了 Linux 支持。如果访问任何一家企业客户，你都会发现他们并不是现在才决定是使用 Windows 还是使用 Linux、使用 .net 还是使用 Java。他们在很久以前就做出了决定 —— 大约 15 年前，虽然对此有一些争论。

00:16:00 - John Gossman： 现在，我见过的每一家公司都混合了 Linux 和 Java、Windows 和 .net、SQL Server、Oracle 和 MySQL —— 基于专有源代码的产品和开放源代码的产品。

如果你打算运维一个云服务，允许这些公司在云上运行他们的业务，那么你根本不能告诉他们，“你可以使用这个软件，不能使用那个软件。”

00:16:30 - Saron Yitbarek： 这正是萨提亚·纳德拉采纳的哲学思想。2014 年秋季，他站在舞台上，希望传递一个重要信息。“微软爱 Linux”。他接着说，“20% 的 Azure 业务已经是 Linux 了，微软将始终对 Linux 发行版提供一流的支持。”没有哪怕一丝对开源的宿怨。

为了说明这一点，在他们的背后有一个巨大的标志，上面写着：“Microsoft ❤️ Linux”。哇噢。对我们中的一些人来说，这种转变有点令人震惊，但实际上，无需如此震惊。下面是 Steven Levy，一名科技记者兼作家。

00:17:00 - Steven Levy： 当你在踢足球的时候，如果草坪变滑了，那么你也许会换一种不同的鞋子。微软当初就是这么做的。

00:17:30 - Steven Levy： 他们不能否认现实，而且他们也是聪明人。所以他们必须意识到，这就是这个世界的运行方式。即使他们有一点尴尬，但是不管他们早些时候说了什么现在都要抛开。不然让他们之前那些“开源多么可怕”的言论影响到现在的决策，才真的是不明智之举。

00:18:00 - Saron Yitbarek： 微软低下了它高傲的头。你可能还记得苹果公司，经过多年的孤立无援，最终转向与微软构建合作伙伴关系。现在轮到微软进行 180 度转变了。经过多年的与开源方式的战斗后，他们正在重塑自己。要么改变，要么死亡。下一个发言的是 Steven Vaughan-Nichols。

00:18:30 - Steven Vaughan-Nichols： 即使是像微软这样规模的公司，也无法与数千个开发着包括 Linux 在内的其它开源大项目的开发者竞争。很长时间以来他们都不愿意合作，前微软首席执行官史蒂夫·鲍尔默对 Linux 用接近信仰的方式深恶痛绝。由于它使用的 GPL 许可证，他视 Linux 为一种癌症。不过一旦鲍尔默被扫地出门，新的微软领导层表示，“这就好像试图命令潮流不要过来，但潮水依然会不断涌进来。我们应该与 Linux 合作，而不是与之对抗。”

00:19:30 - Steven Vaughan-Nichols： 2017 年的微软既不是史蒂夫·鲍尔默的微软，也不是比尔·盖茨的微软。这是一家完全不同的公司，有着完全不同的理念，而且，一旦使用了开源，你就无法退回到之前的阶段。开源已经吞噬了整个技术世界。从未听说过 Linux 的人可能对它并不了解，但是每次他们访问 Facebook，他们都在运行 Linux。每次执行谷歌搜索时，你都在运行 Linux。

00:20:00 - Steven Vaughan-Nichols： 每次你用 Android 手机，你都在运行 Linux。它确实无处不在，微软无法阻止它，而且我认为，以为微软想用某种方式接管它的想法太天真了。

00:20:30 - Saron Yitbarek： 开源支持者可能一直担心微软会像混入羊群中的狼一样，但事实是，开源软件的本质保护了它，让它无法被完全控制。没有一家公司能够拥有 Linux 并以某种特定的方式控制它。Greg Kroah-Hartman 是 Linux 基金会的一名成员。

Greg Kroah-Hartman： 每个公司和个人都因为自己的利益对 Linux 做出贡献。他们之所以这样做是因为他们想要解决他们所面临的问题，可能是硬件无法工作，或者是他们想要添加一个新功能来做其他事情，又或者想引导 Linux 的开发轨道，这样他们的新产品就能使用它。这很棒，因为他们会把代码贡献回去，此后每个人都会从中受益，这样每个人都可以用到这份代码。正是因为这种自私，所有的公司，所有的人都能从中受益。

00:21:00 - Saron Yitbarek： 微软已经意识到，在即将到来的云战争中，与 Linux 作战就像与空气作战一样。Linux 和开源不是敌人，它们是空气。如今，微软以白金会员的身份加入了 Linux 基金会。他们成为 GitHub 开源项目的头号贡献者。

00:21:30 - Saron Yitbarek： 2017 年 9 月，他们甚至加入了 开源促进联盟 Open Source Initiative （OSI）。现在，微软在开源许可证下发布了很多代码。微软的 John Gossman 描述了他们开源 .net 时所发生的事情。起初，他们并不认为自己能得到什么回报。

00:22:00 - John Gossman： 我们本没有指望来自社区的贡献，然而，三年后，超过 50% 的对 .net 框架库的贡献来自于微软之外，这些是大量的代码。三星为 .net 提供了 ARM 支持。Intel 和 ARM 以及其他一些芯片厂商已经为 .net 框架贡献了特定于他们处理器的代码，以及数量惊人的修复 bug、性能改进等等 —— 既有单个贡献者也有社区。

Saron Yitbarek： 直到几年前，今天的这个微软，这个开放的微软，还是不可想象的。

00:22:30 - Saron Yitbarek： 我是 Saron Yitbarek，这里是代码英雄。好吧，我们已经看到了为了赢得数百万桌面用户的爱而战的激烈场面。我们已经看到开源软件在专有软件巨头的背后悄然崛起，并攫取了巨大的市场份额。

00:23:00 - Saron Yitbarek： 我们已经看到了一批批的代码英雄将编程领域变成了我你今天看到的这个样子。如今，大企业正在吸收开源软件，通过这一切，每个人都从他人那里受益。

00:23:30 - Saron Yitbarek： 在技术的西部荒野，一贯如此。苹果受到施乐的启发，微软受到苹果的启发，Linux 受到 UNIX 的启发。进化、借鉴、不断成长。如果比喻成大卫和歌利亚（LCTT 译注：西方经典的以弱胜强战争中的两个主角）的话，开源软件不再是大卫，但是，你知道吗？它也不是歌利亚。开源已经超越了这些角色，它成为了其他人战斗的战场。随着开源变得不可避免，新的战争，那些在云计算中进行的战争，那些在开源战场上进行的战争正在加剧。

这是 Steven Levy，他是一名作者。

00:24:00 - Steven Levy： 基本上，到目前为止，包括微软在内，有四到五家公司，正以各种方式努力把自己打造成为全方位的平台，比如人工智能领域。你能看到智能助手之间的战争，你猜怎么着？苹果有一个智能助手，叫 Siri。微软有一个，叫 Cortana。谷歌有谷歌助手，三星也有一个智能助手，亚马逊也有一个，叫 Alexa。我们看到这些战斗遍布各地。也许，你可以说，最热门的人工智能平台将控制我们生活中所有的东西，而这五家公司就是在为此而争斗。

00:24:30 - Saron Yitbarek： 如果你正在寻找另一个反叛者，它们就像 Linux 奇袭微软那样，偷偷躲在 Facebook、谷歌或亚马逊身后，你也许要等很久，因为正如作家 James Allworth 所指出的，成为一个真正的反叛者只会变得越来越难。

00:25:00 - James Allworth： 规模一直以来都是一种优势，但规模优势本质上……怎么说呢，我认为以前它们在本质上是线性的，现在它们在本质上是指数型的了，所以，一旦你开始以某种方法走在前面，另一个新玩家要想赶上来就变得越来越难了。我认为在互联网时代这大体来说来说是正确的，无论是因为规模，还是数据赋予组织的竞争力的重要性和优势。

00:25:30 - James Allworth： 一旦你走在前面，你就会吸引更多的客户，这就给了你更多的数据，让你能做得更好，这之后，客户还有什么理由选择排名第二的公司呢，难道是因为因为他们落后了这么远么？我认为在云的时代这个逻辑也不会有什么不同。

00:26:00 - Saron Yitbarek： 这个故事始于史蒂夫·乔布斯和比尔·盖茨这样的非凡的英雄，但科技的进步已经呈现出一种众包、自有生命的感觉。我认为据说我们的开源英雄林纳斯·托瓦兹在第一次发明 Linux 内核时甚至没有一个真正的计划。他无疑是一位才华横溢的年轻开发者，但他也像潮汐前的一滴水一样。变革是不可避免的。据估计，对于一家专有软件公司来说，用他们老式的、专有的方式创建一个 Linux 发行版将花费他们超过 100 亿美元。这说明了开源的力量。

00:26:30 - Saron Yitbarek： 最后，这并不是一个专有模型所能与之竞争的东西。成功的公司必须保持开放。这是最大、最终极的教训。还有一点要记住：当我们团结在一起的时候，我们在已有基础上成长和建设的能力是无限的。不管这些公司有多大，我们都不必坐等他们给我们更好的东西。想想那些为了纯粹的创造乐趣而学习编码的新开发者，那些自己动手丰衣足食的人。

未来的优秀程序员无管来自何方，只要能够访问代码，他们就能构建下一个大项目。

00:27:00 - Saron Yitbarek： 以上就是我们关于操作系统战争的故事。这场战争塑造了我们的数字生活的形态，争夺主导地位的斗争从桌面转移到了服务器机房，最终进入了云计算领域。过去的敌人难以置信地变成了盟友，众包的未来让一切都变得开放。

00:27:30 - Saron Yitbarek： 听着，我知道，在这段历史之旅中，还有很多英雄我们没有提到。所以给我们写信吧，分享你的故事。Redhat.com/commandlineheroes 。我恭候佳音。

在本季剩下的时间里，我们将学习今天的英雄们在创造什么，以及他们要经历什么样的战斗才能将他们的创造物带入我们的生活。让我们从壮丽的编程一线，回来看看更多的传奇故事吧。我们每两周放一集新的博客。几周后，我们将为你带来第三集：敏捷革命。

00:28:00 - Saron Yitbarek： 代码英雄是一款红帽公司原创的播客。要想免费自动获得新一集的代码英雄，请订阅我们的节目。只要在苹果播客、Spotify、Google Play，或其他应用中搜索“Command Line Heroes”。然后点击“订阅”。这样你就会第一个知道什么时候有新剧集了。

我是 Saron Yitbarek。感谢收听，在下期节目之前，请坚持编程。

什么是 LCTT SIG 和 LCTT LCRH SIG

LCTT SIG 是 LCTT 特别兴趣小组 Special Interest Group ，LCTT SIG 是针对特定领域、特定内容的翻译小组，翻译组成员将遵循 LCTT 流程和规范，参与翻译，并获得相应的奖励。LCRH SIG 是 LCTT 联合红帽（Red Hat）发起的 SIG，当前专注任务是《代码英雄》系列播客的脚本汉化，已有数十位贡献者加入。敬请每周三、周五期待经过我们精心翻译、校对和发布的译文。欢迎加入 LCRH SIG ：</article-12436-1.html>

关于重制版

本系列第一季的前三篇我们已经发布过，这次根据新的 SIG 规范重新修订发布。

via: https://www.redhat.com/en/command-line-heroes/season-1/os-wars-part-2-rise-of-linux

作者：redhat 选题：lujun9972 译者：lujun9972 校对：acyanbird

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