DevOps-悖论-全-

DevOps 悖论（全）

原文：annas-archive.org/md5/fee4ff212ba96ad8ded46e392b768bbb

译者：飞龙

协议：CC BY-NC-SA 4.0

第一章：介绍 – 什么是 DevOps 悖论？

我喜欢与他人分享。这是我写书时的主要动力。当我意识到作为作者的我们的作品可能在帮助他人时，产生了一种难以言喻的喜悦。但奇怪的是，DevOps Paradox（《DevOps 悖论》）却不是这样。

这次，我的动力更多是自我服务。我写这本书是因为我个人想理解什么是 DevOps。如果你了解我，或者读过我多本DevOps Toolkit系列书籍（https://www.devopstoolkitseries.com），那么你肯定会想，我应该早就知道什么是 DevOps 了，尤其是我还通过这些书籍传播有关 DevOps 的知识。

问题是，如果说我的多年的从业经历让我学到什么，那就是 DevOps 并不是一个明确定义的过程。没有必须遵循的规则。正如我在自己的旅程中发现的那样，正如你在本书中将会看到的那样，甚至可以质疑是否存在“DevOps 部门”或“DevOps 工程师”这一说法。这种模糊性正是 DevOps 对我来说如此迷人的原因，我也希望你，读者，也能感受到这一点。

我喜欢参加会议，但并不是出于显而易见的原因。我很少听讲座。相反，我更喜欢在会议中心和展览大厅的走廊上漫游，寻找下一个愿意让我向他或她请教学问的受害者。参加会议最好的事情是建立网络。最有趣的对话并不是在预定的讲座上发生的，而是在走廊里或聚会后。

我认为自己很幸运，能够把大量时间用于参加会议，因为我知道自己从那些“走廊对话”中受益匪浅。我希望能在这本书中做些类似的事情。

这本书叫做DevOps Paradox（《DevOps 悖论》）。对于那些可能在想这个名字是什么意思的读者，牛津英语词典将“paradox”一词定义为：

一种表面上矛盾的陈述或命题，经过调查后可能证明是有根有据的或是真的。

在这些访谈中，我的目标是审视这些关于 DevOps 是什么的，往往互相矛盾的看法，这些看法，正如我们将要探讨的那样，可能会证明是有根有据的。

目前我们所拥有的想法是，人们应该更加紧密地合作，并且我们应该消除那些拖慢他们速度的障碍。

因此，任何事情都可以是 DevOps。

几乎每个软件公司都将其产品营销为“DevOps”，而“DevOps 工程师”是招聘信息中最受追捧的职位。更不用说“DevOps 部门”如雨后春笋般涌现。

然而，尽管如此，我在书中与每一个人交谈时，几乎每个人都给出了不同的答案，来回应关于“什么是 DevOps？”的这个根本问题。

DevOps 将理智带入了一个非常混乱的世界，这个混乱源于一个误解，即软件开发类似于工厂生产。DevOps 继承了 Agile 所未完成的部分，并促使我们去消除那些我们常常没有意识到存在的障碍。

DevOps 的理念在于促进团队成员之间的共情，最终促成更大的合作。它关乎文化，但也涉及流程和工具。至少，这就是我最初的理解，尽管我从我合作的团队那里收到了非常不同的定义。

为了回答我对 DevOps 的疑问，我问了许多 DevOps 从业者他们认为 DevOps 是什么。他们中的一些是行业老兵，而其他人则是新兴的明星。有些是我的朋友，而另一些是我远远崇拜的人。

这些对话中的许多是通过远程会议记录的，另外一些则发生在酒吧或会议的走廊中。每当有机会时，我都会尽量与人面对面交谈。

我希望访谈能够轻松随意。我不希望人们回答预设的问题。相反，我的目标是将我通常在会议和作为顾问与公司合作时，与专家们进行的对话呈现给更广泛的观众。我确实相信，一些最重要的突破源自走廊里的闲聊。这就是我希望在访谈中保持的精神。

每次对话都从“什么是 DevOps？”或者类似的问题开始。这只是一个开场白，目的是为了引导出一种无结构、无准备并且非常随意的对话。可以把每次访谈当作是与朋友或在酒吧里偶遇的熟人的对话。事实上，有几次访谈实际上是在酒吧里喝着几杯啤酒时录制的！

在本书中，我希望分享与那些实践并经常塑造 DevOps 的人的轻松对话。我的希望是，我们能从中获得对这些人背后驱动力的洞察，并更好地理解是什么使 DevOps 如此强大。

我采访的人唯一的共同点是对 DevOps 本身的兴趣。然而，你会看到，他们中的一些人对 DevOps 的定义（或否定）截然不同，甚至对其是否值得追求也有不同看法。你可能常常会觉得某个人所描述的内容与其他人所说的相矛盾。这是故意的，在我看来，这反映了 DevOps 正在试图驯服的混乱。它也提醒我们，我们在将 DevOps 引入工作场所文化的过程中，仍处于非常早期的阶段，同时，我们还在尝试应对软件行业的复杂性，并为相同的问题找到不同的解决方案。

话虽如此，我敦促你，亲爱的读者，保持开放的心态。你几乎肯定听说过 DevOps，许多人可能正在你们的组织中实施某种形式的 DevOps。我只希望你能暂时放下已有的知识。书中的访谈很可能会颠覆你所认为的知识，挑战你所有的假设和经验。然而，这本书不会告诉你应该站在 DevOps 争论的哪一方。这里没有对错之分。这本书也不会告诉你如何“做”DevOps，尽管你可能会从这些访谈中获得一些实施的启示。我的目标仅仅是呈现 DevOps 悖论的两面，并为你提供空间，让你自行做出判断。

真是讽刺，原本旨在打破组织内孤岛并促进跨部门协作的东西，竟然成为 IT 社区中众多争论的主题！但这正是 DevOps 悖论的关键，不是吗？这也是为什么它如此引人入胜的话题。你可能不同意书中访谈的所有内容，但至少它们应该能激发思考，甚至可能引发你和你的团队在开展 DevOps 实践时，在组织内部展开辩论。

最后，在我们开始之前，我要感谢那些抽出时间接受采访的人，我对你们所做出的巨大贡献感激不尽。谢谢你们！没有你们，这本书不会成形！

我尽力做到平易近人，帮助人们提升技能。随时可以通过 Twitter（@vfarcic）、发邮件给我（viktor@farcic.com）或加入 Slack 工作区 DevOps20（http://slack.devops20toolkit.com/）与我联系。

Viktor Farcic是 CloudBees 的首席软件交付战略家和开发者倡导者，Google 开发者专家和 Docker Captains 成员，且是出版作者。

他的主要兴趣包括 DevOps、微服务、持续集成、持续交付与部署（CI/CD）以及测试驱动开发（TDD）。

他经常在社区聚会和会议上发言。

他出版了《DevOps 工具包系列》（https://www.devopstoolkitseries.com）和《测试驱动的 Java 开发》（http://www.amazon.com/dp/B00YSIM3SC）。

他的一些随想和教程可以在他的博客TechnologyConversations（https://technologyconversations.com/）中找到。

第二章

1

第三章：杰夫·苏斯纳

Sussna Associates 创始人兼首席执行官

第四章：介绍 Jeff Sussna

2011 年，Jeff Sussna 创立了 Sussna Associates，这是一家专注于企业工作坊、辅导和战略设计的公司，帮助客户整合 DevOps。他是《设计交付：在数字服务经济中重新思考 IT》的作者，拥有超过 30 年的 IT 经验，从软件开发到 IT 集成。你可以在 Twitter 上关注他，账号是@jeffsussna。

Viktor Farcic：嗨，Jeff。在我们开始讨论 DevOps 之前，你能自我介绍一下吗？

Jeff Sussna：我是一个独立顾问，专注于敏捷、DevOps 和设计思*的辅导。通过我的公司 Sussna Associates，我在 IT 行业工作了 30 年，在此期间，我构建了系统并领导了跨越整个开发、QA（质量保证）和运*领域的组织。

我在 2008 年接触到了设计思*，特别是服务设计和云计算，这对我来说有点像顿悟，因为我意识到在 21 世纪，服务实际上是云计算和 IT 的核心。无论是基础设施即服务、软件即服务，还是微服务，你所谈论的都是需要在组织的每一个层面上以用户为中心的服务。

我实际上已经将这一理念融入到我的咨询实践中，帮助 IT 团队，无论是企业还是初创公司，让他们真正思考无论是他们的用户、客户、数据库团队、网络团队、应用团队，还是其他任何团队的需求。正因如此，我负责将同理心的概念引入到 DevOps 中。

在我看来，我所做工作的核心是学习开发和运*如何在考虑彼此需求的情况下进行思考。我将所有这些想法融入到我写的书《设计交付：在数字服务经济中重新思考 IT》中。

什么是 DevOps？

Viktor Farcic：在你看来，“DevOps”这个词是什么意思？似乎没有人对它有清晰的理解，或者至少每个人的理解都不同。有些人说它与新工具有关，有些人认为它是文化的变化，还有人将其与 DevOps 工程师角色联系在一起。甚至有人说 DevOps 这个词根本不存在。事情就像这样一直延续下去，好像 DevOps 是一个用来迷惑每个人的阴谋。

Jeff Sussna：对我来说，“DevOps”这个词的意义就在它本身。我们必须开始将开发和运*视为一个更大统一体的一部分。我用来得出这个结论的指导原则再次回到“服务”这一概念。我们交付服务的方式是数字化的，而关于服务的关键在于，你制作它的方式是你制作什么的一部分。

如果你看看过去几年航空业中发生的一些公共关系噩梦，就会发现，航班取消是因为预定系统出现故障。最近就有一个事件，一家航空公司无法为乘客办理登机手续，因为他们的计算机系统瘫痪了，他们尝试使用手机为乘客办理登机手续。

“对我来说，‘DevOps’的意义就在这个词本身。我们必须开始把开发和运*视为一个更大统一实体的一部分。”

——杰夫·苏斯纳

*克多·法尔西奇：我认为现在每个人都把软件当成理所当然了。我们变得不耐烦，期望事情立即发生，如果失败了，用户就会转向其他地方。现在没有忠诚度了。

很多人还没有意识到，这不仅仅是软件功能的问题，还有它系统的稳定性。你同意吗？

杰夫·苏斯纳：越来越多的情况是，客户的用户体验受操作成功和失败的影响，程度不亚于功能和特性的影响。我喜欢举的例子是，假设城里开了一家新餐厅。你在一个星期六晚上去尝试，周一早上上班时，别人问你餐厅怎么样，你说：“食物很棒，但服务很差。”人们就会更少尝试这家餐厅，因为他们认为食物和服务是一个整体体验的一部分。在我看来，DevOps 反映了我们必须把功能性和可操作性放在一起考虑的观点。

无论你的设计多么出色，或者你的网站编写得多么完美，如果它非常慢，或者用户不断遇到 500 错误，他们的满意度都会下降。

你必须思考系统架构和应用架构。你必须考虑部署是如何发生的，并且你必须将安全性与所有这些因素一起作为一个整体来思考。在我看来，DevOps 是一个合成词，意味着我们将两个词合并在一起，之所以这样做，是因为我们开始理解它们实际上是一个整体的一部分。

*克多·法尔西奇：就像是一个大主题，而不是分部门的结构？

杰夫·苏斯纳：是的，对我来说，重要的一点是，DevOps 的融合并不意味着每个人都必须为同一个经理或副总裁工作。每个人都必须把自己的工作看作是更大事物的一部分。你必须从“这段代码如何部署？这段代码的安全性如何？这段代码的效率如何？这段代码如何扩展？”的角度思考你的代码。

这并不一定意味着你必须是那个将它部署到生产环境中或响应警报的人，无论情况如何。我与许多企业合作，这些企业有职责分离的观念，认为开发人员不能将代码推送到生产环境中，但这并不意味着他们不能做 DevOps。如果你是一家大型组织，无论是跨国保险公司还是 Netflix，拥有很多层次和许多技术组成部分，那么可能有很多微服务。如果没有，仍然有很多应用程序。认为你可以将它们都整合成一个大部门，配备一个巨大的桌上足球台和一个巨大的开放办公空间，这样的想法其实没有太大意义。

你必须从跨团队协作的角度看待 DevOps，这些团队不一定向同一个人报告，不一定坐在办公室的同一排，也不一定在同一个城市工作，这没有问题。问题在于，当每个团队都认为，“这是我的工作，我只关心我的工作，任何其他需要我帮助的人都得排队等着，我只会考虑我的那部分拼图。”

“你必须从跨团队协作的角度看待 DevOps，这些团队不一定向同一个人报告，不一定坐在办公室的同一排，也不一定在同一个城市工作。”

—Jeff Sussna

团队环境中的 DevOps

Viktor Farcic：我经常看到同样的事情发生，人们说，“这是我的工作，但那不是我的工作。” 既然如此，如何防止这种思*方式，尤其是在不同的经理给不同的团队下达不同的目标时，尤其是那些目标不一定与整体愿景一致的情况，因为每个人都像你说的，只关注自己那部分拼图呢？

Jeff Sussna：我指导团队的方式是让他们把彼此视为客户，就像公司把支付费用的人视为客户一样。网络团队也有客户，这非常有趣，因为在 DevOps 中，我们有时会陷入这种稍微带点魔幻色彩的思*方式，我们都在想，“嗯，DevOps 的一个关键组件就是云计算。” 云计算解决了很多问题，我同意这一点，但如果你考虑 AWS、Azure 或 Google Cloud Platform，它们就是最终的“信息孤岛”。没有比你们组织和 AWS 之间的隔阂更大的孤岛了。

AWS 甚至不会告诉你数据中心在哪里，更不用说谁在处理你的代码、你的系统，或者其他什么事情了。这些组织的特点在于，它们明白自己处于服务行业，它们的工作就是帮助你成功，并且它们持续创新以帮助你成功。我认为同样的模型也适用于组织内部；无论是分拆，还是有两个跨职能的披萨团队，或者有部门划分——这并不重要。问题必须从“我们如何运营网络”转变为“我们如何帮助人们使用网络”，这是一个非常微妙，但非常重要且真正意义深远的思*转变。

如果你还在想着如何运营网络，而有人需要一个 IP 地址、一个 DNS 条目或防火墙更改，他们将不得不排队等候你的流程。但是如果你将他们置于中心，告诉他们，“好的，我们的工作是确保这些应用程序可以在我们的网络上成功运行并扩展”，那么像 IP 地址、DNS 条目和防火墙更改之类的事项就成了你工作的核心。因此，通过这种方式，你的工作主要就是考虑那些需要使用我们服务的人，并回答传统问题：“我们如何确保路由器不宕机？”这个问题虽然并不会消失，但它变成了一个实现细节，而不再是你工作的核心内容。

Viktor Farcic：这完全合理。每个人的工作都会以用户为中心，无论这些用户是外部的还是内部的。同时，每个人的工作都是帮助别人，即便这个“别人”是来自不同部门的同事。

DevOps 中的同理心

你们都写过并且讲过很多关于同理心的内容。我不确定你们是否创造了“EmpathyOps”这个词，但能否详细解释一下你们所说的同理心是什么？

Jeff Sussna：关于同理心的意义有很多困惑和焦虑，很多人往往误解它。有时候人们认为同理心意味着沉溺于别人的痛苦。实际上，现在有一位来自耶鲁大学的哲学家提出，同理心其实是有害的，是所有世界问题的根源，我们所需要的应该是同情。

从我的角度看，这代表着对同理心和同情心的误解，但我最喜欢的是当人们说，“社会病态者在同理心方面表现得特别好”时。对此我的回答是，如果你的组织里有社会病态者，那你有一个更大的问题，DevOps 是无法解决的。此时，你的问题在于人力资源管理。你需要区分的是情感同理心和认知同理心，我在 DevOps 的语境下使用认知同理心的方式非常简单，那就是从他人的视角思考问题的能力。

如果你是开发人员，且你在思考，“部署和运行我的应用程序的体验是什么？”那么你是在从运*人员的角度思考。如果你是运*人员，并且你在考虑，“当你需要在几个*时内启动一个测试服务器来测试一个热修复，因为所有测试的泳道都被其他事情占满了，这对我的服务器配置流程意味着什么？”那么你是在从测试人员的角度思考。所以，对我而言，这就是共情，这就是共情能力，它正是客户服务的核心，设计思*的核心，产品开发的核心。我们的客户试图完成什么，他们需要我们提供什么帮助，我们怎样才能帮助他们？

“我在 DevOps 中以一种非常简单的方式使用认知共情，即从别人的角度去思考问题的能力。”

—杰夫·萨斯纳

*克托·法尔奇奇：所以，每个人都有客户，我们都需要开始思考我们的工作是否能让客户的生活更轻松、更好，无论这个客户是内部的还是外部的。我们不应该再隐藏在虚构的目标后面。

杰夫·萨斯纳：我给你们举个例子。其实最近我因为这个有点*麻烦，因为我倾向于有点 AWS 的粉丝情结，但之所以这样，是因为我认为他们比任何人都更理解以用户为中心的创新理念。

几年前，我曾帮助一个客户将一个应用程序从共置中心迁移到亚马逊。这是一个相当简单的应用程序，主要是一个“叉车”迁移。它运行在一台开始出现故障的旧硬件上，客户不再想管理他们的硬件了。所以我们说，“好吧，那就把它搬到亚马逊去。”在这种情况下，我们并不打算做一些复杂的工作，比如重新设计应用程序之类的，但我们应该利用一些更基本的亚马逊功能，比如能够让网页服务器在多个可用区之间自动扩展。

这是一个相当直接的操作，没有理由不去做。然后我们来到了架构中的一个环节，那就是 Memcached 服务器，我们无法弄清楚如何将其集群化。结果是，在那个时候，做到这一点相当困难。确实有一个产品可以实现，但非常昂贵，而且我们不确定它是否真正有效。于是我们试探了一段时间，最后决定，别担心它；它只是一个缓存，如果缓存崩溃了，应用程序足够智能，会回退并直接访问数据库。是的，它会慢，但它会存活下来，直到我们有机会重新启动缓存。别纠结了，继续工作，完成任务。

我们完成了工作，我记得大约几周后，AWS 宣布了一项新服务，叫做 ElastiCache，猜猜是什么？——一个跨数据中心运行的集群式 Memcached 服务器。你只需要按下几个按钮，输入几个命令，就能将它作为服务启动。我记得当时我想，简直就像他们在读我们的邮件一样。

这个故事的重点是，亚马逊并不仅仅停留在“我们提供基础设施即服务、存储、虚拟机和网络”这些现有业务上。它们在看自己的客户面临什么困难，如何帮助他们简化这些问题。我认为这就是我们所说的 DevOps 精髓：作为开发人员，我如何让运营的工作变得更轻松、更高效；作为运*人员，我又如何让开发的工作变得更轻松、更高效？

*克托·法尔奇：但是，是什么阻止公司们应用这种思*方式？是因为他们不想采取这种方法，不认为这种思*有价值，还是其他原因？

杰夫·苏斯纳：就在前几天，我和一个客户谈论了他们在流程中遇到的一个障碍，涉及到将代码部署到测试环境。我开始时问：“为什么开发人员不能自己部署代码？那不是生产环境，没有职责分离问题。”他们当时没有想过这个问题。我们讨论了一下，他们说没有任何原因阻止他们这么做。我们需要做一些技术上的改变，但没有规则规定他们不能这么做。这是一个简单的例子，展示了如何提供那些能让开发人员工作更轻松的工具。我认为这背后的思路是可以推广的。

这与开发和设计、产品和开发、开发和运营、以及安全和开发之间的关系有关。我们都需要从“我们如何能更好地帮助彼此完成我们想做的事情？”的角度来思考。同理心是使你能够做到这一点的关键。但同理心也意味着，“忘记我在做什么，你在做什么，你的目标是什么，我该如何利用我的专业知识帮助你实现它？”

大型 DevOps 公司与*型 DevOps 公司

*克托·法尔奇：当你拜访公司时，你是否看到一些反复出现的主题，或者它们之间有一些共性？它们是否面临相同的问题，除了一个公司较*，另一个公司较大这个显而易见的差异？

杰夫·苏斯纳：令我吃惊的是，无论公司大*，它们遇到的这些问题是如此普遍。例如，几乎每一个我接触过的客户，不论大*，都面临合规性问题。

也许他们是一家初创公司，但他们是一家医疗初创公司，这意味着他们必须处理 HIPAA（1996 年健康保险流通与问责法案）；或者他们可能处理信用卡事务，这意味着他们必须遵守 PCI（支付卡行业）；或者他们为联邦政府提供服务，这意味着他们必须遵守 FedRAMP，这和其他任何合规规则集一样严格。审计问题、职责分离和访问控制；这些问题在我的客户中都是普遍存在的，无论他们的规模如何。

“几乎我遇到的每一个客户，无论规模大*，都有合规性问题。”

—杰夫·萨斯纳

我看到开发与运*之间的挑战是出乎意料的普遍存在。我认为主要的区别在于，在大公司中，功能失调往往是结构性的，比如，“我不喜欢你的组织，因为我们有不同的副总裁，而副总裁们在争夺权力”，或者类似的事情。或者他们可能并不争夺权力，而是只是彼此独立，在某种程度上存在竞争关系。

有一些制度化的边界将人们隔开。在*公司中，这往往是更个人化的。例如，“我不信任你，因为两年半前，你在重大问题上搞砸了，所以我再也不想让你部署到生产环境了”，但这种信任问题和理解问题出乎意料地具有普遍性。

这很有趣，因为在敏捷和 DevOps 中，我们经常讨论反馈环路，以及如何更快地学习。如果你看看 DevOps 的三大方式，你会看到流动、反馈和持续学习。令人惊讶的是，反馈竟然是如此困难。

*克托·法尔奇：我认为人们往往会采用一些实践，但失败的地方在于没有理解这些实践背后的目标。因此，我们实施了这些实践，却没有真正与它们建立联系，也没有获得任何实质性的好处。如今几乎每个人都会收集反馈，真正的问题是，有多少人利用这些反馈进行学习和适应？

杰夫·萨斯纳：我曾与一个客户进行过一次研讨会，其中一部分内容专门讨论反馈环路。这个客户是一个非常成熟的敏捷和 DevOps 组织，在某个时刻，我给他们安排了一个练习，让他们将一些线性流程重新构想为循环、反馈驱动的流程，以便看看有什么不同。他们都笑了笑，智慧地点点头。有人举手说：“我们现在基本上没有线性流程了；我们已经把它们都变成了循环的。”我说：“好吧，那就听我说一次 – 试试看会发生什么，这可能是一个非常快速且简单的练习。”

我会把*组分成四个团队，其中三分之四的团队独立得出了相同的结论，他们在练习后非常羞涩地向我报告了这一点。他们得出的结论是，他们非常擅长收集反馈，但实际上并没有利用这些反馈。他们意识到自己浪费了大量时间和精力，因为他们有一个完整的反馈机制，但从未真正把它关闭。如果我看到敏捷和 DevOps 中有危险的话，那就是我们过于关注如何尽快将工作交付到生产环境，而把它看作是一个推送问题。我看到的关于 DevOps 的一个误解是，DevOps 只是关于部署自动化。

“如果我看到敏捷和 DevOps 中有危险的话，那就是我们过于关注如何尽快将工作交付到生产环境，而把它看作是一个推送问题。我看到的关于 DevOps 的一个误解是，DevOps 只是关于部署自动化。”

—杰夫·苏斯纳

问题在于这是单向的，你实际上并没有学习。如果你把东西推向生产环境，然后只是去从待办事项中挑选下一个任务，你怎么能真正知道下一个任务是不是待办事项中最合适的任务呢，除非你关注你刚刚部署的东西发生了什么？我会说，真正突破这种工业时代的思*方式——像把产品推出工厂的大门那样——是一个普遍的挑战。

*克托·法尔奇：这不就是一个盲目遵循流程而不理解背后原因的例子吗？短周期冲刺的理念并不是为了做更多的工作，而是为了更早得到反馈，从而更好地决定下一步该做什么。如果我们只是从待办事项中挑选一项任务，那么我们就错过了重点。

话虽如此，我们换个话题。当你与团队或公司合作时，采用的是什么方法？是从顶部开始、从底部开始，还是从中间开始？

杰夫·苏斯纳：我从各个地方开始；这真的取决于客户。我的意思是，一般来说，可能是从首席信息官到某个运营总监或开发总监，具体情况非常依赖。这个问题很有意思，因为我发现，在某个时刻，这两者必须结合起来。

关于 DevOps 是否需要高层支持，或者它应该是一个草根驱动的事情，存在一个有趣的问题。根据我的经验，起点在哪里并不重要，但在某个时刻，它需要两者的结合。

我见过一些地方，尤其是在敏捷方面，一位首席信息官（CIO）参加完会议回来后说：“我们现在要做敏捷了”，这很好；但从这个阶段到一个能够实施敏捷的组织，实际上并不需要很多地面上的活动。有些活动非常草根化：新行为和新活动的传播。我越来越关注的一个方面是采纳过程是什么样的，在我看来，在我的经验中——我认为这是组织面临的另一个难题——改变组织的行为与改变你的网站工作方式，或者改变你的持续集成流水线的工作方式并没有什么不同。

这是一个必须随着时间推移而发生的过程，并且它必须以敏捷的方式进行。我的意思是，必须基于反馈进行学习；你不能只是简单地放入一个计划然后执行，因为发生的情况是人们与那个计划互动时，他们会遇到困难、抵制、学习、犯错，你会发现你的计划可能需要根据你的企业文化做一些调整，因此这真的是一个必须逐步展开的过程。

改变 DevOps 文化

*克托·法尔奇：当你试图改变文化时，你有计划吗？我记得有人告诉我，你不能真正预测一个复杂的系统；你能做的唯一事情就是戳它，看看会发生什么。

杰夫·萨斯纳：你说得对，你可以使用一些技术将人们引入你的系统，然后你必须与他们互动时的反应相结合。每个人都稍有不同。

我教学时，每次进行教练辅导时，我总是根据组织的规模，从一周到一个月不等，花很多时间进行嵌入式观察，真正理解他们是谁以及他们的现状。然后，我开始引入新的技术；无论是站立会议、持续集成，还是自动化服务器配置，实际上都无关紧要。

然后，介绍看板时就开始变得有趣了。我们想，“这很简单——我们只是向人们展示它是如何工作的并解释主要的工具。”但实际发生的是，当人们开始使用它时，他们在使用过程中会遇到非常独特的困难，这些困难与他们是谁、他们的个性如何、他们的企业文化如何密切相关。真正的工作开始于这里，试图理解这些问题。我认为你真的无法预测这一点。这是一个非常突现的过程。

*克托·法尔奇：没错，我们不能盲目地接受任何事物，因为我们每个人都非常不同，每个公司的文化也不同，我们的项目也不同。认为我们有如此大的差异，却仍希望一个单一的解决方案能够解决所有人的问题，这在我看来是幼稚的。我们都需要积累经验，理解自己，并利用这些知识去发现最适合我们的方式。

我对设计思*很感兴趣，这是你提到过几次的内容。能否详细讲讲这个概念？

Jeff Sussna：设计思*非常简单，指的是你可以借鉴设计师解决问题的方式，无论是图形设计、工业设计，还是用户界面设计师的方式，然后将其提炼成一种方法论，进而应用到其他问题上。例如，如何将 DevOps 引入一家新公司？

设计思*的核心是以用户为中心的设计理念，它基于同理心，但它有特定的技巧来帮助你实现同理心，这些技巧都基于观察和与客户的互动。

我告诉团队的一个关键点，即使是在 IT 部门深处，也是：如果你们要重新设计某个东西——例如，你们是数据库团队，想要重新设计应用团队获取新数据库实例的流程——首先要做的就是观察他们是如何操作的，真正去和他们一起坐下来，看他们的操作；然后从这个过程中，你们可以提出解决方案，制作原型并获取反馈。

“当前的敏捷和 DevOps 实践是不完整的，因为我们没有真正的机制来融入来自我们想要服务的人的真实反馈。”

—Jeff Sussna

太多时候，IT 部门会做出这样的决策：我们先搞清楚正确的解决方案是什么，然后构建它，接着发送邮件宣布将在接下来的三个月里逐步推广，并提供培训。而我们没有做的是花时间去了解我们所提供的解决方案对实际使用它的人们来说是否有效。

设计思*的核心是同理心观察。它在实际执行时可以有更多或更少的形式化，从此出发，采用一个非常迭代的过程，包括原型设计、用户测试、重新设计和重新实施，几乎以敏捷的方式，找到通向解决方案的路径。

我之所以谈论设计思*这么多，是因为我认为当前的敏捷和 DevOps 实践是不完整的，因为我们没有真正的机制来融入来自我们想要服务的人的真实反馈。但与他们一起验证我们的想法、信念、解决方案和策略，这正是我认为将设计思*融入我们所做的工作中的重要原因。

Viktor Farcic：那么敏捷和 DevOps 又是怎样的呢？它们是分别独立的实践吗？还是彼此相互延伸，抑或是同一件事的不同名称？因为根据你所说，似乎两者有些相似之处。

敏捷与 DevOps

Jeff Sussna：DevOps 完善了敏捷的方程式。敏捷强调交付价值和有效的代码，但问题是，仅仅这样做，它并不能实际交付任何东西。实际上，敏捷在编写和测试完成代码后就停止了，但这些代码没人能用，所以它对任何人都没有用处。

这样做的原因是，敏捷发展是在产品时代兴起的，那时候你将代码写好，放在 CD 上，然后寄给客户，由客户负责实际的部署和运营。但那种日子现在几乎已经过去了，因此开发和运*元素实际上是同一方程式的一部分。敏捷实际上无法提供价值，除非这些代码能够部署，且部署环境能够运营，并且问题能够解决，包括新代码的部署，等等。

我不认为没有运*的开发还有什么意义；再强调一下，当我说“运*”时，我指的是从整体可操作性的最大意义上来说，这不仅仅是指运行服务器或基础设施，还包括安全性，这是其中不可或缺的一部分。

如果你的代码或基础设施不安全，那可能比它们不具备扩展性更糟。如果你的代码不具备扩展性，你的网站会很慢，或者你的数据录入应用很慢，这很烦人。

Viktor Farcic：慢总比因有人利用安全漏洞使整个集群崩溃而导致完全不可用要好。如果我的数据被从你的系统中盗取，不仅我将不再是你的客户，甚至很可能会起诉你。我感到困惑的是，关于 DevSecOps 的讨论，因为我总是有种感觉，为什么我们还在讨论安全性？安全性难道不是必需的吗？所以它应该是 DevOps 的一部分？或者，它是不是变成了可选项，现在我们才需要将它作为一个独立的实践来讨论？

Jeff Sussna：如果我的个人健康数据、信用卡或社会安全号码被盗，那可不只是令人烦恼而已。我知道，当人们谈论 DevSecOps 时，他们谈论的是坚固的 DevOps，也就是内建安全性的 DevOps 理念。但问题是，你会想提议做一个非坚固的 DevOps 吗？我肯定不会。

我肯定不想去找我的 CIO 说，我们不想做坚固的 DevOps，我们只想做非坚固的 DevOps，不会担心安全性。我不认为那会得到好评。但从这一点出发，我认为我会说，如果我们想要做敏捷，现在，你真的不能没有将这种思*延伸到你的操作方法中。

我认为，敏捷和 DevOps 没有彼此支持的情况下，它们的意义越来越值得怀疑。我期待有一天我们能找到一个更好的词，能够涵盖整个过程，我们甚至不再关心是否存在划分。我的意思是，如果你想想看，敏捷和 DevOps 之间的分界线仍然存在于开发和运*之间这个奇怪的空间，而这正是我们通过 DevOps 想要消除的地方。可以说，如果你认真对待 DevOps，你就不可能相信敏捷和 DevOps 之间存在本质的分隔。

"我认为，敏捷和 DevOps 如果没有彼此配合，其意义变得越来越值得怀疑。"

—Jeff Sussna

Viktor Farcic：根据你的经验，是否有某些专家团队更愿意接受这种思*方式，还是说这是每个人都会面临的普遍问题？

Jeff Sussna：我认为越来越多的人开始接受将敏捷与 DevOps 结合的想法，特别是从如何将产品经理的脑海中的想法快速推向生产的角度来看。我认为反馈循环的后端要困难得多，我觉得大多数人仍然在为此而挣扎，这是一种错误。正如我之前所说，我认为敏捷和 DevOps 的讨论经常有一个共同的错误，那就是我们总认为它们是单向的。

我给你举个例子：我曾经和一个组织合作，开发负责人告诉我他们会做冲刺演示，展示他们将在部署前展示给大家的内容。冲刺演示的重点是信息收集；它是为了收集反馈，确保在部署之前，你将以正确的方式部署正确的东西。这个开发负责人以一种纯粹的方式对待冲刺演示：“好吧，我们完成了，在发货之前让你们看看，但不要指望我们会做任何改动或听取你们的反馈。”我在很多地方看到这个问题。

Viktor Farcic：这就像是我在给你许可去看它，但你是否看得到对我来说并不重要。

Jeff Sussna：没错，我认为融入设计思*的好处之一就在于其核心理念是，你要将其展示给某个人，然后根据他们的反馈做出相应的更改。

Viktor Farcic：如果我理解得没错，这意味着即使我们回顾过去很多年，在许多地方敏捷方法并没有成功，因为如果它真的成功，那么这种思*方式早就应该深入人心，至少在组织的某些部分。

你提到复杂系统，我觉得这实际上值得稍微谈一谈。

你说得非常对，复杂系统是那些你无法预测的系统。所以，从这个意义上讲，你无法为它们制定计划；你只能根据从探索中获得的知识去探索并与之互动。

Jeff Sussna：我们所构建的系统是复杂系统，即使在那些有着悠久传统环境的企业中，我也越来越看到它们会因为应用程序、数据库、网络、负载均衡器和防火墙之间的交互而发生故障。

为了理解故障，你必须了解所有组件如何相互作用，如果其中任何一个组件有所不同，那么故障可能会有所不同，或者根本就不会发生。数字化业务和数字经济以及所有这些有趣的东西，正在打破这些不同系统之间的边界。

*克托·法尔奇：当我看到像双模 IT 这种理念时，对我来说它并没有和现实连接起来，因为我看到的是面向客户的应用程序，为了正常运行，它们必须与 ERP（企业资源规划）系统进行交互，而 ERP 系统缺乏的敏捷性成了前端系统敏捷性的一大障碍。

现在，我们必须将整个组织和所有系统视为一个复杂的整体。

杰夫·苏斯纳：如果我们不能预测或控制复杂系统，那我们该怎么办？我们就放弃吗？不，我们必须具备持续学习的能力。那么，为什么我们需要敏捷？为什么我们需要 DevOps？为什么我们需要设计思*？

因为当我们正确地处理这些问题时，它们使我们能够非常高效、有效地持续地从彼此、从客户、从我们的系统、从我们的事件中学习，我认为这最终是我们想通过所有这些新实践来实现的目标。

*克托·法尔奇：根据我的经验，当我深入探讨时，超越人们告诉我的表面，我总能发现归咎于某人总是最大的障碍。因为当类似你说的事件发生时——比如停机——总会有人需要为此负责，这意味着没有人会提供足够的信息让我从中学习。

杰夫·苏斯纳：即便是这样，归咎于某个人的想法也假设了你能够将原因孤立开来。

*克托·法尔奇：没错，这又把我们带回了复杂系统的问题。

杰夫·苏斯纳：完全正确。

*克托·法尔奇：我觉得这样就可以很好地结束讨论，除非你还有其他想说的，杰夫？

杰夫·苏斯纳：不，我不这样认为，但和你聊得很愉快，*克托。我迫不及待想看看其他人对 DevOps 的看法。

第五章

2

第六章：达米恩·杜波塔尔

Træfik 的开发者倡导者

第七章：介绍达米安·杜波塔尔

根据达米安的说法，成为一名 DevOps 工程师，关键在于人、文化和工具。除了在 Træfik 的工作外，达米安还是 CloudBees 的培训工程师，专注于 CloudBees Jenkins 平台和 Jenkins OSS。你可以在 Twitter 上关注他，账号是@DamienDuportal。

*克托·法尔奇：我有个问题想问你，我打算以这个问题为切入点来展开我们的 DevOps 讨论。简单来说，杜波塔尔对 DevOps 的定义是什么？

杜波塔尔对 DevOps 的定义

达米安·杜波塔尔：今天，DevOps 成为了一种时髦的流行词，试图聚焦于价值，而不仅仅是技术或成本问题。从本质上讲，DevOps 关乎我们在 IT 行业中应该如何合作。我不仅仅是在谈论流程，还包括文化、工具和相关人员。这也是我说它是一个流行词的原因，因为它没有像 IT 服务管理那样严格的定义。

“DevOps 并不专注于工具本身，而是专注于这些工具如何实现一种新的工作方式，或是打破团队和部门之间的壁垒，这意味着需要互相协作和沟通，从而促进跨团队的意识。”

—达米安·杜波塔尔

最近，DevOps 被另一种影响力所接管，但最初，对我来说，它是一个围绕工具概念开始的运动。DevOps 并不专注于工具本身，而是专注于这些工具如何实现一种新的工作方式，或是打破团队和部门之间的壁垒，这意味着需要互相协作和沟通，从而促进跨团队的意识。

我将 DevOps 定义为同理心，我认为这才是关键所在。DevOps 是一种将同理心带回工作中的方式，Docker 是其中最著名的工具，但绝不是唯一的工具，能够帮助你做到这一点。但重要的是要理解，当我说同理心时，我指的是与其他同事的同理心，不仅仅是 DevOps 两方——开发和运*之间的同理心，也包括工程师与销售人员、高管与员工之间的同理心，甚至是组织内所有部门之间的同理心。这些部门应该关注全局的最优解，而不是各自的局部最优解。你需要意识到其他同事可能面临的问题，而不仅仅是那些影响你或你所在部门的问题。工具只是实现这一目标的一种方式，这也深受工程师的喜爱，因为工程师喜欢他们的工具。

*克托·法尔奇：那么，DevOps 真的是用工具来帮助带回同理心的吗？

DevOps 能否带回同理心？

Damien Duportal：没错！如果你有一个能帮助你建立共情的工具，那么你就有了开始对话的良好基础。即使对工程师来说这似乎很无聊，至少他们会开始交流和倾听彼此。我的意思是，一旦他们停止无休止地争论空格与制表符或 JavaScript 与 Java 之类的无聊问题，他们就必须专注于他们将提供的价值。所以，这确实是我如何总结 DevOps 的方式，再次强调的是如何恢复共情，并专注于 IT 的价值创造和互动方面。

"我将 DevOps 总结为如何恢复共情，并专注于 IT 的价值创造和互动方面。"

—Damien Duportal

Viktor Farcic：但为什么这特别重要呢？

Damien Duportal：由于不同的人类行为。但更重要的是，共情是你用来建立人际互动的最先进的砖块之一。如果我们能够与不同的人、不同的观点和不同的文化做出如此多不同的事情，那是因为我们作为人类能够具备高水平的共情能力。一旦你有了共情能力，你就能理解为什么你要提供价值。如果没有，那么试图创造价值又有什么意义呢？那只会是从你的角度出发，而世界上还有 70 多亿其他人。因此，最终，我们需要共情来理解我们将如何运用我们的工具。

Viktor Farcic：这个说法不错。你提到 Docker 是其中之一的工具；你能详细展开吗？

Damien Duportal：在我成为自由职业者之前，我曾担任开发人员，但因为我们只有少数几个人，我与操作团队的联系非常紧密。尽管我作为工程毕业生参加了 Java 开发课程，但我一直对从早期开始编写基础设施的方法感兴趣。我记不清是谁说的，但我相信是 Netflix 的某人说过——如果你构建它，你就要运行它。我喜欢那种思*方式，这也是我接触 Docker、SaltStack、Chef、Puppet 和 Ansible 等配置工具的原因。

克服变革恐惧

我们大量使用这些工具来帮助将操作团队的关切引入开发中。请记住，许多开发人员不愿意学习这些工具，我很快发现这是因为恐惧。开发人员因为不理解这些新工具，因为缺乏知识，而关闭自己。他们害怕操作知识的概念，并未真正意识到这些工具为他们提供了许多新东西来学习和尝试。但开发人员没有意识到的是，这种恐惧也存在于我们团队的运*人员中，而且这只是局部现象。

Viktor Farcic：对变革的恐惧确实是一个很好的视角，但你是否曾设法从开发和运*团队中消除这种恐惧？

达米安·杜波塔尔：我应该补充一下，我不能把这种经验推广到其他情境，但这就是我从我们这边理解到的事情和行为。针对你的问题，我花了三到四年的时间，尝试在双方之间架起一座桥梁，并说服他们不要害怕。这座桥梁就是我说的：我们可以一起工作，选择结对编程，甚至像下班后一起喝杯啤酒或上班前一起喝咖啡，或者在工作之外一起做些运动。成功了吗？嗯，确实有帮助，但并没有完全解决问题，因为当时我缺乏把同理心带入团队的能力。

当 Docker 出现时，就像我看到了隧道尽头的光明，因为最终，我拥有了一个由一个与运营人员共享相同关切的开发者所生产的开发工具。这就是我使用它的真正原因。好的一点是，无论何时一个人开始使用 Docker，他们都有相同的学习曲线。为什么这很重要？因为这让每个人都看到了我们都有很多需要学习的东西。

Docker 成功地成为了桥梁，因为它成功地打破了恐惧的屏障，因为运营人员不仅看到了他们需要学习的内容，结果发现他们真的很喜欢学习新工具。现在唯一缺少的就是学习的时间。但时间问题也被视为一个潜在的投资机会，运营人员认为如果他们花时间学习 Docker，那么逐渐地，开发人员会跟随我们或我们的建议。同时，在桥梁的另一端，开发人员也开始有了这样的想法：“嘿！那个 Docker 工具听起来不错！它可能对我们有帮助。它容易使用，而且运行速度很快。”Docker 只是将许多听起来可怕的技术变成了一款花哨的工具。于是，带着这样的想法，甚至连营销团队也加入进来，帮助到处宣传它。

“Docker 成功地成为了桥梁，因为它成功地打破了恐惧的屏障，因为运营人员不仅看到了他们需要学习的内容，结果发现他们真的很喜欢学习新工具。现在唯一缺少的就是学习的时间。”

—达米安·杜波塔尔

*克多·法尔奇奇：但是，除了在两支团队之间架起桥梁，Docker 是如何在他们之间创造同理心的感觉呢？

Damien Duportal：Docker 做的是让学习曲线变得线性。你只需要几行代码，就能轻松完成任务。通过这个，你可以看到，如果代码运行正常，那它已经创造了价值。团队可以选择自己什么时候学习，并在想要通过 Docker 实现的目标上增加更多的质量或完整性。与以前你可能使用的任何工具相比，这种方法是相当线性的。可是那时候，你必须学习 Linux 和 Linux 配置，甚至可能还需要学习 Unity 或 systemd —— 所有的发行版，都是以大步伐的方式来学习的。这就是我发现并迅速确信，这些工具带来了同理心的原因。

这让我想起了我们这个行业多年来一直面临的情况，例如一个运*人员来到开发团队说：“嘿！不错的应用。你知道应用程序预计会在文件系统上写入文件的地方吗？”因为他说这句话，实际上暗示着背后的意图是：我们现在在生产环境中有一个问题，可能是性能问题和/或安全问题，或者是审计问题，我们需要这些信息，因为它非常重要。但在这种情况下，沟通的方式只是：“我们需要这个，而且这是强制性的。”但所有开发者听到的只是：“哦，是的，我们需要一些非常无聊的信息，我们不想自己去查找。”

Viktor Farcic：那么，Docker 是否消除了那个障碍？

Docker、容器及其采用速度

Damien Duportal：信息完全被转变了。通过使用 Docker 作为基础通信的支持，我们就消除了这一障碍。在 Docker 中，你可以简单地说：“好吧，让我们使用只读标志”，默认情况下，除非你有一个详尽的数据卷列表，否则一切写入都会被禁止。这些是技术性的内容，但一旦你解决了技术问题，就消除了压力，然后你就可以开始讨论了。我们需要 Docker，因为我们需要去除那个压力。你只需要去除工程部分，专注于提前讨论需求，这就是为什么 Docker 在这里成为了一个重大的变革者，但它是建立在巨人的肩膀上的。

在早些年，这项工作由像 Puppet 和 Chef 这样的工具完成，它们已经开始将开发思*带回到运*中。运*人员其实就是系统的开发者。例如，所有的内核开发者都是开发者，而他们的运*人员只是提供帮助。因此，没有所谓的运*或开发之分，因为归根结底，我们都在做同一份工作。只是每个领域所需的知识量远超一个人能独立掌握的程度，所以我们必须将这些知识进行划分。但实际上，日常工作还是在编辑文本文件、规划和测试，确保这个修改在本地和全球范围内对每个人都一样。我们只需要时常提醒自己这一点，Docker 对此起到了很大的帮助作用。

Viktor Farcic：这很有意思，因为如果我理解正确的话，你的意思是 Docker 使得 DevOps 的实现变得可能，而公司不必规划这种变化。基本上，Docker 自然而然地促成了这一切，而不需要强制要求你与某个人沟通。否则，后果会发生。

Damien Duportal：我曾经说过，Docker 就像是揭开你藏在地毯下藏了一年的灰尘，突然之间，你把 Docker 放到某个地方，然后你可以把它当作成熟度的指标。如果你把 Docker 放到某个地方，结果一切都爆炸了，那么说明你不知道如何监控 Docker，甚至不知道如何构建一个镜像。如果真是这样，那么真正的问题是，在 Docker 之前你到底在做什么？你是不是在闭着眼睛，把代码丢进生产环境而不思考？

"我曾经说过，Docker 就像是揭开你藏在地毯下藏了一年的灰尘，突然之间，你把 Docker 放到某个地方，然后你可以把它当作成熟度的指标。"

—Damien Duportal

一般来说，问题在于知识被分散在各个部门之间，没有人愿意共享。Docker 的出现恰恰是为了强调这一点。它会说：“好吧，如果你遇到问题，那是因为你们之间没有有效沟通。你们已经有了知识，已经具备了技能，但你们需要提高意识和同理心。”对我来说，这才是一个更好的指标。

Viktor Farcic：那么，你认为现在容器的采用程度如何？大家已经都在使用它了吗？还是它的完全接受还在等待中？

Damien Duportal：我会说这个问题仍然悬而未决。

Viktor Farcic：是什么阻碍了大家的普遍采用？

Damien Duportal：我没有足够的经验给出一个明确的答案，因为我没有看到那么多的案例，但至少在过去的两年里，我看到的一个问题是没有花时间去接受变化。通俗来说，这意味着 DevOps 团队在说：“我们害怕这么做。我们总是处于时间压力之下。不要再关注我们的价值，我们能带来什么，或者我们应该去除什么，而是告诉我们应该关注什么。” 所以，你可以说我们可能会使用容器，这对我们有帮助。这是一项投资；我们现在花点时间，这样以后就不需要再花时间了。这个问题更多的是关于处于高度紧张的状态，无法停下来，集中精力，喘口气。当然，这可能是由于一些原因引起的，比如大量员工离职、文化问题或工作负荷大幅增加，但这些问题都不应该持续太久。

我看到的另一件事，主要是在一些*公司，或者那些已经在同理心方面高效的团队里，就是通过共享和表现同理心，他们并没有看到容器带来的价值。假设你有三台大型金属机器：如果你已经有了负载均衡器和一些应用程序，那么安装 Kubernetes 或 Docker Swarm 有什么意义呢？我想在两年后再问同样的问题，因为有些事情正在发生，无法停止。我不会说容器是事实上的标准；只是三年前朝着一个方向发展的一些事情现在已经完全改变了。但我并不害怕这一点，因为这意味着你有一种心态在说：“我们应该这么做吗？” 是的，因为……或者不，因为……。如果这种情况发生，预计你需要在接下来的六个月，甚至几年里，根据你当前的情况评估你的选择。

Viktor Farcic：但问题是，容器会成为事实上的标准，那么我们只是需要更多时间，还是会有其他新的变化？

Damien Duportal：容器带来的一件事就是它不像我们以前那样提供资源管理。我有一个来自 CI/CD 世界的例子，关于 Jenkins，在过去几年里，使用 Docker 遇到了挑战，原因是你想要的是在需要时分配资源，在不需要时回收资源。

当时，人们认为容器是黄金解决方案，它为你提供了一个不可变的环境，你可以在几秒钟内轻松启动和停止它，然后使用隐含的基础设施来运行容器，这能给你带来水平或垂直扩展的便利。目前，我们有了云解决方案，而云中赚钱的方式就是提供一个平台来运行这些容器。所以，我认为这将是一个巨大的推动力，意味着现在市场上所有的大公司都在销售用于运行容器的平台，其余的公司也将会跟进。这正如十年前虚拟机的情况。

*克托·法尔奇克：出于兴趣，你是用什么系统长大的？

达米恩·杜波塔尔：我还太年轻，没经历过向虚拟机的过渡。我只知道我的历史。我从 PowerPC Mac 开始，大家都告诉我，我运行的是虚拟 PC，正因为如此，我在浪费资源。但两年后，当我开始做 IT 板卡工程时，大家都说：“哦，看啊；这台机器提供虚拟机，这样我可以在运行时更容易地更改它。”历史总是会重演。虚拟化概念已经存在了 40 年，所以容器只是一种重复这一概念的方式，这项技术只是提高了其使用效果。

“要让容器成为事实上的标准，还缺少什么？只需要一点时间让每个人都相信这个系统对他们有益。”

—达米恩·杜波塔尔

要让容器成为事实上的标准，还缺少什么？只需要一点时间让每个人都相信这个系统对他们有益。但也有其他因素，例如，招聘和随后的雇用危机，这使得很难找到优秀的工程师。所以，这并不是那些拥有文凭、能在 IT 领域解决问题的人——比如像 IT 工程师或软件工程师，因为我们已经有很多这样的人了——但还不够。我们需要的是拥有不同背景的人，因为随着容器成为事实上的标准平台，它将为每个人创建所需的蓝图，让每个人都能基于任何语言、文化或工作方式来构建东西。我认为这更多的是时间问题，而非其他。

软件公司、供应商和会议

*克托·法尔奇克：你提到过公司。我知道你时不时会去参加一些会议，所以我在想你怎么看待现在的软件供应商？每当我去参加一个会议时，我总是看到每个产品都被贴上了“DevOps”的标签，我有点困惑，因为这让我在思考，他们到底是什么意思？

Damien Duportal：这只是那些供应商在快速变化的行业中找到商业模式的一种方式。关于开源或闭源商业模式的辩论一直存在。正如你所说，今天会议上的每个人都在销售 DevOps，因为每个人都明白，单纯销售一款软件是不可持续的。也许在 1980 年代或 1990 年代是可以的，但今天不行。作为一名开发者，你需要提升自己所提供的价值，否则别人会构建相同的软件，并且会在你身后把你彻底超越。当我作为工程师成长时，新开发的步伐是以年的尺度来计算的，但现在是几个月。

你可以从任何一个传奇产品开始，但几个月后，别人将能够更成功地复制它，或者至少能以更便宜的价格做到。所以，DevOps 是一种避免在商业营销方面封闭自己的方式。

这是市场营销人员和工程师之间的松耦合，因为他们并不完全确定，所以他们把 DevOps 放在两者之间。保持这两个部门之间的沟通渠道应该带来跨部门的意识，因为工程师有一些创意，其中一些具有销售潜力，而其他的则没有，但它们是有价值的内部资产，市场营销需要销售东西。

我不是做市场营销的，但在你需要向没有工程背景的人推销产品时，团队之间必须有一些同步。这就像数据库一样。如果你一直在做同步或开会，你就被锁定了，无法快速前进。但如果你走得太快，组织之间和局部最优之间会产生不同步的情况，这并不是组织的全局最优化。所以，通过将 DevOps 与市场营销紧密结合，你可以说：“好吧，让我们加入这个阻塞关键词，然后再看看。”

Viktor Farcic：你花了很多时间在教学上。这让我在想：当你试图教别人一些东西时，你遇到了什么挑战？

Damien Duportal：这全都与“多样性阻塞词”有关。我说“阻塞词”，因为根据你的意图，它可以有很多不同的含义，但这里的主要障碍是我们迫切需要有技能的工程师，而现在我们有几种方式来教人如何成为工程师和解决问题的人。我们需要的是开发者，而不是那些还未达到工程师级别的人，而是那些能够构建东西的人。

我经历了一个非常有趣的变化，那时一些来自网页开发的人员开始与曾是组织后台的 Java 开发者并肩工作。你会看到一些案例，他们互相竞争。那些前端开发者使用的只是足够简单的类型语言——JavaScript——在 JavaScript 中，你几乎可以做任何事情，而这就是灾难的开始。每个人都把注意力集中在这一点上，但也有很多场景，大家开始从彼此那里学习。

“JavaScript 放弃了类型系统，并吸收了其他语言的优点，这正是我们所需要的：更多来自不同背景和不同工作文化的人。”

—Damien Duportal

JavaScript 放弃了类型系统，并吸收了其他语言的优点，这正是我们所需要的：更多来自不同背景和不同工作文化的人。这样我们就能说：“好，你以前是那样做的，但我会这样做。”我们可以互相学习，因为这不仅仅是关于知道与不知道的人的问题，还涉及到那些思*方式不同的人；而这能帮助你重新聚焦于价值，因为我们的思*方式各不相同，而教育中的最大障碍就是要教会不同背景的人。

教育体系

Viktor Farcic：那么，你怎么看待教育体系呢？我们该如何让它能够应对这么多不同的学习背景？

Damien Duportal：有些人更喜欢动手实践而不是阅读。例如，如果有人说他们不理解你关于网络 OSI 模型的幻灯片，这其实没关系。你应该做的是给他们一个 Raspberry Pi 和一个键盘，让他们通过配置 TCP/IP 来学习，之后他们会回去重新学习 OSI 模型。我们知道，掌握基础知识是必须的，目前来说，这样做是可以的。但是，在 IT 或网络工作几年后，你还需要它吗？还是在做任何事情之前你就需要它？这取决于情况。如果我们说应该用这种方式来教育所有人，那我们就已经走错方向了。

主要的挑战是找到那些适应性强的老师，他们能够和眼前的人交流并说：“好，你不理解我在说什么？那我需要找其他的方式，或者需要向别人求助，也许是*组中的某个人。”这不仅仅是关于做老师或做学生的问题，而是关于知识的共享和彼此的学习。我认为每次我从学生那里学到的东西和他们从我这里学到的差不多，这是没问题的，我认为我们需要那些不害怕这个事实的人。

你只需要看看我生长的地方和我现在住的地方——西欧：教育系统培养了那种恐惧感。你是老师，学生必须称呼你为成年人，而我根本不是，也永远都不会是。但这对很多人来说都是这样的。我认为最好的学习和分享知识的地方是一个不那么正式的环境，但我们仍然有一些工作要做，以确保这一点。只有时间和实验才能帮助解决这个问题。因为再说一次，几乎所有老师都具备技能和知识，但他们分享这些知识的能力却受到限制，因为他们害怕自己不知道一切，害怕自己不总是有正确的答案，害怕说出自己不知道某些东西，或者需要别人帮助。有时候我们只是需要一起找到解决方案，这完全不需要感到羞耻。

Viktor Farcic：因为你现在在教育中描述的内容，听起来与最初你描述的公司中存在的同情问题非常相似。

Damien Duportal：是的，确实如此，原因在于，一旦你能够适应“忘记已学”的过程，你就能开始通过以下方式解决问题：“好吧，让我们深呼吸一下，集中精力思考我需要解决的问题是什么。”你可能会尝试不同的方法直到解决问题，或者也可能没有解决。但无论你做什么，至少你学到了些什么，或许在这个过程中，你解决了问题。我的意思是，这是人类自然的认知模式，正因为如此，我们在教育和工作中都需要这种模式，而不仅仅是在 IT 行业。

我的意思是，我们知道农民是怎么做事情的。例如，你不能当 40 年的农民，每天都有完全相同的工作流程，因为气候在不断变化。你不知道明年是否会有冰雹，是否会太阳光明媚，或者是否会有足够的水源，因此，你必须适应；这是自然的方式。

Viktor Farcic：你有没有接到过别人请求你教他们如何成为 DevOps 工程师的要求？

Damien Duportal：不，从来没有。我的意思是，我该怎么回答这个问题呢？互相交流，然后说：“嘿，你差不多是个 DevOps 工程师了”？

Viktor Farcic：我问这个问题的唯一原因是，我不太理解 DevOps 工程师到底是什么。我到处都能看到这个词，实际上，我时常收到 DevOps 工程师的工作邀请。但归根结底，我仍然不明白他们希望我做些什么。

Damien Duportal：在我第一家公司时，我做了整整一年的 DevOps 工程师，但我依然不知道我的角色是什么。所以，我同意你的看法，确实没有所谓的 DevOps 工程师，甚至没有 DevOps 团队。DevOps 的主要目的是专注于价值，我指的是为组织找到最佳的方式，以及它将带来的价值。

“在我的第一家公司，我做了整整一年的 DevOps 工程师，但我至今都不知道我的角色到底是什么。所以，我同意你的看法，根本没有所谓的 DevOps 工程师，甚至没有所谓的 DevOps 团队。”

—达米恩·杜波塔尔

所以，如果你建立一个仅仅支持专注于价值的组织，那么其他人的工作是什么？他们在做什么？你只是输入了关键词，但实际上你需要的是一个有口才和同理心的人。所以，也许一个不错的起点就是同理心工程师？

*克托·法尔奇奇：每当有什么新东西出现并变得流行时，总会有一股炒作。然后，即使那股炒作还没有消退，后面就会有一个新产品或新工具紧随其后，产生更大的炒作。但现在，我不知道接下来会有什么。DevOps 之后会有什么呢？

DevOps 之后是什么？

达米恩·杜波塔尔：还没有，但老实说，我在职业生涯中还没有积累足够的经验来做出那种预测。我当时完全没法预测到红帽会被别人收购。当萨莎·拉博雷做出这个决定时，我心想：那个人完全疯狂，但事实上，他的经验比我丰富得多。

现在，在技术行业中，我们有了物联网相关的东西，所以也许安全工程师会成为下一个大趋势，因为当每个人都拥有的智能冰箱被黑客攻击时，里面的牛奶和啤酒都会被毁掉。所以，也许这会成为一种新趋势？就像《捉鬼敢死队》一样，安全工程师会因为你的冰箱被黑客攻击而出场。

*克托·法尔奇奇：我的意思是，当物联网到处都是，我不是在说如果，而是当物联网遍布我们周围时，我们可能会看到同样的模式。很久以前，我们曾经请人来修理我们的电脑，但现在我们不再这么做了，因为我们有笔记本电脑，当它们坏了，我们就直接丢掉。但也许这种做法会回归，有点像修理房子的那个人，以一种复古的方式，把修理家居的老派做法带回来。

达米恩·杜波塔尔：那些被迫离开 IT 世界的人——例如，建房子的人——或许能够回归这个热潮，因为你，*克托，可能需要找人砸开你家墙壁，因为没人能破解你的门。所以，你需要一个拿着锤子的人来拆除墙壁。

*克托·法尔奇奇：放我出去！我不能通过门！

达米恩·杜波塔尔：哈哈！我觉得我们都会在新的趋势中玩得很开心。

在亚马逊、微软和谷歌

*克托·法尔奇奇：在我们结束之前，还有一个问题，关于像亚马逊、微软和谷歌这样的公司运作方式。它们是不是正在蚕食对有技能人才的需求？我是说，现在是 2019 年，你不再需要自己开发机器学习了，因为谷歌已经提供了相关服务。同样，你也不需要做转录，因为谷歌可以为你完成，这仅仅是多个可能的例子中的两个。那么，服务与我们所做的事情之间的关系是什么呢？

达米安·杜波特尔：对我来说，这就像是在干涸一条河流。这些公司需要有技能的人，而他们目前雇佣的少数人薪水很高。但现在的问题是：这些人为什么有技能？是因为他们多年积累了经验和知识。但他们是怎么做到的呢？因为雇佣他们的公司给了他们机会。

这就像是 COBOL 的时代。现在的一个有技能的人——除非他们建造新的终结者或超级计算机——在退休之前会想专注于生活中的其他事情。但当他们停下来时，我们该怎么办呢？因为如果我们让河流干涸了，就没有水了。我认为这正是现在发生的事情。

但由于事物的变化，我认为会有越来越多像 Red Hat 这样的公司或新公司涌现出来，因为从另一个角度看，我们有了更强的能力来构建我们想要的任何东西。所以，很多拥有不同技能的工程师将会涌现出来，并且会构建替代方案。我真的相信人性可以做到这一点。

“但由于事物的变化，我认为会有越来越多像 Red Hat 这样的公司或新公司涌现出来，因为……我们有了更强的能力来构建我们想要的任何东西。”

—达米安·杜波特尔

但我要说的最后一件事是，你总会遇到阻力。我们之前讨论过这次采访的转录。在我看来，我愿意花几美元让你做这件事，因为我不想浪费时间去做。但与此同时，我也认识一些人，他们会说：“哦不，我要用 AWS！我要买一台 Raspberry Pi，完全不联网自己做。”

我敢肯定，如果你走遍世界各地的 DevOps 领域，你会发现有些人会自己动手做事情，其中一个人可能会成为下一个 Alphabet 的高管。问题是，现在这些人正在枯竭，但这是短期现象，我们有足够的韧性来解决这个问题。

*克托·法尔奇奇：我们就到这里吧。和你交谈非常愉快。

第八章

3

第九章：凯文·贝尔

首席科学官 – PraxisFlow

第十章：介绍凯文·贝尔

作为 PraxisFlow 的首席安全官（CSO），凯文·贝尔把时间投入到与那些寻求开发 DevOps 流程的客户的合作中。他 25 年的经验来源于他对解决大型 IT 组织面临的复杂问题的热情，以及如何利用 DevOps 来解决这些问题。你可以在 Twitter 上关注凯文，@kevinbehr。

通往 DevOps 的旅程

*克托·法尔奇奇：你好，凯文，你从*与父亲一起工作，涉足了许多后来成为 DevOps 核心话题的领域。你父亲的工作是如何为你做好进入 DevOps 的准备的？

凯文·贝尔：嗯，距离我第一次正式涉足计算机世界已经整整 30 年了。在我年轻的时候，我很幸运地与我的父亲哈罗德·贝尔一起成长，他是现场服务经理协会（AFSM）的联合创始人之一。对于那些不知道的人来说，AFSM 是全球首批致力于全球服务经理的组织之一。AFSM 曾讨论一些今天仍然与 DevOps 相关的话题，例如如何为大型机提供服务，以及讨论客户价值的可用性和持续性。

我七岁时开始制作*型数字计算机，修理真空管设备。大约十岁时，我开始接触中型计算机和大型机的*修工作。我的父亲带领的团队会租用私人飞机飞往客户所在的地方，每当他们的大型机出现故障时，他们会在晚上进行修理，力求到早晨时系统已经恢复正常。如果周五发生故障，我通常会和他们一起去，尤其是他们傍晚出发时。即便是在那个时候，这也是我能与计算机和父亲一起做的有趣事情。

*克托·法尔奇奇：你十岁时就开始修理大型机了？

凯文·贝尔：我的工作是拿着焊锡和散热器。这是在那种你实际上可以修理这些庞然大物的时代！有一个人会和 IBM Armonk 或者他们正在处理的大型机公司通话，他们会拿到电路板的跟踪数据来测试某些电压和阻抗。然后，他们会进行焊接和更换坏掉的组件。我在焊接方面比大多数人都更擅长，因为我手*，可以进入狭窄的地方，但他们大多数时候让我拿着散热器，做 RS–XXX 电缆，而他们则一边链式吸烟，一边低声咒骂，一边戴着眼镜焊接。

*克托·法尔奇奇：到你高中毕业时，你和父亲一起从事大型机*修业务。这一切与你的教育承诺有什么关系呢？

凯文·贝尔：是的，当我大约 18 岁时，我们在犹他州的莫阿布度假。但像很多度假地一样，那里没有工作。对我们来说，这意味着没有计算机服务公司、咨询公司或类似的东西。所以，我和我爸开了一家*型计算机咨询公司。我们去到企业、政府和学校，为他们组装计算机！当时，组装克隆计算机才刚刚变得可能，于是我们直接开始生产自己的计算机。我们还为那些需要*修的大型主机和*型计算机提供服务。我还在一家和州政府有合同的公司做了一些工作。我有一个寻呼机，每当他们给我打电话时，我就去修理大型主机和 Wang OIS 系统。

几年后，我的计算机科学教授问我在那些年里赚了多少钱；我告诉他大约在$35,000 到$40,000 之间，在 1980 年代这算是相当不错的收入。然后，我的教授抓住我的胳膊说：“离开，走！”当我问他为什么时，他对我说了一些对我来说很重要的话：

“凯文，我不是因为你是个不好的学生才这么说，你是一个模范学生。我也不是因为你问了很多关于谁来管理我们教的这些人的问题才这么说。我这么跟你说，凯文，因为你说得对：确实需要有人去编写这份课程。但为了做到这一点，他们必须从实践经验出发。凯文，你必须通过这些组织，亲自写下你的所学。”

虽然我并没有一开始就抱有这个目的，但我确实辍学了——而且我走的正是我的计算机科学教授所建议的道路！

*克托·法尔奇：你从大学辍学后做了什么？

凯文·贝尔：在接下来的几年里，我在 IT 运*中做过每一份工作。我了解了作为网络工程师是什么样子，作为系统管理员又是什么样子，甚至做过那个低级别的职位，负责检查磁盘阵列的故障指示灯、风扇和空调的滤网。从更换备份磁带到编程防火墙。我做过所有这些工作。

我也上过学，学习软件开发。我是一个懒惰而又慢的开发者，但我确保自己理解了一切，从栈底到栈顶。我从 B 语言开始，我们曾开玩笑地说——像汇编语言——这意味着要面对大量的二进制数据，这对我们这些有阅读障碍的人来说非常困难。

在这段时间里，我发现自己工作越多，对那些管理技术的人越感到失望和困惑。似乎公司只是将那些在技术岗位上工作了一段时间的人晋升到管理岗位上。在很多情况下，这些人并不擅长他们所做的事情。他们没有接受过这方面的培训，而且他们通常并不愿意管理这些事务。

“我越是工作，就越是对那些管理技术的人感到幻灭和困惑。”

—凯文·贝尔

*克托·法尔奇奇：但如果你想加薪，那就需要成为一名经理。这就像你可能会一直想做一个程序员，但五年后，你需要更多的钱，所以你开始考虑成为一名经理。

凯文·贝尔：但在那时，实际上没有任何帮助或支持给那些进入技术管理岗位的人。没有人能为这些技术经理提供指导，没有人能回答他们的问题，也没有文档供他们阅读。根本没有任何资源，而这让我感到非常奇怪，尤其是在你稍微反思一下大多数高管职位所强调的能力、教育和经验的重要性时；以及提供培训和文档以确保专业标准的必要性。

这非常奇怪，它深刻地影响了我对 CIO 的看法，因为我没有看到 CIO 单独做出任何决策。我不再看待 CIO 和 CEO 作为公司父母之间的平等合作伙伴关系。CIO 的工作更像是一个保姆，而不是父母。

*克托·法尔奇奇：这真是一个很好的描述方式。

凯文·贝尔：在我看来，CIO 在 1980 年代和 1990 年代并不是大多数公司中的同级职位。CIO 实际上是为其他人服务的。

1980 年代初期的信息系统管理涉及了很多财务人员，当然，技术最初是通过财务部门进入企业的——帮助他们计算数字、构建账本和记录。IBM 的第一台计算机是一台用于跟踪员工工作时间的打卡机。技术解决方案一直得到财务团队的支持。

因此，当财务部门在 1980 年代和 1990 年代决定将技术逐出财务领域时，这非常有趣也很奇怪！我记得在个人电脑首次问世时，我亲眼看到了这一过程。当时，我是一个大型主机技术员，所以有偏见，但像当时许多 IBM 的人一样，我相信桌面 PC 只是大型主机的名片。所以，我每天都坐在它们面前。计算机。IBM。计算机。IBM。我不相信个人电脑会有什么了不起的成就。

然后，突然间，在 1980 年代和 1990 年代我们迎来了客户端-服务器计算。就我而言，客户端-服务器摧毁了计算机技术，导致我们倒退了 40 年。客户端-服务器的问题在于，我们在大型主机中已经拥有了所有这些功能，但它们运作得更好、更快，实际上在计算所有人员、奇怪的承包商和供应商的费用后，还更便宜。但是，财务部门犯了一个错误，只看到了计算机的购买价格。

*克托·法尔奇奇：你可以说，财务部门变成了自己的最大敌人。但大型主机的成本远高于个人电脑，所以客户端-服务器的理念一定非常具有吸引力吧？

Kevin Behr：是的，当然，但当时有另一个错误的假设：认为你可以单独管理个人电脑，因为…它是个人的。现实情况是，当你有 10 万个个人电脑时，它就不再是个人的了。你需要管理所有这些电脑，而且它们是分布式的！

我一直看到技术与组织之间的脱节，以及 CIO 与 CEO 之间的脱节，越来越大。直到几年后，通过 2000 年代和 2010 年代，DevOps 才开始着手修复这种脱节。

弥合 CEO 与 CTO 之间的鸿沟

Viktor Farcic：有趣的是，你职业生涯的最初阶段与 DevOps 之前的历史有关，包括你提到的那些紧张关系和脱节，这些是 DevOps 试图解决的，当然了。你在 IP Services 担任 CTO 的下一步职业发展是否让你更接近我们今天所谈论的 DevOps？

Kevin Behr：是的，在 2000 年代，我曾是名为 IP Services 公司的 CTO，这家公司可以最好地描述为一个早期的 MSP（托管服务提供商）和基础设施外包商。它为大型财富 500 强公司和全球 500 强公司提供关键任务基础设施。就在 IP Services 期间，我们不得不开发方法来管理各种控制系统，因为我们每个客户的审计员都希望进来检查我们的运营。

在这段时间，我开始与 Gene Kim 合作，共同工作，Gene 是另一个志同道合的 DevOps 思想者。我们俩都是 CTO，向 CEO 汇报工作，我们都经历了一个非常具体的过程，就是在工作中采用并调整我们的思*方式，以应对工作中的挑战。

Viktor Farcic：这段经历是否帮助你弥合了你之前提到的组织中 CTO 与 CEO 之间的脱节？

Kevin Behr：是的，我们注意到 CEO 们经常用图像语言来描述事物，使用原色和 0 到 9 的数字。表面上看，这种 CEO 语言可能显得过于简化和过度简化，确实，这也是 Gene 和我有时会有的感觉，因为我们俩本质上都是工程师。关键是，作为 CTO，我们花了大量的时间学习这种 CEO 语言及其相关的 CEO 思*框架。但有时就是这样，必须付出这些努力。

我还记得 Gene 和我曾一致认为幽默可以帮助修复脱节。Gene 找到了一本由 Stanley Bing 写的很棒的书，叫做Throwing the Elephant，我们开始欣赏 Bing 从禅宗的角度幽默地讨论“向上管理”这一话题。

在那个时期，倾听并找到与其他人之间的共同联系是我们另一个重要的经验教训。Gene 和我经常在俄勒冈州波特兰的一个叫 Pazos 的餐馆/酒吧碰面，在那里我们会描述关于我们各自的高管和客户的共同场景。我们发现我们对行业充满热情，并且有许多共同的问题。

Viktor Farcic：比如？

凯文·贝尔：嗯，我们可能会说，“为什么 A 客户有这么多问题？”他们的钱和人才与 B 客户差不多，但 B 客户的表现却好得多。为什么呢？

吉恩和我对这些类型的问题非常有激情，我们说服了上司让我们戴上探险帽。正如吉恩常说的，我们就像是第一次为植物和动物做分类的老探险家。我们的世界当然是商业世界，因此我们研究高绩效公司，看看它们做得与众不同的地方。

我们分享了在 2003 年由吉恩和斯蒂芬·诺思卡特主持的第一次有效的安全与审计控制研讨会上的很多收获，我在会上做了讲座《血与汗与可见操作》，这后来在与吉恩·金和乔治·斯帕福德合作的《Visible Ops》一书中得到了纪实，并于 2004 年底出版。

*克托·法尔奇奇：你为什么决定在你的Visible Ops书中使用 ITIL？

凯文·贝尔：我们决定使用 ITIL 的语言，因为 ITIL 是一个许多人都能理解的标准流程语言。我们还将我们观察到的不同公司所做的所有动作映射到 ITIL 中。

我们的目标是能够使用 ITIL 对成功与不太成功的公司之间的活动模式进行比较。我们发现，许多公司与其他公司做事的方式完全不同——最关键的是，它们在如何管理风险和变更方面的差异。更成功的公司通常拥有最有效的变更管理流程。

一个很好的例子，说明了良好的变更管理的积极影响，是我们在一个客户那里进行的变更——变更了所谓的工作授权请求（WAR）。这个客户的管理层不喜欢变更，因为它有危险——而且他们恰好经营着一家最大的金融机构之一。但有趣的是，这个客户做的变更远比低绩效客户多，而我当时感到非常惊讶！他们的风险面要大得多，但几乎没有失败的变更。或者，即便发生了，它们也会被迅速撤销，几乎对生产没有任何影响。

我们看到像这样的高绩效客户，也看到低绩效客户，两个客户在技能和预算上都很相似。ITIL 分析显示，关键的区别在于不同客户如何管理与发布和事件流程集成的变更过程。结果证明，80%的失败是由人为因素造成的，因此事件是结果，变更是我们的意图。因此，我们开始衡量一些指标，比如变更成功率，以及如何判断你的流程是否有效？它成功了吗？

但我们发现，高绩效客户的一个特点是，他们的控制措施往往比低绩效客户少。这让我们感到非常惊讶。我们当时就想，“嘿！等一下！”

*克托·法尔奇奇：你的意思是对人员的控制更少吗？

凯文·贝尔：不，这一切都与更少的流程控制有关，比如从管理交叉点或审计角度来看。所以，我们在那里思考时，发现我们的客户有大约 15 个控制点，而另一个客户则有接近 40 个控制点来自 COBIT。我想……这根本没有任何意义！

当我们进一步深入观察时，我们发现控制较少的人在构建专门的流程：他们知道自己的流程需要做什么，真正的风险在哪里。与此同时，表现较差的人则在阅读最佳实践，他们认为更多的控制对审计人员更有利。而且低效能者对待每个变化的方式都是一样的：他们会把一群人召集到房间里讨论，但这样并没有让结果更可靠。

高效能者将变化视为发布。他们把整个基础设施看作一个平台，仿佛他们正在向这个平台发布一个新组件。他们以更全面的方式看待一切，因此会追踪相互依赖性。他们做了很多事情，这些事情实际上只是变更过程、事件管理过程和发布过程的一部分。他们的这些过程被集成得如此紧密，你可以知道每一步的结果，而且所有环节都紧密相连。

"[高效能者]以更全面的方式看待一切，因此会追踪相互依赖性。[...] 他们的这些过程被集成得如此紧密，你可以知道每一步的结果，而且所有环节都紧密相连。"

—凯文·贝尔

假设你遇到了一个故障。你可以看到某人在工单上的最后一个问题，以及工单上做的最后一次更改，因为 80%的故障是由变更引起的。但是，解决问题所花费的 80%时间用来搞清楚发生了什么变更，剩下的 20%则用来做实际的修复工作。我们发现，许多高效能者在问题发生的最初几分钟内就排除了变更作为原因因素，从而大大提高了他们恢复服务的平均时间，且有更大的机会保持在他们的 SLO 误差预算之内。

*克托·法尔奇奇：所以，你发现了第一个 DevOps 模式？

凯文·贝尔：没错！高效能客户的不同之处不在于他们在这些场景中失败的次数较少。我们发现，正是公司如何处理失败，测试了它们的组织韧性；更重要的是，它们在*团队中的韧性究竟有多强。

让失败变得更安全

所以现在，我们开始在研究中注意到这些 DevOps 模式，例如，人们愿意专注于一起学习，而不是互相指责，并共同设计韧性。设计一个安全可失败的系统，借用了飞行模拟器的思*。普通学习者需要在模拟器中坠毁几架飞机，才能在现实生活中飞行。关键是将部署与激活解耦，这样我们就可以免费学习，而不影响客户的体验。

当你看到持续部署和持续交付时，我们正在更快地发布代码。在某些情况下，代码首先通过单元测试，然后提交，接着通过静态代码分析、集成测试、快速回归堆栈——砰！生产！那么，为什么我们这么做呢？因为我们知道我们有多种选择：蓝绿部署、暗部署、特性开关、标志和开关。所以，如果某个问题在生产环境中出现，我们可以将其关闭，并有效地将其恢复到原来的状态。许多人采用了蓝绿部署，这允许团队在同一数据库中同时运行旧系统和新系统，直到新系统工作正常且没有停机时才切换到新系统。

通过这些新模式，工程师可以产生安全故障的想法。这与行业以前所说的完全相反，之前行业总是强调必须依赖加固，比如冗余数据中心。当然，所有的金属，尤其是大型服务器，确实让我们感觉很好，因为一切都具有容错性。但 DevOps 一代人认为一切都会失败。所以，给我一个有韧性且安全可失败的系统，这样我们就能自由行动、破坏事物并快速学习！

"给我一个有韧性且安全可失败的系统，这样我们就能自由行动、破坏事物并快速学习！"

——凯文·贝尔

*克托·法尔西奇：说一切都会迟早失败就是承认真相！

凯文·贝尔：没错，那么当它失败时你怎么办？你能多快让它变得不可见？这样就不重要了。因为 Cobb 的思*方式，加上 DevOps，开始让一套不同的可能性显现出来！

*克托·法尔西奇：你是说 DevOps 模式是 DevOps 的核心吗？

DevOps 的核心是让工作民主化

凯文·贝尔：虽然这些 DevOps 模式对 DevOps 至关重要，但我真正认为是 DevOps 核心的东西，我认为我们今天失去联系的，是在 1940 年代和 1950 年代，一种叫做 STS（社会技术系统）的运动和学科。

社会技术系统起初是由一些社会学家提出的，它是二战后立刻展开的一个重大资金项目。我确实有一场关于 STS 的演讲，叫做DevOps 与它在煤矿中的根源。这有点像笑话，但二战后他们必须做的一件大事，就是找出如何生产更多的煤炭来帮助战争后的恢复。那时发生了一个冲突，因为所有的煤炭公司都想保持煤炭价格高，而英国政府则希望降低煤炭价格，以便煤炭和石油能够推动战后的重建。国家的利益是尽可能多地从矿井中提取煤炭。

为了实现这一目标，英国政府雇佣了两位社会学家，Eric Trist 和 Elliott Jacques，去检查所有的矿井，找出哪些矿井最具生产力，以及是什么使它们更具生产力。Trist 和 Jacques 发现，所有低生产力的矿井都高度自动化，而这种自动化并没有带来预期的生产力回报。在许多不同类型的矿井中，他们发现了一种矿井设计，尤其突出，因为它每天产出的煤炭比其他任何设计都多——而且是多了很多倍。这种生产力最高的矿井设计也比其他矿井类型有更少的重大伤害，并且团队士气极高，像铁一样坚固！

Trist 和 Jacques 还发现，这个高生产力的矿井达到了 100%的出勤率，工人们每天都来工作。这很奇怪，因为在大多数矿井里，30%的劳动力在任何工作日都不会到场，因为煤矿工作非常危险，而且在战后的英国，其他工作机会也很多。

为了找出这个高生产力矿井为什么能做到 100%的出勤率，Trist 和 Jacques 在班后与工人交谈，但他们仍然找不到任何不同之处。于是，他们决定亲自下矿井，与煤矿工人一起工作。上面，班长会与所有的煤矿工人开会，讨论他们需要做的所有工作。但当他们与矿工们一起下到矿井时，Trist 和 Jacques 立刻注意到了一些不同之处：这个*组实现了工作上的民主化。

Viktor Farcic：好吧。这是个转折。

Kevin Behr：矿工们关心的是：“整个任务是什么？”不是我应该做的事，或者你应该做的事……而是我们应该完成的整个任务是什么？

在某个特定的情况下，这可能意味着说我们需要一个人来处理炸丨药，或者我们需要炸一些洞，我们需要一个安全员来确保一切顺利；或者我们需要一个人来使用气锤。他们都有不同的角色，因此他们的对话听起来像是：“嘿，昨晚谁没喝酒？你？没有？好吧，今天你负责炸丨药。”

通过这种对话，他们会弄清楚如何将整个任务分解为基于角色的工作。他们根据每天谁最有能力来执行每个重要角色，变得自我组织和自我调节。

此外，他们的另一个优先事项是相互教授足够的彼此工作知识，以便如果他们在事故中受伤，团队仍然能够接手并完成需要做的事情以拯救大家。所以，他们每个人都学了一些彼此的工作，足够让他们能够做这些工作。我的问题是，*克托，你在这里看到现代 DevOps 的一部分了吗？

*克托·法尔西奇：你是在谈论自给自足的团队吗？

凯文·贝尔：是的，你知道吗？他们做到了！有趣的是，他们的老板永远都不知道其中的区别，因为他们的老板都在地面上，待在安全的地方；他们从来不会下到实际的矿井里去。所以，当矿工们知道整个任务是什么时，他们会根据能力自发组织起来。就像是工作的真正民主化。

但不仅仅是这样；他们还在进行交叉培训。你了解帕累托原则吗？

*克托·法尔西奇：是的，对于我们大多数人来说，这就是 80/20 法则。

凯文·贝尔：现在，逆帕累托原则非常有力。它说，有 20%的东西你可以学到，这会让你完成接近 80%的任务。逆帕累托原则通常是双向的，所以，我推测这些矿工们正在学习彼此工作的逆帕累托原则。而这正是 DevOps！

我们常说某人是全栈工程师，但我们很少能找到一个人能够做所有人的工作。那么，为什么不把这些工作分开呢？真正重要的不是他们使用的工具或技术，而是他们如何决定在日常工作中互相协作的方式。

“DevOps 是[...]帮助彼此理解足够的工作内容，以便我们可以考虑接下来做什么。”

—— 凯文·贝尔

我听了帕特里克·杜布瓦斯关于他在一个合同上的工作演讲，我相信那个合同是和某个政府机构合作的，他开发了一段代码，需要把它投入生产。他谈到这有多困难。工作本来不大，但运营人员让事情变得异常复杂，帕特里克当时说：“为什么我们不能一起合作呢？”对我而言，这就是 DevOps 的本质。

DevOps 是在这些边界之间合作，帮助彼此理解足够的工作内容，以便我们可以考虑接下来做什么。但关键字是同理心。跨越边界的关心。

*克托·法尔西奇：你是我在这本书中遇到的第一个说同理心对 DevOps 如此重要的人。

同理心和组织文化

凯文·贝尔：我们谈到 DevOps 中的同理心时是什么意思？我们是说我们理解你做的事情的感受，我再也不会让你经历这样的事了。那么，让我们一起构建一个系统，避免我们再陷入这种困境。

对我来说，DevOps 已经发展成了很多工具，因为我们是人类，而人类喜欢各种各样的工具。作为一个物种，我们通过工具和技术定义了自己。而且，作为一个物种，我们也常常讨论文化，但在我看来，文化就像是后视镜。文化只是我们所做的一切：我们的组织倾向。

改变文化的方式是做事的方式不同。我们不要等待文化，因为文化在后视镜里：它是过去。如果你正在经历转型，那么你转型的目标是什么，这意味着你需要如何行动？

关于 DevOps，非常有趣的一点是，虽然它的使命通常是创造组织文化的变化，但这种变化需要的不仅仅是协调：它还需要纯粹的协作和共同劳动。考虑到我们可能以前没有和组织中的人一起工作，这些都特别难以实现。而且，当这些人可能已经因为没能得到想要的东西而把对方视为敌人时，情况就会变得非常尴尬。DevOps 过程的目标是创造一种新文化，尽管面临这些挑战。

*克托·法尔奇奇：是的，DevOps 难题的一部分是，我们如何在非常尴尬的情况下，与我们不太熟悉的人之间实现纯粹的协作。

凯文·贝尔：人们没有理解的是，DevOps 很难。跨越这些界限工作很难。我们不必做 DevOps，它是可选的——因此做 DevOps 是困难的。但改变文化意味着改变我们在组织中做事的方式。如果我们继续做事不同，那么我们回头看看，会发现我们的文化已经改变。

*克托·法尔奇奇：没错，但这些事情也需要一些时间。

凯文·贝尔：是的，如果我们在两周内做些不同的事情，然后回过头来看，得出结论认为这并没有改变我们的文化，那么问题肯定是人们没有理解他们一直以来做的事情与现在所做的事情之间的关系。DevOps 的共情能力促进了文化的变化，因为它促进了行为的改变。

*克托·法尔奇奇：而且 DevOps 也促进了协作。

凯文·贝尔：是的，协作对双方都有益。从博弈论的角度看：如果我最大化我的效用，那么你也会最大化你的效用。但从人类的非理性和关系的角度看，还有通过多样性建立力量的好处。当我们观察技术团队时，我们可以从 DevOps 的角度看出他们是否作为一个团队聚集在一起，还是分散开来。

“DevOps 流程的目标是创造一种新文化。[...] 但是，改变文化意味着改变我们在组织中做事的方式。如果我们继续做事不同，那么我们回头看看，会发现我们的文化已经改变。”

— 凯文·贝尔

*克托·法尔奇奇：你看到的大多数技术团队是聚在一起还是分开？

Kevin Behr：在美国，许多大型企业公司已经采纳了 DevOps，但在实际情况中，我们通常会遇到这些组织内的“特种团队”；或者说是一些“准军事化组织”的技术团队。这些类型的技术团队不需要遵循与其他团队相同的规则，因此它们在短期内往往能取得成功，因为它们有更少的约束。当然，我们可以为它们设计一些低门槛的试点，并为这些团队设置一些容易跨越的任务。

我和许多 CIO 以及企业交流过，他们喜欢 DevOps 拥有敏捷的基础设施，并且在整个价值流中都具有敏捷性。主要问题在于这些 CIO 们根本不知道如何管理 DevOps。我是不是应该有团队？我是不是应该有一位副总裁？我的回答始终如一，我说：“听着，我更倾向于将 DevOps 看作这样：现在你可以让团队共同开展项目。”

但请考虑志愿消防队。西班牙有这样的组织吗？

Viktor Farcic：我知道它们的存在。

Kevin Behr：所以，在美国，一些*镇无法负担专业的消防员工资，因此他们有志愿者，所有人都佩戴无线电。如果发生火灾，他们都会收到一个非常响亮的无线电信号，然后他们就会疯狂地开车到消防站，跳上消防车，去处理火灾。

这被称为“工作组”，在一个工作组中，有一套非常重要的理解。首先，这些人有主职工作，因此他们可能一分钟在做会计工作，但下一分钟，如果他们收到信号，他们就会迅速行动：现在，他们是消防员。第二个理解是，当他们成为消防员时，可能在前往火灾现场的路上，他们已经知道该怎么做；他们是经过预训练的。就像矿工的情形一样，当他们需要成为消防员时，他们已经知道自己的角色和责任。

我的意思是，我看到的许多成功的 DevOps 互动也涉及到一个组成的工作组。有一些基础设施，一些开发人员，还有一些安全人员，他们都加入了团队；他们知道自己的角色，知道任务是什么。他们完成了任务。砰！

Viktor Farcic：然后，你要开始传播那个团队的成功！

Kevin Behr：是的！每当团队聚集五次时，你应该增加另一个工作组。它们一开始可能不会很出色，但它们会在学习。

这里的广泛思想是创建一套信号手册，以便我们可以让组织知道何时需要合作。当然，这需要一定的能力来理解你周围发生的事情。这意味着，作为工程师，我们有时必须抬起头离开键盘，或者摘掉耳机，注意到周围到底发生了什么。

“作为工程师，我们有时必须抬起头离开键盘，或者摘掉耳机，注意到周围到底发生了什么。”

— Kevin Behr

*克托·法尔奇奇：你认为 DevOps 有社会组成部分吗？

凯文·贝尔：是的，社会技术系统的理念是人优先于技术；技术为人服务。这与我们讨论的技术社会不同，后者意味着机器决定我们如何组织、如何工作，甚至如何布局我们的工作方式。

我观察到，DevOps 的根源在于社会技术的共情。这来自像帕特里克·杜博伊斯这样的人，他说：“为什么我们不能一起工作？”同样，像安德鲁·克莱·谢弗这样的人建议，我们所有的基础设施应该是敏捷的，基本上是代码化的。

我依然与安德鲁保持联系，几个月前我在 Twitter 上与帕特里克简短交流过。对我来说，他们的工作显然是社会技术系统的一部分：人们共同工作并分享。我们将在机器上自动化一些事情，以便有更多时间进行实验、学习和在重要事项上合作。

*克托·法尔奇奇：从这个意义上讲，工具在你认为 DevOps 有助于创造社会技术系统的理念中占有重要地位吗？

凯文·贝尔：是的，很明显，工具在 DevOps 中现在变得如此重要，原因在于人们正在学习如何执行 DevOps 中常见的许多技术——从持续交付、持续集成、持续部署到自动化测试。在很多情况下，我们现在将工具放在了人们面前。

所以今天，当你看到人们讨论如何做 DevOps 时，他们首先提到的是工具链；我在心里想，“所以你们现在是围绕工具来组织团队了吗？”这似乎不太对劲。

*克托·法尔奇奇：那是不是对 DevOps 的根本误解？

凯文·贝尔：是的，这就像白兰地和科尔沃锡的区别。所有科尔沃锡都是白兰地，但并非所有白兰地都是科尔沃锡。

你可能与一些团队跨越边界，在一个非常技术化的项目上合作。每个人甚至可能都在以 DevOps 风格进行协作。但团队通常太专注于工具，而工具决定了团队如何合作。工具甚至可能开始制造分歧。

有时，当我与某个组织合作时，我会谈论原型或刻板印象。每当这样做时，我都会用《**丨**》的故事。我相信，克里斯托弗·罗宾的所有朋友——**丨**、兔子、跳跳虎——他们都是克里斯托弗·罗宾自己的不同表现。这是一种探索克里斯托弗·罗宾个性不同方面的有趣方式。然后，我喜欢说产品经理就像跳跳虎，因为他们对我要做的事情非常兴奋。开发人员更像兔子，而基础设施人员则像厄尔，因为他们走来走去，总是说“谢谢你注意到我。”我的观点是，团队是不同个性混合在一起的。

在大多数团队中，你会发现有一群人对新事物非常兴奋，而另一群人则不那么兴奋，因为那些新事物似乎会伤害他们。例如，运*人员通常非常怀疑，因为他们已经被告知很多关于一切都会变得多么美好的话，然而他们却在凌晨 2:30 接到呼叫，去修复他们刚刚部署的东西。自然，运*人员随着时间的推移会发展出怀疑的态度。

当你设法将同理心引入团队时，开发人员和运*人员似乎终于能够走到一起。你突然听到运*人员说：“哦，我们能不能换个方式做？上次你把那东西扔给我时，它把我打了个黑眼圈，我不得不连续四天熬夜！”而开发人员则回答：“真的？它是怎么做到的？下次如果有问题，麻烦叫我，我想过来帮忙。”这种通过弄清楚问题所在并共同解决的同理心，正是建立信任的关键。

信任是成功 DevOps 的关键

*克托·法尔奇奇：那么信任是你对成功 DevOps 团队愿景的关键吗？

凯文·贝尔：是的，信任至关重要。例如，我确信美国军方是基于这样一个原则运作的：你将以你集体信任的速度前进。你会在你的公司或你自己的团队中看到这个原则的运作。当你感到沮丧，觉得无法完成任务时，你应该立刻评估周围的信任水平。问问自己，“这里的事情是交易性的吗？”例如，如果你下了一个订单，接着我就给你一盘饭？还是我们有关系，并且我们有信任？

“这种通过弄清楚问题所在并共同解决的同理心，正是建立信任的关键。”

— 凯文·贝尔

我有一个故事用来探讨信任。我读过一篇文章，讲述了一位在外国的美国将军和一个来自贫穷国家的将军之间的对话。来自贫穷国家的将军对美国将军说：“你不是一个很好的将军！”美国将军好奇为什么他认为自己不是一个很好的将军，接下来的对话大致是这样的：

美国将军： “为什么你认为我不是一个很好的将军？”

第二位将军： “因为当你把武器交给你的士兵时，你知道他们不会朝你开枪。”

美国将军： “是的，我们建立并拥有信任。”

第二位将军： “当你给人们 30 辆坦克时，他们不会把它们卖到 eBay 上。”

美国将军： “是的，我们有信任。”

第二位将军： “所以，你不必做太多——所以你一定不太擅长这个！”

*克托·法尔奇奇：我喜欢这个！

凯文·贝尔：但你知道将军说了什么吗？他说：“我想你是对的!” 所以现在，美国军方按照不同的原则运作：任务指挥。它不再是每一层级都进行指挥与控制。通过任务指挥，领导者明确他们希望达成的结果，但不告诉我们该怎么做。领导者定义成功和失败的标志，然后让他们的下属向他们汇报，以确保大家保持同步。

保持同步当然至关重要，因为当局势发生变化时，计划不一定会保持不变。团队能够即兴发挥，因为他们理解指挥官的意图，因此能够找到实现目标的新方法。

*克托·法尔奇奇：真棒。

凯文·贝尔：没错，因此当我们采用意图管理风格时，它允许 DevOps 团队自己找到解决方法；他们更了解情况，因为他们离工作更近，他们受到意图以及成功和失败的信号的指导。

采用意图管理风格时，我们还在做一件 Reed Hastings，Netflix 首席执行官所谈论的事情，那就是培养团队的判断力。我们不仅仅告诉团队去哪里或者去哪里后检查是否到达。团队这样是学不到任何东西的；他们往往会在有人向他们开火时停下来，或者直到他们的领导告诉他们继续前进。

*克托·法尔奇奇：当然，团队面临着高效的巨大压力。管理者希望有确定性，但我们从军事战场上知道，最好的计划也不一定会按预期进行。任务指挥确实能解决不确定性。这是试图应对不确定性的一种方式，对吧？

凯文·贝尔：是的，管理者想知道的是计划什么时候能够成功！在我们拥有基于韧性工程的组织中，期望当然是事情会出错。第一步是承认事情会出错，第二步是认识到我们在事情出错时如何应对是非常重要的——无论是过程中，还是事后。

首先，我们如何解决眼前的问题？然后，在修复已经破损的部分时，我们重新获得士气和力量。有时，这意味着在连续两晚未眠后，休息几天。

接下来的步骤是，如何找回我们的激情？我们需要把这种激情应用到确保这些事情永远不会发生的过程中。这是一个不断的庆祝、失败、胜利、庆祝和失败的过程。

在美国，这个过程往往会导致很多人感到精疲力尽。我们对人们施加了很多压力，他们工作了很多不该工作的时间。技术工作不仅在技术上困难，而且生活方式也很艰难。如果你孤单且被困在一份艰难的工作中，又没有人可以合作，面对不可能的截止日期和不讲理的同事，那么你就会感到沮丧。你不会做出最好的工作，最终你会离开公司……这会导致更大的问题，因为我们都知道，软件开发人员和优秀的基础设施人员是很难找到的。

*克托·法尔奇奇：这些人可能一周内就能找到另一份工作，所以他们会离开。

凯文·贝尔：我试图向公司领导解释这个问题，他们却说：“我们要削减成本。”但削减成本有很多方法；首先要变得更有效率，因为只有这样你才能真正做到高效。如果你在有效之前就试图提高效率，那么从长远来看，它总是会花费更多。

并不一定非得如此。我发现，当这些团队开始合作，并且人们逐渐进入新的合作和协调层次时，那些曾经孤单的人，那些曾经沮丧的人，以及那些工作过度的人，他们会从周围的人那里获得同情。突然之间，你会听到像“哦，我知道那是什么感觉”这样的声音，或者“哦，我认识那个女人，下次那种情况发生在她身上时，或许我们可以一起去喝咖啡，鼓励她继续坚持下去”。

“…随着人们逐渐进入新的合作和协调层次，那些曾经孤单的人，那些曾经沮丧的人，以及那些工作过度的人，他们会从周围的人那里获得同情。”

—凯文·贝尔

*克托·法尔奇奇：当我还是个开发者时，我觉得我从未见过一个基础设施人员。在我甚至不确定那个人是否存在的情况下，我怎么可能与某人建立同情心呢？在我看来，可能只是有个脚本在运行，导致我长时间等待！

凯文·贝尔：一个人的“for-next”循环！

*克托·法尔奇奇：是的，因为在我看来，我从未遇到过基础设施人员。

凯文·贝尔：这是一个非常好的观点，因为如果我们甚至没有见过某个人，我们怎么能建立同情心呢？而且仅仅在问题出现时，或者在紧急电话会议中见到人是不够的，因为这些都不是建立同情心的地方。

*克托·法尔奇奇：我遇到过一些人，只有在他们对我大喊大叫时。

凯文·贝尔：是的，这会造成负向强化并削弱社会资本。在面对新情况时，首先最重要的事情之一就是要求你的主要供应商支持公司的团队社交活动。你会感到惊讶，很多团队都希望参与。组织可以找到创造性的方法把人们聚在一起。

获得被倾听的权利

一种非常具有颠覆性的方法是采用 Lean Coffee 方式来召开会议。如果你能说服一个脾气暴躁的伊 eyore（*灰）来参加你的 Lean Coffee 会议，并且你只是提问和倾听，那么你已经在创造改变。你通过这种方式解决的改变问题是，人们希望被倾听，并且希望在愿意倾听之前，能感受到他人的兴趣或同理心。但在变革过程中，重要的是通过先倾听来获得彼此被倾听的权利。

“在变革过程中，重要的是通过先倾听来获得彼此被倾听的权利。”

—凯文·贝尔

如果一个曾经处理过运营和基础设施方面事务的人能够来参加 Lean Coffee，那么每个人都能听到那个运营人员在说什么。开发和运营*组中的人最初可能会感到怀疑。为了取得进展，必须有人能够开始信任。团队成员首先要学会信任，并且要倾听，持续地倾听。人们需要去除过滤器，设想对方所说的内容是出于积极意图，即使一开始可能听起来并非如此。这是许多人在 Lean Coffee 中能够做到的事情。你将所有话题列出，并对这些话题投票。如果我们有新成员，我会有偏见，确保新成员能发言并且理解。

如果这是你第一次参加 Lean Coffee，你可以谈论你想谈的事情，大家都会倾听。我认为当人们觉得自己被倾听时，他们通常更愿意去倾听你。老实说，你是否注意到人们是多么地互相打断对方？我们太忙于向彼此展示我们知道自己在谈论什么，并且表明我们很聪明，以至于我们常常会错过重点。我看到这种情况在许多事情中都有出现。所以是的，你说得对，*克托：当你没有问题的时候聚在一起是非常重要的。

*克托·法尔西奇：我们还能通过什么方式帮助人们进行合作呢？

凯文·贝尔：我喜欢用丰田 Kata 来帮助人们学习如何合作。丰田 Kata 是迈克·罗瑟（Mike Rother）于 2009 年首次提出的。这是一种改善问题局面的简单方法，并且为我们提供了一种科学的方法来实现这一目标。

你开始使用丰田 Kata 方法时，首先要定义一个目标状态，这个目标应该是良好的秩序，以便得到最佳或积极的结果。只有在此之后，你才会查看你当前的实际状态。

接下来，你会说：“如果我们要解决这个问题，达到目标状态时，我们会遇到的第一个障碍是什么？”你列出一个*清单，然后考虑一下参与这个问题的人。

我通常做的事情是将一些基础设施人员和一些软件开发人员聚集在一起，然后给他们一个共同的问题。我们会让他们一起使用 Kata 来解决问题。接着他们会一起进行实验，通常第一次实验不会太顺利；第二次——嗯；第三次——没有争执。

*克托·法尔奇奇：没有人受伤。

凯文·贝尔：没错！他们开始一起解决一些问题，并且开始欣赏彼此解决问题的能力。运营团队和开发团队之间可能说的是不同的语言，但我发现 Kata 使得问题周围的语言和模式标准化了。这使得运营团队和开发团队能够进入一个协作解决问题的流程，因为语言障碍变*了。

改进 Kata 是教基础设施人员有关敏捷和精益方法的好方式。我曾经与一群产品经理和软件开发人员一起做过一次改进 Kata。问题是，产品经理们只是随便给日期定个目标。这导致开发人员认为“这件事必须在这里完成，那个事必须在那里完成。”而在另一方面，产品经理们则认为开发人员把所有事情都估算得过高——这是一个很常见的问题。

当我与那个*组一起工作时，我对他们说：“你们的目标是想要一个可衡量的目标状态。你们想要一个故事的平均周期时间，而你们的平均故事时长是一天。”然后我说：“你们想要这些冲刺的周期时间减少 20%。”基础设施人员说：“那与我们有什么关系？”与此同时，产品经理说：“我们怎么改进？那是他们的事！”开发人员则回应：“是你们设定了最后期限！”

团队立刻进入了冲突。但我告诉他们，此刻这些都不重要，因为实际上，两个团队共同为实现目标状态做出了贡献。所以，使用改进 Kata，我们看到了第一个障碍；它是什么，且我们将遇到的第一个问题是什么？

工程师通常很擅长发现问题，因为他们会告诉你你将会遇到的所有问题；所以，一旦你让他们集中精力解决问题，他们会将其消除。如果工程师心里有一个问题，他们会带回家，无法停止思考，直到解决它为止。

*克托·法尔奇奇：这是我作为工程师的亲身经历中同意的观点。

Kevin Behr：一旦工程师们开始思考一个问题，他们就会带着想法回来，然后我们希望告诉别人。但是，虽然这与个性有关系，也许是最外向的人说得多，但也应该给那些安静的人留出空间，让他们能说出自己需要说的话。

在我刚才提到的产品经理和开发人员的情况中，最终一位产品经理回来对我说：“听着，我意识到我们一直在让你估算时间，然后将你的估算变成承诺，这是不公平的，因为我自己也不喜欢别人这么做。”

这看起来不公平，对吧？让一个从未做过某事的人去估算做这个事需要多长时间。如果是这种情况，问你“如果一切顺利，需要多长时间？”然后我在那个时间点检查一下你，是否会更公平？这样你就不会预留缓冲时间，我也不会强迫你，而只是来检查一下你。那么，这会有什么影响呢？

让我们再思考一下。如果一个项目经理像以前那样走到你面前，问你：“做这个需要多长时间？”，你可能会回答：“嗯，我以前没做过这个。不过我做过类似的事情，花了两天时间。你今天让我做的事有点难，所以我可能会说三天。然后，为了安全起见，我会说需要五天。”你和那个项目经理交谈时，他会告诉你：“好的，那我周五来看看你。”他知道你到时就能完成。然后，项目经理周五回来时，你对他说：“啊，我还需要一天，可能两天。”这个时候，项目经理必须回去调整计划，把日期推后，这通常会引发很多恐慌。

现在，我们来换一种方式。这个时候，项目经理对你说：“告诉我如果一切顺利，你能做什么，我只是来检查一下，没有承诺。”于是，项目经理在第二天回来，问你：“进展如何？”你可能会说：“嗯，我还需要一天半。”项目经理回答：“好的，这听起来不错，但你确定吗？”你说：“是的，这是承诺。现在是我做这件事的时候了，我知道自己在做什么。”项目经理又回来了，这时候事情完成了。请注意，在第二种情况下，项目经理是在第二天就知道你需要更多时间，而不是等到第五天！

Viktor Farcic：完全正确。

Kevin Behr：如果你是项目经理，或者如果你在进行冲刺并担任 Scrum Master，那么你自然会为几乎每个任务加上通常的缓冲期。然后，只要你的截止日期在缓冲期之后，你所需要做的就是通过在整个项目中找到额外的时间，来管理每一个时间损失的瞬间。

在这个过程中，你最常做的事情是提前完成任务！这叫做关键链，是 Goldratt 发明的。关键链基本上要求你在项目中识别出最受限的资源，然后将所有其他项目元素都从属于这个受限资源。

我们在《凤凰项目》中称之为布伦特悖论。我们遇到的情况非常幸运，因为其中一位产品经理读过 Goldratt 的书《关键链》。这位项目经理说：“当开发人员无法按估算时间完成任务时，他们被责骂，这太不公平了。” 突然间，我们看到了之前未曾注意到的事情：我们没有估算，而且有许多人对这个问题做出了反应。我们还有不同的人从不同角度思考他们的管理风格，也有不同的人以自己的方式解读我们到底在承诺什么！

Viktor Farcic：你描述的情况确实很有争议。

Kevin Behr：是的，绝对如此，因为当发生意外情况时，所有这些人群都会感到压力，要么承受责备，要么获得功劳。

当然，也有一种替代方法，那就是通过共同工作的经验，赋予人们相互信任的能力。这样，当问题发生时，人们更能承受问题的冲击，因为在社会上他们基本理解谁能做什么。然后，他们会知道你擅长什么，我不擅长什么，并开始合作。我不知道你怎么样，Viktor，但我宁愿和我认识和信任的人一起面对糟糕的问题！

Viktor Farcic：Kevin，这不只是你这么想！我认为每个人都一样。你必须真的是个心理变态，才会愿意和那些你不认识或不信任的人一起面对问题。

Kevin Behr：没错！所以，你必须成为一名管理者，因为最终，高层管理者做的许多事是没有同情心或共情的。他们根本不知道这给下属带来了什么困难。

在 DevOps 中，我们会问自己如何创造一个有韧性的环境。

—— Kevin Behr

在 DevOps 中，我们会问自己如何创造一个有韧性的环境。我们不需要都是最好的朋友，但我们确实需要有一种合作关系，而且这种关系不能专注于责怪别人。

DevOps 的阴阳

建立无责文化的一个关键部分就是如何进行事后分析。你如何正确地做回顾，以确保责任不成为问题？你如何创造一种环境，让在某人犯错并导致宕机时，他们能主动举手说：“嘿，是我做的，发生了这个，我需要学到什么？”通过这种态度，整个团队会共同进步。

你在事后分析中保守机密，因为团队之间互相信任，他们会一起解决问题。我发现很多组织并没有通过这种方式建立信任，反而那些组织中的人通常专注于在工作中为自己建立安全感。结果是，这些人有时会相互对立。

*克托·法尔西奇：这肯定和你在讨论一开始说的事情有关：公司们过度关注如何防止问题的发生，而不是如何解决问题？对我来说，你刚刚说的就是同一个问题的人的一面。

凯文·贝尔：完全正确。这就像阴阳相生的局面。对我来说，看着 DevOps 发生的事情以及关于其含义的困惑令人震惊。我最近看到一篇文章说，80% 的 IT 经理对 DevOps 感兴趣。然后他们问这些人是否对 DevOps 的含义感到困惑，结果 80% 的人又举手！这是一个糟糕的组合——但你知道吗，我们在生活的其他方面也会做这些事情；这是一种人类的特质！

*克托·法尔西奇：是的，无论我走到哪里，在大多数情况下，我都看到 DevOps 的完全误解，至少从我的角度看，像你一样，我恰好认为问题出在人的本性中。

DevOps 并不像 Scrum 这样容易理解，因为在 Scrum 中，你每天九点钟进来，站着开十五分钟的会。Scrum 的定义非常精确：你做什么、何时做、怎么做。

在谈到 DevOps 时，你会听到人们说：“你需要一起解决问题才能做 DevOps。”然后他们就只说这一句话，这让每个人都在想，这到底意味着什么？接着你会听到：“我是不是应该买 Jira？这就是你在告诉我的吗？”于是，他们去买了 Jira，然后说：“现在我们是 DevOps 了。”

凯文·贝尔：“现在我们是 DevOps 了，”正是这个笑话！我曾在德国做过一个项目，他们也遇到了同样的问题：那些人以为他们在做 DevOps！他们有一个非常详细的计划，关于一切应该如何安排，包含了程序和政策。但当我问他们：“当你们说自己在做 DevOps 时，发生了什么？”他们回答：“哦，那就是当我们没有操作手册时做的事。”就像你描述的那样，*克托——他们完全误解了 DevOps 的含义。

基恩·金和他的团队写了一本书，叫做《DevOps 实战手册》，旨在向人们展示如何在 DevOps 中做一些新事物，同时也介绍 DevOps 背后的一些思*。正如我之前所说，我觉得缺失的往往是那种基本的同理心和同情心，如果你去参加DevOps Days大会，你会听到关于同理心的讨论。同理心仍然是我最优先关注的事项。

所以，如果你在做 DevOps，那么领导者的工作就是促进同理心、学习和判断力。如果你在做 DevOps，领导者可以花更少的时间去管理人们如何做工作，也能花更少的时间去寻找人们如何做和思考工作的证据。如果我是领导者，我可以帮助你发展思*，那么我就不需要一直检查你。我宁愿拥有更少的人，和更少的规则，并且这些人有更好的判断力。你需要更多规则的时候，这通常意味着你可能不信任人，或者不信任人们的判断力。我们之前已经讨论过信任有多重要了。

“如果你在做 DevOps，那么领导者的工作就是促进同理心、学习和判断力……这样领导者可以花更少的时间去管理人们如何做工作，也能花更少的时间去寻找人们如何做和思考工作的证据。”

—凯文·贝尔

*克托·法尔西奇：关键在于我们能够让人们使用他们的大脑。就像他们会采取这样的方式说：“从现在开始，我允许你实际去解决问题——而不是仅仅执行步骤 A、B 和 C。”

凯文·贝尔：是的，因为那样你就能激发人们的大脑去运用更全面的、解决问题的部分。你不希望他们的爬虫大脑或者边缘大脑被激活——因为这不仅仅是关于生存的问题。

事实上，社会技术系统方法的早期先驱之一——一位名叫埃里克·特里斯特的人，甚至曾说过，工作中的学习是一项人权，如果你不实践这个权利，那么你就是一台机器，应该由机器来替代。但如果人们无法为你提供一个可以在工作中学习的环境，那你不如去别的地方找工作。

好消息是，许多技术专业人员在这一点上是非常幸运的。当然，并不是每个人都有这样的好运，但无论你身处何地，都有办法学习，即使公司或其管理者阻碍你，你依然可以学习。如果公司帮助你，而你又有学习的渴望，也许你还恰好有一个可以合作的人，那么——突然间，你就有了真正的学习机会，甚至可能一起解决某个问题。

这是人们在组织中向上晋升时往往无法理解的事情。正如拉塞尔·阿科夫所说，我在这里转述一下：在组织中越往下走，接近一线员工，他们对某些事情了解得越多。而当你越往上走，知道的事情却越少！

工程师们总是喜欢这个笑话，但它确实是真的。当你在组织中逐步晋升时，你必须更广泛地思考，并且需要掌握更多的知识。但另一方面，当你是个体时，在很多情况下你可以自己解决问题——因为你可以独立处理某些事情。当你成为经理，甚至是主管时，你会发现，你必须建立共识、促进合作，组建团队来解决问题。你会意识到，很多问题不是你能单独解决的。

比如说，如果我在销售部门，并且想要进行促销活动，我就得去找市场部门，因为我需要他们向人们宣传；而且我还需要 CEO 的批准，但我也必须和 CFO 谈谈，确认我们有足够的资金。要完成某些事情，自然需要多方面的合作。

丰田、泰勒原则与看板

*克托·法尔奇奇：这让我想起了泰勒主义，回到 1980 年代末和 1990 年代初。

凯文·贝尔：是的，劳动分工，对吧？泰勒方法帮助我们走了很长一段路。泰勒方法让我们走到了丰田，而丰田的起步就是基于泰勒的原则。很多人没有意识到，丰田的管理体系有很大一部分是科学管理的产物。

*克托·法尔奇奇：令我吃惊的是，居然没有人停下来思考，是否真的是一个好主意将泰勒的原则应用到软件开发中。如果今天我做的事情和昨天完全一样，这才是应用泰勒主义的唯一方式，那么我真的很不称职。

凯文·贝尔：哦，我不是说那样做很好。我想说的是，它比之前的做法好，即便它是围绕大规模生产的思想进行优化的。

*克托·法尔奇奇：没错。

凯文·贝尔：现在，我们正处于大规模定制的不同时代，思*方式完全不同。但你说得对，泰勒管理风潮盛行时的思*方式与今天截然不同。尽管如此，泰勒主义确实帮助我们走到了丰田的起点，也推动了福特的流水线生产。

很多人不知道的是，丰田的整个生产系统（TPS）是在破产的背景下诞生的。1950 年，当丰田被银行接管时，丰田聘用了大野耐一。银行曾对丰田说：“除非你有订单，否则你不能生产汽车。”丰田则回应道：“为什么不行？”银行的意思是，丰田生产了太多没人想买的汽车，结果花光了所有资金，最终破产。银行告诉丰田，唯一能确认丰田生产的汽车是否会卖出去的办法，就是在生产前该车已经被卖出去。那么，丰田怎么做呢？他们开发了拉动系统和单件流作为系统目标。

*克托·法尔奇奇：这当然是其中一种思考方式。

凯文·贝尔：但重要的是，丰田在最低成本下做到了这一切，因为最初的单件流并不便宜。到最后，他们已经找到了让它更便宜，并且不断降低成本的方法。丰田在这一过程中没有什么一蹴而就的时刻——他们通过日常的改进卡塔来实现了一切。

*克托·法尔西奇：包括看板的发明吗？

凯文·贝尔：我的意思是，在 1970 年代，有一段时间大野耐一到处宣称，“看板的目的是不需要看板”，那时候人们都快炸了！他的观点是，如果你总是盯着一个看板，或者盯着一个卡片看，那么你就忽视了周围的环境。但看板作为一种问题解决方法，是为了解决特定问题，在一段时间内使用；丰田随后会利用卡塔方法从中成长。

有一天，丰田意识到看板是很有力量的，于是……一切都变成了看板！丰田工厂里到处都是闪烁的卡片和各种信号，大野耐一会说：“这太多动作和浪费了。”最终，丰田找到了减少动作和浪费的方法。我认为我们在所有技术突破中都会经历这种循环。

*克托·法尔西奇：如果某件事是好的，那是不是就意味着更多的更好呢？

凯文·贝尔：是的，我认为我们现在也到了 DevOps 的这个阶段。你会看到人们试图将一些东西加入 DevOps 的词汇中，比如 DevSecOps——更多的东西即将出现。

DevOps 的最佳环境

这完全是跨职能协作，因此管理上的问题变成了：你能做什么来让自己不妨碍别人？你如何能让那些通常不交流的人开始交流，并且是在良好的环境下？当他们听到愿景，或者听到方向时，你可以把人们组织到工作*组中，并告诉基础设施人员，你们怎么帮助开发人员？或者开发人员，你们如何帮助基础设施人员完成这个工作，对吧？这就是领导力。

*克托·法尔西奇：但是 DevOps 在很大程度上是一个草根运动，而领导层并不知道该如何应对 DevOps，是吧？

凯文·贝尔：不，管理层不知道该如何处理 DevOps。他们开完一个随机的会议回来，说，“我需要三个 DevOps，给我这个！现在我们需要一个 DevOps 副总裁！”

*克托·法尔西奇：有趣的是，这甚至不是笑话！我真的见过这些“DevOps 副总裁”中的一个！

凯文·贝尔：哦，我见过他们中的几个！当然，我必须尊重他们处于领导职位的事实，但我不一定明白他们存在的意义。DevOps 的理念是，你应该建立信任和判断力越来越强的团队，而这应该在整个组织中传播！

“管理层不知道如何处理 DevOps。他们开完一次随便的会议后回来说，‘我要三个 DevOps，给我这个！现在我们需要一个 DevOps 的副总裁！’”

— 凯文·贝尔

组织并不了解 DevOps 所需的环境，才能让它茁壮成长。在我们由人力资源和财务驱动的企业模式、结构和组织图中，我们会感到自己被困在这些职位中。我们必须明白，这些职位只是社会构建的产物。

比如，我会向人力资源部门的人指出，他们的组织结构图仅仅是一个假设。我问他们，“这是你们认为组织办公室工作的最佳方式吗？你们怎么知道它有效？测试在哪里？”因为如果一个组织结构图不起作用，那就应该有人来改变它。

我在寻找组织灵活性时，会看看它已经保持这种结构多久了。这里谁能改变它？有没有人，譬如说一个开发人员，能够走过来并说，“我们有个问题。我们的组织阻止我与这个人沟通，但我需要和这个人沟通，因为我们有个问题。”如果他们这么说，大家会听吗？

*克托·法尔奇奇：机会是……可能不行。

凯文·贝尔：因为我们喜欢我们的框架、图表、合规性、工作委员会和所有这些事情，我们因此感到被迫参与。但我一直在向人们展示的是，组织结构图只是一个概念。组织结构图并不了解你现在的项目，也不了解你现在遇到的问题。如果组织结构图阻碍了你采取正确的行动，那么也许是时候坐下来，作为一个团队问问自己，是否有更好的做事方式。也许你不需要得到许可就能完成任务，或者你可以说，“哦，对不起，我不知道我不能和我的邻居合作。”

*克托·法尔奇奇：没错。

凯文·贝尔：我认为很多时候，我们假设我们的工作方式是基于框架和图表的，我认为我们需要测试并推翻这些假设。那些控制组织结构的人需要更加灵活地看待组织的可能性。毕竟，组织总是在朝着某个方向过渡，它们不可能也不会保持不变。

“DevOps 社区中的人们开始看到更大的组织系统。一旦你把 DevOps 放到更大的商业系统图景中，你会以完全不同的方式看待一切。”

— 凯文·贝尔

*克托·法尔奇奇：你乐观认为组织因此可以改善吗？

凯文·贝尔：是的，我对 DevOps 在组织中的前景充满信心，因为 DevOps 可以蓬勃发展的环境也存在于其他系统中。我相信，DevOps 社区的人们已经开始看到更大的组织系统。而一旦你在业务的更大系统图景中看到 DevOps，你就会以不同的方式看待一切。我希望 DevOps 社区能够开始抬头，看到他们正处在这个更大的系统中，并且这个系统本身也是一个更大系统的一部分。我希望更多的组织能够意识到，我们唯一有机会引导我们的系统前进的方法就是共同努力。

第十一章

4

第十二章：Mike Kail

Everest 的首席技术官 (CTO)

第十三章：介绍迈克·凯尔

在超过 25 年的时间里，迈克·凯尔在多个 IT 领域拥有丰富的经验，包括可扩展性、网络架构、安全性、软件即服务（SaaS）和云部署。他在 DevOps 领域的关注点包括同理心、诚信、团队合作和韧性。你可以在 Twitter 上关注他，用户名是@mdkail。

*克托·法尔西奇：嗨，迈克。我想从一个可能看起来很傻的问题开始：什么是 DevOps？我跟我说过的每个人给出的答案都不同，有些人说它是一个过程，有些人说它是一个工具，还有一些人说它是做 DevOps 工程师。你怎么看？

什么是 DevOps？

迈克·凯尔：我当然不认为 DevOps 是一个工具或一个职位头衔。在我看来，DevOps 的核心是一种文化方法，旨在通过利用自动化和编排来简化代码开发、基础设施和应用部署，进而管理这些资源。

"我当然不认为 DevOps 是一个工具或一个职位头衔。在我看来，DevOps 的核心是一种文化方法，旨在利用自动化和编排。"

—迈克·凯尔

*克托·法尔西奇：你曾经谈到过 DevSecOps。这是 DevOps 的下一个迭代吗？

DevOps 的下一个迭代

迈克·凯尔：随着行业的发展，已经有公司转变为 DevOps 文化。在这种情况下，问题是，我们如何向左迁移，并将其纳入持续集成和部署管道？我们需要在过程的早期阶段从 CodeCommit 到构建和交付阶段注入安全性测试。安全性需要作为一个持续的循环来对待，而不是作为一个定期的测试和合规性方法。

*克托·法尔西奇：这是否意味着，通过向包括安全性演进，行业几乎已经落后于没有从一开始就包括安全性？

迈克·凯尔：不幸的是，大多数时候，安全性一直都是一个周期性的任务或过程。例如，当你每季度进行一次渗透测试时，可能偶尔会做静态代码分析，但这些都是手动进行的。你需要思考如何开始利用自动化，将其作为持续集成/持续交付（CI/CD）管道的一部分，确保使用最佳工具来完成这项工作。

你还需要安全工程师来更好地理解软件开发过程。他们不必是开发者，但至少需要了解发生了什么。开发者也需要对安全性有所意识，尽管这永远不会是他们的首要任务或最重要的关注点。开发者有自己的功能需求和其他原因需要进行高速开发，但他们至少需要理解安全方面的内容，并尽早开始考虑它。

*克托·法尔西奇：换句话说，你是在将安全性融入到你的过程当中，而不是将其视为事后考虑。

Mike Kail：完全正确！这就像我们使用 Microsoft Word 或 Google Docs 写长文档时可以实施的祖父母或父母测试。当你在打字时，程序会为你进行拼写和语法检查，这样你就不会因为需要在发布文档时纠正错误而延误项目。

同样的道理也适用于安全、SQL 注入和跨站脚本攻击，这些始终出现在 OWASP 十大漏洞中，不断反复出现。

Viktor Farcic：太棒了，我喜欢这个。从我们问谁的角度来看，DevOps 真正成为热门话题已经有几年了。这让我思考：作为一个行业，你会说我们现在处于艰难周期的顶峰吗？你曾与很多公司合作，我很想知道你是否认为公司在 DevOps 的采用过程中扮演了角色，或者它已经被完全采用了。

“我仍然认为 DevOps 内部的文化转型还处于初期阶段。”

—Mike Kail

Mike Kail：我仍然认为 DevOps 内部的文化转型还处于初期阶段。我们已经看到了早期采用者和领导者展示了 DevOps 的好处，以及它如何改变你的业务。但现在，每个人都在努力弄清楚如何达到那个目标，我认为这就是为什么我们对 DevOps 的真正含义仍然存在很多误解的原因。

从这个角度看：如果我只是称我的工程师团队为 DevOps 工程师，那我就是在做 DevOps。你必须从文化角度来看待这个概念，然后，从那里出发，利用 DevOps 的核心原则之一——测量——来看看你现在的位置，以及它到底是如何帮助你改变业务的。DevOps 不是万能药。

Viktor Farcic：这就是我对这种情况的印象，因为当我拜访公司时，我总是有一种感觉，在大多数情况下，一个随机的团队被重新命名为“DevOps”团队。曾经是工具团队或 CI/CD 团队的，现在变成了 DevOps 团队，当我问人们他们现在做得有什么不同时，他们很多时候不知道该如何回答我。

Mike Kail：很久以前，我曾是 Unix 系统和网络管理员。我通过那时的工作看到了职称膨胀的现象。如果我想赚更多的钱，我就不会做系统管理员，而是做系统架构师。无论是站点可靠性工程师还是 DevOps 工程师，都是为了争取更多薪水而存在的，但并没有带来文化转型的好处。

一个真正的 DevOps 文化，拥有一支工程师团队，意味着他们不仅能清晰地阐述他们正在做的事情与以往有何不同，而且还能实际展示给你看，因为他们在衡量这些变化。他们有关于今天进行多少次部署与几个月前相比的效率指标。然而，看到这些指标对企业有什么好处，而不仅仅是增加部署次数，并不一定等同于实际推动业务发展的因素。为了实现这一点，他们必须同时具备商业关注的视角。

*克多·法尔奇奇：这是否意味着想要进入 DevOps 行业的人需要学习新技能，还是我们需要具有不同能力的人？

DevOps 文化的演变

迈克·凯尔：我认为 DevOps 文化的演变是一个持续的过程。它不是说，突然之间，我从一个运营人员变成了 DevOps 人员，因为我做了一些自动化。我们必须明白，每个人都需要一些软件开发技能，无论是脚本编写、配对编程，还是在 CI/CD 链中实现合适的工具。但归根结底，你必须具备工程师的心态，我想这可能就是我们所说的。

技术领域总是在不断发展，无论是通过新的基础设施，还是通过新的 CO 工具的推出，帮助你更好地管理你的系统。它了解 Kubernetes、Mesos，或其他各种容器编排平台。更广泛的问题是，如何通过 DevOps 文化要素的标准，使这些平台更加高效。

“技术领域总是在不断发展，无论是通过新的基础设施，还是通过新的 CO 工具的推出，帮助你更好地管理你的系统。”

—迈克·凯尔

*克多·法尔奇奇：我最近和一个朋友讨论了一个类似的话题，他描述说 DevOps 行业需要打破部门之间的壁垒。这并不是因为他们效率低下，而是当人们开始一起工作时，他们会开始培养一种同理心，并感受到彼此的痛苦，最终带来更好的协作和不同的解决方案。

迈克·凯尔：没错；否则，就会出现“我们对他们”的心态，这种心态会在文化中隐性或显性地形成 DevOps。你就不再是为了推动业务前进而工作。相反，你是在为了看起来更好，或者让你的团队更高效，而工作。最终，这些都不重要。重要的是你公司的指标，不论是收入、客户满意度，还是其他。

首先，你需要打破壁垒，扁平化组织，消除层级，这对很多人来说是具有威胁性的；然后，你需要判断从个性和协作的角度来看，你是否拥有合适的人，而不是那些纯粹具备工程技能的人。像同理心这样的软技能很重要，适当的沟通能力、承担失败、不惩罚错误，并从错误和失败中迅速学习同样至关重要。

*克托·法尔西奇：这是一个非常好的观点。人们经常问，为什么他们不能有 DevOps 这样的工作模式，在这种模式下，开发人员、测试人员、系统管理员以及来自不同部门的各种人员一起工作。但另一方面，基础设施变成商品的故事也在流传，似乎不再那么重要了。你同意这个观点吗？

迈克·凯尔：我仍然认为你需要了解基础设施的各个组件，以及不同的 CPU、内存或磁盘配置在哪些方面很重要。

基础设施、成本与云计算

你需要把基础设施看作是一组组件。你如何组装这些组件并与它们互动？除此之外，你还需要如何保持一切的持续演进？基础设施比以前更具弹性——用云计算术语来说——而不像过去那样是静态的。那些基于这些基础设施的应用曾经采用的是单体架构或经典的三层架构，但现在随着容器、虚拟机和微服务架构的出现，这一切都迅速变化了。这也是为什么每个人都需要从工程的角度理解应用程序或一组服务的行为。也正因为如此，他们会持续跟踪并寻找异常情况，因为这就是确保你的网站或服务更加可靠的方式。

*克托·法尔西奇：是什么阻止了公司迁移到云端？我与许多公司沟通过后发现，很多公司仍然倾向于拒绝云计算，或者也许是我和的公司不太幸运。

迈克·凯尔：不，问题不仅仅出在你身上。我认为这是一种经典的恐惧、不确定性和怀疑的组合。人们因各种原因担心公共云的安全性，无论是事实还是谣言。例如，人们担心工作会消失。如果我管理数据中心中的硬件，那我现在该如何在云端做这些工作？是不是更偏向自助服务？这正是你必须不断提升自己技能的原因，技能需要更加侧重工程技术，而不仅仅是宠物的*护者。

这里还有其他因素在起作用：怀疑和成本。当你收到公共云服务提供商的每月账单时，你会感到震惊，因为虽然你可能已经将应用迁移到云端，但你没有进行任何适当的重构。你的本地环境是过度配置的——这也是你没有考虑到的成本——现在却在公共云的昂贵虚拟机上运行。你浪费了大量资源。

“人们因各种原因担心公共云的不安全性，无论是事实还是谣言。”

—迈克·凯尔

你应该利用这个机会迁移到公共云，并重新设计如何使你的部署更加高效，因为还有许多其他的成本杠杆。作为曾管理过十几个自有和运营的全球数据中心的人，我知道有许多成本是人们从未考虑过的。最明显的是雇佣人员全天候值班的成本，但你还需要考虑电力和冷却的成本。你会发现，通常情况下，因为你是一个大型成功的公司，你会过度配置硬件，因为你需要应对最高峰负载。你不能像按需部署云基础设施那样随便部署机架服务器。实际上，许多隐性成本从未在本地与云的总拥有成本模型中展示过。

Viktor Farcic：我有相同的印象，每当我讨论价格时，人们总是会将云的成本与仅拥有服务器的成本进行比较。

Mike Kail：根据我的经验，这总是一个苹果与橙子的比较。公司只看每月账单，忽视了从资本支出（CAPEX）到运营支出（OPEX）的转变，或者他们根本没有和首席财务官（CFO）清楚沟通过。如果完全没有考虑，你不能仅仅说：“我正在迁移到云端，完事了”，然后拿到账单，因为你不了解现有的安全控制措施，也不了解如何正确管理它们。

无论是事实还是认知上的问题，缺乏可见性也是一个挑战。我看不到我的服务器，也不能随便走进数据中心。我可能有一些人在做影子云部署，这样就有比我知道的更多的实例在运行。你还需要对云使用进行适当的治理，而我觉得很多人并没有清晰意识到这一点，也没有做好准备。

Viktor Farcic：我有一种感觉，DevOps 正在从以操作为主转向更多的开发导向，随着我们在开发数据中心。现在，大家都成了软件开发者，不仅仅是那些为你的应用程序编写代码的人。

Mike Kail：是的，这回到了马克·安德森的宣言——软件主导世界，因为我们正在走向一切软件定义的时代。软件定义基础设施、网络和安全。现在有一些公司正在做软件定义的电力、电力调节和负载调节。我认为一切都在变得程序化，这也是为什么——回到我常说的主题——每个人都需要具备工程师或开发者的思*方式。

“一切都在变得程序化，这也是为什么——回到我常说的主题——每个人都需要具备工程师或开发者的思*方式。”

—Mike Kail

Viktor Farcic：这可能类似于我们之前在测试领域经历的事情。自动化成为流行时，那些不懂写代码的测试人员变得非常防御性或害怕。也许类似的事情现在正在发生在运*领域。

迈克·凯尔：还有安全性的问题。因为在技术栈的基础层，QA 测试——经典的 QA 测试和安全性测试——非常相似。你都在寻找异常和问题，无论是安全漏洞，还是其他应用问题或错误。这些都曾是人工处理的过程，延缓了整体部署进程，这就导致了争议，进而使你开始对自己正在做的事情产生防御心态，而不是保持合作的态度。

*克托·法尔奇：这就像是从扮演守门人或警察的角色，转变为更多地作为一个合作伙伴。

迈克·凯尔：这就是从成为一个阻碍者转变为一个促进者。你如何快速地提供你的测试——无论是安全性测试还是性能测试——而不对部署和交付过程增加摩擦？

*克托·法尔奇：没错。现在的对话中，几乎无法忽视 Kubernetes 容器的存在。你对此有什么看法？Kubernetes 真的会成为那个统治一切的“魔戒”吗？

迈克·凯尔：我通常是 Kubernetes 的坚定支持者，我先从这一点说起。但是如果你做一项调查，你会发现，许多企业，甚至大多数企业，仍在为虚拟化和迁移到云虚拟机而挣扎。

跨越鸿沟进入容器世界是一个漫长的过程。你不能只是将应用部署到 Kubernetes、Mesos 或任何你选择的容器编排环境中。现在，你就能神奇地拥有微服务、自动扩展、具有弹性、高效能且具成本效益的应用程序了。没有魔法。我认为真正的容器原生应用非常少，尤其是在硅谷以外的地区。

跳跃到“谷底”

*克托·法尔奇：这是不是意味着公司不应该盲目跟随“今天的潮流”？如果你不做虚拟化，就不要去做容器。如果你不做云原生应用，就不要考虑部署到云端。

迈克·凯尔：我认为你首先要问自己，“我们为什么要这样做？这对我们的业务为什么重要？”你需要将其与潜在结果联系起来，而不是仅仅因为它是最新、最酷的技术，就想让自己看起来比 Facebook 还酷，因为那不会发生。

作为开发者或 DevOps 文化的从业者，我们往往会过于迷恋技术。看看 Kubernetes 是多么酷，或者容器和云计算是多么伟大。但你需要把这些技术与实际的业务需求联系起来。为什么要做这些？它对业务有什么影响，应用从云原生或容器原生中能获得什么好处？

我是一个坚定的支持云计算和软件定义的人，我认为有很多方式可以为此辩护。但你需要确保你的文化已经准备好迎接这种技术转型，并且你拥有处理流程和技术组件的合适人才。

“作为开发者或 DevOps 文化的从业者，我们往往会过于迷恋技术。”

—迈克·凯尔

Viktor Farcic：你认为公司到底理解背后的原因有多频繁？他们是因为真正理解为何要做这些事情而加入，还是有人来告诉他们：“你们必须做敏捷！”

Mike Kail：我觉得可能有很多独裁式管理采取“棍棒与胡萝卜”的方式。公司内部有些人或团队说：“看，我们要做敏捷，”或者“我们要做 DevOps。”这不是正确的做法。

就像一个创业公司在寻求融资一样，你必须去做一个正式的演示。你去找高层，告诉他们你所提议的内容以及理由。你展示效率，并且不断确保这不是一次性行为，而是每个人都支持这一持续的转型和演进。

Viktor Farcic：换句话说，人们应该主动找到你，而不是你告诉别人该去哪里？

Mike Kail：我认为这是异步的。不是我或者公司内部的某个人在对员工进行说教。实际上是通过让他们参与并进行协作，这是 DevOps 文化的关键部分。没有协作，你什么都没有。

Viktor Farcic：你提到过硅谷几次。你认为硅谷内外有什么显著的差异吗？

Mike Kail：我认为有。我觉得在硅谷，我们总是最先听到最新的潮流。例如，Docker 已经存在一段时间了，但在过去两年的旅行中，我似乎发现没有人真正理解容器是什么。我曾去某个组织的高管团队，问他们能给我定义一下容器是什么。如果房间里有 15 个人，我会得到 12 个不同的答案，还包括一些争论。

Viktor Farcic：但是，如果差距很大，你认为那些落后的公司能够追赶上吗？我很想知道数字化转型是否有希望。大企业真的能变得有竞争力吗，还是这场战斗已经注定失败了？

Mike Kail：这有点像宗教话题，因为它实际上涉及到公司的内部运作。我见过太多大型企业自寻烦恼，仍然陷入每年预算周期的思*模式。我敢肯定，亚马逊不会这样运作。我得承认我对亚马逊内部运作并没有深入了解，但他们的运作速度之快，他们不可能采用每年预算周期的方式，并且在面对新的转型和变革计划时，总是拖延不前。

许多企业满足于现状或表面现象，因为在心理上，这是他们一直以来的做事方式。在你去除或改变这种思*方式之前，任何技术都无法帮助你。

*克托·法尔奇：这让我想起一个真理：每家公司都是一家软件公司。现在，假设你认为这是真的，那它与外包你的世界有什么关系？显然，没有人会外包核心业务。

迈克·凯尔：你是在说开源倡议吗？

*克托·法尔奇：不，不能是开源——举个例子，假设你是一家大型银行或保险公司，将所有的软件开发外包给第三方。我正在试图弄明白，为什么有人会说软件很重要，却不在公司内部开发它。

迈克·凯尔：我认为你需要将你业务的核心知识产权或皇冠级资产牢牢掌握在自己手中，而不是外包、离岸或近岸处理这些。你需要在某种程度上保护你业务的核心特性，或者至少是那些能为你带来战略差异化的部分。也许你可以依赖第三方开发者来处理其他的事情。

我认为很多人认为外包或将工作交给第三方开发者会更便宜，但我认为考虑到时区问题，特别是语言和文化障碍，情况往往并非如此。这就像是本地部署与云计算的区别：人们没有真正做公平的对比。

*克托·法尔奇：确实如此。是因为这就像是在按人头计价，而不是按结果来计价吗？

迈克·凯尔：没错！

DevOps 之后是什么？

*克托·法尔奇：那么，接下来会发生什么？我不知道你是想展望一个月后的情况，还是几年的未来，但我们作为一个行业会走向哪里？

迈克·凯尔：我们经常听到“泡沫”这个词，但与 1999/2000 年的真正泡沫相比，今天的技术在硅谷已经渗透到我们生活的方方面面。如果我看一下流行语，我认为区块链将开始变得越来越普及。一旦人们理解它的应用场景，它将成为各个领域的颠覆性技术。然而，随着规模的扩展，增长的挑战也随之而来，我认为很多人还没有意识到这一点。

不能将区块链与加密货币混为一谈，但我认为我们会看到加密货币变得更加成熟，正如我们最近所见。例如，前几天，支付公司 Square 宣布他们将允许进行加密货币交易，这将为新业务和新机会的建立提供支持。

"我认为我们会看到加密货币变得更加成熟，正如我们最近所见。"

—迈克·凯尔

另一个仍处于初期阶段的领域是人工智能。我们如何利用人工智能以积极的方式推动商业和人类发展，从而消除其中的偏见？

*克托·法尔奇：理论上，这实际上也应该影响到工程领域。我们是否正在朝着一个方向发展，最终将由人工智能编程，从而让人工智能来编程其他所有内容？

迈克·凯尔：我认为我在技术职业生涯中所经历的每一个角色最终都会消失。再次强调，正如我们之前提到的，有那种恐惧。实际上，我认为 AI 要消除我们所有的工作还有很长一段路要走。实际上，恰恰相反：我更倾向于认为，AI 将创造更多的机会。

我们希望通过利用一些机器学习——这是人工智能的一部分——来消除繁琐的任务，使你的工作更加高效。这样你就可以将时间用于更高阶的事务。我认为这就是我们将会看到的，当人们理解这一点时，他们会取得成功。那些坐在那里担心自己的工作或职位会消失的人，可能一般不会在那个职位上待得太久。

*克托·法尔西奇：在我们结束这次访谈时，您还有什么想补充的吗？我们还没有讨论到的内容吗？

迈克·凯尔：我认为我的结束语是，我们仍处于 DevOps 转型的早期阶段。仍然有很多文化上的机会可以产生影响，实际上可以让事情变得更高效。

*克托·法尔西奇：那就不算是一个独立的项目，而更像是一个永无止境的故事。

迈克·凯尔：我将其描述为转型或持续演进。DevOps 领域的转型永远没有终点。总有一些业务领域或方面需要在性能上进行改进。

*克托·法尔西奇：这就是我不喜欢“数字转型”这个词的原因。某种程度上，它让我感觉这是一件有明确开始和结束的事情。

迈克·凯尔：这不是一个有明确终点的项目。我再用亚马逊的例子来说明。我猜他们一直在考虑数字转型，而且我们社会和世界中还有很多低效的部分可以通过数字转型加以改善。

第十四章

5

第十五章：詹姆斯·特恩布尔

首席技术官 – 微软创业公司

第十六章：介绍 James Turnbull

James Turnbull 领导着微软的“常驻 CTO”团队，帮助初创公司构建正确的架构和团队，以实现成功。作为一位经验丰富的工程与基础设施作家，James 已经出版了多本关于这些主题的书籍。你可以在 Twitter 上关注他，用户名是 @kartar。

什么是 DevOps？

Viktor Farcic：你好，James。我想以一个问题开始我们的讨论：DevOps 对你来说意味着什么？这是一个我觉得非常有趣的问题，因为我为这本书采访的每个人都给出了不同的答案。

James Turnbull：我不确定现在是否还能给 DevOps 一个单一的定义。我从 2009 年开始谈论 DevOps，尽管那年我没有参加比利时根特的第一次 DevOps 事件，但我参加了下一次。

我认为 DevOps 刚开始时，确实是试图建立运*与开发之间的桥梁，主要集中在交接的时刻——代码从开发阶段过渡到部署并进入生产阶段。然后从那里，我们分析了这个特定挑战的许多问题，并发现其中一些问题是文化上的，一些是技术上的，比如自动化和工具，另外一些问题则是流程导向的。

“现在，我认为 DevOps 对很多不同的人来说有很多不同的含义。”

—James Turnbull

现在，我认为 DevOps 对很多不同的人来说有很多不同的含义。我认为，如果你从事市场营销工作，曾经有一段时间，你只是将所有工具重新标记为你的 DevOps 工具包。到了 2019 年，你仍然会看到许多公司有一个 DevOps 页面，或者他们直接称自己为“DevOps 什么”——至于这些工具是否真的是 DevOps 工具，我不确定。

到头来，DevOps 关乎确保应用和产品以跨职能的方式构建，这样产品工程师、设计师、运营、安保和商业人员都能对他们的使命有共同的理解——那就是为他们的组织构建产品，希望这些产品能够为组织创造利润。

Viktor Farcic：这很有道理。你提到了 DevOps 工具，至少当我访问公司并参加会议时，每一个工具都有“DevOps”这个词。就好像没有 DevOps，没人能卖任何东西，这让我开始思考：真的有 DevOps 工具这种东西吗？

James Turnbull：不，我认为没有。我的看法是，确实有一些工具可以使跨职能团队的工作流程变得更好。我认为对于许多公司来说，Slack 就是一个 DevOps 工具，因为它是一个便捷的方式，可以让公司跨团队进行沟通。

我还想说，Puppet 可能算是一个 DevOps 工具，甚至 Chef、Salt、Ansible 或 Docker 也是，因为它们都能实现自动化和工作流，使得管理和迁移资产与代码变得更加容易。任何促进跨职能构建的工具，可能都可以被视为 DevOps 工具，以至于这个术语可能已经没有什么实际意义了。

今天最好的技术栈是什么？

*克托·法尔奇克：你是一个非常技术导向、动手能力强的人。你所有的书，至少我读过的那些，都非常技术性强，这让我不禁想知道你有没有最喜欢的技术栈。我看到你写了很多关于 Puppet 和 Terraform 的内容。是其中一个在取代另一个吗？而且，你怎么看待现在行业的发展方向？

詹姆斯·特恩布尔：我可能不再像以前那样技术性强了。我曾在很多不同的角色之间转换；现在，我主要是一个领导者。我是 CTO，也曾担任过多年的工程副总裁，所以现在我在业余时间涉猎这一领域，但我不再认为自己是一个实践中的 SRE 或系统工程师。

就像 Puppet 和 Terraform 这样的工具，我认为它们的作用不同。Terraform 显然是一个基础设施构建工具，如果你想构建一个虚拟私有云（VPC），并创建一些 Amazon EC2 实例，以及其他一些将它们连接在一起的东西，那么 Terraform 是理想的工具。如果你想配置这些资产并在其上部署应用程序，那么我认为 Puppet 或其他配置管理工具是更合适的选择。

*克托·法尔奇克：那么 O'Reilly 的会议呢？你在那儿看到什么趋势了吗？你能预测接下来会发生什么，至少在 DevOps 或基础设施相关的领域吗？

詹姆斯·特恩布尔：过去几年，我们大大改变了 Velocity 的目的。未来的重点确实是在分布式系统上。我认为基于单一地域的单体应用已经是基础设施和架构世界的“恐龙”。它们的生命周期很长，可能需要很长时间才能消失，但那些正在构建新系统的人，真的需要考虑这是否是开发他们的应用或服务的最合适方式。

我认为有几个原因，其中一个显然是单体应用程序往往更新缓慢，而市场速度现在非常重要，就像你部署一个新特性、新功能或某种能带来显著变化的服务一样，性能、扩展性和可用性也同样重要。单体应用在这方面通常做得不太好。

“客户对应用程序和服务的性能有很高的期望，这正在显著改变数据分发的方式。”

— 詹姆斯·特恩布尔

第二个原因是我认为客户的期望现在要高得多。过去几代人，可能是第三代互联网或云原生的成长者，他们从未经历过没有手机数据的时光。客户对应用程序和服务的性能有很高的期望，这显著地改变了数据的分发方式。例如，不再是很多应用程序的最佳模型是一个大型集中式数据中心；事实上，它是一个以边缘计算为中心的分布式应用程序，在这种模式下，某个特定用户群体的数据更接近这些用户，而不是靠近核心基础设施。我认为，总的来说，我们现在看到的是，至少在未来两到三年，分布式系统将成为基础设施和应用开发的重点，尤其是在后端。

单体架构与微服务

*克托·法尔奇克：你提到了单体架构和微服务。你能解释一下为什么它们现在才开始流行吗？显然，微服务已经存在了几年。这是因为我们的需求发生了变化，还是我们能使用的工具发生了变化？并不是说这个概念很久以前就存在了，而是大家最近才开始谈论它们。

詹姆斯·特恩布尔：我刚开始进入这个行业时，有一个概念叫做面向服务的架构（SOA）。主要是将服务分解为独立的故障域，使它们能够独立扩展、管理和交互。服务的定义相当广泛，通常并不像微服务那样。

但我认为发生了几件事情，即虚拟化、云计算和容器使得微服务架构得以实现。这些工具非常易用，允许人们构建这些服务。

我认为这些服务之所以变得流行的原因是，如果你正在构建一个面向零售和客户的应用程序，并且希望该应用程序能够快速迭代，那么构建独立的服务比构建一个庞大的单体架构要容易得多，因为在某个时刻，你会失去对模型的理解能力。你将无法全面理解这个模型，也无法在不影响其他部分的情况下对其进行更改，而微服务则可以通过合适的协议和 API 进行版本控制、管理，并可以进行金丝雀发布和滚动更新。

*克托·法尔奇克：你有接触或在这种模式下的安全经验吗？因为我听说安全性是一个问题，特别是当与容器结合时。

詹姆斯·特恩布尔：我曾是一名安全工程师几年，所以我认为容器在安全性方面有一些挑战。显然，从计算资源之间的隔离来看，容器不如虚拟机稳健。例如，在大多数情况下，容器代表的是进程隔离，而不是虚拟机管理程序的隔离。但我认为，实际上，很多问题归根结底还是取决于你如何部署你的服务，以及如何构建你的环境。

如果你在前期就将安全架构考虑进去，并在应用程序和基础设施层面都实施深度安全，并且将其设计进你的环境中，那么过去让人困扰的许多常见问题就会变得不那么令人担忧。在构建区域化安全模型和将相似风险水平的工作负载一起部署方面，已经做了大量工作。你可以将营销网页服务器群集部署在一起，但不能与工资系统部署在同一主机上。多年来，很多常识性的做法已经被采用，我认为这使得该领域的大多数安全问题不如看起来那么严重。

*克托·法尔奇：当我看待软件时，至少在你书中描述的方式下，它总是开源的。你认为这意味着封闭源代码的死亡吗？还是封闭源代码现在依然存在？

詹姆斯·特恩布尔：我认为对客户发生的事情，也同样发生在其他领域的软件上。我喜欢开源软件，因为我喜欢能够控制自己命运的能力。我也相信可组合应用程序。Unix 应用程序的基本原则是*巧、可组合的工具，我可以将它们组合起来，构建一个堆栈，我非常喜欢这种模式。对我自己来说，和许多其他可能有相当经验的工程师一样，我喜欢选择一个堆栈，在这个堆栈中，我可以取一些 Kubernetes，取一些 Prometheus，也许再加一点这个和一点那个，然后将它们结合起来，提供我喜欢并且能够使用的堆栈。

"我喜欢开源软件，因为我喜欢能够控制自己命运的能力。"

—詹姆斯·特恩布尔

我仍然认为很多公司，特别是企业公司，仍然希望有人可以在产品或应用程序出现问题时与之沟通。他们想找一个责任人，或者需要有人为他们提供支持和赔偿，因此我认为封闭源代码的企业软件仍然有市场。但我并不确信需求仍然像以前那样庞大。越来越多的人在构建主要是开源的东西。当它的核心是开源时，他们会在此基础上出售额外的技术或功能，这些技术或功能可能是封闭源代码的，也可能以某种方式是商业化的。如果你看看围绕编排工具发生的大量变化，那么其中很多的核心都是 Kubernetes，其他的一些工具则围绕它或基于它构建。

Kubernetes、RHEL 和 Ubuntu

Viktor Farcic：你提到 Kubernetes。你认为 Kubernetes 会影响操作系统吗？我们会继续看到 RHEL 和 Ubuntu 主导市场吗？

James Turnbull：我不这么认为。我个人认为操作系统已经过时；我看不出它的存在意义。我想构建的是那些可以组合的东西，它们只使用我关心的系统级资源，无论是磁盘、CPU 还是内存。我希望能够从一系列库或中间件中选择，然后将这些组合起来，而无需大量其他材料的支持。我认为我们将会看到越来越多像 Alpine 和 CoreOS 这样的东西，在这些系统中，操作系统在很大程度上是一个黑匣子，或者你得到的是操作系统的一个片段，你并不需要配置它，因为很多内容对你是隐藏的。

我仍然认为人们会需要某种形式的支持。当某些东西出现故障时，他们希望能有人可以沟通。我只是想知道他们是否希望在一个不同的抽象层次上获得支持。比如他们是需要一个 RHEL 支持账户，还是需要一个针对特定工作负载、应用服务器或在比如 OpenShift 上运行的堆栈的支持账户？再次强调，这是一个长尾问题，所以我猜测在这方面可能需要几年时间，但我不认为操作系统市场会有太长的未来。

Viktor Farcic：你认为它会被像 CoreOS 这样的新操作系统取代吗？还是会变成类似于自己动手的 unikernel 类型？

James Turnbull：我认为 unikernel 是一种可能性。对于无服务器的东西来说，你并不关心底层硬件，或者比如说你应该运行 AWS Lambda 还是 Azure。这并不重要，不管它是 Ubuntu、Fedora 还是 RHEL —— 对你来说并不相关。因此，我认为我们将会看到一些东西，它要么对终端用户隐藏，因为它对他们来说是一个黑匣子，他们不需要更改任何内容，要么它是操作系统的一部分、一个切片，而不是整个操作系统。

Viktor Farcic：你提到了无服务器计算。我常常听到人们担心会被供应商锁定。你认为这是一个有效的担忧吗？

James Turnbull：我的意思是，那正是这些云供应商希望你做的事情。他们希望你购买他们产品的所有部分，并将你锁定在他们的生态系统中，因此我确实认为这是一个需要关注的问题。

随着时间的推移，我们会看到越来越多的事物看起来像是标准，比如，在很大程度上，RESTful API、GraphQL API 或某种功能，它们非常容易创建模式。无论这些是运行在 Azure Functions 还是 Lambda 上，它们可能只是一些部署功能，而不是对函数核心代码的更改。我很好奇，因为我在 Azure 和 AWS 之外的编程不多，我想看看你是否可以写一个函数，拥有多个后台和多个部署路径，但它们本质上是相同的。我猜这应该会很容易。

Viktor Farcic：那关于调度器呢？我指的是，在 Kubernetes 方面，我看到 2017 年更多的是关于调度的内容。你认为这种情况已经结束了吗，还是我们将继续看到多个解决方案？现在，Kubernetes 是唯一的选择，还是仍然有 Swarm 和 Mesos 存在？

“你仍然需要相当多的基础设施知识来运行 Kubernetes，而调度不是一个简单的工具。”

—James Turnbull

James Turnbull：我认为这个问题很难回答，因为我认为市场还没有完全稳定。我喜欢 Kubernetes、Mesos 和类似 Nomad 这样的工具，但我猜对于绝大多数人来说，这些工具的抽象层级可能过高。你仍然需要相当多的基础设施知识来运行 Kubernetes，而调度不是一个简单的工具。我要说的是，我们距离可以把 Kubernetes 或其他任何编排工具看作是一个平台即服务的工具还很远，在那个时候，开发者可以像在 Heroku 上一样，将工作负载推送到一个黑盒子里，它就会自动工作。

我认为这将会发生，因为一些云服务商开始推出类似亚马逊、Azure 或 Google Kubernetes 服务的工具，如果你拿 Amazon 的 EC2 Fargate 产品来说，你不再管理实例，将其与 AKS（他们的 Kubernetes 产品）结合起来，突然之间，它就非常接近持续交付和集成模型，在这个模型中，我只需推送包含一些元数据的容器镜像，说明它们的数量，并可能与某些度量数据或其他内容连接以进行扩展或缩减，然后一切就绪。我认为这可能是我们未来的发展方向，但我认为我们离这成为一个对广大用户真正有用的工具还有一段距离。

Viktor Farcic：你还有其他想讨论或评论的话题吗？

詹姆斯·特恩布尔：我认为目前有一个非常有趣的讨论，关于监控的定义。传统上，监控非常侧重于基础设施，通常会有一台机器在外面监控 CPU、内存和磁盘，可能还会监控一些事务和错误率。

然而今天，我们看到了两件事：一是我们看到更多框架导向的监控；例如，像谷歌的四个黄金信号或布伦丹·格雷格的 USE 方法——利用率、饱和度和错误率。其次，我们也看到了以可观测性为中心的东西，比如跟踪和端到端性能分析。我非常感兴趣的是，在未来几年里，这个领域会出现哪些新工具。

*克托·法尔奇：我觉得他们并没有跟上我们今天运行的服务量的增长。

詹姆斯·特恩布尔：我同意。我认为这是监控的一个方面，过去它总是有点被忽视，或者是在出现问题后才进行反应的事情。我相信我们现在开始看到这种做法稍微提前注入到开发过程中，所以监控、指标和暴露指标可以被健康检查消耗，而健康检查现在进行得更频繁，这样的话，看看到底会有什么工具和基础设施上的变化出现，将会非常有趣。

我认为很多人仍然使用遗留的 Nagios 安装，未来五年内看看到底是什么将取代它们，会很有趣。

*克托·法尔奇：你认为像 Prometheus 这样的工具已经在走向正确的方向了吗，还是我们将看到一些更为彻底的不同工具出现？

詹姆斯·特恩布尔：我认为 Prometheus 是一个令人兴奋的方向，适用于某些类型的服务，比如微服务、容器驱动的应用和 Kubernetes。

然而，我并不完全相信它在所有地方都适用。但话说回来，我认为没有任何工具是万能的灵丹妙药，所以我认为我们会看到 Prometheus 更多的应用。它有一个光明的未来。

我认为我们还会看到更多类似跟踪风格的工具。此外，我们还会看到第二波或第三波的 SaaS 工具。第一波工具比较简单，像探测工具，你连接到一个服务，如果它返回一个带有 200 退出代码的 HTTP 响应，那么它就是正常的，也许你会抽样一点数据确认它正在做正确的事情。然后在第二代和第三代工具中，出现了像 New Relic 和 Dynatrace 这样的应用性能管理（APM）工具。

“我认为我们会看到 Prometheus 更多的应用。它有一个光明的未来。”

—詹姆斯·特恩布尔

在下一波 SaaS 服务中，我们将看到一种组合，一种混合模式，结合了基础设施级监控、中间件应用级监控、性能级监控、事务级跟踪，然后再叠加一些业务级监控。我现在还不知道这些工具是什么，但我认为在这个领域肯定会有一些非常有趣的事情发生。

*克托·法尔西奇：既然我们谈到了 Prometheus，或许值得一提的是你写了一本关于它的书。我们可以在哪里购买这本书？

詹姆斯·特恩布尔：这本书叫做《Prometheus 监控》（prometheusbook.com），并且有一个折扣码TALKINGDEVOPS，读者可以享受 25%的折扣。

*克托·法尔西奇：我想我们都能同意，未来将会是一个令人着迷的领域。谢谢。

第十七章

6

第十八章：莉兹·凯奥

精益与敏捷教练及培训师

第十九章：介绍 Liz Keogh

作为敏捷联盟颁发的戈登·帕斯克奖得主，Liz Keogh 专注于 Cynefin 框架，并将敏捷在规模化中的应用置于背景中。Liz 接受软件交付中的各种风险，推动团队之间的协作和透明度。你可以在 Twitter 上关注她，用户名是@lunivore。

Viktor Farcic：我想先问一个问题，当我们说 DevOps 时，究竟指的是什么？另外，我也在想，能否简单谈一下 DevOps 与敏捷之间的关系，如果有的话。

DevOps 与敏捷的关系

Liz Keogh：DevOps 曾经是当你在*团队中做敏捷时的情形；那时，只有*型跨职能团队的开发人员直接为客户编写代码。客户会将需求交给 DevOps 团队；开发人员然后开发代码并交还给客户。现在，你有了更大的企业组织，其中运*是一个单独的部门，甚至可能在更大的集团内是一个独立的公司，但你仍然希望能够发布东西。我总是说 DevOps 是一个很好的开始。

“DevOps 曾经是当你在*团队中做敏捷开发时的情况；那时，只有*型跨职能团队的开发人员直接为客户编写代码。”

—Liz Keogh

敏捷通常从开发团队开始。你可能有一些业务分析人员、测试人员和开发人员一起编写代码，然后他们认为自己完成了工作。实际上他们还没有完成，因为他们还没有真正发布产品。运*是接下来的阶段。

你与客户的互动方式并没有什么变化，但如果你能做到可靠地将东西交付给客户，并从客户那里获得反馈，了解进展如何，那你就做得很好了。这是团队内部调整方向和实际改变你发布的内容之间的区别。我个人非常喜欢敏捷流畅度模型。

Viktor Farcic：这是否意味着敏捷某种程度上排除了运*，或者这就是为什么 DevOps 不是敏捷的原因？

Liz Keogh：我不太清楚到底发生了什么，只知道敏捷通常一直是一个以开发为中心的东西。Scrum 框架谈到了跨职能团队，但我猜这与企业的性质有关，我们总是把事情划分到这些水平切割的部门中，不论是在大型企业，还是一些拥有自己初创部门的*公司中。只要你进行划分，你就创建了一个开发和运*之间的鸿沟，需要去弥合这个差距。

当我在 ThoughtWorks 工作时，那是一个旨在革新软件设计、创建和交付的社区，我的 Linux 管理员技能是非常基础的，真的很基础。我实际上是从系统管理员做起的，但那是在 1998 年，主要是 Windows，所以并不需要什么高级技能。但现在，你看看为了发布产品所需的各种专业技能，以及让产品可*护、能够监控、能够备份和其他所有需要的技术，这些通常超出了我作为开发者的能力范围。

如今，你有 Puppet、Chef、Docker 和 Kubernetes；这些工具我从未接触过，因为它们是在我离开实际开发工作后才出现的。我现在只在做咨询工作时参与一些实际的开发，但你看看这些专业技能，真的是很诱人让人想说，“好吧，那是你们的部分——我们做我们的开发部分，然后交给你们，你们负责发布，那就太好了。”

当你真正看清楚使某些东西可靠、可*护，并且避免因为你作为开发者写的东西坏掉而让那些人凌晨 4 点接到电话时，你会发现有很多事情可以做来帮助彼此。运*可以和开发者谈论他们需要什么，开发者也可以与运*沟通他们将做些什么来帮助。那才是真正的 DevOps：成年人相互沟通并协作。

我曾和一些企业中的人交谈，他们说，“我做不了 DevOps，因为运*是一个独立的部门。”但如果你在生产环境中报告了一个 bug，你所需要做的就是在 bug 报告上写上你的名字，这样你就做得很好：你就进入了运*部门。

如果你是开发者，你只需要说，“嘿，如果你在这段代码中遇到问题，来找我谈谈——不要只是写报告，我们在这里，为什么不来找团队谈谈，我们帮你解决？”这就是对发布软件的态度。这才是真正的 DevOps：态度的转变和关系的建立。

“这才是真正的 DevOps：态度的转变和关系的建立。”

—Liz Keogh

Viktor Farcic: 这是一个绝妙的观点。就好像你回到过去，把“Ops”一词换成了“我们用敏捷方法解决问题的测试员”。那些人彼此不沟通，他们生活在不同的部门里。

Liz Keogh: 正是如此！

Viktor Farcic: 我经常听你谈到 Cynefin 框架。你能解释一下它是什么吗？

Cynefin 框架

丽兹·基奥：Cynefin 框架非常注重理解不同的情境以及你如何应对它们。出于这个原因，它被称为“感知装置”。你可以这样想：有五个有序的领域——简单（或显而易见）、复杂、复杂、混乱和无序。它们之间的边界是模糊的。在简单或显而易见的领域，问题很容易解决，因为解决方案显而易见且容易分类。

假设你是酒吧里的女房东。我问她：“啤酒用完了怎么办？”她回答说：“嗯，我当然是换桶。”

当问题进入复杂领域时，它们需要专业知识。一个钟表匠可以修理你的手表，一个汽车修理工可以修理你的汽车，这很好——这两者都有可预测的结果。在复杂领域中，只有当你具备相关的专业知识时，问题才能被分析和解决。

问题在于人类渴望确定性。我们想要可预测性。我们喜欢知道接下来会发生什么。在我们所有的进化经历中，不可预测的事情通常意味着灾难，那是混乱的，这在 Cynefin 框架中把我们置于混乱领域。混乱是事故和紧急情况，是你的房子着火了，是人们在流血至死。混乱是一个暂时性的领域，这意味着它会迅速自我解决。它不喜欢长时间停留在那里，但不幸的是，它可能不会以对你有利的方式解决。混乱也是紧急机会的领域，但它通常是一个非常糟糕的地方，这就是问题所在，因为有一堆事情既不可预测，也不混乱。而这就是许多软件开发发生的复杂领域。

我们必须允许事物自然发展。当我们回顾过去时，我们知道我们已经达到了什么。这被称为“事后相关性”。你可以看到你达到了哪里，但你不可能预测结果。任何与业务合作、获取反馈并改变方向的敏捷项目工作者，都在某种程度上有这种经验。举个例子，你在一个高度不确定的环境中工作。你在做产品开发或创造新产品。比如，丰田经常做的一件事是并行的基于集的工程。他们会同时尝试三种不同类型的发动机，从中他们会找出他们想为新车定型的发动机方面。复杂性思考者，或特别是 Cynefin 思考者，将这些称为“平行探针”。

*克托·法尔奇奇：你能解释一下什么是探针以及它如何与 DevOps 相关吗？我的意思是，这如何融入我们今天所处的世界？

Liz Keogh：探测器是一种可以安全失败的东西。随着你变得越来越创新，你所做的事情中的不确定性也会越来越大。你的变化增多，犯错的机会也随之增大。不过你一定会做出一些发现，尽管这些发现不再发生在团队的安全环境中。许多这样的发现将在生产环境中发生，你无法避免，因为事情是如此新颖和不可预测。

“我认为 DevOps 对于创新，特别是在大规模应用上，绝对是必要的。”

—Liz Keogh

然后你需要能够非常非常快速地改变方向，而这正是我在 DevOps 中关注的地方。很多人把 DevOps 看作是通向可预测性的道路，而不是一个允许你做出不可预测、高度探索性工作的安全网。我认为 DevOps 对于创新是绝对必要的，尤其是在大规模时。

你需要拥有那些自动化测试，比如探测器，不仅仅因为它们能捕捉到问题，更因为它们提供了活文档并且保持代码易于更改。可能更重要的是，你需要有监控机制到位；你真的需要与运*建立良好的关系，这样当那些发现发生时，当生产环境中出现 bug，当某些东西出错时，你能够迅速发现并回滚。这就是凤凰服务器的概念，你可以将这些 bug 释放到一台服务器上，看看情况如何，如果不起作用，你就丢弃这台服务器。这就是现在世界的发展趋势，我们实际上可以“玩”并看到外面发生了什么。我们*时候习惯在安全的地方玩耍；这是我们学习的方式。现在我们就像是在生产环境的游乐场里玩耍，但仍然很重要的是，那里需要是一个可以失败的安全空间。这就是我如此热爱 DevOps 的原因。

“在那里安全地失败仍然很重要。这就是我如此热爱 DevOps 的原因。”

—Liz Keogh

Viktor Farcic：DevOps 某种程度上让你能够快速部署到生产环境并快速失败。实际上，你是在生产环境中验证，而不是在测试环境中。

Liz Keogh：问题是，必须在做到正确与允许犯错之间找到平衡。我总是说，如果某件事是你可以合理预测的，那么你应该尽量做到正确。举个例子，你应该使用类似生产环境的环境，并用类似生产的数据来运行你的测试。

除非你真的有完全相同的客户群、数据和软件环境，否则你是无法做到每件事都如此的，而这几乎是不可能的；你最终会在生产环境中测试某些东西。没有办法绕过这一点，所以你必须有非常好的机制来及时发现问题。

Viktor Farcic：如果我们遵循相同的逻辑，你也必须拥有完全相同的用户群，不是吗？

Liz Keogh：完全正确！

行为驱动开发（BDD）

Viktor Farcic：你对行为驱动开发（BDD）很感兴趣。你能向我们解释一下，对于那些可能不了解的人，它是什么吗？

Liz Keogh：BDD 出现是作为测试驱动开发（TDD）的替代。TDD 并不真正关于测试，因为任何做过 TDD 的人都会说，在甚至还没有任何代码之前，你就已经编写了测试。本质上，你并不真正测试任何东西；你在描述你将要编写的代码如何工作，为什么它对你有价值，并提出了一些你想要使用它的方式的示例。

当我们开始把它们视为行为的示例时，那就是类级行为。你会说：“这是我的类如何行为的一个例子。”但是然后你有了你的系统：“这是我的系统如何行为的一个例子，这是我应用程序使用的一个例子”，我们称之为场景。原理是一样的。你拿出你的场景，现在你有了你认为你的系统将如何工作的一个例子。

当事情是可预测的时候，它们需要专业知识，并围绕这些场景进行对话是一个非常好的方法，这样你可以自己获取专业知识，并掌握人们希望使用的语言，这就是我们称之为普遍语言的东西。当事情真的不确定时，这些场景提供了我们所说的一致性，因此有一个现实的理由认为你即将做的事情是一个好主意。你可能会发现，这个例子并不完全符合你的想法，或者客户并不完全想以这种方式使用它，然后你将不得不改变你的场景。你越是不确定，你就越需要进行探索性对话，而自动化的重要性就越*，因为自动化是一种承诺，如果你致力于那些正在变化的事物，那么这是一种过度投资。

你希望在你认为自己已经对要解决的问题有了很好的理解之前，尽可能少地做承诺，然后当你理解了问题，你可以开始编写这些场景，自动化它们，并试图猜测你认为解决方案应该是什么样子。但有时候需要通过实践学习，你实际上必须尝试一些东西，然后你才能理解它。

与我开始软件开发时相比，现在的开发中有很多试验和原型制作。

Viktor Farcic：我猜你开始是用瀑布模型。你能告诉我们你的经验吗？

"与我开始软件开发时相比，现在的开发中有很多试验和原型制作。"

—Liz Keogh

Liz Keogh：是的，当我刚开始时，我参与了一个瀑布项目，我们有三年的开发周期，我相信在那之前还有一年半的分析周期。我在地下室待了三年，做这个项目，在这三年里我们根本没有发布任何东西，但现在我们能够发布了。Diana Larsen 和 James Shore——敏捷流畅度模型的背后人物——称之为“按需发布”。在这个模型中，如果你把这些东西做对了，你就能在你想要的时候发布，这意味着你可以非常快速地改变方向。这也意味着快速试探和原型开发可能比以前更重要，而自动化实际上变得不那么重要，尽管你进行的对话依然非常重要。

关于这些场景的讨论——关于你认为这对人们有什么帮助、他们可能如何使用它、需要考虑哪些其他利益相关者，以及它如何为他们工作，我们需要什么其他结果，以及哪些上下文在范围内或不在范围内——这些讨论依然非常关键，同时也非常轻量化。它们并不会占用太多时间。

我总是建议先从对话开始，只有在你非常擅长进行这些对话时才转向工具。在你仍在开发一个*的代码库时，改造场景大约需要一个月的时间；显然，这并不是一个月的全职工作。如果你从工具开始，放下它们，然后进行一些对话，一旦你围绕场景进行了这些对话，你会回头时对问题有更好的理解。

Viktor Farcic：如果我们邀请运*参与进来，是否意味着 BDD 也在朝这个方向扩展呢？

Liz Keogh：有一点，但你仍然需要通过他们想要的东西来讨论一些示例。通常，他们的示例会集中在监控上；例如，“如果我们遇到像这样的 bug，我们应该怎么做？”这些会是你如何利用这种关系的示例。

我经历过的最好的讨论，不是关于软件应该是什么样子的，而是我们作为团队如何合作，快速解决软件发布后可能出现的任何问题。我真正喜欢的是人的因素。这就是复杂性问题——Cynefin 框架——真正发挥作用的地方，因为人类系统是我们所说的复杂自适应系统。它们是这样的系统，系统中的个体可以改变系统本身。

虽然你可能能通过观察软件的行为，认为“好吧，这是相对可预测的”，但一旦你有两组人一起工作，你就需要更加宽容，并且更加关注这种关系的构建，关注它的发展，哪些方面没有起作用，以及如何修复那些不起作用的地方。

我真的很喜欢当对话和情境从软件如何表现转到我们作为人类如何表现时。话虽如此，如果你在监控方面做得很仔细，你会有一些例子，告诉你在什么阈值下会触发你的监控，并且你可以提出问题，询问它将如何表现：“你会给我发邮件，还是我会收到我的呼叫器通知？”你也可以进行这样的对话，但 BDD 并不是开发软件的唯一方式，当然也不是唯一的测试方式。有许多优秀的测试实践与 BDD 完全无关。当人们把测试和 BDD 视为同义词时，他们错过了测试人员所做的所有其他事情。

我喜欢我的测试人员，因为他们让我在失败时感到安全。我认为人类的天性就是选择一件事然后坚持下去。例如，我采用了 BDD，曾经只关注 BDD，别无其他。几乎所有其他事情也都发生了同样的情况；今天，一切都需要是一个容器。

*克托·法尔奇奇：那么敏捷与 DevOps 之间的关系呢？你对此有什么看法？DevOps 会替代敏捷吗？它是互补的，还是相互冲突的？

莉兹·凯欧：敏捷只是一个帮助人们查找不同实践、知识、经验、故事的锚点，帮助找到一个社区。它们都是相互关联的。

DevOps 是其中的一部分吗？它绝对与之相关，如果你有一个跨职能的团队，那是的，绝对相关。我是一个狂热的看板（Kanban）爱好者，当我们做看板时，我们从现在此刻的状态开始。我有些人在做大瀑布项目的测试阶段做看板，所以你不再需要跨职能的团队了，且这样做的优势是你可以从你所在的任何地方开始。你不需要重组组织结构，也不必担心管理线，你只需要开始改进。

你开始改进的方式是看看价值流，看看有哪些部分可以改进。一个显而易见的大问题就是开发和运*要合作。你的开发团队，可能是跨职能的，然后是你的运*团队。你希望他们合作得更好，交接更顺畅；这是理想的情况。即使他们是一个独立的组织，或者是完全不同的部门，并且拥有不同的管理线或不同的 KPI，他们仍然可以合作。

"你开始改进的方式是看看价值流，看看有哪些部分可以改进。一个显而易见的大问题就是开发和运*要合作。"

—莉兹·凯欧

使用敏捷或 DevOps 进行咨询

*克托·法尔奇奇：当你为采用敏捷或 DevOps 的公司提供咨询时，你有一种规范性的做法吗？例如，你必须做 Scrum！

Liz Keogh：你必须学习 Cynefin，因为这几乎是我教的第一件事。之后，如果你想从 Scrum 开始，那就开始吧。我认为 Scrum 是一个很好的入门方式，特别是对于一个新项目，如果你还没有任何现成的工作内容。

通常，大型组织已经做了大量的分析工作。我们经常讨论如果我们能拥有灵活的范围该有多好，但大多数组织已经做了三个月的用户体验研究和分析，而这些分析往往限制了我们的选择。那么，让我们从垂直方向切分，先弄清楚最重要的部分，优先交付这些——哪些部分风险较大，哪些部分不确定性最高，哪些是新东西？

让我们先做这些，并尽早做。让我们先试探一下，看看效果如何，然后再看看实际需要做什么才能发布这个功能。我们还需要做些什么才能让这个你真的感兴趣的新东西上线，但同时，我们可以用最*的方式来交付它吗？

有人在 Twitter 上问是否有更合适的术语来替代最*可行产品（MVP），我告诉他们，它意味着不*于你可以交付的最*功能，因为我还没有遇到过足够有攻击性的人，能真正快速交付有价值的东西。你可以交付非常*的功能并从中学习很多，或者至少能把它们弄成一个你可以轻松点击按钮就发布的状态。我曾听到有人说，“哦，但是你知道，我们不被允许在生产环境中更改数据库。”好吧，那就改变你自己的环境中的数据库，然后把脚本提供给运营团队。

有一些管理的方法，也有运营所需要的东西：有些地方是他们正在遭遇困境的。我和一个团队沟通过，他们一直工作到凌晨四点，修复错误，试图找出系统崩溃的原因，并且拼命地想发布新版本。当五个团队都在尝试同时发布时，这些可怜的人肯定不开心。我们可以做很多事情让他们作为开发者更开心，我只希望看到我们伸出援手，问一句：“嘿，怎样才能避免你们再被叫醒到凌晨四点？”

有些人非常喜欢给实际的开发者发警报器，让他们在凌晨四点被叫醒——我自己没有凌晨四点处理问题的经验，根本不知道从哪里开始，但如果能聊一聊需要做什么，才能避免凌晨四点叫醒人，以及你能做什么来帮助他们——那将会是很好的。

Viktor Farcic：确实。根据你到目前为止所说的内容，似乎你更加强调转变或改善人和文化，而不是依赖工具。

Liz Keogh：这是关于交付软件的，事实证明，关注人是实现这一目标的最佳方式。我不希望人们觉得我说的都是空话；我并不是为了人而关注人。

“这是关于交付软件的，事实证明，专注于人是做这件事的最佳方式。”

—Liz Keogh

当我与企业和组织交谈时，我的重点是交付，而让人们协作是交付的一部分。事实证明，所有你认为能创造一个非常棒的工作环境——那些激励人们并使工作变得有趣的东西——也是有助于交付的东西。如果你专注于交付，你最终会为人们做正确的事。你可以把它当作一个很好的测试；如果你发现自己通过对人们大喊大叫来推动工作进展，那么你的流程可能就有问题。

Viktor Farcic：当你尝试帮助组织改进时，你是如何预测它们的行为的？

Liz Keogh：有些事情会遭到激烈反抗。当这种情况发生时，不要担心，尝试其他方法。总会有一些事情是你可以改变的，如果你找到那些你能改变的东西——这正是 Cynefin 的核心，也是探索真正含义的关键——集中精力去做，并且找出那些能够帮助你实施变革的人。不要为那些不在你控制范围内的事情担忧。

如果你找到一个人在项目中成功实现了 BDD，那么你就知道组织支持 BDD。如果你发现那个人还成功地与运营部门的人进行了对话，你可以让这两个人一起做一个关于他们共同学习内容的演讲。任何你发现能够推动积极变化的东西，都要支持它，放大它，抓住它，给予足够重视，因为每一点积极的变化都为其他地方的积极变化赢得了一些空间，直到有一天，你发现那些曾经抵触的部分不再存在，大家都在使用云技术，而你甚至不知道它是怎么发生的。

我现在大部分时间作为顾问，都在四处游走，一边感叹“哇，真棒”，一边问怎么做得更多，怎么做得更大，怎么把这种做法推广到其他地方，同时传播这些好故事。

Viktor Farcic：是否有某些类型的专业知识、专家或部门更具防御性，或者其他一些更容易合作，还是你觉得无论在哪里，它们基本上都是在同一层面上？

Liz Keogh：这取决于组织。每个组织都有自己的部落。如果你读过 Ray Immelman 的《Great Boss Dead Boss》，你会了解到部落行为与组织的关系。我发现这完全是对的，在任何你看到部落受到威胁的地方，那些部落的边界都会被强化。

我曾遇到过一次后端开发人员开始学习做一些 UI 工作，而 UI 开发人员加强了他们的边界。事实上，我已经在三个不同的地方看到过 UI 开发人员加强自己*部落边界的情况。对我来说，在 ThoughtWorks 这会完全是不可思议的，因为我曾是一个前端开发人员，做 Swing 和桌面应用程序。我只做过一点点 Web 开发，但我知道如何编写一些 HTML、CSS 和基本的 JavaScript。

我可以纠正一个拼写错误并更改颜色，但觉得这是别人领域的事情对我来说真的很奇怪。但是当你发现人们感到威胁，并且觉得他们的专业知识被贬低时，他们就会加强自己*部落的边界，突然间你会听到，“UI 开发人员比后端开发人员更厉害”，这时组织内部就出现了裂痕。诀窍是让你的内部团队感到被重视和安全。

你希望开发和运*都能觉得他们可以合作，因为他们都是技术娴熟的专业人员，且都有深厚的经验。通过 DevOps，你所做的就是连接这两个群体；你不是把它们拆开，也不是将所有人都扔进跨职能团队，因为每个团队都必须有一个运*人员。这也是为什么我认为在某些情况下，特别是在处理企业时，Kanban 比 Scrum 更有效的原因之一。你需要尊重并关注这些团队；你不希望整个组织感到被威胁。

这就是约翰·科特尔（John Kotter）提出的紧迫感真正发挥作用的地方。在他的演讲中，科特尔讨论了围绕竞争对手建立紧迫感的必要性。他谈到与亚马逊、谷歌或 Facebook 竞争有多么困难。他还讨论了你的威胁并不来自组织内部，而是外部。你希望的是组织内部的每个人都能团结起来应对外部威胁，而不是彼此对立。

“你希望开发和运*都能觉得他们可以合作，因为他们都是技术娴熟的专业人员，且都有深厚的经验。通过 DevOps，你所做的就是连接这两个群体；你不是把它们拆开。”

—Liz Keogh

Viktor Farcic：我喜欢这个。我可能记错了，但我记得曾听你说过，交付不仅仅是开发和运*。你是什么意思？

Liz Keogh：当我在企业环境中看一个端到端的价值流时，我通常会说，“好吧，让我们把开发团队放在中间。”

客户有需求，或者可能是某个客户代表有一个想法，知道如何帮助他们，或者也可能是某个利益相关者有某种需求，这些人将成为开发团队和他们之间的障碍。他们能直接去找开发团队，说：“嘿，你能为我做这个吗？”可能不能，因为会有某种优先级排序的限制。

我曾为一些公司工作过，在那里你浪费了宝贵的时间跳过各种部门之间的障碍，不是为了获得资金，就是为了让项目启动，或者是推进到下一个阶段。你需要在等待各种董事会审批的同时，组织开发团队。六个月过去，开发人员甚至还没机会接触到代码，而接下来的情况通常是这样的——这正是敏捷方法中我们经常看到的——等我们接手项目时，之前的所有工作已经完成。

现实情况是，有各种各样的人介于你的开发团队和真正发布某个东西之间。如果你所在的公司信任度较低，且不太习惯从 IT 部门获得所需，那你可能还会有一个用户验收测试组，准备对你的软件进行严格的测试。

作为顾问，我通常会在白板上画出这个图，我会说价值流是由人组成的。我会标出所有参与将某个东西推向上线的不同团队，然后我会让带我进来的那个人画出他们影响范围的虚线。

Viktor Farcic：让人们参与进来似乎是让组织意识到问题的好方法，但将其实施到多个团队之间，并让他们真正进行改变，显然需要很长时间。

Liz Keogh：我通常发现，如果我被引入到 DevOps 中，情况往往没有延伸到运*层面。还有一些其他团队，DevOps 的范围也没能触及，通常运*是由大约 10 个不同的团队组成，而这些团队之间并不交流。会有一个团队负责渗透测试，另一个团队负责监控，再有一个负责分析，甚至还有一个团队负责支持。

你最终会成为那些将各个团队汇聚在一起的人，所以，开发和运*：一个很好的开始。如果你能让这些团队合作，你会发现你的项目组合和治理需求也需要被解决。

现在你还会开始发现你的资金模型，然后最终你会让业务部门参与进来，业务部门会说：“等等——如果我们现在做这些*事，可以做这个实验吗？我们能做这件*事吗？”

然后你就在进行创新，这也是大型组织要花几年时间才能达到的一个点。我认为有时，当人们引入像敏捷框架（Scaled Agile Framework）和大规模 Scrum 等方法，并将其强加到组织中，重构一切时，一生的习惯依然存在，讲述的故事仍然是相同的故事。你不能仅通过重构来改变故事；你通过建立良好的关系来改变故事。是的，开发与运*（Dev 和 Ops）是一个良好的开始，但它仅仅是一个开始。

“良好的 DevOps 文化让失败变得安全。”

—莉兹·凯奥

*克托·法尔奇：你提到了创新。你是如何促进创新的呢？每当我拜访公司时，我总是听到相同的回答：“我们想做这个，我们想尝试那个，但我们没有时间。”

培养创新

莉兹·凯奥：你可以做几件事：首先是确保事情在失败时是安全的。如果不允许失败，那么没人会去尝试可能会失败的事情，因此 DevOps，至少是良好的 DevOps 文化，使得失败是可以接受的。如果你无法实现创新，那就专注于如何确保失败是安全的，如何确保生产中的高质量，如何确保能把能做到的事情做到正确，然后确保犯错是可以接受的。

你可以专注于持续交付，然后是持续部署，这样很好——让你的凤凰服务器上线。然后还有其他可以做的事情。有一个叫做浅尝混乱的做法，这是 Cognitive Edge 在其 Cynefin 培训中教授的内容。它涉及将人们分开，这样就能产生不同的观点，这种做法，就像混乱一样，创造了一个紧迫的机会，但同时也是一个没有什么可失去的地方。当你不能与别人交流时，你自己产生的想法往往比你和别人一起想出来的更疯狂。当人们处于团队中时，他们更倾向于寻求共识。实际上，我花了一些时间打破共识文化。

你需要让失败变得安全，然后创建一个宽容的系统，在这个系统中，你有尝试的权限。你可以通过让人们自己尝试或者在非常*的团队中尝试来做到这一点，这样即使有一些返工和重复工作也无所谓。通常，延迟的成本远大于返工的成本，我认为很多人没有意识到这一点。人们没有看到，如果不等所有人达成共识，实际上他们能多么迅速地行动。因此，你需要让做错事也变得可以接受。

*克托·法尔奇：在这种情况下，有没有人给你留下深刻印象，说他们认为做错事是可以接受的？

Liz Keogh：Chris Matts 做到了。他发起了“实物期权”运动，他是我在实物期权方面的导师。他说，如果你面对两种不同的情况，并且不确定哪一个是正确的，那与其做大量无效的复杂分析，不如选择那个最容易改变的。如果发现它是错误的，你可以改变它。但如果发现它是正确的，那就太好了。

这就是那种思*方式。它是关于我们如何前进，而不需要去问组织中所有其他人的意见，去了解他们认为正确的做法。再次强调，一旦你开始这样做，当人们意识到这是安全的，并且你开始支持他们，并且你开始到处说：“哇，这太棒了”，其他人也会想尝试一些事情，你就开始建立一种文化，让人们愿意尝试新事物，并做出正确的决策。

Viktor Farcic：如果我理解得对，交付是团队的努力，而创新更多是个人的努力？

Liz Keogh：提出创意无疑是个人或*团队的工作。实际上，Jabe Bloom 有一场精彩的演讲，名为《社会资本的价值》，他提到了 Ronald S. Burt 的结构性空洞。人们没有联系的空洞正是创新的源泉。每个人都过于紧密地连接，造成了巨大的稳定性，但你无法尝试新的事物，所以你必须打破这种状态——例如，让各个独立的开发*组去尝试一些新的事物。如果你想迁移到 Git，不要作为一个组织统一决定迁移到 Git；让一个*团队先尝试，他们可以告诉你是否值得这么做。

如果你想尝试某个特定的 BDD 工具，可以让两个团队分别尝试两个不同的工具。你可能最终需要重写其中一个，或者使用两个不同的工具，直到其中一个被淘汰，但这总比什么都不做要好，也比花六个月时间进行分析来判断是否可行要好。相反，你是通过实践来学习的。所以，做点事吧。培养这种文化就是促进创新的方式。

Viktor Farcic：我们已经讨论了很多关于包含不同人群并促进合作的内容，所以我想问你，为什么这个领域里女性这么少？

DevOps 中的多样性、性别角色和代表性

Liz Keogh：你知道的，我不是适合回答这个问题的人。每次有人问我，团队中有女性和没有女性的团队有什么区别时，我都会说我不知道，因为我从来没有加入过没有女性的团队。我不是专家；作为女性并不意味着我能成为开发领域中“女性”的专家——我根本无法告诉你。我知道的是，没有人告诉我我不应该在这里。

我七岁时开始编程，因为我爸爸把 BBC 电脑放在那儿，旁边有一本手册，里面插图是一些美丽的彩色机器人。这是专门为孩子们设计的。所以，我算是很早就接触了编程。几乎从我记事起，我身边就有电脑，我想也许这就是秘密所在：确保在学校里支持女生，并确保她们也有榜样。这是我学到的一点。

我一直讨厌被当作“女性代表”。每个人都说他们希望有更多女性讲者。但我对这个的回应是：“你为什么不请我，因为我真的很擅长谈论 DevOps 和 Cynefin 之类的东西？但是不，你们想要的是一位女性讲者。”我花了很长时间才意识到，拥有一个女性榜样对女孩们，尤其是对进入这个行业的年轻女性来说，确实很重要。然而，我有点不情愿地接受了这一点，因为我并不想成为质量和性别多样性的讲者。

“你为什么不请我，因为我真的很擅长谈论 DevOps 和 Cynefin 之类的东西？但是不，你们想要的是一位女性讲者。我花了很长时间才意识到，拥有一个女性榜样对女孩们，尤其是对进入这个行业的年轻女性来说，确实很重要。”

—Liz Keogh

我想成为 Cynefin 和 BDD 的讲者，但有时性别多样性问题、性别歧视和性骚扰成了问题，因为这些都会成为障碍。所以，我也得成为这些问题的讲者。但这并不是我想谈论的内容。我的热情是交付软件，而且是作为一名女性来做，但这也意味着我不得不谈论这些其他问题。

自学工程师与今天的受教育工程师之间的区别

Viktor Farcic：换个话题，你提到你七岁时就开始接触电脑。你对今天的自学工程师和受教育工程师之间的区别有什么看法？更广泛地说，你如何看待当今世界的教育？

Liz Keogh：我不知道自己不知道什么。那时，我比一个黑客更有纪律性。我在编程方面的思*相当有条理，所以我学会了如何测试我的软件，我很快意识到，如果我在后期写测试，我会产生怀疑。最开始，我是围绕空接口写测试，只是让它们能编译，当然，这现在很像 TDD。当我开始职业编程时，没有 IDE。我们都在用我们能找到的文本编辑器。我记得是 Vi 或者 Emacs 之类的，然后通过命令行编译。

IDE（集成开发环境）那时候还不存在，我不知道什么是设计模式，也完全不懂领域驱动设计。我不知道有社区可以学习这些东西，那时候互联网还处于初级阶段。我是在 1998 年毕业的，所以互联网还在起步阶段；公司们都没有域名，也没有网址。

Viktor Farcic：但过去 20 年这一切都发生了变化——互联网爆炸式发展。

Liz Keogh：没错。现在互联网无所不包，你可以获取到更多的信息，了解更多优秀编程实践的内容。我有一些朋友在学术界工作，他们在学术工作中也会编程，但总体来说，他们仍然没有跟上现代编程的步伐。他们没有学习 TDD（测试驱动开发）或 BDD（行为驱动开发），也没有接触到 DevOps（开发与运*）。不过，他们知道这些东西的存在。你只需要主动联系，因为总有愿意帮助你的人。

比如，Stack Overflow 和 Stack Exchange 网络非常棒，这不仅仅适用于开发人员和运*人员，或者 Dev 和 Ops，它对任何处于领导岗位的人都适用。这里有 PM Stack Exchange，你可以在这些地方学习心理学。*基百科非常棒，因为上面有大量免费的信息。我以前在上学时必须去图书馆借书，但现在你不再需要这么做了。你可以随时接触到整个人类的知识，所需的只是找出你不知道的东西，和你希望了解的那些，因为有比你一生能学到的还要多的东西。

Viktor Farcic：你怎么知道自己不知道什么呢？我认为这可能是问题所在，因为如果我从未听说过 BDD，我怎么知道我不知道它呢？我是在举例子。

“你可以随时接触到整个人类的知识，所需的只是找出你不知道的东西，和你希望了解的那些，因为有比你一生能学到的还要多的东西。”

—Liz Keogh

Liz Keogh：你找到一个在你想要从事的领域工作的人，然后问他们：“我不知道什么？你会从哪里开始？”如果你在一个新地方工作，且没有专家的帮助，你就通过实践来学习。我几乎是 BDD 的早期参与者之一，我参与了 JBehave 的故事，它是第一个英文的系统级 BDD 自然语言工具。我们是通过尝试来学习的。JBehave 1.0 是不可用的，没人使用它。

我最近在推特上分享了 David Chelimsky 的一篇博客，他在文中将 Ruby 版的 JBehave（作为 RSpec Story Runner 编写）转化为了纯文本。这显然是 Cucumber、JBehave 2 以及所有后续英语工具的前身。在这种情况下，你通过实践来学习，犯错是可以的。创造一些没人使用的东西也没关系，因为它可能会引导出一些人们真正会使用的东西。

Viktor Farcic：最后，我要问你一个我最讨厌被问到的问题。你对未来有什么看法？

未来

Liz Keogh：火星。我想去火星。我非常希望看到人类在火星上生存，我知道 Elon Musk 仍在追逐这个目标。

那么，我认为我们将会看到什么呢？我认为我们会看到更多的汽车进入太空，更多的大规模实验在安全的环境下进行。我觉得未来会非常激动人心。我认为公司将会更加对自己的伦理负责，这意味着不会再有像 Uber 那样的行为，也不会再有大众排放丑闻。话虽如此，我希望看到组织的透明度。我认为我们会看到一些大型银行的消亡，真心觉得当银行消亡时，合并现象会开始出现。

我看到一些大企业中的浪费现象，实在无法理解有钱的人怎么支持这种程度的浪费。资本主义会导致这些事情的融合，我真的非常希望这一切能够朝着好的方向发展。我认为，或许在一个好的方向上是有空间的，去让投资更透明，让这个世界变得更好。我认为，在接下来的五年内，我们可能会看到一次经济危机，因为财富过于集中，且这种集中程度让人类社会无法接受。

在过去的一年里，我还看了气候变化方面的 IPCC 报告。这个话题没有那么令人兴奋，但却更为紧迫。所以现在，我的重点就在于此。我仍然希望公司们能够挺身而出应对这个问题；我也希望我们会看到一些新兴的技术，能够为此提供帮助。这将会很艰难，但我们从自己的角度能做的事情还是很多的。

Viktor Farcic：那么，你认为未来几年会有大规模的爆发吗？

Liz Keogh：我认为，当你有紧迫感时，就会有混乱。它为创新提供了大量空间，也为尝试新事物提供了大量空间，因为你没有什么可失去的。

我感觉在接下来的 10 年里，我们将看到一些非常令人兴奋的事物。我们有区块链，许多新工具正在进入市场，我们有出色的 DevOps 实践，并且有一个完整的开源生态系统，这是我开始编程时没有的。Java 是免费的，仅此而已。我已经在 IT 行业工作了 20 年，已经见证了许多变化。我认为接下来的 20 年将会比这还要大。在另外 20 年后，我认为这个世界将无法与我 20 年前所知道的世界相提并论。

Viktor Farcic：你认为传统的、缓慢的、僵化的企业能够在那个未来中生存下来吗？

“在另外 20 年后，我认为这个世界将无法与我 20 年前所知道的世界相提并论。”

——Liz Keogh

Liz Keogh：他们会在那些商品化的、无聊且非常可预测的事情中生存下来，但就像人们提供电力和水一样——这类事情将不会赚到很多钱。Simon Wardley 在他的映射中提到这一点；一切都会朝着右边发展。你在 Cynefin 中也看到了这一点，一切都会顺时针旋转。它变得稳定，然后你在稳定的基础上构建。所有的东西都将稳定化，所以我们现在看到的那些创新的东西——我们认为 DevOps 是创新的——它将成为软件开发的常态。人们会问，“为什么要用其他方式做呢？”

你将能够即插即用 DevOps；你将拥有非常便宜的 Google 服务器，那么为什么不使用它们呢？没有人会有自己的基础设施。如果你建立了自己的基础设施，而你又没有和 Google、Facebook 或其他大型公司合作，人们会问，“你在做什么？你真的在手动配置服务器吗？为什么要这样做？”那时会是这种疯狂的程度。虽然我们现在还没到那个程度，但我们会到达的。

Viktor Farcic：我可能比这更怀疑一些，因为我有种感觉，每当我去拜访企业时，他们的回答通常是“我们都在做敏捷”，然后你和他们待一天，你会意识到，他们其实才刚刚开始做敏捷。

Liz Keogh：尽量不要使用“敏捷”这个词。在我做咨询时，我不使用“敏捷”这个词；我专注于交付，讨论不确定性、可预测性以及类似的事情。我专注于令人惊叹的东西。

当你看到某些东西正在变化——当你看到一些真正了不起的事情——专注于它，传播它，讲述故事。鼓励其他人讲述故事，因为故事有力量，是推动变革的非常有效的方式。

Viktor Farcic：还有什么是你想分享的吗？

Liz Keogh：曾经有人问我，工作在软件开发领域中，最喜欢和最讨厌的是什么。我说最讨厌的是人类倾向于在不确定性中看到不存在的模式，然后继续前进，结果做错事情。而最喜欢的则是人类能够在不确定性中看到不存在的模式，从而推动前进。这两者是相辅相成的。所以，那些让我们跌倒的东西，也是让我们能够前进的东西，我觉得值得庆祝这一点。

第二十章

7

第二十一章：朱利安·辛普森

Fuel50 全球安全与平台经理

第二十二章：介绍朱利安·辛普森

朱利安·辛普森曾在 Neo4j 工作直到 2018 年 8 月，在那里他帮助交付了涉及 DevOps 和持续交付的项目。2018 年 8 月，朱利安转到 Fuel50，成为全球安全与平台经理，专注于构建公司的平台。朱利安还是 DevOpsDaysNZ 的组织者。你可以在 Twitter 上关注他，用户名是 @builddoctor。

定义 DevOps

*克托·法尔奇：我想从一个双重问题开始问你。首先，你如何定义 DevOps？然后，这一定义在你的职业生涯中是如何体现的？

朱利安·辛普森：我曾是一个 Unix 系统管理员。在那个角色中，我花了很多时间在互联网泡沫时期构建 Solaris 服务器，并与开发人员争论。这种系统管理员和开发人员之间的冲突持续了我职业生涯的接下来的三到四年。

在这段时间里，有两件事对我来说变得显而易见。首先，手动构建系统的方式似乎是错误的，其次，处理这种冲突似乎确实适得其反。虽然我可以陷入一场好的争斗，但这似乎不是一种积极的方式。最终，在 2002 年，我发现了 CFEngine 项目，并开始使用 CFEngine 来构建我的所有系统，以便重建这些构建。

这与 Solaris Jumpstart 相结合，这在当时是一个非常棒的技术，因为从硬件角度来看，我可以随时构建一台机器。我还可以对构建进行迭代，并将源代码存储在版本控制中，这些做法最终发展为 DevOps。一个重要的补充是，我在 2004 年发现了敏捷运动；我认为 DevOps 运动作为敏捷运动的自然延伸发展而来。

“我认为 DevOps 运动作为一种自然的发展，源自于敏捷运动。”

—朱利安·辛普森

*克托·法尔奇：这也是我通常的描述方式。虽然我同意 DevOps 是敏捷的演变，但你所描述的冲突是我今天在开发人员、QA、安全人员和其他所有相关人员之间看到的现象。你认为这些冲突的原因是什么？

朱利安·辛普森：我认为这完全是组织内结构性冲突的问题。对我来说，作为一个行业，组织设置有冲突目标的团队，然后期望他们像解决个人问题一样解决这些冲突，简直令人难以置信。你负责确保系统的安全、正常运行并保持可用，而你的工作就是尽可能快地交付它。

我不知道这是不是仅仅是民间智慧，还是我们可以依赖的实际研究，但似乎有很多团队专门以非常快的速度交付错误的东西，而这往往是以牺牲安全性或可用性为代价的。如果这些因素让你感到焦虑，那么实际上，团队一起讨论项目中需要交付的功能，并激励整个团队确保安全地交付并确保可用性，对我来说，似乎是理所当然的做法。

DevOps 与敏捷的区别

*克托·法尔西奇：让我们多聊聊从敏捷到 DevOps 的演变。你具体是怎么理解的？

朱利安·辛普森：我在敏捷运动发展得比较晚的时候才加入。我没能亲眼见证一些早期的敏捷项目，但我理解的是，我们解决了如何知道该构建什么，以及我们应该如何以迭代方式规划和交付构建的问题。一旦你解决了这个问题，接下来就会面临工程挑战，比如集成。现在项目末尾出现巨大的合并阶段已经没有借口了，因为持续集成至少自 1990 年代末期以来就已经存在了。

"DevOps 是应对在项目早期阶段成功时所遇到的那些问题的回应。"

—朱利安·辛普森

你会发现一些原本没有的问题，因为你可能反正没能成功过。我现在才试着表述这个问题，但也许 DevOps 是应对在项目早期成功阶段时你遇到的那些问题的一种回应？

如果你变得更擅长编写既正确又最适合当下的软件下载并进行部署，你突然需要考虑所有这些其他的操作性问题。对我来说，如果你有部署问题，可能反而是个好问题。

*克托·法尔西奇：没错，如果你的流水线的某一部分突然变得更快了，那么，正如你所说，你会遇到下一页的问题。

朱利安·辛普森：我是约束理论的忠实粉丝，所以这绝对是符合实际的。我相信你需要在整个价值链上进行优化，而不是仅仅基于成本进行优化，这是很多项目所做的事情。

*克托·法尔西奇：按部门的成本，事情变得更复杂了。

朱利安·辛普森：完全正确。我曾在多个咨询项目中工作，在这些项目中，部门政治不像是影响因素，反而是所有这些开发者的日费，这是项目经理能直接看到的。所以，他们会优化开发者的利用率，而不是其他方面。

*克托·法尔西奇：就像是一个优化的 Excel 表格，当你改变了两个数字，突然之间，你就变得更加优化了。

Julian Simpson：我发现，在一些项目中，开发人员完全有可能在他们的开发系统上运行所有的验收测试。我认为他们当时应该做这个，因为我们有一个巨大的持续集成（CI）和 QA 瓶颈，所以最合理的做法是每对开发人员在提交代码之前先运行这些测试，从而缓解瓶颈。这个信息对于项目经理来说是非常难传达的。

Viktor Farcic：我最近发现你被称为 The Build Doctor？你是怎么得到这个名字的？

Julian Simpson：在 2004 到 2008 年之间，我有一个*的专业领域，专门为别人修复 Ant 构建。在那个时候，我对 Apache Ant 非常熟练，甚至在一本书里写了一篇关于重构 Ant 构建文件的文章。现在这个工具不再那么流行了，但在那时，我曾想过自己是否会从咨询工作转型，或者是否只是建立我自己的个人品牌。我想，好吧，Build Doctor——我已经靠修复这些东西为生了，所以我就基于这个建立品牌。但现在，这个品牌的事情暂时搁置了。

Viktor Farcic：你现在在做什么？

Julian Simpson：自 2012 年起，我一直在为 Neo4j（前身为 Neo Technology）工作。在公司内部，我曾在工程、市场和 IT 部门工作过。我发现自己做过从产品开发到在 Amazon 上部署我们全栈网站的一切工作。

现在，我在做内部 IT 项目并编写内部应用程序。实际上，今天早上我一直在编写删除 Dropbox 账户的脚本。

Viktor Farcic：那么，是什么让 Neo4j 成为一家伟大的公司？

Julian Simpson：简而言之，就是人。

Viktor Farcic：你能详细说明一下吗？因为如果把这个和你的工作领域以及 DevOps 的概念联系起来，你认为真有 DevOps 团队这种东西吗？

Julian Simpson：当我加入 Neo4j 时，我与瑞典团队合作。作为一家公司，我们倾向于优化优秀的人才和良好的态度，我们几乎不知不觉地在这方面有了一批非常优秀的成员。

DevOps 团队、DevOps 问题和配置管理团队

但是，我们能不能有一个叫做 DevOps 团队的东西呢？我不这么认为。你可能会成立一个团队来解决 DevOps 问题，但我甚至不认为我们特别有一个 DevOps 问题。我会说你只是有一个问题。从 2009 年起，那个名字被创造出来时，我对这一运动的最初想法是，它应该是关于协作的，也许工具会在这种协作中自然产生。

"我们能不能有一个叫做 DevOps 团队的东西呢？我不这么认为。"

—Julian Simpson

我原本期待开发者会采用配置管理工具，这样系统人员和开发人员可以进行合作，但我没想到一堆传统的系统管理团队会因为某些工具的相似性而将自己重新品牌化为 DevOps。我没想到传统意义上的配置管理团队会变成 DevOps 团队。在某种程度上，我认为唯一的区别现在是在外包平台上，因为我们一直都有一个人在管理你所说的平台。

*克托·法尔奇：这让我感到困惑。一方面，几乎没有人反对 DevOps 主要是关于协作的观点。但另一方面，你有大量的 DevOps 团队，这对我来说完全是矛盾的。如果你创建了另一个团队，你实际上是在创建另一个孤岛，这可能根本不会帮助协作。

朱利安·辛普森：我看不出你现在所称的 DevOps 团队和过去的配置管理团队有什么区别。唯一的区别是，今天的 DevOps 团队承担了过去系统或 Unix 管理团队可能做的事情：相同的基本结构，只是团队中间换了个新名字。

如果你要有那个 DevOps 团队，我希望你能把外部的开发和运*团队带进来，并进行轮换，目标是缩*规模或解散该团队，或者只用一两个人来负责管理你的管道运行所依赖的基础设施。

*克托·法尔奇：根据我访问过的公司，我的理论是，DevOps 团队是那些最快改动职位名称的团队。

朱利安·辛普森：这变成了一种品牌或地位的象征，而不是一种有用的协作练习。

*克托·法尔奇：我曾在一家软件公司工作，他们也没有提供帮助。如果你去参加一个会议，十年前的每一个工具现在都变成了 DevOps 工具。他们都在说，如果你购买这个工具，你就会获得 DevOps 认证。

朱利安·辛普森：完全正确，而且这样做的激励机制太强了。我甚至建议 CITCON 重新品牌化，至少更多地讨论 DevOps，因为我认为他们是这种典型会议的一种。

Jez Humble和Dave Farley的书《持续交付》的灵感之一，来源于我们有一个由八人组成的 DevOps 团队，包括我自己、Chris Read、Dan North、Tim Harding 和其他几位。我们的工作就是在一群按日计费的承包商、顾问和可能因为工作负载过重而无法承担太多的运*团队之间架起桥梁。我们的任务是清偿技术债务，或是处理如何将代码从 CI/CD 重新部署到生产环境中，同时通过他们所需的所有风险管理和内部控制。这一团队最终解散了，它是为了应对一个问题而扩展的，一旦大部分问题解决后，最终变成了我一个人处理，直到我离开。

“它[DevOps]变成了一种品牌或地位的象征，而不是一种有用的协作练习。”

—Julian Simpson

Viktor Farcic：几乎每个人都给我不同的解释，尽管我必须说，我最喜欢你的解释。我在你的一篇博客中读到，DevOps 的完整定义就是常识。那么，如果 DevOps 是一个理论，且早在古代就存在，我们知道开发和运*以某种方式需要协作，为什么你认为 DevOps 在最近才成为一件事呢？

Julian Simpson：我认为 DevOps 一直都是存在的。我发现有趣的是，当我曾在 ThoughtWorks 工作时，Martin Fowler和他们的 CTO Rebecca Parsons 都曾在大学做过系统管理员。我认为 DevOps 以前只是团队中的某个人在做的事。我以前合作过的开发人员在任何 Unix 系统上部署时都非常有能力。

我的很多经验都非常偏向于 Unix。前几天我在一个以.NET 为主的公司做了一个演讲，虽然我不确定我的信息是否真的传达到了，因为他们的问题略有不同，但我认为总会有人解决这些问题。但我认为，随着互联网泡沫和千年虫问题的兴起，我们真的忘记了，因为记得吗，Linux 桌面版当时并不算是一个热门的事物。

你仍然有很多人部署到 Unix 上，我认为 macOS 在开发领域并不流行，所以几乎没有人在使用命令行。至少我的经验是，每个人都希望获得一台 Windows 机器和一个 IDE，并被告知交付一些代码，他们甚至没有工具来在不同的操作系统上解决问题。我认为，我与开发人员之间的冲突很大程度上源于他们几乎只需要 Java。我认为“编译一次，到处运行”的口号的营销也加剧了这个问题。微软的“视觉化一切”的口号也让人们对正在发生的事情缺乏理解。

你会看到开发者有着解决重要问题的巨大需求，比如“千年虫问题是否会让客机从天上掉下来？”或者像 Pets.com 这样的不太重要的问题。很多没有经验的开发者进入了这个行业，根本没有能力解决这些问题，因此他们更频繁地被推给运*团队处理。

恰好在我开始从事软件项目工作后，Y2K 和互联网泡沫时期结束了。我曾做过技术支持，所以对之前的几十年可能一无所知，但我的感觉是，我们在 21 世纪初搞砸了很多事。

*克托·法尔奇奇：那个时候每个人都成了程序员。

朱利安·辛普森：没错！我们总是开玩笑说，那些在互联网泡沫破灭后会回去卖人寿保险的人。对他们来说，获得一些证书后，就可以开始做短期合同工作，虽然日薪不高，但比很多普通工作（比如卖人寿保险）要有很大优势。

*克托·法尔奇奇：那不也是软件供应商开始对 UI 方式进行激进推进的时代吗？我的意思是，你有 Adobe Dreamweaver，可以拖放东西，突然间就创建了一个网页。你还有 VSB 和 Oracle ESB，你也可以拖放并创建所有迭代。我听说这也是“任何人都能做”的营销理念的一部分。

朱利安·辛普森：这是我关于微软在品牌营销方面视觉化一切的观点。我曾在一个公司工作，那里的开发者很强势，我们使用 Perforce。回滚和提交在 Perforce 中相当复杂，最终，最好的做法是写一个脚本。我会为你编写这个脚本，你只需运行它，就可以还原那个提交。

我为之工作的那个人不同意，因为他认为一切都应该是可视化的。这是他的坚定信念。如果他不能点击一个按钮，拉出一段文本，那么对他们来说就太过复杂，违背了他们的信念。微软希望鼓励这种方式，他们想要和 Unix 区分开来。这一切发生在 GPL 病毒式传播的时代，所以我认为销售带有 GUI 的产品并没有任何帮助。

我发现这是判断一个人技能的试金石。如果他们没有 GUI 来引导他们到正确的地方，那么观察他们如何解决问题就非常有趣。

“我认为现在已经意识到 GUI 阶段有些错了，这也鼓励开发者更多地探索命令行。”

—朱利安·辛普森

*克托·法尔奇奇：你认为这还成立吗？我有一种印象，尤其是从 2017 年起，整个行业都在远离所有基于 UI 的东西。如果你看看 Docker 和 Kubernetes，它们完全是命令行操作。一切都在回归 Unix 的基础。

Julian Simpson：我没有花时间去玩新版的 Windows，但他们有 Windows PowerShell Core 这一事实表明他们发生了变化。几年前，当我看到 Scott Hanselman 通过git push将应用部署到 Azure 时，我真的非常惊讶。我认为人们已经意识到图形界面阶段有些错误，这也鼓励开发者更多地探索命令行，这改变了我的工作。以前我的工作是理解构建脚本是如何工作的，以及 Unix 或 Linux 生产环境是如何运作的，我认为很多人现在才开始明白这些。

Viktor Farcic：当你提到 Unix 和 Linux 环境时，你认为我们终于看到了那里的一些变化吗？这是一个一段时间以来没有变化的领域，无论好坏。

容器的演变

Julian Simpson：我认为容器已经发生了很大的变化，因为你有了这个不断向上迁移的价值堆栈。

Viktor Farcic：你是什么意思？

Julian Simpson：我们曾经把业务逻辑和存储过程保存在数据库中，但它已经转移到数据库上方的代码中。我认为我们距离看到容器最终走向哪里还有很长的路要走，但看起来这是最大的变化。现在没有人再关心主机操作系统了。

Viktor Farcic：你的意思是，它不再是最低要求了吗？

Julian Simpson：是的，我认为在某些方面，它非常有帮助，无论你是在看容器还是平台即服务，人们都可以通过它们来交付代码。我对容器运行时的具体细节不是很感兴趣；我只是很高兴，如果我想推出某些东西，我可以将其部署到 ECS，或者任何现有的容器运行时作为服务。

Viktor Farcic：我认为 CloudBees 有一个，不是吗？

Julian Simpson：是的，在 CloudBees，我们主要是与 Jenkins 相关的，但我们现在基本上是 100%转向 Kubernetes。

我认为在某种程度上，容器正在实现 Java 很久以前就承诺的目标：随处运行。微软 Windows 在这方面仍然有些不稳定，但它也在逐步改善。

我也认为，容器供应商没有告诉任何人他们能够像 1990 年代承诺的那样在硅芯片上运行容器，这一点有所帮助。正如你所说，他们没有兑现这些承诺。我认为你是对的，以前我的工作不仅仅是运行 Jenkins 或项目选择的其他 CI 服务器，还要为它们配置环境。现在你可以说每次构建都在一个容器中运行。是的，很多问题已经消失了。如果你能够构建一个容器来代表一个生产运行时环境，并且是一个空白墙，那就完美了。

展望未来

Viktor Farcic：没错。我讨厌下一个问题，因为我一直被问到这个问题，但我还是要问你：你怎么看未来的发展？

Julian Simpson：老实说，我没有答案。我认为公共云是一个值得关注的领域。亚马逊、微软、阿里云、IBM 和谷歌云之间进行如此大规模的军备竞赛，对于我们这些只想交付内容的开发者来说，选择将变得非常丰富。

“我们都认识一些人，他们每天上班做自己被要求做的事情，然后又回家。我认为当不可避免的自动化发生时，这些人将面临巨大的职业风险。”

—Julian Simpson

我认为，尤其是亚马逊在网络方面做的很多工作是很有趣的，这样我就能在需要时把我的本地网络与 Amazon VPC 桥接。我可能可以把大量的 IT 工作外包给亚马逊，专注于编写有意义的内容，当然，当亚马逊也写这些内容时，我也要和它竞争。

Viktor Farcic：当我问我的一个朋友类似的问题时，他也从云计算开始了。他的理论是，让不称职的人做每天重复的工作，最终他们会因为亚马逊和 Azure 而失业。这将成为一个筛选机制，区分出那些做有价值工作的和只是做“某些事情”的人。

Julian Simpson：我能很容易理解这一点。我们都认识一些人，他们每天上班做自己被要求做的事情，然后又回家。我认为当不可避免的自动化发生时，这些人将面临巨大的职业风险。有些人的职业生涯将会被自动化“替代”。那句“走开，否则我们用一个很*的 Shell 脚本替代你”将再也不会更贴切了。

Viktor Farcic：没错。另一个让我困惑的事情是，我 15 年前就听到过类似的理论，认为人们会被 Shell 脚本取代，但至今似乎还没有发生。

Julian Simpson：我认为现在不同之处在于，Shell 脚本将只是调用 AWS CLI。

解决供应商锁定问题

Viktor Farcic：你是否担心供应商锁定问题？即公司基本上能够接管并把你永远锁定在它们的平台上？

Julian Simpson：我觉得我有些担忧。我猜随着这些公司试图区分它们的所有服务，必然会产生某种程度的锁定效应。显然，保持你被锁定在它们的平台上符合所有人的利益。但如果它们试图销售相同的基础产品，那就成了你追我赶的竞争，最终会陷入恶性循环。

结果是，这些公司会尽力区分他们的产品。我是说，如果我是一家严重依赖某一云平台的公司的 CTO，我会考虑减轻这种风险；例如，可能将部分工作负载转移到其他地方，这样我就能具备管理不同平台的技能。我认为，能够外包一切的一个问题是，你也在外包你的技能萎缩，无论是作为个人还是作为一个组织。

*克托·法尔奇奇：这应该与我们在大型主机上遇到的问题，或者每个人都将所有事情外包时遇到的问题没有太大区别吧。

但正如我所说，一方面，我听到了很多关于厂商锁定的担忧，但另一方面，我不确定这与公司以前外包所有事情时，或者运行大型主机时没有什么不同，那些也是厂商锁定。以某种方式，我们，或者至少我们中的一些人，仍然设法克服了那些问题。

朱利安·辛普森：我认为它不会像过去历史上的一些厂商锁定那样糟糕，比如贝尔电话公司，这样的公司曾因垄断被拆分。我认为这将是你接受厂商便利所付出的代价。

*克托·法尔奇奇：这非常有趣。

朱利安·辛普森：如果你只是说在 Azure 上运行最方便，然后你只在公司内部培养这些技能，那么是的，我认为很容易就会陷入厂商锁定，而这可能导致昂贵的退出。我认为，不再需要自己构建平台，可能是一个净正面因素。

“如果我是一个依赖单一云平台的公司的 CTO，我会考虑采取措施来减轻这种风险。”

—朱利安·辛普森

我曾在几个工作中需要在办公室安装 SPARC 系统，这非常麻烦。我认为，对于任何希望提供软件或服务的人来说，最好是他们不需要雇佣人手来在办公室里搬动服务器、将其架设起来，然后安装并试图让它们工作。那是我在 1990 年代做的事情，我认为我们现在拥有的技术显然要好得多。我认为，按分钟租用 IT 服务具有不可思议的价值。

*克托·法尔奇奇：如果你排除 Netflix、Google 和 Apple 这些大公司，你怎么看构建私有云？它是否有意义，且是可行的选择？

朱利安·辛普森：我可能会对自己是否能交付一个私有云持怀疑态度。我确信我可以做到，但在这种安全威胁环境下，试图保持私有云的安全，可能比以往任何时候都更具挑战性。过去几年我们看到的一些安全问题让我感到惊讶。

*克托·法尔奇奇：你认为我们现在有更多的安全问题，还是这些问题只是变得更明显了？

朱利安·辛普森：我认为它们今天变得更加显眼了，我也认为安全研究似乎也跟随这些趋势。一旦有人发现一个漏洞，便会有更多的目光去寻找类似的漏洞。它们似乎是成波出现的。但我认为随着事物变得更加互联，安全问题变得不再像以前那样不显眼。十五年前我们并没有假设企业网络不是一个安全的地方。

文化与协作

Viktor Farcic：这是一个有效的观点。最后，你有没有什么想说的想法或者是我遗漏的什么问题？

Julian Simpson：不，我认为我们已经讨论了我认为最重要的内容，那就是文化。我非常高兴我们并没有真正讨论自动化或任何工具，除了作为其他事物的例子。对我来说，DevOps 完全是关于文化和协作的。

Viktor Farcic：那是否意味着文化塑造了工具，还是工具塑造了文化，或者两者都有？我的意思是，你能单独采用其中之一吗？

Julian Simpson：我猜不是，因为人们的期望必须发生变化。我认为他们使用的工具和工具使用的文化是紧密相连的。如果你能改变文化，那么工具可能会随之改变，反之亦然。但我认为事情不仅仅是这样。

Lindsay Holmwood 在 2016 年新西兰惠灵顿的 DevOpsDays 上做过一个演讲，他指出文化是有些隐形的，实际上你看到的都是一些物件，它们能告诉你文化的状况。考古学家会挖掘出某些东西，然后做出假设，实际上这里也是一样。我认为我们每天都能看到一些东西，它们能告诉我们公司的文化，或许工具仅仅是文化的一个物件。

“对我来说，DevOps 完全是关于文化和协作的。”

—Julian Simpson

Viktor Farcic：我以前没听过这个，但我喜欢这个说法。

Julian Simpson：是的。这完全是从 Lindsay 那里借来的，如果你和他聊一聊会很棒。如果你的公司需要大量的控制，那么你可能不会选择分布式版本控制系统，或者你可能想使用一些合理的产品来捕捉需求。甚至“捕捉需求”这个词可能也有某种文化影响。我想我最后想说的是，我认为工具可能会告诉你你的文化是什么。

Viktor Farcic：我喜欢这个。我真的很喜欢这个。

第二十三章

8

第二十四章：安迪·克莱门科

Docker 高级解决方案工程师

第二十五章：介绍安迪·克莱门科

安迪·克莱门科是 Docker 公司的一名资深解决方案工程师和架构师。他还是一名技术专家和 DevOps 分析师，专注于帮助组织从传统的开发实践过渡到一套现代化的文化、工具和流程，提升软件的发布频率和质量。你可以通过 Twitter 关注他，用户名是 @clemenko。

*克托·法尔西奇：我想从我问每个人的一个问题开始我们的讨论：什么是 DevOps？

什么是 DevOps？

安迪·克莱门科：DevOps 是一种生活方式。它的核心在于能够适应新技术，不仅仅是从开发者的角度来看，也从运*的角度来看，同时保持灵活。这并不是说 DevOps 仅仅是这些。它还融入了很多其他的概念，这也是为什么我称它为一种生活方式。除了能够适应，你还需要容器、十二因素应用、声明式基础设施和基础设施即代码。是的，周围有很多流行词汇，但归根结底，它只是生活方式。它是关于灵活性、重新调整工具并不断向前迈进。

*克托·法尔西奇：那么，安迪·克莱门科是如何将工具融入这个框架中的呢？因为在今天的领域里，我发现每一款工具几乎都是 DevOps 工具。

安迪·克莱门科：在某种程度上，工具几乎并不重要，因为你可以给一个木匠任何一把锤子，他们依然能够成功。在 DevOps 中，你可以给任何一个 DevOps 或 SRE 工程师（现在你想称他们为啥都行）一个工具——无论是 OCI、Rocket、Docker、Kube、Swarm、Jenkins 还是 GitLab，都没关系——他们应该能够使用这些工具。但最终，关键是要足够灵活和开放，接受下一个看起来完全不同的工具。

"DevOps 是一种生活方式。它的核心是能够适应新技术，不仅从开发者的角度，也从运*的角度来适应。"

—安迪·克莱门科

*克托·法尔西奇：说到工具，我对容器非常感兴趣。你认为，作为一个行业，我们开始同时讨论容器、微服务和 DevOps 是巧合吗？这纯粹是运气，还是背后有某种联系？

安迪·克莱门科：我会说这是一个巧合。容器帮助加速了 DevOps 生活方式的普及，但在我曾经在大型 Hadoop 集群上工作，并且看到过使用 Puppet、Chef、Salt 和 Ansible 的 DevOps 方法论之后，我们所做的实际上就是重新调整工具，提升了抽象层次。我们不再是在操作系统层面进行编排，而是在集群层面进行编排。

但这种关联帮助加速了发展的进程。现在无论你是在工业界、政府部门，还是其他地方，情况都是一样的。大家有一个共识：当你有一个开发团队和一个运*团队时，他们常常会“把东西丢到篱笆另一边”。DevOps 的生活方式就是将这两个团队及其职能结合起来。忘记团队吧，因为一个拥有改变能力的团队比两个尝试做同样事情的团队要更快。在这种加速中，我认为容器起到了作用。老实说，我想说的是，这关乎软技能，关乎人，关乎团队，和工具没关系，就像 Docker、DevSecOps 和 GitOps 这些都只是流行词汇。我们将达到这样一个阶段，不论你创建的是容器、虚拟机还是 JAR 包，它里面都有元数据，告诉你它应该如何运输，谁应该批准它的生命周期。

Viktor Farcic：这很有道理。

Andy Clemenko：但我记得去年在 KubeCon 上，Brendan Burns 在一个面向实践者的会议中做了一个关于自我部署镜像的演示，展示了你的对象不仅了解自己需要什么才能保持健康，而且还知道它需要去哪里，谁需要批准它的使用以及安全来源。所以，现在你有了内置的审计追踪，并且你为这个对象加上了尽可能多的嵌入式元数据。

Viktor Farcic：所以，几乎可以说我们正在转向通过代码和元数据进行沟通？我不需要告诉你我想要什么，因为这些内容都已经在我的工件中自包含了。

Andy Clemenko：完全正确，作为构建者，或者作为团队来构建这些对象，你可以描述它应该做什么，同时也有机会将其引导到其他方向。但今天，如果我给你一个 Docker 镜像，你可以对它做任何事情。我喜欢这样一个想法：在未来，我可以给你一个 Docker 镜像，我可以将其锁定，只允许你运行它，这样你就无法进入其中，也不能对它做任何奇怪的事情。但它也有安全来源，确保你知道是谁把它交给我的，然后我又通过加密技术把它交给你——至少有一个审计追踪。

下一阶段，至少在我看来，是让这些对象真正具备，我不会说是自我意识，但至少有更多有意义的关于安全性、来源和部署的元数据。假如，不是有一个docker run命令，里面包含三次换行并传递卷等东西，而是你直接执行docker run，然后容器自己就会说：“嘿，我应该有这个，在哪里呢？我应该有这个变量，但你没有给我。可以给我吗？”更自我意识的状态算是一种奇怪的描述方式。

描述今天的公司情况

*克托·法尔奇：换个话题，如果你今天要创办一家公司，它会是什么样子？人们会如何与公司互动和沟通？

安迪·克莱门科：我非常喜欢*型公司，那里的团队之间的界限较为模糊。所以，如果我要创办一个初创公司，我会确保我们内部的 IT 团队理解我们的产品，确保每个人都能协作工作。我认为，一旦公司人数超过几百人，围栏立刻就会出现。

我从客户互动中一再听到的一句话是：“哦，那是网络团队的事，他们能做的时候会去处理。”有了这些围栏，你就会有不同的北极星、不同的目标，或者不同的战略和管理者。我更喜欢一个扁平化的组织结构和跨职能团队。比如，今天你可能对监控和帮助客户解决方案感兴趣，但这并不意味着内部的 IT 团队不能借此机会。

*克托·法尔奇：但这些围栏是不可避免的吗，还是说它们只是更为熟悉？我自己也在想，因为我还没有见过一家像那样运作的大公司，而这是我很想看到的事情。

安迪·克莱门科：我认为你会看到一些团队，但不幸的是，与跨职能团队相对的却是组织的稳定性。因为如果你有一个团队，随着公司规模的增长，你会发现这些团队会分成几个*团队。那么，问题来了，如何组织这些团队？简单来说，如何控制它们，确保它们一起前进？你可以通过给每个团队设立一个北极星来做到这一点，这样就能开始形成这些垂直的围栏。

这其中的难点在于，组织结构本身就很难，而问题是很多人最终都进入了中层管理。由于这个原因，人们有很大的动机去*持中层管理的存在。看看 300 人公司门槛的角度。一道门槛是 100 人，第二道是 300 人，然后是大约 500 到 600 人，甚至可能更接近 1000 人。但对我来说，在理想的公司中，我喜欢保持在几百人的规模范围内。

举个例子，我昨晚收到了一个邮件，内容是：“嘿，我知道你下周三在罗利。你能在周四到休斯顿吗？”我回复说我愿意去，只要他们批准我的差旅申请，我就会去，并完成任务。这不是我的团队，也不是我的区域，但他们需要帮助，那就去吧。

*克托·法尔奇：这就是奉献！

个性、诚实与感知环境

安迪·克莱门科：另外，现在所有行业中有两种类型的性格。要么是 A 型，要么是 B 型，字面上的意思。A 型人会投入进去，做任何事情以完成任务。用一个用滥的词来说，A 型人的座右铭是“任务，任务，任务”。而 B 型人则在一定程度上会坐下来，按下按钮。我在各行各业中都看到了这种情况。

我是兼职的志愿消防员，我在消防服务中看到这种情况，在公司里也看到，在政府部门也看到了。事实上，我在各个地方都看到了。诀窍是，如果你真的想保持跨职能团队和文化的持续发展，你需要找到那些愿意付出额外努力的人。并不是每天都这样，因为那样会失控。但要找到那些愿意做的人，展示出勇气并付诸实践，然后再考虑抱怨或获得补偿的事情。

“A 型人会投入进去，做任何事情以完成任务。用一个用滥的词来说，A 型人的座右铭是‘任务，任务，任务’。而 B 型人则在一定程度上会坐下来，按下按钮。我在各行各业中都看到了这种情况。”

—安迪·克莱门科

*克托·法尔奇奇：这非常有趣，因为我曾和一些人谈过，他们说，“哦，我所在的公司在增长，而随着公司成长，我开始怀疑是否要换个地方工作，原因正是如此。”然后我常常会收到类似的后续问题，“哦，但如果你们发展到 1,000 人，那很好，因为更多的人会将这种增长与更好的业务等因素挂钩。”我从未真正理解这一点，因为你不得不问，这对我有什么好处？ 这不是我的公司。如果我们是 1,000 人，而不是 200 人，那为什么更好呢？

安迪·克莱门科：如果从纯粹的财务角度来看，假设有两家公司，一家有 10 名员工，另一家有 1,000 名员工，谁赚得更多？答案是位于公司顶部的人。因此，公司的规模越大，收入越多，股票的价值也就越高。

你是否直接被激励去做这些事？说到底，金钱真的是你的动力吗？我穿着连帽衫，我是一个拥有工程学学位的工程师，想要解决问题并制造一些酷炫的东西；这就是我的全部。我现在的工作是帮助客户解决问题，创造一些酷炫的东西——我在帮忙，我喜欢这样做。如果我们多卖了一个*工具，我会得到额外的一分钱吗？不会直接得到。 也许在年底间接得到一点。但那不是我个人的北极星。我认为，需要一种特定类型的 CEO，才能按下刹车，并不认为大规模扩张会解决所有问题。因为在我看来，并非所有的增长都是好的。

*克托·法尔西奇：我想这取决于你追求的是什么。我有相同的感觉，我肯定是在追求钱，直到某个程度。我不能每月只赚 100 美元；但我也有一个限度，到了这个限度我就会觉得，“好吧，这已经没什么区别了，”除非我有雄心去买一架直升机之类的东西。

寻找你的北极星

安迪·克莱门科：那是你的北极星！暂停一下这次采访，我想问问你怎么看？我知道我们的讨论一直集中在我身上，但你怎么看待公司规模和拥抱 DevOps 这件事？

*克托·法尔西奇：关于公司规模，我跟你感觉类似，公司越大，我在其中工作的乐趣就越少。

安迪·克莱门科：很高兴你和我看法一致。

*克托·法尔西奇：我觉得这算是我的定义。我觉得做软件工程在某种程度上是一种特权。我之所以这么觉得，是因为我们是为数不多的，通常是为了乐趣而加入的职业，而且我们还能一直乐趣满满。归根结底，只要我还在玩得开心，那就太棒了。只是我觉得我们越大，乐趣就越少。

我访问了很多公司，我觉得他们没有希望。我和他们合作了短时间，教他们怎么做这做那。但一年后我回来，问他们在做什么，他们却问我，“你是什么意思，‘告诉我们在做什么’？你去年在这儿，知道我们在做什么！”

安迪·克莱门科：这就是问题——没有什么变化。就流行语或术语而言，官僚主义是与 DevOps 及其生活方式的反模式。我只是想做 DevOps 生活方式的公式，但在这些大型组织中，确实需要官僚主义，因为你必须在某种程度上组织这么多人。否则，就会变成西部荒野。你得做得像个更好的初创公司。我真的认为我们需要拆分那些大公司，把它们保持得*一点。CEO 必须有勇气不让公司发展到 10,000 名员工，因为一旦公司大了，你就会失去灵活性，也失去了适应这种生活方式以及随着风向变化，适应任何新北极星的能力。

但不幸的是，钱就是权力。我们需要的是大公司所拥有的资金，来资助那些*公司。这就像一种奇怪的共生关系，但并非互惠的；中间存在一个空白。我目前正在执行一个合同，已经工作了 1200 *时，或者说 50 天，我们的团队在过去两个月里，已经花费了 500 *时的时间，用来配置我们的笔记本电脑，跟他们说，“嘿，我们需要一个 NFS 共享，我们需要 Windows 虚拟机。”我们确实处于一种“需要这个需要那个”的状态。问题是公司的回应是，“是的，它正在来，伙计。让我们调查一下。”我有一台笔记本电脑，始终保持 VPN 连接。不错，这很好用，但突然之间，我无法通过 SSH 连接到 Linux 主机，然后他们又怪我们关闭了某些服务。

我的意思是，我可以通过跳跃和跳动来解决——我是个技术宅——但这显然是个防火墙问题。所以，接下来的自然反应是，“好吧，我们会提交一个工单。”没问题，但现在你得等六周，等网络团队处理。那时我会对网络团队说，“嘿，伙计们，你们想让这个项目成功吗？”公司会回应，“好的，我们会接受你们那张百万美元的支票，但现在我们的员工越来越沮丧和烦躁，因为我们没有做任何事情。”

Viktor Farcic：但在以前，我有一种感觉，当我处于这种情况时，我不会觉得这是在浪费我的时间，因为我有薪水可以拿，但你们完全是在浪费你们的钱。最终，我会拿到薪水，所以我不在乎。但后来我意识到，也许我们对事情的看法不同。实际上，我认为完全无关紧要——零进步——的事，对于别人来说可能是大事。

Andy Clemenko：我想这跟 DevOps 的生活方式有关，我认为这也是关于不断前进的。它意味着迈出一步，即使是从三个月缩短到两个月的微*步伐，那也是向前的一步。在精神上，当我没有前进时，无论是在公司、生活、财务还是其他方面，我都会感到沮丧。我喜欢那种前进的动力。我相信，有一个程度是，公司至少会感觉到前进的方向，尽管这不是你和我理想中的目标。

“问题是，一些公司只是说，‘我们想要 DevOps。’那是他们的目标，但你在那里却在想，他们根本不明白 DevOps 究竟是什么。”

—Andy Clemenko

我在开始合作时做的一件事就是尽力确立一个北极星目标，不管是短期的、中期的，还是长期的项目。这可以是多个北极星，或者是一个系列，但至少你知道你最终想要去的地方。因为这样，你在任何时候都可以问自己，“我是在朝着目标前进，还是偏离了方向？如果偏离了，原因是什么？”因为有时候你得回头重新寻找路径，那没问题，但至少你得理解自己正在倒退，远离最终的目标。

不幸的是，问题在于有些公司只是说，“我们想要 DevOps。”这是他们的目标，但你在想的是他们根本不理解 DevOps 实际上是什么。最让我感兴趣的是，当公司说他们想要 Docker，这几乎是他们常挂在嘴边的话。但问题是，Docker 对他们来说意味着什么？

我常开玩笑说 Docker 生活方式，因为 Docker 不仅仅是容器。它是 CI/CD，是版本控制。一些地方甚至没有持续的版本控制，无论是通过监控还是日志记录。它包括 ELK、Splunk、Prometheus 和 Grafana。所有这些都是你要添加到基础设施中的聚合系统。实际上，它甚至有点像 Puppet 或 Ansible。它是理解 Kubernetes 的 YAML 配置，而我只能说，“天啊，救命！”

Viktor Farcic：完全正确！

理解你买的是什么

Andy Clemenko：但它也包括 Jenkins、GitLab，所有这些东西。举个例子，以我现在的项目为例。我们需要版本控制，也需要一个 CI 系统。所以，我问客户，“你们有吗？”他们说，“嗯，那边的团队有——”我问，“你们有中央系统吗？”他们回答说，“没有，我们没有中央系统。”然后他们可能会问，“那我们能自己搞定吗？”但那其实不是他们的工作。最终的结果是，你得去找另一个团队，问他们，“你们知道自己在买什么吗？”

一个经典的例子是，你买了一辆车，开出车行，但 200 英里后，你会抓耳挠腮，因为车子停了。你没意识到你得加油，或者得换轮胎、加机油、清洁汽车，还要做其他的*护工作。你可能会想直接回去换一辆车。但不行，你得理解自己买的是什么。

Viktor Farcic：完全正确。我觉得我面临的一个重大困难是，当我和客户合作时——假设他们的目标是持续交付流水线——我觉得我不能欺骗他们，也许我应该告诉他们，他们不应该在这种情况下追求持续交付。

安迪·克莱门科：我曾与客户进行过具体的对话，并说过类似的话，也许容器并不适合他们。如果他们不愿意建立 CI 系统或版本控制，随后他们也不愿意理解构成 DevOps 生活方式的所有这些内容，那么也许容器并不适合他们。

有时会被误解，但我为自己能够对客户保持诚实而自豪，并告诉他们：“你们需要这个、这个、这个和这个。”事实上，我昨天在一个集成商那里做了同样的事。我在白板上写下了他们需要提供的清单，因为他们正在构建一个参考架构——基础设施、监控、日志记录和 CI/CD——而他们从开发角度出发，更担心 CI/CD，但我告诉他们，提供 CI/CD 只是其中一项工作，因为，嘿，你们在构建很棒的*部件，但它们要去哪里？怎么执行？如果你们无法高效部署，那就没有意义。

*克托·法尔奇奇：但有时，我认为这不仅仅是与意愿或能力有关。

安迪·克莱门科：如果你的目标是做最低限度的工作，那就继续做吧。同样，如果那对你有效，那就太好了。但请不要妨碍那些想要改变并向前迈进的人。

你必须足够勇敢地告诉那些人，也许你应该停留在过去。也许你应该坚持使用 Windows Server 2003，而不必担心容器、DevOps 和 CI/CD，因为这些都是生活方式。客户不一定总是喜欢听到真相，但我宁愿对客户保持诚实，而不是试图操控他们。我认为诚实能够建立更健康的关系，因为它建立了长期的信任，有时候，它甚至能促成客户的改变。偶尔给客户一点“耳光”也许并不是个坏主意。

*克托·法尔奇奇：完全正确，至少对于学术界或销售人员来说。

安迪·克莱门科：我昨天参加了一个销售电话会议，会议内容就是“卖、卖、卖”。这家公司关心的只是前进。那么问题是，他们应该为他们的 Jenkins 服务器使用哪个 Docker 引擎？我觉得关键在于问自己是否真的需要支持。你的公司政策是否规定你们一定要有支持？如果是的话，那我们可以直接为你们卖两张节点许可证，每个节点每年 1,500 美元。对于他们大多数预算来说，这几乎是一个四舍五入的误差。

我的回应是你可以运行 CE，而你实际需要的支持几乎为零，因为我一直在用 CI 系统构建 CE。公司的回应是让我们给他们发报价。缺点是我们无法销售专业服务，包括完整的产品套件。但你知道吗？归根结底，至少客户感觉他们从销售人员和我这里得到了一个诚实的答复。

“客户不一定总是喜欢听真话，但我宁愿一开始就对客户诚实，而不是试图操控他们。我认为诚实会创造更健康的关系，因为它建立了长期的信任，有时候，它还能推动客户的变化。”

—Andy Clemenko

Viktor Farcic：之前你提到过 Kubernetes 的 YAML，实际上我记得你说过，“天啊，帮助我们！”你为什么会这么说呢？

论 Kubernetes、Docker 和降低入门门槛

Andy Clemenko：每当有新技术出现时，开发者必须降低入门门槛，特别是对于改变抽象视图和改变工具来说，你必须让它变得容易。Rancher 在使编排变得简单方面做得非常出色。他们需要一个目录，天啊，真是太棒了。

我曾经有一个公司主管，他完全不是技术宅。能够通过点击两个按钮就部署一个 Ghost 博客服务器，让他大吃一惊。你必须把这个入门门槛降得非常低。我现在看到的 Kubernetes 问题是，YAML 本身在单个对象类型中用了四次spec。YAML 格式没问题，每个人都能做垂直线，并且在他们的代码中正确对齐空格。

但它的整体结构呢？昨天一个客户在谈论 Swarm 与 Kubernetes，如何在 Swarm 中使用一个对象，它描述了入口 URL-FQDN，表示副本数，表示端口数和其中的卷，且是一个对象——在 Kubernetes 的术语中，这是七个对象。那有点令人沮丧；更不用说目前 Kubernetes 有 37 个顶层对象了。然后是我最喜欢的一个，叫做 CRD，自定义资源。如果我们的理论足够适合你，你可以自己创建一个，我们就和它一起工作。Kelsey Hightower 曾说，Kubernetes 不是最终目标。有人需要出来，我要向 IBM 和 Red Hat 致敬，OpenShift 变成了一个有主见的 Kubernetes。这很酷，但那不是 Kubernetes，我认为把它卖成 Kubernetes 是不公平的。

Viktor Farcic：对，那么，在你看来，应该有什么东西来解决这个问题？

Andy Clemenko：有人需要出来说，我们都将在下面使用 Kubernetes。我们理解 Kubernetes 的 YAML 格式，但我们会简化它，并制作自己的转换应用程序来格式化它。

它将转化为更低层次的原语，转化为 37 个顶级对象，以至于开发人员只需说，“这是我的镜像，”或者更好的是，“我们讨论过元数据是与镜像一起临时存在的，但这是我的镜像。这里是副本数，这是它应该在的网络，这里是它正在监听的端口——端口号，而且非常简单，在 5-20 行内，最简化的形式。”

看看 Helm：他们一直在尝试做到这一点，但 Helm 本身就很复杂。你必须拉取图表。我甚至没看 Helm，而人们却说 Helm 很简单。但，不，事实并非如此。你一次又一次看到，在帮助这些公司理解 DevOps 生活方式时——这些工具非常难。

*克托·法尔奇奇：它很简单，直到它不能完全做到你想要的，然后它就变成了一场噩梦。

安迪·克莱门科：看看围绕 Kubernetes 的炒作周期。我有客户说，“我们想要 Kubernetes！”我就问，“你们在做什么特定的事情吗？你们是拉取的吗？为什么特别需要 Kubernetes？”这是一个他们无法回答的问题，因为他们根本没有答案。其实，这归根结底是因为某个高层看到它在《CIO 周刊》上，或者它现在正是流行的 buzzword，他们必须拥有它。然后你开始向他们展示那个 YAML，或者是为了将入口控制器与部署前面的服务连接，你必须有一个入口对象。现在这就是四个对象。

*克托·法尔奇奇：我问这个问题的原因是，当我跳入 Docker 时，我觉得它是我能为公司里每个人使用的少数几种技术工具之一。如果你是测试员，那它对你有用；如果你是开发人员，它对你也有用，就像你是操作员一样。当时，Docker 几乎是一个沟通工具。它对每个人都有用，入门门槛也很低。我甚至能向我妈妈解释它。但是后来，Kubernetes 来了，我很佩服它，因为 Kubernetes 非常强大且可扩展，它允许你做任何事情，甚至包括做咖啡。但现在，我实际上无法再解释 Kubernetes 是什么，除非某个人决定将自己的生命奉献给 Kubernetes。

安迪·克莱门科：这是一种信仰。

*克托·法尔奇奇：由于其复杂性，我认为 Kubernetes 不能只是你工具包中的另一个工具。你需要专注于它。因此，在我看来，它对开发人员是没用的，因为他们永远学不到 Kubernetes 所需的一切。虽然也许我有点悲观。

“所罗门·海克斯（Solomon Hykes）并没有发明容器；让我们诚实一点。[…] 他和他的团队所做的，只是让 Docker 以一种更简单的形式运行，对我来说，这是一个转折点。”

— 安迪·克莱门科

Andy Clemenko：不，我同意你的观点，因为我也有同感。对我们在 Docker 的激动之处在于，所罗门·海克斯并没有发明容器；让我们老实点。我们过去已经有了分区、属性和封装技术。他和他的团队能做的只是简化 Docker 的运行形式，对我来说，这是一个关键时刻。我真的认为我们需要一个操作平台——一个简化的框架，这也是我对 Kubernetes 被应用到 Docker Enterprise 中感到兴奋的原因。

如果我们能像苹果那样对待它：让它简单些；让它运行起来，降低入门障碍并向前推进，那么，希望我们能在 Kubernetes 之上进行足够的抽象。如果有人想要全天候使用kubectl，就留下这扇门开着，但要稍微抽象一点，使其足够简单可行。当我们谈到终身者与主动追求者以及大公司时，我认为，一旦入门门槛稍高于一英寸，就足以引起很大的阻力。如果你想在公司内推动变革，你必须让这种阻力——可能发生的阻力——降到零。我想这几乎就像一个数学函数。你越接近零阻力，组织内变革的可能性就越高。因为我知道，当我第一次接触 Docker 时，至少从系统管理员的角度来看，我把它看作是一种威胁。

Viktor Farcic：你真的把它看作是威胁？那么从那时起到现在有什么变化？因为你现在是 Docker 的高级解决方案工程师，所以你最初的看法一定是错的。

Andy Clemenko：当时，我把 Docker 视为威胁，因为开发者可以做那些需要系统管理员的事情。因此，我的第一反应是 Docker 反对系统管理员。但那是直到我第一次docker run。然后灵光乍现，我有了一个顿悟：“天哪！我得去这个了不起的公司工作。我决定了！”但再说一遍，你必须尽可能降低入门门槛。

你有没有看到新开发者看到那个 1,700 行的 Kubernetes YAML 文件用来部署 Prometheus 和 Grafana 时的表情？我昨天做了，他们的下巴都快掉地上了。

Viktor Farcic：我知道你的意思，我经常看到这种表情。人们经常打电话给我，说：“Viktor，你能帮我们处理这个问题吗？”，或者告诉我他们想要跳入 Kubernetes，前半个*时都是兴奋的，但随后现实开始显现。

我认为在我们讨论 DevOps 的背景下，这是一个有趣的话题。但我认为 Kubernetes 促进了这些角色的创建，并且系统管理员将能够使用它。

我希望未来我们作为一个行业，能够不再讨论 Kubernetes，而是看到它上面有一些只有少数人了解的东西。我猜这和你描述的 Docker E 差不多。

安迪·克莱门科：现在的内核开发者有一个问题；每一层总会有极端的专家，但直接与这一层互动的人数变得非常少。

*克托·法尔西奇：因为你没有在使用它。

安迪·克莱门科：没错，没必要。

*克托·法尔西奇：我现在在使用 Mac 和你交谈。我不知道它背后是什么，因为我不关心。

“老实说，我甚至不关心这个容器是否符合 OCI 标准。最终，我只希望它能工作。我希望它是可移植的。我希望它是安全的。我希望它是简单的。”

—安迪·克莱门科

安迪·克莱门科：这是一个很好的观点。我相信是来自 Sun 的斯科特·麦克*利，曾在多年前谈到过 Sun Grid 的部署以及 SAS Grid 的首次亮相。他曾说，当你插上吹风机时，你不需要了解核能。你只需要插上吹风机，然后它就能工作。所以，今天应用同样的想法，因为我不关心下面的编排器是什么——老实说，我甚至不关心这个容器是否符合 OCI 标准。最终，我只希望它能工作。我希望它是可移植的。我希望它是安全的。我希望它是简单的。

展望未来

*克托·法尔西奇：那么，接下来呢？

安迪·克莱门科：在不久的将来，我认为无服务器架构会逐渐获得更多动力，但我仍在等待无服务器架构能够直接写入底层编排器，而不是像现在这样，作为一个额外的层级存在。对我来说，无服务器架构本质上只是一个快速反应调度器，某种程度上。

埃利亚斯·佩雷拉在 OpenVAS 方面做了一些非常棒的工作，甚至让它具备了自我自动扩展容器的能力，因为它部署了自己的 Prometheus。对我来说，从概念上讲，在多个层次上拥有类似的功能似乎有些多余。那么，我想问一下：如果我们能将 OpenVAS 集成到底层的编排器中，为什么不直接将它集成到 Kube 或者 Swarm 中呢？

至少这样的话，我会提倡一个 38 个顶层对象。但是，关键是，如果你有更多的批处理任务，比如无服务器架构，它们仍然可以使用相同的调度。你不需要在它们之上再构建和添加所有这些额外的东西来做同样的事。我的意思是，我希望能看到一个编排器只需要说：“好，1 到 5 是长时间运行的，6 和 7 是无服务器的。”我们刚才还提到了自我感知的特性。如果你有一个容器，它会说，“如果我在 10 分钟内没有被使用，关闭我”怎么办？

在这种情况下，你甚至不需要为无服务器架构或守护进程分别创建一个对象。这个东西本身是自我意识的，它会说：“嘿，我没被使用。把我关闭。”它会告诉编排器：“我不忙，把我关掉。”然后当下一个请求到来时，编排器会说：“醒来。”就这样，为什么不呢？我说我们应该模糊这些界限。你不觉得这样让事情变得更简单吗？让我问你，Viktor，你还记得第一次执行docker run时的那个时刻吗？

Viktor Farcic：这就是我在说的。当我第一次运行 Docker 时，我的反应是：“好吧，我十分钟前开始，现在我已经明白它是怎么回事了。我不知道幕后发生了什么，但它能工作。”

Andy Clemenko：你能够执行一个docker run并查看你的网页，这使你得到了那个灵感时刻，这正是我们对所有 DevOps 工具的需求。这就是变革真正发生的方式——通过这些灵感时刻。

Viktor Farcic：没错，不过回到无服务器架构，你会倾向于选择你所描述的那种方式，还是类似于 Lambda 和云服务商的专有技术那些东西？

Andy Clemenko：我不会下任何赌注，因为今天的计算发生在各个地方。它发生在你的手表上，发生在你的数据中心，也发生在别人数据中心。无论是本地部署还是云计算，还是无服务器架构和完整的守护进程，或者你想怎么称呼它——服务器/无服务器。可能不是 50/50 的比例，它们会流动。我认为会一直存在两者的平衡，因为安全和财务原因。我经常听到客户说，公司政策要求我们不能接触互联网，所以他们完全是隔离的。你不能使用亚马逊，也不能使用 Azure，或者有一个项目团队在构建一个 VPN 到 VPC，他们会专门配置一个链接，所有这些事情。但这种平衡将一直存在，事实上，我们所做的只是转移责任。

那么，我认为无服务器架构会取而代之吗？不，我认为它会占据今天容器空间的最多 20%。但是，猜猜看？后端的格式是什么是无服务器架构的？

Viktor Farcic：Kubernetes？

Andy Clemenko：所以，它是相同的基本对象和相同的构造。那么，为什么我们不能让这个构造更加自我意识呢？无论它是批处理作业——无服务器技术上就是这样——还是一个长时间运行的守护进程，持续提供流量？

Viktor Farcic：因为我目前对无服务器架构的担忧是，我需要选择使用哪个平台，然后几乎永远都得坚持使用它。从技术角度来看，我本来更喜欢你刚才描述的方式——告诉我如何解释某个事物，然后告诉我它会以 Lambda、Azure 函数或 VAS 的形式运行。但这不应该是我的担忧。

“我目前对无服务器架构的担忧是，我需要选择使用哪个平台，然后几乎永远都得坚持使用它。”

—Viktor Farcic

Andy Clemenko：这本不应该是，但对我来说，它是一个过程。从根本上讲，在容器内部，它只是一个执行任何操作的过程——无论它是包装在 Lambda 函数、Azure、OpenVAS 容器，还是一个长时间运行的 Kube 容器中，它本质上都是一个过程。这个过程并不关心它被封装在什么里。它并不知道自己不是一个有意识的存在，不会像“我活着了！我死了。我活着了！我死了”那样循环。它只是运行。

需要构建独立的框架在我看来是在制造更多的混乱。没错，这提供了工作保障。但话说回来，这并不是低准入门槛；不过，经过一番尝试，OpenVAS 确实相当流畅。创建一个函数很简单，集成它也很简单，执行它也毫不费力，更不用说它还有自动扩展等有趣的功能了。但我仍然希望看到它完全与一个单一的协调器集成。

我会给亚马逊很多肯定。我并不喜欢他们正在构建的东西，怎么说呢，但我会给他们很多肯定，因为他们降低了准入门槛。他们让在虚拟机和对象存储中消费数据库变得过于简单。但如果你深入挖掘的话，实际上非常复杂，包括 CloudFormation 模板、所有的 IM 策略和安全组。我个人不使用 AWS 或任何类似的东西，因为它太复杂且令人烦恼。

Viktor Farcic：但当你说他们让它变得太简单时，我第一个想到的是，过去确实是，但现在并不是。

Andy Clemenko：其实，你说得对。

Viktor Farcic：现在我更喜欢 DigitalOcean，因为它有我需要的东西，而且没有那五万多种我不需要的东西，尽管我还是被这些东西困扰。

Andy Clemenko：我是一个忠实的 DigitalOcean 粉丝。

Viktor Farcic：说实话，我与 AWS 合作过很多次，但我仍然完全不理解它是如何工作的。但现在想想，实际上没有人真正懂；这简直是一场疯狂。我有种感觉，他们走的路径和我们之前描述的 Kubernetes 的路径一样，但它正变得越来越复杂。

Andy Clemenko：没错，我认为亚马逊的一个不利之处或不公正之处在于，他们让 AWS 变得非常“粘性”，因为它非常复杂，某种程度上，Kubernetes 也走上了同样的道路。它之所以非常“粘性”，是因为一旦你学会了，你就不想再用其他任何东西。看看这个事实，如果你在简历上写上“AWS 架构师”或者“认证 Kubernetes”这些字眼，你的电话就会一直响。这对那个简历上的人来说是好事，但你知道，我认为它在某种程度上把许多*公司从市场上排除掉了。

Viktor Farcic：不过，你知道，如果 AWS 认证的需求很高，那就意味着它实际上太复杂了，因为我不认为有人像 Kubernetes 一样说自己是容器认证专家。

Andy Clemenko：或者说，我已经通过 Docker 和 Kube 认证了。

*克托·法尔奇奇：但在 Docker 中，你到底是为了什么获得认证的？只需要两天就能通过认证。

安迪·克莱门科：我们的认证内容是对注册表的基础理解，以及推送和拉取等相关内容。但是你完全可以在一两周内学会并通过考试，难度不大。

*克托·法尔奇奇：没错。不管怎样，我知道我们现在没时间了。很高兴和你聊天，安迪。非常感谢你的时间。

第二十六章

9

第二十七章：克里斯·赖利

作者和 DevOps 分析师

第二十八章：介绍克里斯·赖利

克里斯·赖利，位于大丹佛地区，是一位自称为糟糕程序员转行做行业分析师，现在是 Fixate IO 的 Sweetcode.io 编辑。Fixate IO 是一家面向技术受众的内容营销公司。通过这个角色，他涉及 DevOps、SecOps、大数据、机器学习和区块链。他是 DevOps 学院董事会成员，已经担任此职务超过四年。你可以在 Twitter 上关注他，账号是@HoardingInfo。

*克托·法尔奇：我知道你的职业生涯主要围绕着作为分析师的工作。但你也是 Sweetcode 的编辑。你是如何走到今天这一步的？

一名糟糕的程序员转行做行业分析师

克里斯·赖利：我的答案可以用一句话来总结：我是一名糟糕的程序员转行做行业分析师。虽然我没能成为一名程序员，但我对软件开发实践、构建应用程序以及围绕这些的流程有着强烈的热情。因此，我决定专注于理解行业，而不是尝试转变我的技能，成为更好的程序员。所以，我除了是 Sweetcode 的编辑外，还成为了一名 DevOps 分析师。

在职业生涯方面，我的上一任雇主是一家名为 CloudShare 的公司，它提供专门用于大型业务应用开发的 DevTest 环境；换句话说，类似 SharePoint、SAP 或 Oracle 类型的应用。在 CloudShare，我从事产品管理工作，所以我本质上是推动产品方向并关注市场动态。

我还为 DevOps.com、O'Reilly 和 TechTarget 写了很多文章。我的内容主要关注组织如何吸收现代开发实践，并且对企业进行大量的鼓励，促使他们做出改变。我对市场非常熟悉，包括亲自使用了很多工具。但之后，我创办了 Sweetcode，它现在是一个更专注于开发者的网站，拥有很多非常强大的战术性内容。

什么是 DevOps？

*克托·法尔奇：我想从一个可能听起来非常傻的问题开始：什么是 DevOps？

克里斯·赖利：我非常坚信，DevOps 不是你可以简单地“做”的事情。你不能仅仅说，在某个特定的时间和日期，你“做过”DevOps。“做 DevOps”永远不应该是任何人说出来的，因为你永远不可能“完成”DevOps。

"你不能仅仅说，在某个特定的时间和日期，你‘做过’DevOps。‘做 DevOps’这句话不应该是任何人说出来的，因为你永远不可能‘完成’DevOps。"

— 克里斯·赖利

DevOps 不是一种东西；它是一种原则，一种实践，它是你用来驱动所有构建交付链决策的方式。这意味着它涵盖了从那个让人畏惧的词“文化”到实施的所有内容。一个很好的例子是，如果你走进 Slack 的大门，看看他们的开发环境。你可能会说，“哇，看看你们：你们的开发人员在支持自己的代码。如果他们构建了它，他们就支持它，你们一天发布数百次。你们有持续交付——太神奇了！你们做到了，你们中大奖了——你们就是 DevOps。”

你不能这么说，因为“你们就是 DevOps”这个说法实际上并不存在。正如我们在 Slack 所看到的，他们一直在并且将永远在努力找出如何做得更好。这就是 DevOps。他们总是在思考如何做得更好，尽管从外部人的角度看，他们可能拥有世界上最好的开发环境和交付链。但他们仍然在思考，“我们如何能做得更好？我们还能自动化哪些部分？我们如何能做得更快？我们如何能做更多的发布？”如果你关注的是更高质量的软件、更快、更频繁的发布，那么你就是在“做 DevOps”，你甚至不需要称之为 DevOps。这就是我认为 DevOps 的定义。

Viktor Farcic：我觉得你在描述一个扩展版的 Agile，或者至少是类似的东西。

Chris Riley：我不同意。虽然 Agile 更加简洁明了，有着明确的操作系统，但 DevOps 更加虚无缥缈和哲学化。这一点非常重要，因为正是通过 Agile，或者甚至在那之前，我们从瀑布开发实践中学到了很多东西。

如果你是一个组织，认为自己可以启动一个项目来实施 DevOps，并且期望最终能够实现可行的 DevOps，那么你实际上会得到一个DevOps 商店。实际上发生的情况是，一旦你做到了这一点，DevOps 商店就不再是 DevOps 了。它死掉了，因为，例如，CloudBees 收购了 Codeship，突然间你需要重新考虑如何进行持续集成，因为你可能正在使用一个不同的发布自动化工具，现在你需要考虑，“我的发布自动化工具是不是不同了，或者有一个新版本出来了？”

如果你把交付链设计得过于僵化，并且说：“这是我们的 DevOps 交付链”，以至于你无法适应下一个出现的东西，那你就没有在实践 DevOps。在 DevOps 中，你总是在向前看。你总是在关注下一个是什么，目标是避免陷入这样一个周期：六个月后，构建了一些东西，我们说：“哦，天哪，这已经过时了。我们需要重新调整，因为变化太快了，而且更好了，我们没有做好准备，也没预料到会有变化”，这在技术领域将是最荒谬的说法。

“你真的无法获得 DevOps 原则和哲学的认证。你一旦认为自己可以获得认证，你就已经与环境产生了隔阂。”

—Chris Riley

我对 DevOps 被视为一种原则和哲学感到不舒服，因为这让管理和构建 DevOps 环境变得更加困难。这变成了一个非常庞大的人员问题，而人员问题是最难解决的。你不能忽视这一事实。

Viktor Farcic：我完全同意。这就是为什么当我去参加会议时，有点失望，因为你也会看到那些广告，宣传我三年前就知道的每个工具现在是 DevOps 认证的。广告词大多是“买了这个，你就成为 DevOps 了”。我不知道你有没有同样的感觉，但我真的快疯了，因为这太商业化了。

Chris Riley：我是 DevOps Institute 的理事。他们最初提供的是 DevOps 和文化的高层次课程，但后来他们做出了调整，现在更多关注战术层面的内容。你真的无法获得 DevOps 原则和哲学的认证。你一旦认为自己可以获得认证，你就已经与环境产生了隔阂。你可以获得认证的是那些具体的流程和实现方式。

即使在发布自动化中，事情也在不断变化。这不是一个静态的环境。

变化的速度

Viktor Farcic：你说得对，变化的速度确实非常快。在今天的世界里，跟上变化几乎是不可能的。如果我们以你的 Jenkins 为例，几年时间，它从一个容器调度器切换到另一个，新增了几百个插件，更新了用户界面，摒弃了旧的作业定义方式，转而采用一切皆代码的哲学，等等。Jenkins 只是众多例子中的一个。我很幸运，工作让我能够花更多时间学习新技术，而不是像其他人那样，但我依然常常感到自己在落后。

不过，继续说下去，我看到你非常关注从一种文化向另一种文化的过渡。你与从大企业到*型初创企业的人们都有过交流。你有没有发现两者之间在方法上的一些模式或差异？

克里斯·赖利：从我与企业进行初次对话的四年间，事情发生了很大变化，那时大多数人都是机会主义者，表示，“哦，是的，我们在考虑 DevOps。这很好。我们知道有一些新的东西在到来。”然后，你会看到这种分化，像*型初创公司从底层构建 DevOps 商店或原则。

我不应该这么说，因为我刚才说过 DevOps 并不是一种“东西”。在 DevOps 的早期，几乎就像你有一个只有会员才能加入的 DevOps 俱乐部，企业是不能加入的。那时的心态是，“嘿，让我们把这个留给那些知道如何快速发布软件的秘密俱乐部成员。”但随后情况发生了非常快速的变化，企业迅速加入进来。然而，大规模的采纳其实直到 Docker 发布才真正到来。当 Docker 发布时，它给人的感觉是 Docker 已经有点落后了，因此企业加快了进程，看到更多的采纳，因为 Docker 的普及性太强了。

我应该说的是，容器如此普及，以至于企业立即接受并采纳了 DevOps。因此，变化发生得非常迅速。这种分化并没有那么大。真正重要的是，企业没有奢侈的条件可以彻底剔除一切并重新开始，而初创公司可以将整个交付链工具化，使其与 DevOps 方法论保持一致。

DevOps 在科技行业

*克托·法尔奇奇：有时，晚开始反而是一个优势。现在创建的初创公司没有大公司和老公司所背负的包袱。无法抹去历史往往会让我们变得迟缓，而在像我们这样的行业中，一切都可能在一天之内发生变化，作为一个没有遗留应用程序的初创公司，可能是一个巨大的优势。

以这种心态，如何推广新的价值观、流程和工具？我想这并不重要它是 DevOps 还是其他什么；公司应该有一种机制来传播变革。

“应用程序开发通常会接受 DevOps，大多数组织也是如此。如果他们不接受，那你就有一个 HR 问题。”

——克里斯·赖利

克里斯·赖利：我在企业中看到的最酷的事情，而且它确实非常有效，就是通过托管来推动采纳。这些公司建立了——我不喜欢这个词——卓越中心，在那里他们会在组织内部建立一个很棒的 DevOps 环境和文化。它会非常出色地为一个非常*的、不太关键的应用程序生成代码，并且他们会使用它，并且将其在整个组织中进行管理。

一些组织将其作为一种政治手段，并且他们会更自然地进行托管，比如通过内部晋升，而其他组织则将其构建成一种结构。事实上，美国有一家非常大的媒体公司就是这样做的。

他们有一个*型的 DevOps 环境，投资于工具和流程。他们说：“嘿，开发团队！我们有一千个*型开发团队（我不知道是不是一千个，但确实有很多 10 到 20 人的*团队）。你们每个人都在做自己的事，按照自己的方式做，这是可以的。然而，如果你们希望我们为你们提供支持，这包括预算和技术支持，那么你们就必须使用 DevOps 团队创建的工具之一。” 这是一种非常自然的驱动，而不是说，“哦，我们大概应该加入这个”，然后他们就这么做了。

对于这家特定的媒体公司来说，情况稍微容易一些，因为他们的开发团队彼此独立。他们为自己拥有的每个媒体网站配备一个开发团队。网站很多，所以因为他们已经有两个团队的结构，这让事情稍微容易一些，相比之下，比如说，一家银行只有一个庞大的团队。即便是在大银行中，他们也有一个叫做共享服务部门的组织，这是 IT 和应用程序开发之间的一个缓冲层，且共享服务将支持 DevOps。

应用程序开发通常会支持 DevOps，大多数组织也是如此。如果不支持，那么你就会遇到人力资源方面的问题。最难的部分是与 IT 团队的整合。共享服务的作用是批准流程和工具。他们与 IT 协商，确定哪些可以使用，哪些不能代表开发者使用，这样就行得通了。这是一项巨大的努力，但最终它会成功。

我认为这真的很酷，因为企业的接受总是一个借口，但我觉得现在不再是了，因为很多人会说，“是的，DevOps 确实很酷，但我们太大了。” 这种“我们太大了”的反应是不够的，但我认为很多企业已经意识到这一点。

Viktor Farcic：当我听到公司用“我们太大了”作为借口时——我听到过很多次——我的第一反应总是，“不，你们的文化还没有准备好。你们公司内部的组织结构或沟通方式并不协调。”

Chris Riley：是的，除非这些公司开始实施 DevOps 战略，否则它们将会落后于竞争对手。最终，它们将没有选择，因为某个应用程序会更好。例如，亚马逊将进入医疗行业，而亚马逊现在正在谈论要做的事情。所以，现在医院必须担心应用程序的易用性和质量。

Viktor Farcic：当这些事情发生时，当某人真正颠覆行业时，通常会导致行业急需发生改变，变得更好。这让我不禁想，发生这种事时，是否已经为时太晚。

Chris Riley：是的，也不是。这与 DevOps 无关，但在 Satya Nadella 成为微软现任 CEO 之前，微软曾感觉好像太迟了。然后他们做到了，但他们能做到，是因为他们有钱。背后是现金的巨大力量。

你知道，对我来说有趣的是，有一家在 DevOps 领域非常著名的金融机构，以开发自己的开源 DevOps 工具而闻名。但这家机构内部的一个*部门，已经定期向 DevOps 社区求助——而且他们甚至和开发这个工具的*组没有任何联系——请顾问进来向他们解释什么是 DevOps。这简直让人困惑。你有一个团队在到处谈论 DevOps 有多棒，他们还开发了自己的工具，工具很棒，但开发这个工具的团队甚至不知道另一个部门的存在！但回到你的问题。这就像是你的结构出了问题；你有一个沟通问题，意味着有些地方严重出了错。

Viktor Farcic：没错。你有没有遇到过那种情况，有人说：“哦，我们试过了，失败了。这不起作用，这一切都是徒劳的？”

Chris Riley：哦，当然，部分尝试并失败的反应。这就像是在说你太大了。

我做的事情是问：“你尝试输入了 DevOps 方法论的哪个方面？你是否直接尝试了持续交付？因为那并不是一个好主意。为什么不先自动化测试呢？我们先自动化一些较*的东西。别明天就去做金丝雀发布，然后告诉我，‘哦，我们做了金丝雀发布；它把软件发布得太快了，人们都很生气。’如果你这么说，我的回应就会很简单，‘你为什么选择那个？自动化其他的东西吧。’”

Viktor Farcic：我听过这样的故事，如果你不知道什么是自动化，就无法跳跃穿越时间。他们说，你将无法实施容器，因为你的差距太大，没法跳到下一个阶段。

Chris Riley：我不认为你可以直接跳进去，更广泛地说，这种心态一直是个问题，人们认为一个工具可以解决问题。他们认为 Jenkins 是 DevOps 市场中的发布自动化工具，如果他们买了这个工具，就说明他们正确地做了 DevOps，因为 Jenkins 会把 DevOps 带到他们的组织中，然后他们就完成了。这种心态永远行不通。如果你期待工具来为你解决问题，那你就是错的。

自下而上还是自上而下？

Viktor Farcic：这就是为什么我认为，购买那些承诺仅凭存在就能带来文化变革的工具是非常危险的。那么，在你看来，哪种方式更有效：自下而上还是自上而下？更具体地说，当有一个倡议时，应该从哪里开始？

Chris Riley：我会稍微不同地回答这个问题，因为我认为这两个问题从各自的角度来看都很关键。不过，话虽如此，如果我必须选择一个，我会说是从下而上。如果你有下而上的开发问题，举例来说，如果一个开发人员告诉你他们不想专注于构建应用程序，并且他们不想更快地把应用程序发布出去，那么你就选错了开发人员。如果这是你的问题，那么这就带来了更大的挑战，因为你不应该需要向一个开发人员解释为什么构建应用程序和加速市场发布是重要的。

出于这个原因，在下而上与上而下的比较中，我认为 90%的努力应该是上而下，因为这是最大的障碍。这在质量保证团队，或者质量工程（QE）团队中非常常见，他们渴望做新事物，因为他们相信自动化。他们有一个关于整个交付链的整体视角，他们看到了所有的环节。但 QE 团队从来没有预算，他们必须向研发团队（R&D）证明这个需求，研发团队可能又得向其他人证明，才能争取到预算去购买功能测试工具，比如 Selenium。

这是最困难的部分。当这些人去找决策者时，如果决策者不了解 DevOps 的价值，他们可能不会说这是愚蠢的；但他们可能会说你不能这样做，或者因为他们不了解这将如何影响底线，他们可能会直接不予理会。现在解释变得更容易了，因为你可以很容易看到很多行业现在指向那些质量非常高的应用程序，这些应用程序不仅提升了客户满意度和客户参与度，还真正影响了底线。

"现在很多行业都指出，质量非常高的应用程序正在获得更好的客户满意度、更高的客户参与度，并且真正影响了底线。"

—Chris Riley

这正在改变人们的想法，有时候，改变想法几乎是不可能的。但你还面临薪酬结构的问题。如果运*团队的薪酬是为了确保东西永远不会坏掉，那么他们与开发人员之间就会产生直接的利益冲突，因为开发人员的薪酬是为了确保他们能把应用程序快速发布出去。运*人员不希望任何事情发生变化，因为变化可能会导致问题。

当 IT 运*专注于不让开发人员发布任何东西时，他们自然会成为瓶颈。因此，薪酬和组织结构的变化只能从上而下进行。从 100 人的开发团队到 5 到 10 人的开发团队，只是另一种只能从上而下进行的重大结构变化。我认为这就是工作的方向，所有的努力必须在这里投入。

*克托·法尔奇：当你提到开发团队时，你是指那些可以自行开发和运营的自给自足的团队吗？

克里斯·赖利：我知道有不同的方式来处理这个问题，但容器和微服务的酷炫之处在于，它们不仅仅是基础设施工具；它们还是应用架构工具。如果你开始考虑将应用程序构建并拆解成服务，你自然会遇到这样一个事实，那就是我们需要更*的开发团队。例如，你不需要 100 人来编写一个登录服务，你只需要两个人。我认为这种新的架构自然会把组织带向这个方向，这很酷，但他们必须为这种变化做好准备。话虽如此，我仍然倾向于那些拥有 DevOps 工程师、开发人员和质量保障人员的*团队。

除了一些非常罕见的环境之外，我并不完全相信“如果你构建了它，那么你也应该测试并支持它”这一理念。我确实认为，如果你测试了它，你需要测试自己的代码，但自动化的创建应该由其他人来做。我认为，去找开发人员说：“你需要为你的代码编写 Selenium 脚本，”这种做法是不合适的，因为它永远不会完成。必须由其他人来做这个工作。我仍然认为需要有质量工程（QE）团队，可能是一个跨所有开发人员的团队，或者是*团队中的个别成员。

DevOps 部门

*克托·法尔奇：那么，你怎么看待 DevOps 部门呢？今天我看到很多这样的部门，尤其是在大企业中。当我仔细观察这些企业时，我听说他们将成立一个 DevOps 部门，负责为整个公司做 DevOps。

克里斯·赖利：回到我之前提到的那家大型媒体公司，他们的做法就是这样。他们进行实施，但不负责整个组织的实施。他们更关注的是了解什么是最佳实践和最佳工具。他们在组织层面实施的内容包括聊天机器人、与 AWS 或其他云服务提供商的集成，以及那些真正是你会使用的工具，因为它们所集成的服务是全球性的。

每个人都在使用 Slack，因此他们可以为 Slack 创建内容。每个人都在使用相同的云服务，所以他们可以为这个云创建内容。我认为，这就是 DevOps 部门的所在。我不认为你可以走进任何一个组织，说：“我们需要成立一个 DevOps 部门，”然后这就是解决问题的答案。

“DevOps 工程师”作为一个职位对我来说是有意义的，但我认为你不一定会有 DevOps部门，也不需要去追求这一点。相反，我认为 DevOps 是一种你应该在整个开发组织中推广的原则。你应该以一种支持这些举措的方式来改革你的组织，而不是仅仅说你需要建立这个 DevOps 单位，然后就完成了——你就是 DevOps 了。因为那样做的话，你真的需要赋能那个单位，而大多数组织并不愿意这么做。你不能只是让人们去比赛建立 DevOps，结果却不给他们实际做的工具。我认为这通常是你只是建立一个 DevOps 组织之后发生的事情。

“‘DevOps 工程师’作为一个职位对我来说是有意义的，但我认为你不一定会有 DevOps 部门，也不需要去追求这一点。”

—Chris Riley

Viktor Farcic：在我看来，建立一个 DevOps 部门反而会形成另一个孤岛。我曾经听过一句话——这是我非常喜欢的描述——那就是 DevOps 完全是关于同理心的，通过将不同的人聚集在同一个团队里，你培养了人们之间的同理心，他们最终理解彼此的痛苦。

Chris Riley：说这些话的唯一问题是 CFO 根本不在乎同理心，而有钱的人可能根本不关心这个。人力资源部门可能会在乎，但这就是销售任何东西的问题。你必须讲他们能听得懂的语言，而 CFO 会关注金钱。要么你为我们省钱，要么你为我们赚更多的钱，我认为 DevOps 两者都在做，这很酷。我觉得这段解释的好处在于它看起来并不是不可逾越的。这就像皮克斯的结构一样。

在史蒂夫·乔布斯加入皮克斯后，他构建了所有的工作环境，目的是创造员工之间偶然相遇的机会，这样即便他们没有任何实际的理由互相交流，某个电影的图形设计师也能和另一个电影的应用开发人员交流。皮克斯的做法是，因为每个人都需要上厕所，他们把厕所设在一个大共用区域，让这些人能偶然遇到对方——这就是创造同理心的方式。这样，他们就能理解彼此的工作，彼此对对方的电影充满兴趣，对自己正在做的事情感到兴奋，并且在他们做的每一件事中都意识到这一点。这是一个很好的解释。

Viktor Farcic：我同意 CFO 和在公司高层职位的年轻人大多了解金钱。你如何将这一点转化呢？你会怎么说，如果你做 DevOps，你能赚到什么？它如何转化为金钱，你又如何衡量它？

克里斯·赖利：有时候似乎没有直接的衡量标准。当我与那些构建业务应用程序和内部应用程序的组织沟通时，我会用不同的方式解释问题，因为在这种情况下，用户满意度就没有那么重要了。因为他们的用户并不付钱给他们，而且他们也不会离开。用户会按要求去做。

顾客满意度是值得关注的。从 SharePoint 领域过来，我对此非常了解。如果组织内部的人不喜欢 SharePoint，他们就不会使用 SharePoint。由于不使用 SharePoint，你的计划就无法实现。所以，用户确实很重要，用户体验也同样重要，既包括外观和感觉，也包括保持更新和及时解决问题。如果有人遇到 bug，它就会被修复。

通常，在业务应用场景中，修复一个 bug 至少需要三个月时间，到那时，你的客户——通常是那些讨厌自己工作内部的用户——已经变得不再高效。这个效果随后会呈现出雪球效应。所以，这就是业务应用的情况。

如果你是一家银行，你的目标是避免失去客户，因为这是一个高度竞争的市场，而且默认情况下，大家都讨厌银行。首先，你会想要创建一种降低成本的客户体验，因为人们不再频繁光顾你的分行，也不再频繁拨打你的客户支持电话。其次，你可以更快地推出新的产品——新的支票账户，或者其他什么产品——这意味着你可以更快地吸引这些产品的客户并与他们建立更多的联系。所有这些都无法实现，除非你有一个真正强大的应用程序，而这个强大的应用程序是会有 bug 的，因为 bug 是不可避免的。你需要能够应对这些 bug，因为如今的客户非常挑剔，而你不能改变客户。

你还需要适应客户使用应用程序的方式和他们的期望。他们的期望就是应用程序能够正常工作。他们希望看到你频繁地进行更改，更快速地解决问题，并且对他们的使用行为做出响应。所有这些现在都是期望，除非你是一个认为自己足够强大能改变世界用户行为的组织，否则你需要能够回应这些期望。因为如果你不回应，你无论做什么都会失去客户；至少，你会有一群愤怒的客户，他们需要更多的支持，而这将使你与客户群体合作的成本增加，也让你更难向他们销售新产品。

*克托·法尔奇克：这是一个有效的观点，我觉得很有意思。

Chris Riley：实际上，任何组织都能感同身受，究竟是失去客户、无法竞争，还是无法快速执行新的计划，最终都会归结到那一天。对我来说，这看起来像是一个显而易见的决定。如果你和一个真的会反对这个的人待在一起，那我只能想，“好吧，不管你知不知道，这事儿都会发生在你身上。”

以苹果为例。苹果正在以一种非常隐秘的方式进入银行业。它将通过 Apple Pay 悄悄渗透这些银行，因为现在，借助 Apple Pay，我可以给你发送带钱的短信。如果你没有绑定的银行卡，你现在拥有了苹果提供的信用和账户，而他们这么做只是因为他们能够做到。这应该会让银行感到害怕。

我觉得这就像是，“好吧，这会发生在你身上，你会后悔的。”你会失去工作，但在你进入下一个公司后，由于你在之前的工作中积累的经验，你将成为该公司最大的 DevOps 支持者。

Viktor Farcic：虽然我同意你说的很多内容，但我有一种感觉，你主要是在谈论内部开发。你对那些将软件外包，进而将其商品化的公司有什么看法吗？

外包和软件的商品化

Chris Riley：这是一个有趣的观点，我要大胆一点。我不想让某个行业感到疏远，但我认为这些外包公司希望能够接受 DevOps，不仅是因为他们必须支持客户，还因为他们希望更快、更好地构建应用程序。

话虽如此，我认为技术如今已经成为商业的核心组成部分，外包应用程序开发是一个巨大的错误。我只是觉得公司不应该做这样的事。经历过这种事情后，我知道它是如何运作的，我也知道谈判的过程，因为你必须屈从于开发公司在技能、资源等方面的限制。做出改变以及围绕变化的复杂性是非常困难的。我认为除非财务上不可行，否则任何组织都不应该考虑外包。但你必须对自己诚实，当你说自己在做一个平庸的应用程序时，如果是因为钱的问题，你必须能接受这一点，而且你必须知道，最终你会不得不从外包中回归。

比如，有一家公司构建了一个影响者营销平台，前面三个版本的效果并不理想，主要是因为有很多 bug。但这个平台解决了一个问题，人们感兴趣，它有效，他们得到了客户——但它并不完美。然后这家公司决定转向内部开发，当他们转向内部时，他们专注于招聘一位了解 DevOps 的开发经理，之后一切都改变了。正因为这个转变，他们的应用程序质量飞跃提升。它变得非常棒，这是一家非常*的公司，现在他们的平台非常酷。

“我认为这些外包公司希望拥抱 DevOps，因为他们不仅需要支持客户，而且还希望更快、更好地构建应用程序。”

—Chris Riley

Viktor Farcic：我认为这只是一个问题，是否公司已经意识到他们是一家软件公司。如果是，那么软件开发就是核心业务，没有人会争辩说核心业务不能外包。关键是公司是否意识到如今每家公司都是一家软件公司。

话虽如此，我很好奇关于信任的问题。你如何相信一个外部公司能够做好如此重要的工作？你能外包开发工作，同时保持控制和质量吗？

Chris Riley：你在一个约会网站上也能看到相同的情况，这类网站通常是完全外包的。我认为从 SecOps 和应用程序开发的角度来看，这是很有趣的。AshleyMadison.com 就是一个很好的例子。他们所有的开发工作都是外包的，我们都看到过那件事的结果。他们盲目地接受了正在开发的内容，结果却成为了一个巨大的漏洞，简直是愚蠢。我认为，组织不加密其数据库中的密码应该是违法的。如果你这样做，那你应该违反了某种法律，因为这对你的用户不公平，因为当你外包时，你并没有真正控制这些数据。

我只认为，组织需要将开发工作保留在内部，外包的唯一理由是如果财务上真的不可能。如果财务上不可能，你必须意识到你只会短期外包。

Viktor Farcic：说实话，当你看到一个优秀的开发人员能够做出多少工作时，你必须质疑财务可行性，尽管他们可能很昂贵。

Chris Riley：毫无疑问。我们在 Sweetcode 有过这样的经验，这也是我对此话题充满热情的原因。我们内部有一个平台，用来简化研究的过程，基于研究来决定我们要写的内容，找到我们的贡献者来写，然后写作并发布。

我们有一个平台来简化流程，因此完成它所需的手动工作更少。我们已经写了三次这个平台。第一次我写的时候，效果非常糟糕。第二次，我们找了一个外包公司。我对应用开发了解足够多，因为我在架构方面非常擅长，所以我处于一个可以审查他们代码的奢侈位置，因为我知道发生了什么。大多数组织没有这种情况。我意识到质量非常糟糕。虽然功能是有的，但质量差到任何新加入的开发人员都无法接手。在那种情况下，最好的选择就是重写。

我唯一想说的是，对于那些对应用开发一无所知但有一个好点子的人，他们可能不得不求助于专业公司，而这就是一个糟糕的局面。我的意思是，如果你是创始人，几乎每家公司都必须有一个应用，就像每个初创公司都必须有一个技术创始人一样。

“对于那些对应用开发一无所知，但有一个好点子的人，他们可能不得不求助于专业公司，而这就是一个糟糕的局面。”

—克里斯·赖利

*克托·法尔奇：这是否意味着，如果我外包某个东西，那么那个东西可能是我认为不属于核心业务范围的东西？听起来好像是在说，“哦，软件对我来说不重要。让我把它放到像清洁服务那样的框里”，类似这样的意思。

克里斯·赖利：你说得对——我的意思是，我们公司外包的是什么？我们外包法律事务，这实际上非常重要，我们外包簿记、会计师和人力资源。我们不是从事法律、会计或人力资源业务的。

你完全正确，它们都是很好的服务，但对我们来说，这些并不重要，因为我们所构建的产品和服务，并不需要将它们带入公司内部。我认为你说得对，如果你不够重视这些，那么你就根本不在乎。

*克托·法尔奇：最后，我想问一下，您有没有什么建议给那些刚刚开始 DevOps 之旅的人？

开始你的 DevOps 之旅

克里斯·赖利：DevOps 文化无论如何都会到来。它可能伴随着一场血腥的混乱或某个共鸣的时刻，但只要组织专注于自动化和更早地发布更好的应用，它就会自然而然地到来。

因此，我不建议组织浪费时间讨论沟通或文化。相反，我认为他们应该对每天的发布数量、问题响应时间和自动化百分比设定指标，并将这些目标与奖金和工作表现挂钩。

如果组织推动更频繁的发布和更好的应用质量，那么他们就会弄清楚文化问题，他们也会学会如何更好地沟通，因为这些都会成为主要的障碍。

有些人通过员工流失发现问题，而其他人则经过大量争论后才会明白。但与此同时，如果这些内容是自上而下传授的，那么同一个组织一开始就会扭曲文化的教训。

*克托·法尔西奇：太棒了，非常感谢你的时间。

第二十九章

10

第三十章：Ádám Sándor

云技术顾问

第三十一章：介绍 Ádám Sándor

Ádám 通过利用云技术来提高商业中的软件交付速度。他是认证的 ScrumMaster 和认证的 Kubernetes 管理员，Ádám 将大部分时间投入到 DevOps 技术中。您可以在 Twitter 上关注他，用户名是 @adamsand0r。

*克多·法尔奇：首先，您能告诉我们您认为什么是 DevOps，以及您如何在职业生涯中使用 DevOps 吗？

什么是 DevOps，它是如何使用的？

Ádám Sándor：我是一个从 Java 开发者转行的云原生顾问，目前在一家总部位于阿姆斯特丹的咨询公司 Container Solutions 工作，我们帮助企业适应云原生技术，并探索 DevOps 中的最佳实践。

我认为 DevOps 是一种软件开发方式，它打破了开发软件的人和运行生产环境中软件的人之间的障碍。理想情况下，这意味着一个团队可以负责在生产环境中运行自己的软件，这样可以提高修复问题的速度。DevOps 还可以改善软件设计，因为开发人员可以获得大量反馈，这使得他们可以以一种能够运行这些解决方案的方式来设计解决方案。我非常相信这是“你构建，它就由你运行”哲学的一部分。

*克多·法尔奇：但是为什么有人会想做这个呢？

Ádám Sándor：因为 DevOps 有助于加速软件交付，同时减少部署过程中出现问题的风险。DevOps 还帮助满足日益增长的需求，通过快速交付新功能以及修复客户遇到的任何问题，从而提高客户满意度。

“DevOps 是一种软件开发方式，它打破了开发软件的人和运行生产环境中软件的人之间的障碍。”

—Ádám Sándor

*克多·法尔奇：那么，您如何开始实施 DevOps 过程呢？

Ádám Sándor：在 Container Solutions，我是云技术顾问，我们首先进行一个发现过程：我们两个人会去一家已经在使用某个想法的公司。在一些售前会议后，我们进入发现过程，因此我们已经有了对他们问题的初步了解，以及他们希望解决的内容。问题通常集中在他们的软件交付过程中。在几天的时间里，我们进行研讨会，探索公司的软件环境、交付过程和整体架构。这让我们了解公司发生了什么，并验证客户所识别的问题是否是他们真正需要解决的实际问题。确保我们解决的是真正的问题，而不是对客户可能遇到的坏情况做出一些快速反应，这是非常重要的。

这里可以做个类比，就像医生看到一个头痛的病人，并不是因为病人头痛就直接给他一些阿司匹林，而是先听取病人的描述，可能会发现病人需要改变饮食习惯。在我合作的公司背景下，有的公司可能邀请我们来安装 Kubernetes，以提高软件开发效率。但我们仔细一看，发现他们的软件交付过程涉及三个部门。首先，开发人员编写软件。然后它会经过测试部门，最后交到运*部门。现在，真正的问题就在于这个过程！Kubernetes 并不会改善这家公司软件交付的效率。该公司的问题本质上并不在软件层面，因此我们尝试说服他们打破这些部门间的壁垒，令团队对其生产环境负责。一旦这个问题解决，我们可能会引入 Kubernetes 来更高效地实施新的流程。

*克托·法尔奇：你发现过人们因症状错误去看医生的情况吗？人们在一开始就知道他们的技术流程出了什么问题吗？

亚当·桑多尔：我很难给出一个确切的数字，说明有多少人带着错误的症状来找我们，但这种情况是双向的，有时候客户的判断是非常准确的。他们可能已经做了足够的功课，带着明确的思路来找我们，知道自己的问题所在，并有解决方案。但即便如此，他们仍然可能在实际执行解决方案时遇到困难，而这种情况通常是因为他们没有掌握所有必要的内部知识。在这种情况下，我们就能为他们提供帮助。

但有时，客户可能对他们的症状有很大的误解，甚至到了我们无法帮助他们的程度，因为他们根本不准备改变。在这些极端情况下，一家公司可能会盲目寻求新的技术来解决问题，而没有真正识别出当前面临的根本问题。

Kubernetes——解决我们所有问题的方案？

*克托·法尔奇：我了解到你们主要使用 Kubernetes，这意味着你们紧跟最前沿的技术。这是你们担心的问题吗？

亚当·桑多尔：我们从未经历过这种技术失败的情况，因此从这个角度来看，它不是一个问题，毕竟它是最新最好的技术。我们从不建议客户轻易尝试某个新技术，尽管我们一直在关注新技术的前沿，随时准备迎接即将到来的挑战。通常情况下，我们建议使用那些已经至少证明自己有效一年的技术，且我们知道它们能够为客户提供帮助。

*克托·法尔奇：这意味着每个人都应该迁移到 Kubernetes 吗？这需要做哪些工作？我想，这不仅仅是创建新的 Docker 镜像和 YAML 文件吧。如果我是一个已经存在很长时间的公司，而且我什么都有了，那对我来说意味着什么？

Ádám Sándor：对于这样一家公司，起步会是一个概念验证，证明 Kubernetes 是否适合你。根据短期计划，这个概念验证要么集中在将传统应用迁移到 Kubernetes 上，要么集中在使用公司计划转向的技术创建新事物。公司是否希望将部分或所有的传统应用迁移到 Kubernetes 上，取决于很多因素。我想指出的是，这样做既不是不可能的，也不是不可取的。

Kubernetes 实际上是一个非常适合支持传统应用的系统，例如，像能够使用文件将配置注入到 Pod 中这样简单的操作。你可以非常容易地模拟基于配置文件的环境，适配那些需要大量配置文件的传统服务，因此容器是一项相当向后兼容的技术。

“Kubernetes 实际上是一个非常适合支持传统应用的系统，例如，像能够使用文件将配置注入到 Pod 中这样简单的操作。”

—Ádám Sándor

Viktor Farcic：我还想知道，如果你们站点有一个管理不善的传统基础设施，且应用设计很糟糕，你想把它们迁移到容器和云端，你会先把它们迁移到现场的 Kubernetes 上，然后再转向云端，还是先迁移到云端而不使用 Kubernetes，或者两者兼顾？

Ádám Sándor：如果可能的话，使用云服务商。他们会做很多 Kubernetes 和其他服务的重担管理工作，解放你的资源，让你能专注于更具业务中心的任务。但也有合理的理由不这么做——比如对新数据中心的巨额投资，数据存储的法规要求等等。

Viktor Farcic：那不会产生防御性政治吗？因为如果你有一支负责现场基础设施的工程师队伍，如果我们把所有东西都迁移走了，那这些人怎么办？他们会有工作空间吗？

Ádám Sándor：我不知道是否会有足够的空间来容纳所有人，但我从未见过一个项目，里面的人因为不再需要而不得不被解雇。是的，使用云服务商时，你不需要运行 Kubernetes。但实际上，设置开发和部署工具，以及追踪部署情况的系统，依然有很多工作要做。这就是我提到的以业务为中心的工作——淘汰低附加值的工作，转向能为业务带来更多直接价值的事情。

探讨变革的动机

Viktor Farcic：你认为是什么驱动了这些改进的请求？是竞争的压力，还是对新技术的真正兴趣？

Ádám Sándor：我认为我们看到的最大动机，也是大多数公司忽视的，是能够快速发布软件的能力。他们意识到自己应该每半年发布一次新软件，但他们需要在竞争对手已经赶上之前，尽早意识到这一点，并采取适当的流程，确保生产管道充实。如今市场中的巨大压力最终让工程师离开，因为坦白说，这真的是一个糟糕的工作环境。

还有对新技术的兴奋，因为当市场上的公司在寻找工程师时，他们的 HR 部门感觉到新招聘的人会问：“你们使用什么技术？”当他们听到使用的技术不是最新版本时，这些新招聘的人就不再对加入公司感兴趣。管理层最深切感受到的是，当他们有了一个新想法时，等到他们将其投入生产时，已经太晚了。

“管理层最深切感受到的是，当他们有了一个新想法时，等到他们将其投入生产时，已经太晚了。”

—Ádám Sándor

Viktor Farcic：我之前听说过，一个动机并不是管理层改进的动力，而是吸引和留住人才。

Ádám Sándor：绝对如此！

Viktor Farcic：这是否意味着工程师变得挑剔了？

Ádám Sándor：工程师变得挑剔了。如果他们在自己的工作上有些能力，他们是不会加入一个需要手动安装 Linux 服务器的公司的。

Viktor Farcic：我只是在想，这与将开发外包给第三方的政策有些矛盾，因为你可以选择一个地点，然后决定把一切交给别人。

Ádám Sándor：我认为“让我们把一切都交付出去”的心态之所以存在，是因为外包趋势已经不像以前那么强烈了。我不是这方面的专家，因为我只在市场的一个*部分工作过，但我看到了一些公司进行内部化，也看到一些公司外包，但在较便宜的国家建立长期的开发团队。他们不会把这些开发团队当作一次性劳动力，而是知道他们在为长期使用而建立这些团队，同时尝试将这些团队整合进公司，成为一流的员工。

我认为公司和员工开始意识到，想要吸引人才，就得留住人才。即使你没有面临在其他国家招聘员工的挑战，通常在东欧或印度，人们也需要了解公司、产品以及当前应用和基础设施的状态。招聘过程本身就是一项昂贵的工作。你希望能长期留住员工，并且招到优秀的人才，因为那些不太有经验的人更难培养。你可以以较低的薪资雇佣某人，但之后却需要花半年的时间来让他们熟悉工作，这不仅会花费大量金钱，还会浪费更多时间。

Viktor Farcic：那是不是经济因素正在促使公司远离外包呢？

Ádám Sándor：我认为这也是整个 DevOps 文化的新发展方式：即你构建它，你运营它，团队所拥有的其实是一个产品。你把团队与产品结合起来。产品负责人、设计师和业务分析师——每个人都是产品团队的一部分。你希望让他们与这个产品保持长期的联系，因为他们真正理解它。公司开始真正重视这种长期的参与，而这正是外包和雇佣临时员工所无法做到的。

Viktor Farcic：那么，接下来会是什么呢？是否有新的事物即将出现，还是我们还得继续使用 Kubernetes 一段时间？

超越 Kubernetes 的未来

Ádám Sándor：我有点惊讶，下一步的进展竟然这么慢，可能是因为 Kubernetes 在行业内的普及程度还不够。但我确实相信，一旦 Kubernetes 得到更广泛的应用，下一步将会是基于 Kubernetes 构建的产品。但在此之前，Kubernetes 正处于一种停滞状态，因为它比虚拟机和低层网络服务更高层次。

我相信，未来要么是 Kubernetes 会整合更多的功能，最终转变为一种与现在有些不同的形态，要么是会有其他基于它构建的产品出现。但我不认为这些产品会很快出现。我认为 Helm 是一个很好的例子，但那并不是一个商业产品。

“Kubernetes 在行业内还没有得到广泛应用。但我相信，下一步将会是基于 Kubernetes 构建的产品……在那之前，Kubernetes 可以说正处于一个停滞不前的状态。”

—Ádám Sándor

Viktor Farcic：如果你想在本地运行 Kubernetes，你会推荐我在虚拟机上运行，还是在裸金属上运行？

Ádám Sándor：老实说，我并没有对这个问题有深入的看法。理论上，在裸金属上运行 Kubernetes 会更高效，但低层网络的相关问题可能会让人感到困难。也许最好让像 VMware 这样的解决方案来处理那些真正低层的硬件问题；在这种情况下，提升虚拟机的性能反而会更好。我不认为 Kubernetes 在这个环境下已经足够成熟，但说实话，我并不是专家。

Viktor Farcic：你有过 unikernel 的经验或者意见吗？

Ádám Sándor：我没有太多经验。我看到的是，它们是一个很好的想法。如果你从高层次看，它们完全可以战胜容器，因为它们具有容器的优点，同时又在虚拟化管理程序上运行，而虚拟化管理程序本质上就是公有云——巨大的虚拟化管理程序。

但我也看到的是，unikernel（单内核）似乎成熟得不够快，无法吸引足够的关注。工具链根本不够完善。实际上，云服务提供商并不允许你在他们的虚拟化管理程序上运行任何你想要的，只能运行他们自己的虚拟机镜像。所以从理论上讲，它是可以实现的，但在实践中，目前并没有真正发生，而且我没有足够的行业洞察力来知道，亚马逊是否在秘密地做些什么。

Viktor Farcic：其他云服务提供商怎么样？这是我同意的观点，如果我错了请纠正我，但对于我们大多数人来说，不使用像 AWS 或 Google 这样的云服务提供商是没有意义的，因为它们已经商品化，并且比我们更了解他们在做什么。这对围绕基础设施和配置管理工具构建的软件和厂商的未来意味着什么？

Ádám Sándor：我认为配置管理工具不会因为云服务提供商的存在而变得过时。你完全可以使用 Puppet、Chef 或 Ansible 来配置你的 AWS 基础设施。

Viktor Farcic：但是，你应该做吗？或者说，你能做吗？

Ádám Sándor：就目前来看，我认为无论是与云服务提供商一起使用 Puppet、Chef 和 Ansible，还是与本地基础设施一起使用，都没有区别。真正处于风口浪尖的是 VMware；他们是云服务提供商的竞争对手。

Puppet、Chef 和 Ansible 的问题在于，它们并没有真正推动你向更好的基础设施发展。它们只是提供了一种更优雅的方式来限制它们在操作系统上提供的抽象级别。这并没有导致一种更好的软件部署方式；它本质上比写一个 SSH 进入机器并运行其他脚本的脚本要更好看一些，但也没好到哪里去，因此你无法获得不可变的基础设施。

如果你启动一千台机器，并且想在它们上运行相同的 Puppet 配置，三台会失败，那你该怎么办？你没有办法处理这种情况，并且加速任何一台机器都需要很长时间，所以从本质上讲，这些工具就是不合适的。如果我们停留在虚拟机的世界里，那么正确的解决方案是预先制作镜像并进行管理。

这就是 Docker 的作用，因为安装和预先制作虚拟机是件麻烦事。没有什么像黄金镜像这样的东西可以扩展，因此 Docker 出现并解决了这个问题，但它们不是通过虚拟机来做的，而是通过构建容器镜像来实现的。

*克托·法尔奇：这是否意味着它们的潜在用途就是构建这些镜像？

亚当·桑多尔：可能是这样的。但当你在构建镜像时，其实没人需要在 Docker 文件中使用 Ansible，虽然他们可以这么做，但我认为没有人觉得非得这么做。实际上，我们又回到了脚本化，因为这样就足够了。

*克托·法尔奇：根据我的理解，我喜欢这些工具，因为无论我的服务器处于什么状态，它都会将镜像收敛到预期的状态。

亚当·桑多尔：如果我在构建镜像，那么我知道初始状态是 Vanilla Ubuntu……

*克托·法尔奇：没错。我不太明白为什么我不直接运行一个 shell 脚本。我需要 apt-get 来安装这个；我不需要检查它是否已经安装，因为我知道它没有。

亚当·桑多尔：有趣的是，实际上这些工具确实有效。Kubernetes 做的事和它一样；它将状态收敛到应该存在的地方。从这个意义上来说，它做的事情和 Ansible 没有区别。Kubernetes 实际上做得更好，因为它是在一个完全不同的抽象层次上执行的。当你已经有了预构建的镜像，只需要管理这些镜像的实例时，你就可以做动态状态管理，这样就可以了。

没有人为不可变的 Kubernetes 集群而哭泣，但你在操作系统内部做的所有低级操作，比如在这里放置一个文件，在那里复制另一个文件，设置一个标志等，这些才是你希望提前处理并完成的事情，除非你要构建一个新的镜像，否则永远不再触碰。

*克托·法尔奇：这意味着你跟随不可变性和预构建镜像的逻辑。那么这是否意味着，并不是总是如此，但有时候，实际上在 Kubernetes 中使用 ConfigMaps 做的事情是错误的，如果目标是不可变性的话？

亚当·桑多尔：是的，不可变性需要在某个地方停止。Kubernetes 本身是一个超级动态的系统，所以，没错，它确实与不可变性相矛盾。但简单来说，不可变性在一定程度上是有意义的。我见过超级可配置的应用程序，如果你把这些应用程序放进 Docker 容器，你需要配置 150 个环境变量来设置那个镜像，这显然不是你想要的基础设施方式。

*克托·法尔奇：我们需要那些东西吗？

亚当·桑多尔：你真正想要的只是确保在不同环境之间只有少数非常特定的差异。获取它们，配置它们，其他的就不要再动，除非你在构建像数据库镜像这样的东西，而这些东西当然需要在成千上万的环境中运行。但如果是这种情况，你可以再次锁定一些参数，从中构建自己的镜像，并且每个环境只更改那些你需要的参数。理想情况下，你的所有环境应该是完全一样的，你应该查看那个状态，然后尽可能少地偏离它。

Viktor Farcic：什么会是“少”的意思？副本的数量？

Ádám Sándor：副本的数量，用户密码，等等。这些基本的东西。证书、公共主机名等等。

Ubuntu 和 Red Hat 在这个新世界里

Viktor Farcic：我喜欢讨论哪些东西正在变得过时。这让我回想到了操作系统。我们在这个新世界里还需要 Ubuntu 或 Red Hat 吗？

Ádám Sándor：简单来说，是的，我们需要。目前，有两个地方需要使用操作系统。一个是在运行容器的服务器上，另一个是在容器内。所以，在运行容器的服务器上，我们已经看到转向非常简化的操作系统，这些操作系统只做最基本的事情。

"[在这个新世界里，我们还需要 Ubuntu 或 Red Hat 吗？] 简单来说，是的，我们需要。"

—Ádám Sándor

Viktor Farcic：我在想像 Rancher 和 CoreOS 这样的平台。

Ádám Sándor：没错。以 CoreOS 为例，它非常简化，只启动容器，仅此而已。它运行 Docker，就这样，容器内的操作系统就是这样。

Viktor Farcic：那算是操作系统吗？

Ádám Sándor：嗯，我们可以称它为操作系统，因为它像操作系统一样工作。但当然，它是从实际运行它的机器上窃取了内核，同时依然假装自己是操作系统。从某种意义上讲，它确实是一个操作系统，因为所有工具都已安装，所有程序都在 Linux 发行版里。我们需要这些东西吗？通常，我们不需要。是的，它们在调试时很有用，而且它们对更旧的应用程序也有帮助，但“遗产”在这里是一个非常宽泛的概念，因为在一个仅有内核的裸 Linux 上安装 JVM 是非常困难的。

所以，可能可以在其周围使用一些 Linux 发行版。也许将来有人可以制作一个非常精简的镜像，里面只有 JVM 需要的东西。如果能做到那样就好了，因为那样会更安全且更*巧，但我真的认为 Docker 如此受欢迎的一个主要原因是它在向后兼容性上的表现——也就是说，在镜像里，你只是做 Linux 相关的操作。很容易就能进入这个环境，因此它提供了很多好东西，却几乎没有什么牺牲。镜像里有些程序实际上并不被使用，这并不是一个大问题。

Viktor Farcic：我推测，从某种意义上讲，这会对像 Red Hat 这样的公司构成威胁，因为你刚刚提到 Ansible 和 Red Hat 的相关性正在降低。

Ádám Sándor：Red Hat 知道这一点，这也是他们构建 OpenShift 和 Red Hat Atomic Linux 以运行 OpenShift 的原因。

"Red Hat 是那个早期识别 Kubernetes 并迅速加入的聪明公司。现在，他们已经达到了可以几乎放弃自家 Linux 发行版的地步，因为他们在 OpenShift 上有了新技术。"

—Ádám Sándor

红帽公司是最聪明的那个，他们早早认识到 Kubernetes 的潜力并迅速加入。现在，他们几乎可以放弃自家的 Linux 发行版，因为他们在 OpenShift 上拥有新的技术。而同时，Ubuntu 和 Zeus 都在努力跟上，但问题在于它们远未达到红帽的水平，这也是红帽已经能够收购 CoreOS——他们在这个领域最大的竞争对手——的原因。

*克托·法尔奇：你更喜欢哪一个？原生的 Kubernetes？还是更倾向于在其上进行二次开发？

亚当·桑多尔：我确实喜欢 OpenShift。如果有人愿意为此付费，那么它所提供的支持和安全性是值得的。Kubernetes 就像 Linux，有无数人在为其贡献代码，发生了很多事情，所以没有人会严格遵循治理流程，这完全没问题。但假设你想为你的银行构建一个内部云平台，你肯定希望确保其安全，虽然当然没有人能绝对保证安全。红帽通过 OpenShift 提供的功能和安全性是合乎逻辑的。

*克托·法尔奇：如果我不愿意付费，应该选择 OpenShift Origin 还是 Kubernetes？

亚当·桑多尔：我认为你必须选择你更看重的东西。如果你看重快速的更新、全开放源代码的特性，那你会倾向于选择 Kubernetes；而如果你看重较慢的更新、更高的稳定性以及不完全开放的特点，那么你可能会选择 OpenShift。然而，OpenShift 也有一些额外的特性，比如 CI/CD 流水线和不错的图形界面，这些可能会受到一些人的青睐。但也有些人可能不喜欢。所以这是一个权衡。OpenShift Origin 当然是开源的，但你不会在其中修复 bug。

*克托·法尔奇：你有什么想法？

亚当·桑多尔：云服务提供商比较。

*克托·法尔奇：你怎么看待其他云服务提供商，除了那三大巨头之外？比如 Microsoft Azure。

亚当·桑多尔：我不太了解其他云服务提供商，但目前如果选择任何云服务提供商，我会关注他们的托管 Kubernetes 和无服务器服务质量，因为你需要这些来构建现代软件。但即使 Google Cloud 的 Kubernetes 服务是目前最好的，它似乎也无法占领大部分市场份额。

*克托·法尔奇：我认为很多读者会对 Google 在某些领域被认为是*玩家这一事实感到震惊。

Ádám Sándor：这很奇怪，但是真的。Google 在公共云领域确实犯了大错。几年前他们的战略完全崩溃了。有趣的是，亚马逊的新做法也是试图跳过容器，定义未来，这就是 Lambda 的整体概念。这是一种受限的编程模型，但具有出色的可扩展性，非常适合云原生。实际上，Google 曾经也做过类似的事情，在早期推出了 App Engine。他们将所有的赌注押在了无服务器的尝试上，但那时实在太早了。他们当时的想法是，“我们不做这种原始的虚拟机启动方式，因为网络就像 VMware 一样。” 他们提供了一个合适的编程模型和一个特殊的数据库，这样你就会深深绑定在云中，但它非常适应云原生，且从云提供商的角度来看，运行应用程序也很便宜。

这个想法很棒，除非人们说，“我只想进入一个图形界面，点击然后启动一个虚拟机，然后做我过去 20 多年一直在做的事情。” 现在这种情况正在慢慢变化，因为 Docker 容器变得流行，因为你仍然可以做以前做的事情，只不过方式略有不同。

“Docker 容器变得流行，是因为你仍然可以做以前做的事情，只不过方式略有不同。”

—Ádám Sándor

Viktor Farcic：如果我没理解错的话，Kubernetes 不就是在一个供应商之上，抽象出该供应商正在做的事情吗？理论上，如果 Kubernetes 是稳定的，无论我是在 Azure、AWS 还是 Google 上运行，它应该做的事情是一样的。但是这对业务而言不是威胁吗？那么，什么会成为区分的标准？作为用户，什么会阻止我从一个供应商切换到另一个供应商呢？

Ádám Sándor：价格。如果 Kubernetes 真的成为了一种商品，那它的核心竞争力就会变成价格。但事情不止如此，围绕它的服务也很重要。机器学习做得怎么样？这是他们真正区分开来的地方，并试图通过像 lambda 这样的方式来吸引你，在那里他们也可以将你绑定到他们的代码执行环境中。

Viktor Farcic：但他们真的会关心 Kubernetes 之外的附加服务吗？

Ádám Sándor：当然，Kubernetes 做不到的东西还有很多。数据库、机器学习、DNS 等。云提供商的生态系统确实非常重要，生态系统与 Kubernetes 的整合深度以及 Kubernetes 本身的质量也同样重要。

Viktor Farcic：所提供的服务是区分不同供应商的关键。我认为不会有任何供应商能在所有服务上都比其他供应商更好。一个在机器学习方面更强，另一个则在大数据等领域更有优势。那么，这是否意味着未来我们会在多个平台上运行自己的集群或多个集群？

未来会围绕集群展开吗？

Ádám Sándor：对于大公司来说，这可能是有意义的，但涉及的成本相当大，因为云本身的管理各有不同。例如，API 或者 UI 可能会有所差异。

如果你使用的是 Google Cloud，并且在 Google Kubernetes Engine 上运行应用程序，那么管理 Kubernetes 之外的部分其实并不复杂，因为 API 和其他一切都非常好用，但你会有很多代码、Terraform 或者其他编写的内容来处理这部分。将你的应用程序的一部分迁移到 Azure 或 AWS 并编写一些 CloudFormation 来处理定价和其他问题并不那么简单。你必须足够大，才能利用这些协同效应，前提是你明白，使用多个服务提供商并不会很容易。

Viktor Farcic：这是一个很好的观点。我知道本书的其他贡献者也提出了供应商锁定的问题。但可惜的是，我们现在时间不多了。我只是想感谢你今天抽出时间与我交流。

Ádám Sándor：完全没有问题，我真的很享受这次交流。谢谢你。

第三十二章

11

第三十三章：Júlia Biró

Contentful 的网站可靠性工程师

第三十四章：介绍 Júlia Biró

Júlia 是一位经验丰富的基础设施和工具工程师，专注于可扩展系统、自动化和 DevOps。她曾在 Prezi、爱立信等公司工作，现就职于 Contentful，这些经历使她对 DevOps 如何融入现代 IT 实践有着丰富的理解。你可以在 Twitter 上关注她，用户名是@nellgwyn21。

Viktor Farcic：我知道你在 DevOps 领域工作了大部分职业生涯，Julia，我想知道我们能不能从你在 DevOps 方面的经历入手，谈谈你是如何进入这个领域的？

灵光一现

Júlia Biró：我出生并成长在匈牙利，接受过数学训练。我想看看是否可以把我最喜欢的学科从学校带到职业生涯中。然而，这个想法后来证明并不明智。我并不适合做数学工作，反而对更实际的问题产生了更大的兴趣。正因如此，最终有人建议我学习编程，这也使我逐渐走向了 IT 行业。

一旦我决定了，我开始接受软件工程师的培训，最终，我幸运地加入了一家名为 Prezi 的公司，在那里我是一名非常初级的工程师，加入了基础设施/DevOps 团队。就像我脑海中突然亮起了一盏灯。我突然意识到，这种工程领域正是我想要从事的工作，从三年半前的那一刻开始，我可以说我成了一名 DevOps 工程师。

DevOps 的词典定义

Viktor Farcic：现在假设我们正在查找 DevOps 这个词在字典中的定义。我们会找到什么定义呢？

Júlia Biró：在我的词典里，DevOps 是指公司中负责运行服务的团队的职能和责任，以及实现这一目标的相应工具集。它有一个花哨的名字，叫做 DevOps 工具链，但这只是一个流行词。实际上，它就是任何人愿意理解的东西。

“DevOps 是指公司中负责运行服务的团队的职能和责任，以及实现这一目标的相应工具集。”

—Júlia Biró

Viktor Farcic：你能否详细说明一下你所说的“流行词”是什么意思？

Júlia Biró：人们常常认为 DevOps 是一种灵丹妙药，会让你取得成功，并且如果你采用了 DevOps，每个人都会变得更加快乐。但要真正适应 DevOps 的理念，就像是要改变你体内的三个器官，或者变成一种动物。这是一种深刻的结构性变化，除非你从一开始就有这个理想并准备好从*规模着手，否则是很难实现的。你必须从一开始就具备这种灵活性。所以，除非你具备这些条件，否则很难做到，尽管也有成功的例子。

*克托·法尔奇克：根据我了解的情况，您曾在相对较大的爱立信工作，然后又去了相对较*的 Prezi。在这两者之间，您看到了什么区别吗？

朱莉亚·比罗：非常同意，尽管我不认为爱立信（至少我工作过的部分）在任何意义上都是 DevOps，因为我当时工作的产品与 DevOps 完全不同。我看不出 DevOps 如何适用于那些有 15 年生命周期和两年发布周期的产品，这正是爱立信生产的基础设施上运行的软件的情况。我不是说这不可能，只是我没有见过。

但我确实亲眼看到，DevOps 实践中的领导者似乎从公司还很*的时候就开始采用 DevOps 心态，因此他们在成长的过程中带着这种决心。但并不是他们决定把一个大公司转变为 DevOps。

*克托·法尔奇克：您的个人资料中说，您帮助团队完全拥有他们的产品。您是什么意思呢？

“在 DevOps 中有一个概念，团队应该拥有他们的服务，从编写和测试代码到运行它，甚至在出现问题时，他们应该能及时反应。”

—朱莉亚·比罗

朱莉亚·比罗：在 DevOps 中有一个概念，团队应该拥有他们的服务，从编写和测试代码到运行它，甚至在出现问题时，他们应该能及时反应。这是我认为对那些执行这一理念的公司有益的 DevOps 思*。

这个前提的第一个要求是，服务需要是可拥有的，这意味着在规模和复杂性上都能被一个合理的团队所拥有。它应该足够*，以便一个合理的团队能够管理它，这对于微服务来说是成立的。接下来的想法是，一个团队应该负责所有工作，而不是某个人写代码，然后另一个人单独测试，另一个人部署并运行，第三个团队则在半夜被叫醒，当服务出问题时再来解决。我相信，如果公司转向完全拥有模式，大多数公司都会受益，因为那样团队能够更积极、更有创造性地开发新东西，最终，他们会有更高质量的产品，因为团队之间的摩擦减少了，而有一堆工具可以帮助他们实现这一点。

*克托·法尔奇克：我猜您不是在谈论一个 100 人的团队吧？

朱莉亚·比罗：对我来说，一个团队是一个能够在没有人告诉他们做什么的情况下，以有机的方式合理合作的人数。从我的经验来看，我看不出 100 个人如何能一起做到这一点。当然，我不是说这不可能，但我没有过这么大团队的经验。

*克托·法尔奇：在这种情况下，你的团队规模相对较*，但他们需要掌握的专业知识却大大增加。因为这个*团队需要具备测试和部署的能力，还要处理各种其他事务。那些团队是怎么获取这些知识的呢？当我和一些团队沟通时，他们给我的回答仅仅是：“我的团队知道如何编写 Java 的 getter 和 setter。”

朱莉娅·比罗：也许你可以给团队一张纸，让他们在上面构建一个图灵完备的机器，然后从那里开始。开个玩笑！有一种全栈工程师的概念，他们能够编写前端代码和后端代码，在服务客户端架构中都能胜任。但关键在于提供结构化和良好文档化的工具，团队才能真正使用这些工具。就像你学会使用洗衣机和咖啡机一样，或者在我们的案例中，如何学会使用 CI 和部署工具。你需要让它们易于使用，文档齐全，并且得到良好的*护。

DevOps 或基础设施团队的工作是去除复杂性，并将 DevOps 作为服务提供给公司，以及其他仍在负责所有权的团队。团队仍然拥有部署的内容、部署的时间以及部署的地点，但他们不需要大量的访问权限或知识就能做到这一点。

有些领域做这件事相对容易，因为 CI 系统非常易于点击，UI 也做得非常好。诚然，为其他任务创建具有良好用户界面的工具需要更多的努力。你可以创建一个部署系统，点击一个按钮就能部署，再点击另一个按钮就能撤销部署。另一方面，有些任务是 UI 无法满足的，团队需要获得新的知识。例如，在配置管理方面，如果你希望你的团队管理他们服务运行的环境，他们需要学习某种配置管理工具，通常这意味着，“天哪，我需要理解操作系统是什么”，这显然需要比写 JavaScript 更多的知识，除非你采用无服务器的 Lambda 方式（自从本次访谈录制以来，团队理解和管理运行环境的压力已经大大减少，这得益于容器化平台和无服务器技术的普及。*）。

*克托·法尔奇：问题是，当你选择 Lambda 等无服务器技术时，就没有回头路了。

朱莉娅·比罗：但很快，无服务器和 Lambda 会有自己复杂的管理工具。总会有这样一层不断出现的隐藏复杂性的需求，通过构建非常非常复杂的东西来控制这些复杂性，而这些复杂的东西本身也会变得更加复杂。

*克托·法尔奇：既然你是一个站点可靠性工程师，你认为站点可靠性工程师和 DevOps 工程师之间有什么区别吗？

站点可靠性工程与 DevOps

Júlia Biró：根据我的理解，站点可靠性工程是 DevOps 工程的一个子集，是一个非常特定的子集，具有非常不同的目标。DevOps 工程师的工作是让其他团队更加高效，并帮助实施完全所有权原则，而站点可靠性工程师的工作是通过一个非常简单的指标来定义我工作的成功，这个指标就是站点的正常运行时间。

“DevOps 工程师的工作是让其他团队更加高效，并帮助实施完全所有权原则。”

—Júlia Biró

在我的工作中，我为其他团队提供工具，以便他们能够以实现高可用性的方式运营他们的系统。我的工具包为他们提供了良好的工具和测试、监控、告警、简易部署以及简单回退的良好指南。归根结底，我确保他们自己能够以可靠的方式运行他们的服务，掌握这一知识——从如何进行良好的测试到如何有效处理事故。

Viktor Farcic：一方面，这将是管理工具，另一方面，它也将是教学。

Júlia Biró：正是这样！DevOps 工程师的工作不仅仅是提供工具，还需要为团队提供最佳实践。例如，在 DevOps 范畴内，提供一个良好的本地开发环境或一个良好的测试环境给组织。

作为站点可靠性工程师，我对本地开发环境并不感兴趣；那不是我的范畴。就我目前所在的地方来说，我甚至都没有见过我们的本地开发环境，而我已经在那里待了五个月了。但我非常关注的是他们应该进行什么样的监控。监控应该自动为服务安装。事实上，我总是被一连串的问题困扰，我需要回答，比如：如何赋能其他团队让他们创建自己的监控？他们如何能够轻松设置告警？他们如何能够创建良好的仪表盘？什么样的仪表盘才算好？它如何才能始终可用并提供正确的信息？

只有当团队拥有相关工具，并且具备所有相关的知识和概念时，才能期望他们负责地运行自己的服务。这是我的工作之一。举个例子，我目前正在推动公司采用一种新的、更有效的事故处理流程，因为如果我们处理事故的方式更好，那么这些事故就会更短，从而提高我们的可用性，并总体上改善公司的正常运行时间。

Viktor Farcic：如果我理解正确的话，但如果开发团队对他们所做的事情负有最终责任，那么他们是否可以在某种程度上拥有决定权或选择权，比如是否使用 Kubernetes？我的意思是，实际上如果团队说“不，这归我负责，我要用别的东西”，那是否是他们的选择？

Júlia Biró：这里有多个观点。一个观点是，技术栈和工具的统一性通常对公司有益，因为它能够促进跨团队的合作，团队之间的流动性，知识和专业技能的积累与传播，以及代码编写。因此，所有这些因素都表明，如果我们都使用相同的语言，会更好。

但另一方面，考虑到我们任务的异质性，你可能会发现有更合适的工具来完成某项工作。一般来说，自由感（和自治）是不容*觑的。我看到的有效做法是有一到两个标准技术栈可以支持。如果你选择了不同的工具，那么就需要你自己确保达到相同的质量水平，但如果你的团队有时间来做，那为什么不呢？目前，在 Prezi 公司，有两个标准技术栈。有相关的工具、监控、测试等等，如果你选择为用户服务创建另一个技术栈，那么你需要自己构建例如服务间通信、客户端库等内容。

另一个重要的事情是要有一个生产准备清单，并且包含非常具体的验收标准。你可以通过给他们一个简单的选择来帮助他们：偏离标准是有成本的。你让团队为此付出，而不是整个公司，剩下的就是经典意义上的质量和过程控制。做任何你想做的事情，只要确保你符合标准，工具是兼容的，那就可以了。

Viktor Farcic：如果我说，这就像你可以选择你的责任，但从某种意义上讲，实际上是为了让你使用它而使其变得具有吸引力和趣味性，直到你不太想偏离它，你会怎么说？

Júlia Biró：这并不意味着你就不能偏离，因为如果用户体验非常重要，且你实际上需要围绕第三方技术栈提供工具，那么其他人也会开始使用它。只是你想要实现的主要目标是让人们可以轻松地创建新服务并拥有它，因此你希望减少他们不需要做的工作。

这就是所有标准技术栈和工具存在的意义，当然还有对同一工具的技术积累。你不希望人们独立地重复解决同样的问题，比如测试或监控服务的最佳方式 60 次。你想做的是给他们提供好的解决方案，如果这些方案不起作用，他们可以自己寻找解决方案，或者把问题反馈给你。但你的最终目标是减少摩擦，并在可能的地方重复利用知识。

Viktor Farcic：我很好奇，DevOps 中的女性在哪里？我在这个领域很少看到她们。

DevOps 中的女性……或者说缺乏女性

Júlia Biró：嗯，你说的就是我！话说回来，从历史上看，自 1980 年代中期以来，女性在 STEM 和科技领域的比例有所下降。美国国家公共广播电台（NPR）有一篇很棒的文章（https://www.npr.org/sections/money/2014/10/21/357629765/when-women-stopped-coding），讨论了为什么会出现这种情况，我真的推荐给你任何读者。

但如今，我们发现有一种上升的趋势，部分原因是由于多样性差距引起的关注，部分原因是行业的意愿，另一半人口也开始尝试成为工程师。人们意识到，女性的比例同样能在编程中表现出色。但问题是：目前进入科技和编程学习的最简单方式是通过前端。从我自己的经验来看，当我第一次尝试编程时，只是 HTML 和 CSS，这甚至不能算作编程。

“DevOps 的老手们曾经是实际的系统管理员，穿梭于服务器之间，配置路由器，而如今他们已经不再做这些了。但现在的新人成员来自其他软件工程和 IT 领域。”

—Júlia Biró

目前邀请女性进入科技领域的大部分激励措施都从前端开始，她们会接触到前端或动态网站，以及像 HTML+CSS、JavaScript、Python+Django 和 Ruby on Rails 这样的语言和框架。为什么是这些语言？可能是因为它们最容易在家里尝试，因为你可以在厨房桌子上成为一名非常优秀的前端开发者。但基础设施的编排并不是你没有一些资源就能做的，且某些问题只会在一定规模下显现出来。这是一个需要时间让人们逐渐理解的领域。

DevOps 的老手们曾经是实际的系统管理员，穿梭于服务器之间，配置路由器，而如今他们已经不再做这些了。但现在的新人成员来自其他软件工程和 IT 领域，简单来说，当前在这一领域的女性主要处于职业生涯的起步阶段，所以她们更多的是在前端领域，但她们正缓慢且稳步地渗透其中。实际上，不仅仅是我这么说。Stack Overflow 有一份很棒的开发者调查（https://insights.stackoverflow.com/survey/2017#developer-profile-developer-role-and-gender），它展示了这一点。

Viktor Farcic：我之所以问这个问题，是因为我知道你正在与 Rails Girls 和 Django Girls 等组织做很多办公室外的活动。

Júlia Biró：我参与的各种志愿活动都是为了邀请更多女性进入科技领域。我正在与一些非常明确提出这一邀请的组织合作，这不仅仅是为了教女孩技能；更重要的是让女孩或女性知道，她们应该尝试科技，因为这是一个有趣的事情。

我以各种方式参与其中，例如参加 Rails Girls 和 Django Girls，这些是面向女性的开源工作坊。这些是为期一天的工作坊活动，旨在从零开始构建动态网页应用，参与者通常没有编程基础。趣味性来自于，到了最后一天，他们创建了一个能够展示给家人的项目，因为它已部署在互联网上的真实服务器上。这些工作坊的目标是让人们体验到，使用技术创造某样东西是如何运作的。参加这些工作坊后，我认识的一些女性实际上改变了职业方向，学习了 Python 或 Rails，最终成为了职业开发者，现在她们在科技行业有了完全合法的职业生涯。

另一个我参与的领域是将相同的概念应用于孩子们。有人说，女孩到 13 岁时就意识到数学和技术并不是“女孩的事情”。事实上，这篇文章（https://www.theguardian.com/society/2017/sep/20/children-are-straitjacketed-into-gender-roles-in-early-adolescence-says-study）是关于我们在早期青春期如何将性别角色固定化的非常重要的阅读材料。这些项目的目标是希望在这一点之前接触到这些女孩。我们试图通过创作让她们获得与技术的非常好体验，让她们学到，哇，原来这也可以是属于我的。如果她们喜欢，那就太棒了；如果她们不喜欢，那也没关系；她们只不过是和其他 15 人一起度过了一天的工作坊，并参观了一个很酷的办公室。

Viktor Farcic：你有没有尝试过一些旨在让女孩从高中阶段开始接触技术，这样她们可以将这种兴趣延续到大学学位的项目？

Júlia Biró：是的！我们曾经举办过一个儿童工作坊版本，进行了一项为期 10 周的 Processing（https://processing.org/）课程，面向高中女生。我非常自豪，因为一些曾经是我的学生的女孩，现在已经在接受工程师培训了。

但需要注意的是，不仅仅是女性没有机会加入科技行业。我也曾在艺术大学教授过课程，因为我认为编程可以成为艺术创作的一个工具，我想将这个工具传授给艺术家。在这段时间里，我们为艺术家教授了入门编程课程，其中一些人非常喜欢它，甚至尝试在他们的作品中使用它。

我在匈牙利所合作的组织是 Skool（skool.org.hu）——一个由技术教育基金会支持的项目，专注于与年轻女孩合作。这个项目有一个计划，他们与儿童之家中的孩子们合作，这非常了不起，因为这些孩子通常是没有机会接触到技术的群体，而现在他们正在儿童之家里接受为期 10 周的课程。

Viktor Farcic：真是太棒了。

“多样性不仅仅是让更多女性进入这个领域。这也包括让更多来自不同背景的人参与进来，比如帮助那些贫困儿童。”

—朱莉娅·比罗

朱莉娅·比罗：的确如此，因为多样性不仅仅是让更多女性进入这个领域。这也包括让更多来自不同背景的人参与进来，比如帮助那些贫困儿童。技术可以是社会流动的快速电梯。在非常短的时间内，你的收入潜力可以大大提高。你只需要一台笔记本电脑和一条互联网连接，如果你有天赋，你就可以成为一名出色的工程师。但有些人甚至没有这些基本工具的使用权。为那些处于入门阶段的人提供工具的机会是工作的一部分。但同样重要的是要认识到，处于贫困状态会对学习所需的技能产生严重的负面影响，所以缺失的可不仅仅是笔记本电脑。

*克托·法尔西奇：接下来，你觉得技术会发生什么变化？如果你要预测未来，今天有哪些瓶颈需要解决，你认为我们当前面临的主要障碍是什么？

技术的未来与我们面临的挑战

朱莉娅·比罗：这可能听起来有些天真，但复杂性是我们在不久的将来将要面临的最大障碍之一。即使我们使用的是标准工具，我们的基础设施也由许多不同的部分组成，而我们希望能够做到正确。我们无论如何都想记录这些内容，因此我们使用 Terraform。它本身就是一种复杂性。

我的直觉是，Terraform 是一个定时炸弹，因为它很难进行修改和测试，找到合适的使用方法也同样困难。基本上，Terraform 就像是一种新的编程语言，存在很多漏洞。

当你想对微服务环境中的某个服务进行修改时，你也会遇到复杂性。在 Contentful，尽管我们有本地开发环境，但我需要启动六个相关服务才能在本地运行，以便服务器启动并进行测试。这种复杂性与人类大脑能承受的负荷有关，这也是为什么我认为它现在是一个瓶颈。

15 年前，扩展性是一个瓶颈，但现在不是了。如果你做得好，在合理的限制和基础设施扩展的情况下，现在其实是非常非常容易的；现在的瓶颈实际上是技术变化的速度。一旦你达到一定规模，改变技术就变得非常非常困难。但这并不是一个新问题。人们将像曾经困于 Java 一样困于 Kubernetes。

*克托·法尔西奇：你提到了——我不知道该称之为新事物的开发还是创新——但发展速度加快了。你是如何跟上的呢？

朱莉娅·比罗：实际上，我对没有跟上这个进度感到有些愧疚。

*克托·法尔西奇：但是如果发展速度在加快，我们是不是要变成超人了？

朱莉娅·比罗：我不知道，这就是我说它是瓶颈的原因。随着新问题和新技术的出现，技术本身变得更快过时。但与此同时，下一代更好的工具也在以更快的速度出现。尽管如此，这实际上有一个巨大的好处，因为没有人需要在某个工具上拥有超过两年的经验，所以无论你在这个领域工作了两年还是 20 年，实际上都没有太大关系。这意味着，最终，进入这个领域将变得越来越容易。

例如，我不需要做十年的实际系统管理员才能成为一个有效的基础设施或站点可靠性工程师。不像我，许多同事比我多 10 年经验，其中一半是在互联网黄金时代担任系统管理员。公司能够采用新技术的速度可能会受到心理限制，而且不会比这个速度更快。但是关于你提到的学习问题，就像其他一切一样。如果人们把精力投入其中，每天工作八*时，然后再花八*时阅读下一个东西，那么他们就会变得非常擅长。

*克托·法尔奇克：这是否意味着，如果一家公司能够跟上趋势，那么在那里工作的人需要有时间来学习和深造？

朱莉娅·比罗：当然！我总是说，我的工作就是理解新事物，然后把它自动化。所有我曾经解决过的问题都应该被自动化，或者至少被记录下来，这样我就不需要再次寻找答案。如果有时间，最好是自动化，这样就没有人需要再去考虑它们。当然，也有时间去参加像会议这样的活动，因为其余的只是编程，而编程当然不仅仅是编程，它也是一种技能。我们总是需要应对另一个抽象层次和另一组复杂性，并为此准备好工具。

复杂性增加的必然性

*克托·法尔奇克：这是否意味着复杂性的增加是不可避免的？

朱莉娅·比罗：完全正确，这就是进化。

*克托·法尔奇克：我喜欢这一点。

朱莉娅·比罗：事情是这样的。一旦你能做某件事，你把两个这样的事情组合起来，然后等到你把五个组合在一起时，你就会觉得，“哦，这太糟糕了”，然后你就开始自动化它。到第 22 次时，你意识到你想让那个特定的实例略微不同，并且你想在那里加一个if。你基本上想用变量来控制它，使用完整的编程语言，然后，轰！你创造了另一个复杂度层次。

但一旦你有了编程语言，就没有什么能阻止你从 50 个增加到 5000 个。很容易说，“这里我有了另一个层次。”之后，你需要做的就是教会每个人这些内容，并将它们写进代码，然后进行代码审查，从那里进入测试，并开发出一个完整的环境。

Viktor Farcic：你提到了遗留应用的复杂性。是否有一种情况，在某一时刻不再*护某些东西是合乎逻辑的呢？比如说，你有一个用 COBOL 或 Java 写的遗留系统。如果你想在某个时间点减少复杂性，你就需要重新开始。但同时，没有人愿意扔掉五年的应用开发成果。

Júlia Biró：如果你能把它拆解成更*的部分，你总是可以对其进行重构，这似乎正是现在 DevOps 的思路。不是要扔掉单体架构并替换它，而是将其拆解成更*的部分。当然，较*的部分会带来复杂性，但它们内部更容易控制和访问。

Viktor Farcic：所以，我们是在用另一种复杂性替换一种复杂性。

Júlia Biró：是的，基本上就是这样。但这个的优势在于，替换它会导致更易分割和并行化的复杂性。如果你有一个单体架构，而有 100 个人在上面工作，那么所有 100 个人都需要在脑海中处理这个单体架构的复杂性。如果你能将它分解为 10 个部分，那么 90 个人只需要了解其中十分之一的复杂性，可能还有一些依赖关系，而 10 个人则需要了解 DevOps 工具链或运行微服务的复杂性。

Viktor Farcic：在我们即将结束这次对话时，有没有什么是我还没有问到的，你想谈论的？

Júlia Biró：在我的职业生涯中，我曾经在一家公司工作，那里我真正体验了 DevOps、基础设施和站点可靠性，以及所有这些新的概念。然后我在 2018 年 5 月加入了 Contentful，就在它经历了一次大规模的增长后，花了一些时间（大约一年）才调整到新的规模，并且相应的工具和流程也逐渐成熟。自那时以来，它真的迎头赶上了。

从实用主义的角度思考

目前让我感兴趣的是，这些差异让我非常务实地思考所做的事情、为什么要做这些事情，以及我应该从 Prezi 引入并在 Contentful 启动什么。例如，哪些 DevOps 的理念是可以获得的，并且值得为我新的公司所获取的？我之所以这么想，是因为，比如说，我在 Contentful 的技术栈比 Prezi 的栈更年轻更新。但是，另一方面，一些工具已经更为成熟，而复杂性却变得压倒性。

我每天工作的动力来源于我对 Contentful 将会成长的信念，我选择跟随它，因为我想在它成长的过程中参与其中，并且我希望能促进这种成长。

Viktor Farcic: 你会说在某种情况下推广事情比在另一些情况下更容易吗？在使用一个成熟的技术栈时比在一个年轻公司用更少的技术栈时容易吗？

Júlia Biró: 这完全不同。例如，成熟的一个标志是，当我离开 Prezi 时，已经有了一个非常明确的推动想法的流程。一年前，当我第一次尝试在 Contentful 推动想法时，我甚至不知道该从哪个平台开始。一年后，肯定已经有了一个清晰的流程。另一方面，因为 Contentful 的工程师和层级只有 Prezi 的一半，我实际上只需要在午餐时说服两到三个人，某些事情就可能开始了。

"成熟的一个标志是，当我离开 Prezi 时，已经有了一个非常明确的推动想法的流程。"

—Júlia Biró

我对这个或那个没有偏好。在 Prezi，我需要学习很多工具。例如，作为负责监控管道的团队成员，监控管道本身就由六个不同的微服务组成。而这只是监控，而这非常难。现在在 Contentful，我常常感觉我们并没有真正的结构化概念来解决我们前进的方向。

最糟糕的是，我不断在想我们其实并不知道自己在做什么。我说这句话并不是指我们不知道使用什么技术，而是我们不知道我们希望如何使用这些技术。所有这些事情都是模糊且未定义的，这给你带来了很大的不确定性，而这对我来说很难应对，因为我并不擅长处理不确定性。所以，对我来说，这就是挑战。但另一方面，如果我下定决心去整理事情，那就很容易了，因为有时候我需要做的就是写下某些东西，然后试图让别人跟随或同意它。仅仅创建流程几乎和创建工具一样有效，因为它已经能够解决问题。

Viktor Farcic: 有一个问题。每个公司都认为自己是特别的，自己在做一些特殊的事情。然而，确实有一些经过验证的做法比其他做法更有效。我们的行业是如此异质化，以至于实际上我们仍然不知道什么方法比其他方法更有效。或者，是公司只是信息不足或无能，还是完全有其他原因？

Júlia Biró: 不，我并不认为我们如此异质化。实际上，当我在找工作时，我很容易找到一个使用和我之前公司相同 60%工具的公司，唯一的区别是它们被稍微不同的方式使用。微服务架构的美妙之处在于，实际上多样性被包含在微服务内部，作为工程师，标准问题意味着你可以有标准的解决方案，这是一种优势。

在 Prezi 有一个想法，我认为很有道理，那就是你应该把精力集中在你专长和服务领域所涉及的具体问题上。你应该尽量以最简单、最标准的方式解决其他问题。在 Prezi，这意味着我们有自己独特的解决方案来渲染可视化和其他内容，但在监控方面我们不想重新发明轮子，因为我们是一家视觉传播公司，而不是一家监控公司。

在 Contentful，我们确保你的内容既易于编辑，又具有高度可用性，因为这是我们的专长，也是我们的服务，重点放在可用性上。我们不是一家监控公司。我们不会在监控上投入大量精力。并不是说我们不做监控，而是我们不会从零开始编写自己的解决方案，因为我们的监控问题是标准化的，应该由标准工具来处理。

*克托·法尔奇克：所以，你应该专注于你的专业领域，然后通过标准的方式将其他内容解决。但让我困惑的是，这有点矛盾，因为一方面我们可以同意应该有标准，这样我们就不会浪费时间，但另一方面，如果事情每天都在变化，你就永远无法提升速度，因此标准也不能持久。

朱莉亚·比罗：通常每个问题领域都有一*部分标准解决方案可供选择，可能是三到五种，它们文档齐全，支持良好。但正如你所说，瓶颈总是在变化。所有的新解决方案都是为了改进某个瓶颈，但它们并不是在不断解决同一个问题。它们是在解决下一个问题。

*克托·法尔奇克：所以，每当我们解决一个问题时，总会有另一个问题需要解决，实际上，不断加快的新过程和工具的速度反映了我们在不断提高标准。

朱莉亚·比罗：例如，目前在容器调度和编排领域有五个主要工具。我认为在这个领域不会出现 50 个行业标准，新的技术将不再是关于容器编排。它将是关于其他的事情，其他基于它的东西。

*克托·法尔奇克：就像蛋糕一样？

朱莉亚·比罗：总是像蛋糕一样。例如，一旦虚拟机成为一种易于获取的资源，你就可以扩展你的基础设施，直到你需要与 AWS 进行个人谈判，讨论你使用的剩余节点数量。人们可能会有 60 亿个 Kubernetes 集群，但之后，它将再次成为一个易于扩展的资源，然后复杂性将转移到别的地方。

*克托·法尔奇克：我同意。

Júlia Biró：我的意思是，人们仍在编写 UNIX 工具，但这是因为我们每天都在使用已经有 30 年历史的 UNIX 工具。为什么？因为它们在我们编写的每一款软件中都有，并且我们在这方面没有采用新的标准，因为它们是相同的标准解决方案。对于服务器，你使用 NGINX、HAProxy 或 Apache 服务器，它们都完成相同的工作，然后你知道，没问题，它们工作正常，你不需要第十六个了。

Viktor Farcic：那太棒了。不过，我在想，是什么让你感到这么有共鸣呢？

工程恒定

Júlia Biró：我有幸与一些经验丰富的工程师一起工作，比如像你这样的。我在这方面也很新，但我们已经说过技术变化很大，我非常想知道什么是“工程恒定”的东西。

那些可能随着经验而来的东西是什么？它们不是特定技术的知识，而是技能、思*模式和通用的最佳实践，不会过时。是否有一些东西可以在不深入学习两三种单一技术五年的情况下，提升我的工作效果？从这一切中得出的问题是，“有哪些东西我可以学会而不必在技术领域花费十年时间，并且它们不会过时？”

Viktor Farcic：你可以在一年内学会 Kubernetes。

Júlia Biró：但是 Kubernetes 将在三到五年内过时。

技术行业有哪些恒定的因素吗？

Viktor Farcic：开玩笑的。但有这样的东西永远不会过时吗？如果你走出技术范畴，是否有任何文化上的因素在持续改变我们对一切事物的看法？技术行业中有这样的恒定因素吗？

Júlia Biró：有基本的想法，比如对女性美的描绘，在过去大约三千到五千年的艺术中似乎是一个非常恒定的事物，在整个世界范围内都如此。操纵群众的方法（用来让你的大部分人口站在你这边）也大多自古至今在书面政治史上保持不变。

Viktor Farcic：好的，可以理解，你可以这样认为。

Júlia Biró：我确实感觉到，当我与周围的工程师交谈时，他们可能来自不同领域，却有一些方法是他们无论在哪个领域或者实际问题中都会应用的。这些方法不会改变。不管你是在 1983 年、2003 年还是 2013 年编程，有时问题是相同的，但答案不同，解决方案也不同。我对这一部分很感兴趣，这一部分区别于编程的工程学。

Viktor Farcic：但这难道不是我们行业不成熟的一个迹象吗？

朱莉娅·比罗：这在某种程度上是成熟的表现，我在身边看到的很多人都有这种特质。这也是我从那些比我经验更丰富的人那里学到的东西。但我也认为，这是可以有意识地去做的事情，而且你可以稍微偷学一下，尽管你还没有那么多经验，也尽量去用它。

*克托·法尔奇奇：不久前，我和一位建筑师朋友聊天，我告诉他，昨天我们还在用 Java，而今天我们用的是 Go，谁知道明天会怎样。他跟我解释说：“是的，因为作为建筑师，我的工作已经有几千年的历史，我们已经有足够的时间来摸索，而你们却没有。”

朱莉娅·比罗：我的意思是，审美的法则并没有改变，但由于材料的变化，建筑的方式在过去两个世纪发生了巨大的变化。

*克托·法尔奇奇：但是你刚才说，建筑已经有几千年的历史，而我们才只存在 50 年。

朱莉娅·比罗：不，事情是这样的。我有一位前同事，他在一家完全远程的公司工作，所有的工程师都是资深的，他讲了一个故事：“我们要去吃晚餐。我们每年见一次面，然后去参加一个离线/团队建设活动，我们尝试去解决一些架构问题。你会发现，通过问‘我们要解决的问题是什么？’，你能取得多大的进展。”

“那就像是资深工程师们做的一个超级简单的技巧。他们不会让自己陷入细节中或者走入死胡同，而是时不时地退后一步，问一问，‘我们是不是在接近目标，是否有更短的路径？’”

—朱莉娅·比罗

那就像是资深工程师们做的一个超级简单的技巧。他们不会让自己陷入细节中或者走入死胡同，而是时不时地退后一步，问一问，“我们是不是在接近目标，是否有更短的路径？”这些都伴随着成熟而来，但如果像我一样狡猾，你会尽早地去运用它。我对这些事情很感兴趣。基本上，是否有一条快速通道可以让你成为一名资深工程师？这就是我感兴趣的事情，因为我没有那么多时间。

*克托·法尔奇奇：这是一个很棒的观点。感谢你抽出时间和我聊聊。

第三十五章

12

第三十六章：达蒙·爱德华兹

Rundeck 公司联合创始人兼首席产品官

第三十七章：介绍达蒙·爱德华兹

当达蒙·爱德华兹创办 Rundeck 公司时，他帮助创建了一个平台，改变了全球成千上万的 IT 运*，使其能够更加高效地运行并快速扩展，同时保持安全性。这些都是 DevOps 之旅的标志。你可以通过 Twitter 关注达蒙，账号是@damonedwards。

DevOps 之旅

*克托·法尔奇奇：我想先做个简短的介绍。你能告诉我们一些关于你自己以及你是如何进入 DevOps 领域的吗？

达蒙·爱德华兹：在 2005 年到 2007 年间，我是一个专注于现在称为部署流水线的精品咨询组织的一员。那时候，网络规模的服务仍然是一个相对较新的概念，但我们是配置和部署大规模应用的专家。

当行业开始转向云计算时，无论是在 VMware 中虚拟化，还是在初期的 AWS EC2 中，一切都成为了软件栈的一部分。我们发现这实际上非常适合我们，因为我们大多来自于操作密集型背景。在 2007 年到 2009 年之间，显然规模已经不再是问题；部署的技术方面已经成为一个被解决的问题。

挑战在于，正如我们的客户所说，他们希望能够更快速地完成任务，以一个能够学习并超越竞争对手的速度前进。这使我们意外地成为了精益咨询顾问，客户说：“这个自动化非常有效，但我们注意到我们没有像那些拥有相同自动化工具的其他人那样快。为什么我们没有变得更好，而他们却变得更快？”

这就是我们进入精益运动的原因。我们回顾过去，超越了敏捷，研究了丰田生产系统、德明、戈德拉特等内容，解码为什么有些组织能够更高效地完成任务，走得更快，生产出更高质量的东西，而其他组织却做不到。我们是自学成才，通过试错法学到了很多，因为当时并没有太多关于将这些技术应用于整个开发和运*生命周期的知识体系。

*克托·法尔奇奇：从你谈到的时间线来看，这似乎正是 DevOps 运动起飞的时刻。你们一定是在这个概念刚开始时的最前沿。

达蒙·爱德华兹：我和像帕特里克·德博瓦、约翰·威利斯、安德鲁·谢弗、约翰·奥斯波等人一起，正是在帕特里克组织了第一次 DevOps Days 时点燃了 DevOps 的火花。事实上，我是那个发邮件邀请基恩·金（当时主要是《可视化运*》一书的作者）来参加第一次 DevOps Days 会议的人，那时他还没听说过这个会议。

“我们尤其对企业中的 DevOps 感兴趣，因为这是 DevOps 问题——那些真正棘手且有问题的——真正存在的地方。”

—达蒙·爱德华兹

我和我的同事 Alex Honor 在对话中提出的是一种以企业为中心、以运营为优先的视角。很多人都对将敏捷方法扩展到整个部署流程感兴趣，但我们更关心的是运营如何向开发方向延伸。我们特别关注企业中的 DevOps，因为真正棘手且问题复杂的 DevOps 问题通常就在这里。

如果你是一个*型组织，或者是一个单一用途的大规模网站组织，你的 DevOps 问题都有简单的解决方案。是的，这需要付出努力和深思熟虑，但前进的道路是明确的。你需要做的就是把每个人召集到同一个房间里，告诉他们停止以旧方式做事，而是采用新方式，你的问题通常会通过直接的努力得到解决。

现在，试想一下在一个大型、复杂的企业中，你有多个业务线，通常这些业务线是通过收购或有机增长在几十年中聚集起来的。你拥有各种类型技术的一切，并且你有着庞大的人群、技能、思*方式和流程，而这个庞大、分布式的组织遍布全球，跨越数十种政治结构，要在这种环境下实施系统变更是非常困难的。这是一个完全不同的挑战，非常难以应对；这些就是那些棘手的 DevOps 问题。

Viktor Farcic：你现在在 Rundeck 工作。你能谈一谈你在那里做的工作吗？

Rundeck 公司与 DevOps

Damon Edwards：Rundeck 诞生于 2010 年，最初是作为一个开源项目。它填补了自动化工具链中的空白，并且拥有一个我们认为是谦虚且有益的社区，所以我们一直在推动它的发展。大约在 2014 年，我们发现有些事情变得特别起来。第一个迹象就是，许多大型的知名企业开始向我们求助，寻求 Rundeck 的帮助，而不是我们的咨询服务。他们会说：“我们知道你们是咨询公司，也许以后我们会考虑，但我们现在在用 Rundeck，我们需要在这里和那里得到帮助。”

最终，我们发现 Rundeck 被公司用来解决他们 DevOps 中的运营问题。在足够多的人告诉我们 Rundeck 改变了他们的工作方式之后，Alex Honor、Greg Schuler 和我——Rundeck 公司的三位创始人——决定关闭咨询公司，专注于 Rundeck。决定性因素是，我们通过一家产品公司能在更大规模上帮助更多的人，而作为咨询公司时我们无法做到这一点。

Viktor Farcic：我对 Rundeck 的了解非常基础。如果我理解得没错的话，它有点像一个任务执行器。

Damon Edwards：从技术角度来看，这是正确的，但这不是令人兴奋的使用案例。自助服务操作是 Rundeck 的大价值所在。操作团队将在团队内部使用 Rundeck，将他们现有的各种脚本、工具、命令和 API 创建成标准操作程序。这为团队内部带来了大量效率提升，但真正有趣的地方在于，当他们利用访问控制功能将这些操作程序提供给运营以外的人时，因为这时候他们可以真正重新思考组织的运作方式。

Viktor Farcic：所以，团队使用它，但自助服务才是主要目标？

Damon Edwards：是的，但团队通过标准化工作方式看到了很多好处。标准化鼓励持续的改进和实验；这是已知的精益技术。与其我有一堆脚本，你有一堆脚本，别人也有一堆脚本，不如把它们都放进 Rundeck 中。我们一起合作，想：“嘿，我们一起找到一个好的方式来做这些事情。” 所以，将你现有的脚本、工具、命令、API 插入 Rundeck，Rundeck 提供了工作流、通知、错误处理、用户输入管理、UI、API、日志记录等等。

Rundeck 的访问控制功能正是让人们兴奋的原因，因为现在他们说：“嘿，让我们让那些传统上不做运营活动的团队也能进行运营活动。” 一个简单的例子就是经典的 DevOps 思想——让开发者在生产环境中执行重启。这在大多数企业中是一个相当令人震惊的概念。你怎么做到的呢？你不能给他们生产环境的登录权限，然后说：“这里是你的 SSH 密钥、sudo 权限和一些脚本... 祝你好运！” 因为这种方式在企业环境中行不通。这个问题足够复杂，涉及到许多团队，大多数人最终都会放弃。

但是现在，借助 Rundeck，开发者可以直接说：“好吧，让我们使用 Rundeck。插入重启脚本，运行健康检查确保它有效，然后运行命令停止监控并操作负载均衡器。然后，围绕它设置一些额外的保护措施，比如限制用户输入选项、通知和错误处理。” 接着，他们会使用 Rundeck 的访问控制功能，安全地授予开发团队在生产环境中进行重启的权限。同样，你也可以只给他们权限，观看可信的 SRE 在生产环境中执行重启。无论哪种方式，他们都能获得更好的控制和可视性，这使他们能够将执行操作任务的能力分发到更广泛的组织中。

这种自助服务能力解锁了许多你在前瞻性企业中看到的 DevOps 组织变革。他们希望将控制权解耦并推向更接近交付团队的地方，以便能够更快地行动，而运营团队则保持在一旁，不干扰他们。

Viktor Farcic：这就像是集中管理，同时强调赋能其他组织成员的能力。

Damon Edwards：这是个有趣的说法。我们认识到运营领域的专业知识和能力不会消失，但认为有一个集中式的运营组织，负责所有的“运营工作”，是无法跟上今天需求的步伐的。你需要一个机制，能够分散控制，但又有运营专家来*持监督。

这也是 Rundeck 设计理念中的一部分。我们不想成为又一个仅仅负责移动数据的工具，因为市场上已经有很多工具能够很好地完成这项工作，无论是 Chef、Puppet、Ansible，还是容器编排工具。我们让人们使用他们想用的工具，然后再根据这些工具创建出需要跨越不同工具的逻辑流程。我认为我们曾经都活在一个幻想中，认为有一个自动化工具能够统治一切，但我们所做的其实是接受异构性是首选现实的观点。让人们做他们需要做的事情，帮助他们协调这些工作，并确保其安全。

“让人们做他们需要做的事情，帮助他们协调这些工作，并确保其安全。”

—Damon Edwards

Viktor Farcic：你怎么看待 DevOps 的商业化以及 DevOps 工具这一更广泛的概念？

DevOps 的商业化

Damon Edwards：这确实是一个有趣的话题，因为人们总喜欢寄希望于工具。首先是 Puppet，然后是 Chef，最近是 Ansible，而现在是云原生和无服务器架构。每一个新的自动化工具都宣称会主宰世界，但当专门负责这个工具的项目团队离开后，它就变成了遗留工具。现在，我们几乎有了各种工具。与此同时，有人会说，如果再引入一个新工具，就能解决所有问题。这是一个一直存在的循环。

现在，许多公司都在推行 DevOps，而他们的人依然在遵循他们一直以来的模式，寻找一个 DevOps 工具来帮助他们。我并不怪罪厂商将他们的工具作为 DevOps 工具推广，因为大多数工具本身都很优秀，能够解决特定的问题。但当你的 DevOps 问题并没有消失，而且你又多了一个工具需要*护时，请不要感到惊讶。

“如果有什么值得学习的，那就是精益（Lean）的一课；你需要让团队自行选择他们认为需要使用的工具。”

—Damon Edwards

如果说有任何东西是 Lean 方法的教训，那就是你需要让团队自主选择他们认为需要使用的工具。他们需要关心如何进行整合，关心工具链架构，或关心如何让其他人将他们的工具与别人的工具连接在一起。自从我们首次意识到企业的异质性是需要被接受的这一点以来，这一直是 Rundeck 的一个主要设计理念。

过早的优化或工具标准化实际上对组织是不利的。如果你强迫一个团队做他们不愿意做的事情，而他们有充分的理由不想做，那么你只是在给这个团队增加不必要的负担或摩擦。异质性不仅是生活的事实，我们认为它实际上是一个特性。让团队做他们需要做的事情以确保成功，只需要关心如何将其与其他团队整合，确保适当的安全性和合规控制到位。

*克托·法尔西奇：我完全同意。从我自己的经验来看，我至今还难以找到真正朝这个方向努力的大型企业。我一直有这样的印象，那就是 DevOps 就是这样的情况。每个人都在谈论 DevOps，世界上每一家公司都有 DevOps 项目，但实际上没有人在真正做。

达蒙·爱德华兹：改变工作方式本身就非常困难。对于那些推动变化的人来说，这可能会感觉很有风险且令人害怕。这不仅仅是从组织角度来看；我也在从个人角度谈论这个问题。

这是一个例子。你告诉大家：“好吧，我们要把运营能力分配给交付团队，所以我们应该让这些交付团队具有跨职能性。这意味着我们从运营中拿走人员，将其转化为更多的 SRE 技能。我们会留下一些 SRE 负责平台和我们因实际原因无法分配给中央团队的专业领域。”这就是跨职能团队的理念，听起来合乎逻辑，但在人际和政治层面上你在做什么呢？你是在从一个团队中剥夺人手，然后将其分配给另一个团队。

在大型企业中，很少有人会承认的一个秘密是：真的很难知道别人都在做什么。大型组织的高层管理者需要间接的方式来识别不同管理层级的绩效。假设你是一个理论公司中的总监级别——你处于 C 级的四到五个层级下面，距离实际操作的人群有三到四个层级，而高级管理人员想知道你是否做得不错：“*克托做得怎么样？他会有发展吗，还是他的职业已经达到瓶颈？”

*克托·法尔西奇：我们现在进入 DevOps 的日常讨论，这很好，但我很想知道这在理论公司中是如何运作的。

Damon Edwards：按照传统的企业标准，他们可能会说，“哦，Viktor 看起来挺不错的。他不断增加团队人数和预算。Viktor 一定做对了什么事情；我们应该关注一下那个 Viktor，他有前途。”

你是一个理性的人。你关心你的职业生涯，而你的家庭也依赖于你的职业生涯。你最不想做的是什么？放弃预算或人员！你在职业生涯中已经被条件化，知道这些都是你是不是一个弱者或不称职经理的信号。突然之间，你对把团队成员从你手下转移到其他团队的想法变得更加谨慎了。组织变革之所以困难，是因为人们有个人和政治上的动机，这些动机往往和组织的利益不一致，这是我认为的首要问题。

Viktor Farcic：那么，第二个问题是什么？

Damon Edwards：第二个问题是，企业文化中的许多奖励机制是围绕交付设计的。例如，你完成了一笔巨大的销售，或者你稳固了一项关键合作——这就是你的奖金。你交付了一个重要的 IT 项目，带领公司上云，或者你交付了我们向华尔街承诺的新 Foo 服务——于是你获得了加薪。交付成果的消息传到董事会，这样在商业导向项目上的交付也成了让你进入快速晋升名单的方式。

现在，假设你是一个被激励着交付成果的开发领导者。你想要荣耀和奖赏，对吧？你最不希望做的事情就是做任何不涉及交付的事！承担一堆 SRE（站点可靠性工程师）和共同承担生产服务的责任意味着你在承诺资源并被评判的事物是与交付无关的。

对公司来说，正确的做法是坚持你已经构建的东西，保持其运行，并发展它以满足客户未来的需求。但从个人角度出发，你可能会说，“算了，已经完成了，让别人去操心这个，给我安排一个全新的项目”，因为那样你就会成为上年交付了客户价值 X，今年又交付了客户价值 Y 的 Viktor，这就是快速晋升的捷径。

“所有这些的现实是，人们的工作方式很难改变，这意味着大型企业也很难改变。”

—Damon Edwards

所有这些的现实是，人们的工作方式很难改变，这意味着大型企业也很难改变。如果你能通过在组织图上为一些现有的框架加上些 DevOps 的新鲜感，情况会简单得多。

这就是为什么在如此多的企业中，DevOps 被局限为发布和系统工程的新名词。他们实际上并没有做到让 DevOps 高绩效者非常成功的那些事情，即改变他们的基本运作方式。市场上有很多供应商乐意加强这种行为。为什么要复杂化销售？让他们只是做个“DevOps”外观改装，宣告胜利就好了。归根结底，这真的不是技术组织文化的问题；这是一个业务文化的问题。

Netflix 的运作方式正是由于技术组织的存在；这是他们运营整个业务的方式。亚马逊之所以运作方式如此，正是因为这是亚马逊运营整个业务的方式。Google 也是如此。除非你的业务想要改变运营方式和激励措施，否则不要指望技术组织会有太大不同。在技术组织的内部，我们仍然可以做出很多改进；只是不要指望业务部门会被技术尾巴摇着。他们还得自己弄明白。

*克托·法尔奇克：至少从我看到的情况来看，做决策的业务方仍然习惯于像对待软件开发一样对待任何其他决策。

达蒙·爱德华兹：这是个有道理的观点，因为他们只看到自己眼前的工作，并按照自己的激励机制行事。因此，他们会按照当前的信念来运行事务。太多时候，你会看到技术组织告诉业务部门他们应该如何运作，应该以描述的“正确方式”去做事情，而当业务部门不这么做时，通常会对“白痴”有些抱怨。事实上，业务部门也有他们自己的看法。他们知道自己需要什么，认为他们的方式是理性的方式去做事情，如果技术方面不同意，那么他们就是在抱怨或者根本不懂。

当然，冲突随之而来。每个人都认为自己是理性的，认为自己所做的对公司最有利，这是我们必须牢记的事情。全世界很少有人上班时会说，“我今天怎么能把事情搞砸，我能做什么愚蠢的事情呢？”

*克托·法尔奇克：但在大公司中，人们真的在尽力为公司做最好的事情吗？我这么说是因为，我看到的情况是，大公司实际上是一群*公司的集合，无论你把它们称为独立部门、部门还是公司，不管你怎么称呼。你是否觉得，为部门做正确的事情未必就是为公司做正确的事情？

Damon Edwards：大多数人认为他们在做正确的事，但我认为你提了一个好观点。从商业角度来看，视角和背景真的很重要。你可以把一家大公司看作是多个公司的组合，因为这些部分往往可以在一定程度上独立运营，而这种隔离鼓励了孤岛行为。在这种情况下，最终会有一些人只看到大拼图的一*块，他们会尽力做好这一部分，但并不是为了整体业务的最大利益。而对于拼图中其他部分的人来说，他们可能会认为那些人并没有以公司的最佳利益为出发点，但这些人只能看到他们自己有限的视角。这个孤岛问题从开发和运*的传统分隔一直延续到今天。

Viktor Farcic：这非常正确，因为如果你更深入地思考，每个人都有自己的目标。运*的目标是什么？就是永不宕机。如何做到永不宕机？那就是永远不部署新的版本。我的意思是，开发人员希望每秒发布一次，因为他们并不在乎我们是否会宕机。

Damon Edwards：没错。人们很容易只关注自己正在做的工作，而忽视从端到端的系统来看问题；同样，也很容易在无意中失去动机，无法为端到端系统的最佳利益而行动。

说明这一点最直观的方式是询问客户如何看待你的组织。客户看到的是一个交易点，或许还会看到一条横向的线，表示为了完成这个交易需要发生的一切事情。他们不关心你的职能孤岛，也不关心谁做什么。重要的是，它是否让他们满意？它是否以合适的价格提供了他们想要的功能？在合适的时间，合适的功能和合适的价格是否都能满足他们的需求？这才是他们关心的；这是一种非常横向的视角。

那么我们如何看待内部的工作呢？我们通过工作职能来思考，或者是我们名片上写的职称，通常这是一个垂直的、按职能对齐的视角。人类本能地倾向于将相似的事物归在一起。让我们把开发人员与开发人员放在一起，把运*人员与运*人员放在一起，把测试人员与测试人员放在一起，把安全人员与安全人员放在一起。然后，从这个基础上，我们为这些群体内的效率管理这些人。结果是，一旦这样做，人们就会失去对客户关心的事情的关注——那就是端到端的能力。当人们进行优化时，往往没有意识到自己在做的是局部优化，实际上是在破坏整个端到端系统的优化。问题就从这里开始。

质量的感知及其对工作的影响

Viktor Farcic：你认为这些人会根据客户对质量的感知来获得激励吗？

Damon Edwards：理想情况下是这样。但他们知道那是什么吗？他们知道自己的工作如何真正融入整个系统，并且如何影响质量吗？我们以一个孤立的防火墙团队为例。

这个防火墙团队可能提供西半球最好的防火墙规则变更。他们的工作是确保只做出最好的和最安全的规则更改。他们通过提供有限的变更窗口来做到这一点。如果你在周二下午 2 点之前给他们提交防火墙规则更改，那么到周四下午 4 点，你的变更就会完成。

现在，假设我是一个开发人员，我需要一个更改。我可能会想，虽然我不是防火墙专家，但我会尽力弄明白在这个支持票上该写些什么。我在周一提交了票务请求，但周三因为请求的问题被退回给我。我和网络管理员来回沟通，弄清楚该如何请求我想要的东西，但后来发现我错过了变更窗口，只能等到下个星期四。

支持团队不会提前处理，因为它还不是生产服务，所以现在我只能等到更改发生。问题在于，现在每个人都在等待这个防火墙规则更改，因为他们以这种断开、孤立的方式在工作。防火墙规则的优化是从防火墙团队的孤岛视角做出的，而不是从端到端系统的视角。

Viktor Farcic：确实如此。这就像那句名言：如果你想真正了解一个社会，你需要了解它的监狱系统。对我来说，这可以翻译成你刚才提到的票务系统。如果你想看看一家公司有多敏捷或精益，只需看看他们的票务系统。

Damon Edwards：哈哈！我从没把票务系统比作监狱，但我明白你的意思。孤岛效应和票务队列的破坏性倾向确实在 Rundeck 的世界观中占据了重要地位。

我们在咨询时曾注意到，票务队列加剧了孤岛效应，让人们失去共享的上下文，开始向内聚焦，并为自己的孤岛视角进行优化。最终，公司会受到影响，尽管每个人看起来都非常忙碌，且各自的领域非常高效。

Viktor Farcic：所有这些请求队列都会给公司带来各种经济成本，因为你在引入延迟；你在中断上下文。

Damon Edwards：没错。从其他领域我们知道，工作队列会导致延迟、质量问题、增加的开销、士气低落、学习减少和更大的风险。不知道为什么，IT 运营总是忽视这一点，假装基于票务的请求队列很昂贵或会导致破坏性的行为。

Viktor Farcic：然而，票务系统已经成为我们生活的方式，特别是在运营方面。

Damon Edwards：没错。我的意思是，票务系统最初被称为故障单，因为它是用来处理出错时的情况。它本来是为了处理例外情况而设立的。但在这个过程中，它变成了我们管理工作的方式，并且为运营团队提供执行工作的权限。

我们最终做的事情是，带领那些希望成为高效学习型组织的公司，向整个价值流中撒下基于票务的请求队列。我们将那些处于现有瓶颈、延迟、不良交接和知识丧失的队列，扩展到每个角落。这感觉像是一个真正的行业盲点。

我们一直强调的一个大主题是，必须设计你的组织和基础工作的方式，尽量减少交接的次数。你必须尽量消除将工作交给其他团队的需求，而做到这一点通常意味着更多地推动跨职能团队的方式。然而，跨职能团队的理念也有其局限性，在某些情况下，你就是无法消除那些交接。

这在运营中尤其明显。我们不可能有足够多来自那个大防火墙规则更改团队的人去为每个团队配备一个，我们不会有足够的安全人员，也不会有足够的系统工程师、数据库管理员（DBA）或存储专家。如果是这种情况，我们就必须将他们的工作转化为基于拉取的自助服务接口。这意味着其他团队在需要这些操作时，将通过自助服务接口来完成，无论是图形界面（GUI）、API 还是命令行，都能做他们需要做的事情，快速从系统中获得反馈，然后继续进行。

Viktor Farcic：你的意思是，比如在需要时获得虚拟机？

Damon Edwards：是的，那是一个低级别的例子。我不应该需要开一个单子让别人帮我做，因为我有 API 或一个网页按钮，我可以得到我想要的东西，从那里开始。你怎么让环境团队在没有 DBA 单的情况下做模式更新？你怎么让开发者在生产环境中自己重启或进行健康检查？你怎么让业务分析师自己运行目录更新程序？

关键的想法是，自助操作不仅仅是按下按钮来执行某个操作。那些想要按按钮的人，还需要有定义自己按钮的能力，就像在 Amazon EC2 中，你可以定义自己的 Amazon Machine Images（AMI）。如果 EC2 只告诉你可以启动五种类型的实例，那它就没什么用了。让人们定义自己的程序，他们仍然可以让安全和运营人员对这些按钮进行代码审查。

在 EC2 的例子中，它们之所以有用，是因为它们提供了框架和护栏，让你能够掌控并发挥作用。自助服务模式不仅仅是按下按钮的能力，还包括团队定义按钮的能力；这是一个强大的设计模式。

DevOps 的最佳定义

Viktor Farcic：这个问题听起来有点傻，但我喜欢它，因为每个人给我的答案都不同。我们在讨论中已经提到过无数次了，但 DevOps 究竟是什么？

Damon Edwards：我听过的最好的定义来自于 Adam Jacob。他说，DevOps 是一种文化和职业运动，专注于如何构建和运营高效能的组织，这种方法源于实践者的经验。

“DevOps 是一种文化和职业运动，专注于如何构建和运营高效能的组织，这种方法源于实践者的经验。”

——Adam Jacob（由 Damon Edwards 引用）

我认为这是任何描述中最好的，因为我认为它抓住了 DevOps 运动的本质。DevOps 确实是一个包含多个不断发展的问题和解决方案的伞形概念，所有这些都基于创造更高效能和更高质量组织的理念。试图做出比这更详细的描述会失去重点，因为 DevOps 是一个运动，而不是静止不变的事物。

我认为那些试图将其定义得更具体的人是在发明一些从未真正存在的东西。那也没关系，他们可以尝试这么做，也许他们会为这个运动带来一些新东西，大家都会受益。但如果这个运动忽略了他们，他们也不应该抱怨。我记得第一次听到 Charity Majors 把 DevOps 描述为开源运动的就是她；社区走到哪里，社区就跟到哪里。

Viktor Farcic：这是一个很好的定义。

Damon Edwards：它对很多人有效，并让他们专注于重要的事情：改善技术组织的运作以及组织内部人员的生活。DevOps 中的定义争论是没有意义的。

Viktor Farcic：你怎么看待 DevOps 的商业化？当我参加会议时，几乎没有任何软件不贴上 DevOps 的标签。

Damon Edwards：我对此有一些复杂的感受，因为起初，我更倾向于纯粹主义，并宣称将所有事情都贴上 DevOps 标签是没有意义的。这就像说一个人是敏捷的，或者说一个机器人将会使工厂变得精益。但随着时间的推移，我的立场有所软化——部分原因是我意识到市场最终决定了那些工具只是把 DevOps 标签贴在盒子上，然后很快被揭露出来。我还意识到，至少在宏观层面上，这表明了行业需要改变它的工作方式，因为即便是工具供应商也在谈论它，那么更多的高管会倾听。

*克托·法尔奇奇：难道大多数这些供应商不是在声称 DevOps 完全是部署吗？

达蒙·爱德华兹：很多供应商推动这一叙述，因为这正是他们卖的东西。并不是所有人都如此，但确实有很多这样做的供应商。这可能是工具供应商跳进 DevOps 的唯一负面影响；它迎合了企业只是想给他们的旧流程涂上一层新的 DevOps 油漆的冲动。如果 DevOps 只是部署，那我们可以把它当作一个工程项目来做，不用担心那些叫做‘人’的乱七八糟的事情。

“如果 DevOps 只是部署，那我们可以把它当作一个工程项目来做，不用担心那些叫做‘人’的乱七八糟的事情。”

—达蒙·爱德华兹

这也反映了大公司如何喜欢解决问题。当你在食品链中爬得越高，尤其是在大公司里，管理就越变得事务化。他们会说：“告诉我问题是什么。告诉我需要签什么检查，告诉我我能得到什么。我会把它与其他检查进行权衡，然后签署我认为正确的检查。”工具非常符合这种模式，供应商们知道这一点。公平地说，我是一个软件供应商，我知道这一点。然而，我们认为那些能够持续下去的工具供应商，是那些真正解决问题并清楚自己能解决和不能解决的问题的供应商。“买我的工具，我就能解决你的 DevOps 问题”这是不可能的，除非你把 DevOps 框定为非常狭窄且大体上无益的范畴。我们可不是为了让软件运行得更快而穿上这些行头的。

*克托·法尔奇奇：对我来说，这听起来像是 Scrum 的反面。人们跳进 Scrum 方式，认为改变人类的工作流程就能解决问题，而现在我们遇到的是它的反面：买这个工具，它就能解决你的人力问题。

达蒙·爱德华兹：这真的是一个很有趣的角度。我认为这种相似性还更深。多少公司“采用 Scrum”，却并没有真正改变他们的工作方式？他们买了工具，做了一些*规模的培训，然后就用 Scrum 涂抹现有的瀑布式流程和思*方式。那些这么做的公司最终加入了“Scrum 没用，一定不行”的反弹潮。我们无疑会看到相同的事情发生在 DevOps、SRE 和未来出现的任何其他运动中。事情就是这样。

*克托·法尔奇奇：这有点正常，但也许你的期望太高了。假设你完成了某个任务的 15%。那仍然是某个任务的 15%。

达蒙·爱德华兹：这是一个很有道理的观点。我们可能会忽视它的净正面效果。至少人们已经意识到他们有问题，并且正在尝试一些方法。我的担忧是，当他们用这些努力来宣布过早的胜利时。实际上，什么都没有改变，或者他们把它当作虚假的证据来证明它没有效果。

*克托·法尔奇：总是有这样的人，这让我想起很久以前，当其中一位质量保证经理找我时，我在推动自动化，他们说：“我找到了一种无法自动化的测试用例。这一切都毫无价值。”但对我来说，我想，“你找到一个，那又怎样？”

达蒙·爱德华兹：人类是复杂的，改变人类的工作方式是相当困难的。

当前行业

*克托·法尔奇：我听到过一个理论，说我们行业中的一个大问题是，我们今天的成功是因为大家不重视运*工作。就像敏捷方法一样，突然间我们有了“明星人物”。行业说，“这是个明星开发者，这是个明星测试员，这是个明星产品负责人”，但是从来没有在任何积极的奖项上下文中提到运*人员。

达蒙·爱德华兹：这可能有点道理。我不确定是不是某些人获得了明星地位，但我更关心的是很多 IT 工作者的待遇不公，而不是少数人的舒适生活。

“我更关心的是很多 IT 工作者的待遇不公，而不是少数人的舒适生活。”

— 达蒙·爱德华兹

你可以去到世界各地那些遥远的公司技术中心，实际上，很多人在这个行业里只因为它比卖保险赚得多。我的意思是，仅此而已。他们只是想度过一天，养家糊口，周末带孩子去参加体育活动，而他们却身处那些高度功能失调的组织，做着通常令人气馁的重复性工作。他们因为所承受的压力和冲突而左冲右突，疲惫不堪。

这浪费了大量本可以更好利用的人力资源。如果我们能找到更好的工作方式，那么对个人有好处，对公司的业绩也有巨大好处。这就是为什么我对精益、DevOps 和 SRE 等话题如此看好；重点是人们如何工作以及如何改进这种方式。

*克托·法尔奇：我觉得现在是结束我们对话的好时机。

达蒙·爱德华兹：我们确实谈到了很多内容，我非常享受这个过程。

*克托·法尔奇：我也是。谢谢，干杯。

第三十八章

13

第三十九章：川口幸介

Jenkins 软件项目的创始人

第四十章：介绍川口浩介

作为一名备受尊敬的开发者和广受欢迎的演讲者，川口浩介也许最为人所知的是创建了 Jenkins，这是一个被广泛采纳并成功成为社区驱动开源项目的持续集成平台。川口浩介在 Jenkins 社区背后的原则——可扩展性、包容性和低门槛参与——是 DevOps 发展的许多驱动因素之一。您可以在 Twitter 上关注他，用户名为@kohsukekawa。

*克托·法尔奇克：在我们深入探讨 DevOps 之前，您可以先简要介绍一下您自己吗？

川口浩介：我可能最为人所知的是 Jenkins 项目的创始人，该项目起初是一个持续集成服务器，现在在广泛的计算行业和自动化领域中更为普遍。目前，我是 CloudBees 的首席技术官，这是一家涉足多个领域的公司之一，其中包括产品化 Jenkins，以及帮助公司进行数字化转型。

什么是 DevOps？

*克托·法尔奇克：那么，一个简单的问题：什么是 DevOps？

川口浩介：老实说，我觉得今天 DevOps 这个词有点被滥用了。事实上，我自己有时候也在思考人们究竟指的是什么。DevOps 的真正含义取决于几个因素。我个人将 DevOps 与这种趋势联系起来，这种趋势在过去几十年里，自动化程度越来越高，反馈周期也越来越短。

"我觉得 DevOps 这个词有点被滥用了。"

—川口浩介

在过去五年中，从编写代码到管理质量保证（QA）并将其推向生产并运行，这种自动化反馈周期已经无所不在。我认为人们通常会默认采用这样的实践，然后称之为 DevOps。当我与这些在大型企业工作的人交谈时，我觉得他们立即将 DevOps 视为消除现有组织边界的重要问题，这对他们显然是一个重要问题。我知道有些人喜欢强调这一点，并将其更多地看作是一个组织性的事情。

DevOps 工具包及其对组织的影响

*克托·法尔奇克：关于 DevOps 工具包，您认为哪些工具能够赋予工作者更大的权力？您认为某些工具比其他工具更适合人们对 DevOps 的定义吗？

川口浩介：在跨多个不同事物的广泛自动化背景下，以及这种对自动化与人类控制需求日益扩展的情况下，工具显然是实现自动化的主要手段。我知道许多 Jenkins 用户是这样看待这个世界的。

像我这样的软件开发人员喜欢发明工具。这就是我们的工作。所以，从这个世界观出发，我们自然而然地会想出自己的工具，来填补这些空白，并进一步扩大自动化，因为没有自动化，你就无法创造更短的反馈周期，而这正是 DevOps 的关键部分。对我来说，这才是最有趣的部分。它感觉更贴近我们能够解决的领域，相较于企业中的组织结构问题，后者不仅仅是由技术问题决定的，还有许多其他因素。例如，开发和运*分开的确有很好的合规理由；历史上，它被视为一种*护良好的合规必要性。从根本上来说，这不是一场技术上的斗争。

*克托·法尔西奇：你是 Jenkins 的创造者，它是最受欢迎的开源工具之一，你还是一家公司 CTO，正如你自己所说，这家公司与企业合作。你认为*型绿色田地式开源公司和大型企业之间，工具和流程的运作有显著区别吗？

“开发和运*分开有很好的合规理由；历史上，它被视为一种*护良好的合规必要性。从根本上来说，这不是一场技术上的斗争。”

—川口浩介

川口浩介：企业人员需要处理的那些问题和挑战，和*公司面临的层次不同。对于*公司来说，时间就是金钱。正如我之前所说，这些*型企业通常员工人数不多，所以他们在选择工作方式上有更大的灵活性。

合规性通常没有那么真实；这并不意味着你可以忽视它，但你可以“低调”一点。在其他企业中，当为新员工提供资源时，你必须考虑的分隔问题就像是为全球团队而非本地团队进行优化。难怪有一方觉得另一方有点傻。他们各自面临不同的挑战。

*克托·法尔西奇：举个例子，当我去 DockerCon 的不同展位时，看到的都是“DevOps, DevOps, DevOps”。现在所有的软件供应商几乎都与 DevOps 有关。你认为是什么驱动了这一趋势？

川口浩介：我想说两件事。

首先，如果我看一下我所说的那种十年的自动化进程，那么我们谈论的不仅仅是 DevOps。现在它包括了基础设施、服务、虚拟机或软件定义网络。在这个广泛的趋势中，你可以包括像持续集成这样的实践，而持续集成至今大约有十年历史了。今天，DevOps 被用作这场进程的通用标签。我认为这场进程会继续，但在某个时刻，它会有一个不同的名称。

其次，我们这些工程师可能会对每个人都在谈论 DevOps 并根据自己的议程扭曲其含义而翻白眼，但我们也低估了以一种更广泛的受众能够理解的方式进行沟通的重要性，这实际上是非常困难的。

为了实现我们知道是必要的变革，作为工程师，你必须动员你的组织，这意味着要与那些非工程师的人进行沟通。像 “DevOps” 这样的术语是非常有用的方式来捕捉这些思想，当很多人以不同的方式说相同的事情时，这会增加这个观点的可信度。因此，所有这些供应商说 “DevOps” 其实是在帮我们一个忙。

Viktor Farcic：我最近听到很多关于组织变革的事情，大家都在把一切推向左侧。你怎么看？对我来说，工具是显而易见的，就是选择一个能完成工作的工具；学习如何使用它并实现它。在你看来，还有哪些其他的变革需要实施？

Kohsuke Kawaguchi：是的，正如你所说，技术层面显然有很多问题，还有其他的挑战。我可以给你举个例子，Jenkins 产品本身的基础设施只有有限的容量，所以当我们想要将更多的 QA 工作推向左侧时，我们能做的也非常有限。换句话说，这需要资金，而在开源项目中，资金往往很难获得。

然后，还有一个对 QA 至关重要的挑战。QA 实际上是一个永无止境的挑战，需要自动化大部分工作，而且这并不容易。我曾经做过编译器工作，所以我曾天真地认为测试是非常简单的——实际上它是完全确定的。我有一个输入，运行程序得到输出。然后我将输出与应该得到的输出进行比较，然后就完成了。但是大多数有趣的应用程序，实际上很难通过这种方式来衡量。

“QA 实际上是一个永无止境的挑战，需要自动化大部分工作。”

—Kohsuke Kawaguchi

有一次，我去了一家汽车制造商，他们有一座塔，上面装满了车头灯。他们正在测试一个控制车头灯的*型微控制器。想象一下，把它们安装到塔上，验证灯是否真的亮起，重置硬件等等。这些都是工作。仅仅在技术方面，仍然有很多类似的巨大挑战。每次我们想做更多的 QA，总有一长串这样的难题需要解决。

Viktor Farcic：更不用说如果你在那些公司里，面临的组织挑战了。

Kohsuke Kawaguchi：完全正确！你有不同*组的人，你习惯以某种方式操作，而你的左移进程在项目的不同阶段以不同的速度进行。如果你想象一下，有人正在一个运营团队工作，接触着 100 个不同的运营团队，而只有一个团队想要以不同的方式做事，那么反应就是，“看，我不能只为你一个人调整。”

这些问题总是充满挑战。我再给你举个例子，讲讲更快的交付如何在下游产生摩擦。市场营销团队：他们做的事情，比如营销活动或事件，更适合大规模发布。你不会因为一个功能就发布新闻稿，对吧？客户接触团队也是如此。他们不想通过过多的沟通去打扰客户。你希望将事情批量处理。随着工程工作变得更加连续化，这些人也需要改变他们的工作方式。这并不是什么新鲜事，不能说是我发现了别人都不知道的惊人发现。说起来容易做起来难。

容器的炒作

Viktor Farcic：说到技术，过去几年所有的炒作都集中在容器上。你怎么看容器在整个局面中的作用？

Kohsuke Kawaguchi：我在 Sun Microsystems 工作时，我们有一个自己的操作系统，叫 Solaris。我记得在一个内部会议上，他们谈到了一个叫做 Solaris Zones 的东西。他们说，“哦，我们可以把用户空间划分为不同的部分，并为它们分配不同的 CPU 大*、内存等。它们就像一组不同的计算机，几乎没有开销。”所以现在回头看，我可以看到他们其实是在构建后来的容器技术的基础。

Solaris 团队一定是有意识地设计了这个功能，充分意识到它可能带来的影响。但是它根本没有引起关注。还有许多类似的例子。从 Solaris 中我得到的启示是，作为开源工程师，我们常常认为，只要把代码发布出去，并解释它的功能，那么其他有相同想法的开发者就能理解，并从他们的角度看待问题，进而能够使用它。结果证明，这完全不是事实，这也是我之前没有意识到的。

Solaris 团队把所有的螺丝、螺母和引擎都组合在一起，做成了这个新难度的隔离功能，他们期望我们其他人能理解其中的要点，但我们并没有理解。它需要通过某种打包和定位，才能让主流真正看到它的价值，这对我来说是一个有趣的历史课程。

Viktor Farcic：但你对容器的看法是什么？显然，它是我们在这个领域做的一切的关键部分。

河口幸子：显然，我认为容器非常棒。我简直不敢相信我们仍然需要说它们是好东西，但这个领域正在非常快速地发展。我记得曾经参加过一次 DockerCon 会议，感觉这些人将会是下一个 VMware，他们将占据那些会部署数十万容器的企业和大型公司。然而，在短短几年内，我们发现兴趣的层次向上移动了。容器被认为是好东西，但现在它已经和 Unicode 一样不再令人激动。每个人都在用，而没有人关心。

“显然，我认为容器非常棒。我简直不敢相信我们仍然需要说它们是好东西，但这个领域正在非常快速地发展。”

—河口幸子

我对这一领域惊人的发展速度感到震惊。现在，我认为 Kubernetes 正在风头最劲。但是，如果你看看亚马逊的未来动向，他们实际上几乎把 Kubernetes 隐藏起来，像是一个实现细节。

一旦某个东西在某一层级占据主导地位，这种主导地位就会立即推动对话向上发展。现在，人们开始讨论所有更高层次的价值观，整合它们，并如何将其隐藏在背后。Unicode 和 TCP——它们是一样的。我认为这已经在 Kubernetes 中发生了。这就是我所说的“无聊”。

*克托·法尔奇奇：好技术的关键是，如果它变得无聊，但每个人仍然使用它，那它就完成了它的使命。

河口幸子：我认为这是工程师们的终极名人堂——实现了“好技术”，这种技术变得如此无聊，没人再谈论它。我住在圣荷西，所以我偶尔会跨越金门大桥，那是一个壮丽的工程奇迹。我不知道是谁建造了它，但我确信其中蕴含了大量艰苦的工程工作。尽管人们从中受益，但大多数人并不会停下来思考其中的工作。

有时，我觉得这个世界应该更加认可这些人的工作，但我也觉得这些人可能根本不需要来自全世界的认同。我敢打赌，他们知道自己已经做出了伟大的工作。

会议、开源、美国与中国

*克托·法尔奇奇：现在，你是 CloudBees 的首席技术官，负责技术方面的工作。我很好奇，你是如何应对这一切的？我之所以问这个问题，仅仅是因为我自己也不知道该怎么做。每次参加一个会议，我都有一种感觉，那就是我需要再花上一年的时间，才能搞清楚那些程序到底在做什么。

川口浩介：我希望我知道答案。我自己也在努力跟上发生的事情。我觉得参加会议很有用，因为那里的人会试图向你解释事情，而不是期待你自己去理解。与此同时，从更宏观的角度来看，像你我这样的人可能擅长理解那些模糊不清的部分，所以从这个角度来说，参加会议有点浪费时间，因为我们可能在相同的时间里自己学到更多东西，而不需要花时间去旅行。此外，当你是技术的生产者时，会议是一个很好的方式，可以听到使用你产品的人的反馈。听取他们的意见总是值得的。

我去参加会议的另一个原因是，我个人无法看录制的视频。我根本无法长时间集中注意力。我开始看 YouTube 视频，然后在 15 秒钟内就开始做多任务处理，接下来，不知不觉中，我完全失去了对视频内容的关注。如果我能改善这一点，我在获取信息时会更加高效。

我也认为“经得起时间考验”这一观点是有一定道理的。如果我长时间听到某件事情，那么它可能值得关注。就像“口碑”一样。如果你信任的人对某件事情感到兴奋，那也很可能值得关注。我认为，实际上，普通人过滤信号与噪音的唯一方式就是这些。

*克托·法尔奇奇：我不知道他们是怎么管理的，也许他们根本没管理。你对开源有什么看法？当你开始你的职业生涯时，开源还不是一个热门话题，但现在已经成了。那么，从一开始就是闭源的项目，是否还有未来？

川口浩介：在我们谈这个之前，我得纠正你一下。开源已经存在很长时间了，远在我开始做 Jenkins 之前。我认为它仍然证明了我之前的观点，那就是寻找更可行的方式来推广 DevOps。我真的相信，开源本质上是一种更好的软件开发方式。我亲眼见过许多专有软件被开源所打败。我们已经谈到过 Sun 和 Solaris，所以这就是我的例子。

当我思考是什么让开源如此成功时，我认为一个关键因素是，开源让来自各个地方的新想法可以更快速地被测试，从而迅速地凝聚成更好的解决方案。创新无处不在，这是一个关键的区分因素。

但是我觉得，现如今，在不同的*度上，另一个正在出现的区分因素是他们所面对的问题的规模。

*克托·法尔奇奇：你能再澄清一下吗？

Kohsuke Kawaguchi：我在日本度过了职业生涯的很大一部分。在全球软件开发市场中，日本大约占有 10%到 15%的份额，因此这不是一个*市场，但也不是大多数市场。由于语言和时区等各种挑战，日本的软件公司大多只解决国内市场的问题。它是一个封闭的市场。

日本大约有 1 亿人。如果你在运营一个服务，并且服务的对象是整个日本，你的扩展挑战最多也就只有 1 亿人。我参加了中国的开发者会议，意识到尽管他们的国内市场同样封闭，但它要大得多。所以，他们最大的服务公司正在面临并解决一些日本公司甚至未曾想到的扩展问题。

我很震惊中国谈论如何需要机器学习来帮助我们的运营。在日本，这是一个科幻问题，而在中国，这是今天的一个现实问题。全球唯一能与之匹敌的市场是美国。所以，我坚信在接下来的十年里，我们的技术领域将成为美国和中国的双头垄断。

由于市场的规模，当这些市场首次发现新问题时，它们会被解决，并且解决方案会传递给全世界，这样其他国家就不会真正进行创新。

“我很震惊中国谈论如何需要机器学习来帮助我们的运营。在日本，这是一个科幻问题，而在中国，这是今天的一个现实问题。”

—Kohsuke Kawaguchi

我想说的是，接触到前沿挑战的机会正变得和开源一样，甚至更具区分度。我曾说过创新曾经发生在各地，但我现在感觉创新正发生在接近大市场挑战的地方。人们说最终用户公司现在是创新的源泉，而不是供应商，我认为这也是同样的原因。所以，这是我始终保持在心中的一个前景。

未来十年内的 DevOps

Viktor Farcic：你怎么看待未来十年内 DevOps 的发展？

Kohsuke Kawaguchi：我希望我能更好地把握未来，来谈论一些有趣的事情。就像我一直说的，我认为显而易见的方向是更多的自动化。

世界各地对软件和技术的需求将会增加。例如，每次我经过机场并展示我的驾照来认证自己时，我会想到，这应该是一个可以解决的问题。所以，是的，会有更多的软件，也会有更多的自动化。

我想我就是离不开自动化！除此之外，我认为数据和机器学习在我们开发软件的过程中应该扮演核心角色。这些技术已经打破了许多领域，认为我们自己的职业不受影响是愚蠢的。但我不知道这些事情会发生得有多快。如果我能预测这些事，我现在应该是在做那件事，而不是在跟你说话。

“将会有更多的软件，也会有更多的自动化。”

—川口耕介

*克托·法尔奇：你提到过几次自动化。当我访问公司时，总是看到很多人在反复做重复的手动任务。我甚至参与过一些人质疑自动化的对话，这对我来说完全无法理解。有什么不喜欢自动化的呢？为什么我们还没有实现自动化？

川口耕介：是的，这很有趣。其实有时候我也有同样的感觉。作为局外人，我们进入一些地方，确实有时会低估现状的合理性。事情总是比眼见的要复杂——我不理解的事物、我无法把握的细微差别、背景等等。我觉得我们对这些事情稍微谦虚一点并不坏。如果我的父母认为我们的工作完全可以自动化，我也不感到惊讶。你去办公室，坐在电脑前，然后再回家。你似乎每天都在重复这个过程。这有什么不能自动化的呢？

*克托·法尔奇：完全正确。

川口耕介：我们需要*心，因为我们在看别人时，可能也会掉进那个陷阱。并不是说没有人在做那些应该被替代的重复手动工作。我敢肯定，也有些人会抗拒变化什么的。但我第一反应总是假设他们看到了我没有看到的东西。所以，我也不清楚。就我个人而言，我没遇到那些真的在做这种重复性工作的人。大多数时候，我认为人们看待自己的工作并不觉得它特别重复。

另一个有趣的视角是，如果你想到日本，他们有传统的文化项目，比如茶道、剑道或柔道。这些是艺术形式，强调重复，按照一定的型，反复练习同样的任务直到完美。你从模仿大师开始，然后慢慢发展出自己的风格。看起来好像是在同一个地方打转，但对于没有训练的人来说，实际上这是一个向上的螺旋运动。隐含其中的是对前辈智慧的尊重。每次“这次我做得比上次更好”的感觉也很让人满足。我认为这是激励自己走得更远的关键。我认为这些很美丽，尽管这也许只是亚洲心态的一部分。

Viktor Farcic：在我们开始结束时，我很想知道，现在有没有什么事情真的让你在行业中感到兴奋？

Kohsuke Kawaguchi：作为技术人员，我们总是对玩新玩意儿感到兴奋。所以，我想玩这些新工具和新服务是让我非常兴奋的一件事。昨天，我在玩谷歌的新语音合成引擎，效果相当不错。这有点像黑魔法，很酷，然后我就开始想我们可以用它做些什么，比如有声书、开车时的语音导航，或者其他的。你永远不知道它能带来什么。新技术总是像这样有趣。

我确实喜欢玩这些玩意儿，但与此同时，一些平凡的问题也让我感到兴奋。我去看一些大公司在快速部署大型复杂软件时遇到的问题。每个人都有测试不可靠的问题，或者测试太多，且大部分时间它们并没有发挥什么有用作用。他们开始质疑是否运行所有这些测试真的有意义。我很感兴趣看看我们是否能智能地挑选出需要运行的测试，并按正确的顺序执行。我有一种感觉，我们能把平均周转时间缩短一个数量级。

另一个平凡问题的例子是我们如何跟踪漏洞，进行代码更改，然后再进行验证。这是一个无处不在的问题，它通过人们的手动沟通和协作来*系。我觉得其中一些已经准备好进行自动化了。

十字绣、乐高和 DevOps 之间的联系

我想，一个人的平凡问题可能是另一个人的激动人心的挑战。除此之外，还有十字绣。

Viktor Farcic：十字绣？你到底指的是什么？

Kohsuke Kawaguchi：十字绣是一种针线活。我开始做这个是因为我的妻子也做，我觉得和她有一个共同的爱好会很好。通常这是老年女性的爱好。让我用极客们能理解的方式解释一下十字绣。想象一下一个屏幕，上面有像素。每个像素可以是不同的颜色。我们就是这样构建图形的。十字绣和这个完全一样；只是它是在布上做，而不是在屏幕上，使用的是彩色线而不是像素。它只是视频屏幕的模拟版本。所以，我会绣一些视频游戏角色什么的，纯粹是为了好玩。

现在，显然，真正的十字绣操作是非常手动且重复的。我觉得我应该能把它自动化。如果有一台可以编程的机器，就像缝纫机一样，我想看看能不能控制它做正确的事情。一台可以接收 JPEG 或 PNG 格式图片作为输入的机器，然后为我做十字绣。我觉得那会很棒。那样我就能说，我掌握了十字绣的所有技巧，然后可以转向另一个爱好。我真希望能做成这样。我从来没能在十字绣社区找到任何一个对这种自动化充满热情的人。大多数十字绣爱好者之所以喜欢它，是因为他们喜欢在绣的时候和别人聊天，所以对于他们来说，自动化的想法是可怕的。他们会问，做这个有什么意义？这就是为什么我迫切想找到一个场所来谈论这些事情。

如果我能做到这些，乐高可能是下一个。

*克托·法尔奇奇：乐高和 DevOps？这是我没想到会和你讨论的话题。

河口弘介：我是一个大乐高迷，在乐高社区里，你可以不断地讨论如何整理和存储你的乐高积木。你建造一个东西，然后把你建好的模型拆掉。你*时候大多数人都把乐高积木放在一个大袋子里，然后你长大后就不再玩乐高，转向其他东西了。但是对于我们这些从未对乐高失去兴趣的人来说，我们不断买更多的乐高套装，积木多到不能放进一个袋子里。找你想要的积木将会花费无数的时间。

我有几个抽屉都装满了乐高积木，在整理它们的时候，自然我开始想着，“哇，积木这么多，我得自动化这个过程。”实际上，很多人真的是这么做的。所以，他们不仅仅是建造软件，而是建造机器。它配有一个摄像头，可以拍下传送带上积木的照片，然后将形状与目录中的形状进行比对，再通过某种喷嘴吹气把积木推到正确的箱子里。这种自动化真是有趣，但反过来，我发现自己总是试图自动化一切，做任何可能的自动化。这就是我的“工作方式”。我不知道其他软件开发人员是不是也有这种感觉。这个故事没有结论，但这正是让我兴奋的原因。

*克托·法尔奇奇：我觉得有一种恐惧，如果你做这些事情，你就是在把自己从一个“保证的工作岗位”中自动化出去。

河口弘介：那不是很完美吗？因为现在我可以死心塌地地去做其他事情了，因为我已经完全实现了自我自动化！当然，我们知道没有什么事情是完全可以自动化的，甚至连十字绣也不行。我的意思是，软件开发教给我们的一点就是，当你通过自动化解决了一个问题时，你就会面临下一个问题，而这个阶梯永远不会结束。对我来说，这种循环是挺有趣的。

比如十字绣，如果有一天我设法制作出我所描述的终极十字绣机器，我接下来可能会开始考虑如何自动化管理我的线材库存。到那时，我可以绣任何设计，因此我敢肯定我将以难以想象的规模使用这些线。今天，去当地商店买合适颜色的线可能需要几天时间。当一个绣品项目需要几个月时，这还可以接受，但如果它只需要 15 分钟，那就不行了。那么，如何优化这个过程呢？

“软件开发教会我们的事是，如果你通过自动化解决了一个问题，那么你就会面对下一个问题，而这个阶梯永远不会结束。对我来说，这有点有趣。”

—Kohsuke Kawaguchi

或者想想《Minecraft》玩家遇到的那些次要问题。我曾经有一个可以在 Minecraft 世界中创建可编程机器人的 MOD，因此我可以编程让它进行挖矿或建造。一旦你自动化了挖矿部分，那就太好了，但我们有几乎无限的原铁矿石库存，然后你就开始想，“哦，现在我需要自动化冶炼部分。不然我就永远在冶炼了，”于是你就这样一直走下去。

Viktor Farcic：这是我听过的最怪异的故事。

Kohsuke Kawaguchi：我希望这至少能对读者们带来一些娱乐性。

Viktor Farcic：哦，我觉得它会是的。我的意思是，对很多人来说，我认为将它与乐高和《Minecraft》联系起来，会是一个非常好的方式，将 DevOps 与现实世界联系起来。

Kohsuke Kawaguchi：谢谢，Victor。这真有趣。我很期待看到你的书。

Viktor Farcic：感谢你抽时间和我交谈。

第四十一章

14

第四十二章：肖恩·霍尔

云架构师

第四十三章：介绍肖恩·霍尔

作为一位经验丰富的行业顾问、作者、演讲者和企业家，肖恩·霍尔在 DevOps 云自动化、可扩展性、Docker 和 Kubernetes 方面有超过 20 年的经验。他的经验涵盖了从*型初创公司到财富 500 强企业。你可以在 Twitter 上关注他，账号是 @hullsean。

肖恩·霍尔与数据库世界

*克托·法尔奇克：让我们开始吧，先介绍一下你自己，告诉我们你是如何接触到 DevOps 的。

肖恩·霍尔：我住在纽约，已经在技术领域和初创公司中工作了十多年。我最早的工作是为高流量网站做数据库工作、可扩展性和性能调优，像 好莱坞报道 和 公告牌 这样的站点，每个月有一亿独立访客。那时候，亚马逊开始变得更大，很多初创公司要么迁移到云端，要么原生部署他们的应用程序到云端，因此我看到了在自动化方面专业化的机会。

我的背景其实是在 Unix 和 Linux 领域，因此对我来说转向这个方向是一个不错的选择，但我仍然做很多与 MySQL、Postgres 和 Redshift 相关的数据库工作。如今，我还做很多 Python 编程，以及像 CloudFormation 和 Terraform 这样的自动化工作，它们允许你在云端或 AWS 账户中编写脚本，管理所有对象，这也使你能够对所做的所有更改进行版本控制。

*克托·法尔奇克：每次做演讲时，我都会被问到一个相同的问题：我们应该如何处理数据库？

肖恩·霍尔：我有时会读到一些关于人们尝试将 MySQL 数据库放入 Docker 容器中的文章，以及由此产生的糟糕性能，所以这个问题确实非常值得探讨。很多自动化尝试通过重复性等方法来解决的问题，并不一定适用于数据库。例如，如果你有一个由用户和活动组成的大型 MySQL 数据库，这些表随着时间的推移已经发生了变化。我的意思是，你有插入操作，也有删除操作，数据库会根据使用情况调整和优化大量的 I/O 操作到磁盘。

现在，如果你要重新构建这个数据库，磁盘上的布局会有所不同。因此，假设一个重新构建的数据库与另一个完全相同，这种假设并不一定成立。在微服务中，当你进行备份时，你必须为所有这些备份添加版本号或时间戳，然后问题就来了：如何在特定的时间点恢复整个应用程序。如果你有 10 个微服务数据库，想要恢复它们，可能会变得更加困难。

开发与运* – 如何定义 DevOps

*克托·法尔奇克：转到一个更广泛的话题，你如何定义 DevOps？我问过的每一个人给出的答案都不一样。

Sean Hull：事实上，我对这个问题有很多看法。几年前，我在我的博客上写过一篇文章，名为划分开发与运*的四个字母词，暗示这四个字母词可能是一个脏话，就像开发团队对运*团队咒骂一样，而运*团队也对开发团队咒骂。但我指的四个字母词是“风险”。

总结我的文章，我认为，过去的开发团队和运*团队在业务中是分隔的，他们有着截然不同的任务。开发人员的任务是编写代码来构建产品，并满足客户的需求，同时直接将变更纳入并推动更复杂的产品。因此，他们的日常思*关注的是变更和回应产品团队的需求。

另一方面，运*团队的任务是稳定性。就是“我不希望这些系统在凌晨 2:00 宕机”。因此，从长远来看，运*团队的思*方式是尽量保守，减少可变部件、减少代码和新技术。你的技术栈越简单，就越可靠，越稳健，越不容易失败。我认为，开发团队和运*团队被分隔成孤岛的传统原因是因为这两者有着截然不同的任务。

这两者是两种不同的方式，来优先考虑你的工作和优先事项，特别是在思考业务和技术时。然而，缺点是这些团队之间的沟通并不畅通，他们经常针锋相对，推彼此朝着相反的方向发展。但为了回答你的问题，“DevOps 是什么？”，我认为它是一种文化运动，努力让这些团队更好地沟通，而这是一件非常好的事情。

Viktor Farcic：那基础设施呢？

Sean Hull：我所看到的情况是，随着基础设施代码的普及，很多公司根本没有运*人员、DBA，甚至没有运*团队。他们只有开发人员。只要你能够构建基础设施，这没问题，但我们已经失去了运*团队所带来的那种稳定性、可靠性和保守思*的心态。而现在，一切都落在开发人员肩上，他们不仅要编写代码，往往还要部署基础设施。

在大公司中，通常会有一个独立的 DevOps 团队，因此希望他们仍然承担一些运*任务，但我更倾向于简化的思考方式。“DevOps 是什么？”是一个有趣的问题，我认为它对不同的人意味着不同的事情。

“它[DevOps]对不同的人意味着不同的事。”

—Sean Hull

*克托·法尔奇奇：我同意。每个人的答案都不同，所以没有人知道这是什么。你刚才说的让我想起了一个有趣的，或者说是令人恐惧的——我不知道是哪一种——案例。我曾与一个人交谈，他说：“哦，我喜欢这个。对我们来说真的很有趣，因为如果我们实施无服务器方法，我们就可以摆脱所有操作，因为我们将没有服务器。”你怎么看待这个问题？

肖恩·赫尔：实际上，这是一个很好的问题，但比那更复杂一些。我写过一篇文章叫做 《向无服务器迷问的 30 个问题》，在文章中我深入探讨了我们是否需要担心在使用无服务器架构时的相关问题。虽然无服务器架构确实简化了操作，但仍然有很多需要注意的地方。例如，在一个无服务器框架中，你可能有一个服务用于身份验证，另一个服务，比如 DynamoDB 或 Firebase，作为数据存储。然后你有运行中的 Lambda 函数。随着更多组件的加入，你会有更多的暴露面，这些暴露面可能会受到恶意代码的攻击。

例如，在传统的三层架构中，数据库隐藏在 VPC 后面。但在无服务器架构中，数据库位于互联网上，那么你如何测试和部署 API 网关的更改呢？在传统应用中，你有 Web 服务器，部署应用代码等——而在无服务器架构中，你必须部署 API 网关配置。

对于 Lambda，有一个无服务器框架，可以使用无服务器 YAML 文件来配置 API 网关，部署时，它会使用 CloudFormation 为你完成所有这些工作。但在无服务器应用中，测试是另一个更复杂的领域。你可以在本地进行某种程度的测试，但它与在本地运行数据库的应用程序测试有很大不同。

*克托·法尔奇奇：但是在无服务器架构中，你通常是连接到其他地方的数据库，那么你在哪儿运行开发数据库？

肖恩·赫尔：你可能无法在本地运行所有这些组件，因为事实证明，无服务器框架已经构建了存根，以便在你的计算机上本地运行类似 Amazon 的资源。在管理无服务器框架方面，我确实认为无服务器简化了某些事情，但也使其他事情变得更加复杂。

探索无服务器函数、SQL 和云服务

*克托·法尔奇奇：你如何进行无服务器函数的负载测试？

肖恩·赫尔：每次调用该函数，您都需要支付费用，那么您真的想在十万客户身上进行负载测试吗？我不知道。此外，还有超时的问题。您在 AWS 账户中有资源限制，所以也许会碰到瓶颈，因为您每个月只能运行一定数量的 Lambda 函数，或者您有 10 个 Lambda 函数，其中一个函数失控，导致其他所有函数下线，因为您已经达到了某些资源限制。

我认为肯定还有一些需要管理的事情。我认为 DevOps、基础设施即代码和无服务器已经改变了系统管理、站点可靠性工程师和运*工程师的工作性质。这改变了他们的日常工作，但我仍然认为还有很多工作要做。

"DevOps、基础设施即代码和无服务器已经改变了系统管理、站点可靠性工程师和运*工程师的工作性质。"

——肖恩·赫尔

*克托尔·法尔奇克：我们如何将数据库过程与我们正在进行的所有自动化集成起来？

肖恩·赫尔：数据库管理要比自动化 Web 服务器部署、缓存服务器（如 Memcached、Redis）或搜索服务器等组件复杂得多。显然有更多的复杂性。另外，持续集成中的另一件事是，您的代码通常与影响数据库的代码一起部署。

例如，也许您有一个用户表，其中有一个手机号码，而您想添加一个工作电话号码。因此，您围绕此编写代码，然后编写 DDL，即 SQL 语句来添加该列，并将它们与 Python 或 Node.js 代码一起部署。这些被称为迁移。因此，您正在将数据库版本向前迁移，以便现在该表可以支持该附加列。

事实上，迁移脚本通常包括前进和回退脚本。但对于数据库来说，您可以看到，对于代码来说这没问题。您可以回滚到旧版本。这没什么大不了的。但是，如果您现在回滚数据库，可能会有数据存在于该附加列中。

如果您刚刚添加了一个工作电话号码，也许您的 10000 个用户中有 10000 人添加了他们的工作电话号码，如果您回滚，您将删除该列并丢失数据。

在某些情况下，回滚和前进脚本由 DBA 或负责管理数据库的人员管理。但如果您是一家自建应用程序的企业，那么您就没有这样的奢侈。也许您会盲目编写代码，删除该列，并丢失数据？这只是我们在企业其他部分进行的自动化不一定总是在数据库层面同样有效的另一个例子。

Viktor Farcic：正如我所说，这不是我的专长，但我一直有一种印象，我宁愿没有回滚功能，而不是让人们依赖这种功能在数据库中。这似乎比实际提供任何真实的价值更危险。第一笔交易进入系统时，你怎么回滚？你做不到。

Sean Hull：这确实是一个复杂的问题，很多人都曾思考过这个问题。但与此同时，过去数据库模式更改通常是临时的做法，比如你把脚本交给 DBA 说：“嘿，添加这些列。”这与版本控制系统没有紧密绑定，因为这很难做到。数据库没有版本化的模式——至少 MySQL 和 Postgres 没有——据我所知，Redshift 也没有。所以目前，它们并不真正支持这个功能。

Viktor Farcic：在做迁移时，你有偏好的工具吗，还是直接使用 SQL？

Sean Hull：一些语言支持这种做法。例如，Ruby 内置了迁移功能，所以当你进行代码更改时，也可以部署 SQL。响应是，这些 SQL DDL（数据定义语言）命令块会和其他代码分支一起存放，这样当你检出应用程序的特定版本时，你也在检出数据库的某个版本。

Viktor Farcic：那么关于应用程序的零停机部署呢？比如人们使用蓝绿部署或滚动更新，这实际上意味着你的应用程序会同时运行多个版本。那么，你在数据库层面上如何处理这个问题？

Sean Hull：这是另一个好问题。现在很多公司都在使用 Amazon 关系型数据库服务（RDS）。它是一个托管的 MySQL、Postgres 或 Oracle 数据库，由于它是托管的，你无法访问命令行，也无法访问服务器本身。

几年前，我为一家名为 ROBO 的公司工作，当时需要对 RDS 进行数据库升级。在 MySQL 安装中，你可以登录命令行，直接访问 MySQL 实例。这样，你可以在几秒钟内重启它，且通过复制可以实现双主模式。其中一个是只读的，数据在两者之间进行双向复制，这样你可以在数据库设置为只读模式的情况下进行零停机部署和零停机升级，而且只需短时间保持只读模式。

我在尝试升级 RDS 时的经验是，升级后重启至少需要五分钟，而且我们对幕后发生的事情几乎没有可视化，因为服务器是由 Amazon 控制的。我们只能访问 MySQL 数据库；我们没有权限访问实例，所以我们无法真正看到重启和升级的状态，也无法知道它是否因为数据损坏等问题而被拖延。

Viktor Farcic：那么，你是怎么处理的？

Sean Hull：我们进行了多次演练，并在另一个 AWS 账户上创建了数据库，然后对其进行了升级，并计时以查看需要多长时间。这是一种非常繁琐的数据库升级方式，不仅没有实现零停机，实际上还保证了停机时间。没有真正的办法避免这一点。对于一些初创公司来说，这样做是值得的，因为你有一个托管的解决方案：数据库始终在运行，你有一个仪表板，可以查看发生了什么。

然而，如果你没有数据库专家来管理你的数据库，那么这会简单很多。但如果你有 DBA，自己管理 MySQL 或 Postgres 会更好，因为你可以显著减少停机时间。

Viktor Farcic：那另一种情况呢？假设我们不是在升级数据库，而是在发布一个与数据库交互并可能更改模式的新版本应用程序。在这种情况下，我们将有两个版本的应用程序，它们可能需要不同的数据库模式。假设版本 1 和版本 2 引入了一个新列。你有什么建议来处理这种情况吗？

Sean Hull：是的，之前我提到的迁移脚本，加上你的代码更改；所以，当你检出应用程序的新版时，你也应该检出新版的 SQL 语句和 DDL 语句，这些语句会添加那个新列。所以，如果你从头开始，你会从数据库的导出文件开始，然后应用所有指向它的迁移脚本。

Viktor Farcic：这些更改是否需要与应用程序的先前版本向后兼容，还是直接采用新模式？

Sean Hull：通常你是在向前推进。如果你要倒退，你可能需要或不需要应用已删除的列，因为例如在我之前描述的情况中，我们添加了用户的手机号码和工作电话。如果你回到应用程序的早期版本，它就不会访问工作电话。

如果那个额外的列存在，通常不会有问题，除非在某种特定情况下，如果你在应用程序中使用了 select *，而 select * 正是因为这个原因而受到批评。如果你使用 select * 并更改了数据库列，你将得到不同数量的列返回，可能会导致代码出错。你永远不应该使用 select *，而应该明确指定你访问的所有列。

Viktor Farcic：当然。那么，根据你的经验，当你曾经合作过的公司迁移到云时，你认为最大的潜在问题是什么？

“我认为最大的障碍是文化问题；现在云中的一切都做得完全不同。”

— Sean Hull

Sean Hull：我认为最大的障碍是文化上的；现在云中一切的运作方式都完全不同。在传统的计算世界里，你有物理服务器，你设置服务器，给它命名，把它插入网络，并像在现实世界中一样配置所有这些东西。几乎就像物理物品都有名字。

在我们拥有托管服务之前，人们在自己的业务中有一个机柜或者一个机房，你可以实际看到机器并插入电缆。但在云中，一切都是虚拟化的，这最终成为一个完全新的范式，这不仅对业务人员构成挑战，也迫使技术人员以全新的方式思考。

Viktor Farcic：你说挑战，像是安全吗？

Sean Hull：是的，我们以安全为例。在 AWS 中，你有 VPC，它就像虚拟网络一样，因此你可以设置私有子网和公共子网，并且可以通过两种方法来控制对子网内服务器的访问：一种是安全组，另一种是访问控制列表。这与旧世界中控制服务器访问的方式非常不同，在旧世界中，你需要有一个防火墙，由网络团队管理和配置，或者你会在每个服务器上配置防火墙，比如使用 iptables。

在亚马逊的世界里，它无疑是复杂的，但那些防火墙的配置是以安全组和 VPC 上的 ACL 的形式呈现的，因此它的虚拟化网络功能非常强大，但也非常复杂，故障排除也很困难。当你尝试访问服务器，却没有响应，并且你通过调试和故障排除试图找出可能的原因时，这些问题是巨大的挑战。

但回到你的问题，迁移到云端的最大挑战是，对于企业来说，这有一个很大的学习曲线，不仅仅是理解一个 EC2 服务器是如何启动的，它是如何使用磁盘的，还是如何访问亚马逊的弹性块存储（EBS），如何在 S3 中存储文件，以及如何编写响应事件并在该环境中采取行动的 Lambda 函数。这是一个全新的范式和一套全新的技术，因此对工程师和业务人员来说，都是一个巨大的学习曲线。

Viktor Farcic：我见过很多这样的工具，它们告诉你，如果你购买我们的工具，我们将把你现有的东西迁移到云端。例如，Docker 在最近的 DockerCon 上宣布，他们将容器直接迁移，而不需要做任何改动，一切都会正常运行。你对此怎么看？

Sean Hull：销售人员为了卖产品，往往会大大简化问题；以我的经验来看，关键就在于细节。并不是说像那样的自动化工具就没有价值或用处。它可能是将你的应用部署到云端的第一步，而且可能比逐一重建所有东西要更简单。但我怀疑，单单依靠一个脚本，它就能神奇地解决所有问题。

举个例子，EC2 实例有不同的性能特征，不仅仅体现在磁盘 I/O、内存和 CPU 上，在较*的实例中，实际上它们会限制网络访问，因此你可能启动一个实例，但它的表现可能不尽如人意。可能会花费一些时间。事实上，可能会发生各种问题。你可能写过一些假设你有 root 权限的 MySQL 脚本，然后你将它们迁移到 RDS 中，却因为没有访问权限而出现错误。要考虑的事情有很多。

Viktor Farcic：那么，应用程序呢？假设我是一个公司，过去 10 年开发了 OpenFrame 应用程序。这是否需要某种改变范式或架构？你对此有何看法？

Sean Hull：可能会。例如，许多应用可能使用共享存储。现在，Amazon 有一个叫做弹性文件系统（EFS）的东西，旨在镜像传统数据中心中看到的功能。但真正正确的做法是将资产和内容存储在 S3 上，不过在那些旧的应用环境中，S3 是不存在的，所以你必须重写应用的部分内容来使用 S3。我去年和一家媒体出版公司合作，他们使用 NFS 服务器来存储一些内容。

“很多年过去了，很多公司曾经被 Oracle 锁定，现在已经过去了这么久，出现了新一代的人，他们还没受到过那样的伤害。”

—Sean Hull

正确的做法是使用插件——在这种情况下，是 WordPress——来访问 S3 中的文件。但是他们希望在尽量减少变更的情况下将其迁移到 Amazon。短期内，我们设置了 EFS，这是 Amazon 的 NFS 版本。Amazon 在云中构建 EFS 的唯一原因正是因为，就像你提到的那种情况一样，你有应用要迁移，而你不想进行重构。在 Amazon 中，原生的做法是将文件存储在 S3，因为 S3 提供生命周期控制和不常访问的功能，它还有 Glacier 以及其他相关服务，这就是在云端的原生做法。

供应商锁定、AWS 和跟上 DevOps 世界

Viktor Farcic：你合作的公司是否会在迁移到 Amazon 时，表达对供应商锁定的担忧？

Sean Hull：是的，实际上我觉得很多公司已经与 Oracle 深度绑定已经过去了很多年，时间已经过去得很久，以至于现在有一代人没有经历过这种情况。我感觉现在关于 Amazon 锁定的恐惧感可能没有想象中的那么强。像 Terraform 这样的工具可以连接到 Google Cloud；它可以与 IBM Cloud、Azure 和 AWS 等云平台进行交互，因此，如果你在 Terraform 中构建了基础设施代码，就可以在任何一个云平台上部署资源。Terraform 就像是 CloudFormation 上的一层，能够以通用的方式实现这些功能。

Viktor Farcic：你对容器调度器怎么看：Kubernetes、Mesos、Swarm 等等？

Sean Hull：我没怎么使用过 Kubernetes 和 Docker Swarm。Docker 很棒，容器化已经存在很久了，从 1970 年代末期就有了。事实上，我认为最初的 BSD 项目是容器化的先驱，虽然显然 Docker 是大家现在都非常熟悉的现代版本，它做了很多强大的事情。

你可以非常轻松地启动开发环境和 QA 测试，因此你可以将所有代码封装起来，重建一切你需要的东西来让你的应用程序运行，这使得所有事情都变得更加可重复等等。我认为容器不会很快消失，因为它们满足了一个非常大的需求。

Viktor Farcic：我有一种感觉，新事物出现的速度只是在不断加快。你是如何跟上这个节奏的，与你合作的公司又是如何应对这些变化的？

Sean Hull：我觉得他们并没有跟上。我去过很多公司，他们从未使用过无服务器架构。他们的工程师根本不知道无服务器是什么。Lambda、Web 任务和 Google Cloud Functions 已经发布一段时间了，但我认为能够真正利用它们的公司非常少。我写过另一篇文章博客，叫做 Is Amazon Web Services Too Complex for Small Dev Teams?，我在其中暗示了它确实是。

我发现很多公司想要按需计算的优势，但他们实际上还没有足够的内部专长，无法充分利用 Amazon 所能提供的所有功能。这正是人们未能跟上技术进展的原因，因为它变化得太快了。我不确定答案是什么。就我个人而言，确实有很多我不知道的东西。我知道自己在 Python 上比在 Node.js 上更强。有些公司使用 Node.js，你可以用 Java、Node.js、Python 和 Go 编写 Lambda 函数。所以，我认为 Amazon 在新技术上的投资使得平台能够比许多公司更快速地发展，而这些公司还无法充分利用这一点。

“Amazon 在新技术上的投资使得平台能够比许多公司更快速地发展，而这些公司还无法充分利用这一点。”

—Sean Hull

*克托·法尔西奇：这是我从他们会议的公告中听到的印象。我当时想，要是我去的话，光是准备可能就得一年，如果我专心致志去做这一年，我还是很难在一天内跟上他们宣布的所有内容。

肖恩·赫尔：最近有个客户问我是否有使用过 Lambda 的经验。我说：“有的。”他说：“我们想用一个叫 Lambda@Edge 的东西。”我说：“我不知道 Lambda@Edge 是什么，我甚至没听说过它。”结果发现，Lambda@Edge 是四五个月前发布的一个产品，实际上挺酷的。通常情况下，在你的应用程序中，内容要么是从 Web 服务器提供，要么是从 S3 提供，然后你有 CDNs 来获取这些内容，并将其保存在离流量来源更近的位置。

假设我在纽约托管一个应用程序，但我有一个在日本的客户，他们访问那个内容。他们会访问一个离日本更近的 CDN 端点，因此应用程序会更快。所有的图形图像、CSS 和其他可以缓存的内容都会在该端点进行缓存。Lambda@Edge 允许你编写在边缘执行的 Lambda 代码，因此你可以检查用户认证时的 Cookie，然后查看 CDN 是否允许他们访问某些内容。你可以编写在边缘执行的 Lambda 代码，从而进一步加速你的应用程序。如果你的应用程序大部分是 Lambda，你将完全实现分布式，到那时你会看到巨大的性能提升。

*克托·法尔西奇：直到今天，我都没听说过 Lambda@Edge。

肖恩·赫尔：Lambda@Edge 提供了四个新的事件：既有请求前和请求后的端点，也有源前和源后的事件，因此你可以像任何其他 Lambda 代码响应 AWS 世界中的事件一样做出响应，而 Lambda@Edge 提供这四个新事件，允许你编写在 CDN 端点上运行的代码。

DevOps 的未来及总结

*克托·法尔西奇：我现在要问你一个我最讨厌别人问我的问题，所以你可以选择不回答。你怎么看未来？假设一年后的情况？

肖恩·赫尔：我看到技术领域越来越碎片化，我认为这最终会让事情变得更脆弱，因为例如，使用微服务的公司不会犹豫使用 Ruby、Python、Node.js 和 Java。它们有 10 个不同的技术栈，因此当你招聘新员工时，要么让他们学习所有这些栈，要么必须雇佣每个技术领域的专家。所有这些不同的云服务以及它们各自的特性也是如此：这种碎片化正在发生。

让我们以 iPhone 为例。想一想，在 Android 和 iPhone 之间，应用程序测试有多复杂。我的意思是，你有数百种不同的智能手机运行 Android，它们的屏幕尺寸、硬件配置、内存大*、底层硬件都不同。有些可能甚至有其他手机没有的额外芯片，那么你该如何在所有这些不同平台上测试你的应用程序呢？

“你有数百种不同的智能手机运行 Android，它们的屏幕尺寸、硬件配置、内存大*、底层硬件都不同。[…] 那么，如何在所有这些不同平台上测试你的应用程序呢？”

— Sean Hull

当出现这种碎片化时，意味着应用程序的效果会受到影响。我认为今天技术领域发生的事情，跟 10 到 15 年前一样，那时你的数据库后端有 Oracle、SQL Server、MySQL 和 Postgres。也许一些使用 DB2 的企业客户会选择 DB2，但现在有数百种开源数据库、图数据库、DynamoDB 和 Cassandra 等等。对于这些数据库来说，并没有真正深入的专业知识。

最终发生的情况是，像那些使用 MongoDB 的客户一样，他们通过艰难的方式发现了 MongoDB 中存在的各种奇怪行为和性能问题，因为在幕后发生的事情，几乎没有人掌握深入的知识。而在 Oracle 的领域，例如，有一些职业数据库管理员（DBA）专门研究 Oracle 的内部，成为性能专家，所以你可以雇佣这些专家来解决特定的问题。

据我所知，掌握 MongoDB 内部知识的专家并不多。你只能直接联系 MongoDB；也许他们有一些工程师可以派出来，那么未来会怎样呢？我看到很多碎片化和复杂性，这使得互联网和互联网应用变得更加脆弱，更易出现故障。

Viktor Farcic：你认为这种趋势会继续下去，还是会有所逆转？

Sean Hull：我不知道它是否会逆转，或者如何逆转；这似乎是一个更加普遍的趋势，涉及到所有人类知识的增长。看看科学和不同的专业领域，它们变得更加复杂，我认为这种复杂性可能会带来非常意外的惊喜。

举个例子，我最近读到一篇关于青少年抑郁症的研究论文。我知道这有点偏题，但研究人员认为，青少年抑郁症与智能手机的过度使用有关，因为智能手机改变了人们的社交方式。我认为，技术领域日益复杂的碎片化可能会带来一些非常意想不到的后果。我不知道我们该如何应对这个问题，也不清楚如何遏制这一趋势，因为它似乎每天都在不断增长。

Viktor Farcic：我有同样的印象。我认为没有什么会消失，就像我们现在还得考虑主机一样。但为了结束，是否还有什么你想讨论的？

Sean Hull：不久前，我写了一篇文章，标题是自动化如何影响 DBA 角色？。我和一个在 Oracle 领域工作的同事聊过，他感叹事情变化太快，很多公司现在不再招聘传统的 DBA 角色了。这部分是因为有像 Amazon RDS 这样的托管服务简化了这个过程，因此不再需要专门的人来承担这个角色。

总结来说，在我写的文章中，我提到有很多机会留给那些拥有深厚数据库知识的人，但他们需要主动出击，转变思*，并以全新的方式展示自己的技能和知识。

我确实认为，深厚的数据库知识对公司来说非常有价值，尤其是在它们采用微服务并尝试将数据库容器化时，或者遇到多租户、与 Amazon 相关的奇怪性能问题时。我认为，具备深厚数据库知识和性能优化经验的人，依然能够在当今的技术环境中发挥作用并创造价值。我只是认为，关键在于如何将这些知识打包，并以新的方式推销自己。

Viktor Farcic：我有同样的印象。我认为这实际上远远超出了像数据库这样的具体例子。我感觉其他领域也发生了类似的事情，我看到越来越多的 Java 开发者其实知道如何编写 getter 和 setter 之类的东西。我有一种印象，这种情况正在到处发生，对我来说，这是一个非常严重的警告，提醒我们可能会遇到麻烦。

Sean Hull：我认为，发生的事情是，招聘经理们开始意识到他们不太可能找到完全符合他们要求的具体技能的人，所以他们必须寻找更为通用的技能组合以及具有更广泛计算机理解和知识的人。一旦找到了，他们需要问：“嘿，你愿意提升自己，学习这些新知识吗？还是你觉得自己有信心解决这个问题？”

Viktor Farcic：这是结束采访的一个很好的地方。谢谢你。

第四十四章

15

第四十五章：Bret Fisher

Docker 资深专家与云系统管理员

第四十六章：介绍 Bret Fisher

Bret Fisher 是一位自由职业的 DevOps 和 Docker 顾问、Udemy 讲师、培训师、演讲者以及开源志愿者。他还教授有关 Docker 和容器技术的课程。你可以通过 Twitter 关注他，用户名是 @BretFisher。

什么是 DevOps？

Viktor Farcic：我想从问你一个问题开始，你能否为我们提供一个简短的介绍，告诉我们你是谁，以及你是如何参与 DevOps 社区的？

Bret Fisher：首先，我会说我是一个主要专注于 Docker 的 DevOps 顾问。也就是说，我其实是 Docker Captain，既工作又教授该程序。可以说，我 24/7 都活在 Docker 中。

Viktor Farcic：昨晚，我和三位自称为 DevOps 工程师的人交谈，他们都来自不同的公司。你会以为他们会以相同的方式描述自己的工作，但事实并非如此。事实上，他们每个人都用不同的术语描述自己的工作。所以，我想问你一个问题，也是我在这本书中问过每一个人的问题，DevOps 到底是什么？

Bret Fisher：今天的 DevOps 定义并不是那些从事 DevOps 的人所做的事情，所以你问我这个问题真有趣。人们曾要求我在我的 Docker 课程中加入更多的 DevOps 内容，因为他们自称是 DevOps 的初学者。但他们其实并不是 DevOps 的初学者，而是 IT 的初学者。

“今天的 DevOps 定义并不是那些从事 DevOps 的人所做的事情。”

—Bret Fisher

如果刚刚开始从事 IT 的 John 或 Jane 来找我说他们想做 DevOps，我会发现这很难实现。为什么？因为对我来说，DevOps 是只有在你有一定的运*或开发经验后才能做的事情，因为你必须在某种程度上了解这两个领域，才能真正理解 DevOps 的整体概念。如果你对这两个领域都很陌生，你就无法真正成为 DevOps 的一部分。

Viktor Farcic：所以，实际上没有人知道 DevOps 究竟是什么？

Bret Fisher：对我来说，DevOps 其实就是如果你是开发者，你需要和运*人员一起工作，分享关于将软件从开发者的笔记本电脑迁移到生产环境，并处理其中的一切问题的共同关注点。然后，在软件进入生产环境后，DevOps 的工作就是确保项目保持正常运行，并且可以可靠地更新，同时在整个过程中，所有参与者之间形成持续的反馈循环。这个循环是软件如何从开发者端一直到服务器，然后再通过越来越快的循环进行更新。

但是让我们暂时想象一下，我和你在一个 DevOps 团队里。如果将来我们仍然以现在的速度发布软件，我会说我们团队的表现不太好。我们应该优化并使系统更高效，当然前提是我们想要更快。如果公司不打算更快，那也没关系。我觉得很有趣的是，DevOps 现在成了那些想要进入技术行业的人的入门门槛。每个人都在说技术很棒，DevOps 是我们都应该做的事情，但我就是看不懂这怎么可能运作。如果我既不知道怎么做开发，也不知道怎么做运*，那我怎么可能同时做好这两项工作并成为 DevOps 呢？

Viktor Farcic：这就是我不断遇到的问题。我不断遇到那些刚刚开始 IT 旅程的人。在他们职业生涯的那个阶段，他们对任何事情一无所知。那时他们从零开始。

这就像我第一次接触 IT 时说：“我要成为一名 DevOps 工程师。”这就像我在选择我要成为一名测试员一样。我将成为一名开发者，我完全不理解怎么就发生了这种情况。你刚才说你上过 Docker 课程，但在我看来，当你完成这些课程后，你就是一名认证的 DevOps 工程师，你可以说：“我是一名认证的 DevOps 初学者。”

Bret Fisher：如果有人说他或她是行业新人，想要进入 DevOps 领域，那么我可以以培训他们朝着这个具体目标前进的方式雇佣他们。如果我必须让他们成为一名 DevOps 工程师，他们的第一份工作显然是学习团队正在使用的开发语言，并有效地成为一个非常初级的开发者。

我会把新人安排到构建团队，这样他们就得参与使用 Jenkins，或者构建和测试应用程序并自动化这一部分。对我来说，这是唯一一个他们不需要开发代码，而是稍微理解代码的角色。他们其实不需要懂运*，但他们会和运*人员打交道，结果是，他们会稍微了解一些运*的痛点。

“如果我必须让他们成为一名 DevOps 工程师，他们的第一份工作显然是学习团队正在使用的开发语言，并有效地成为一个非常初级的开发者。”

—Bret Fisher

快进一年：我现在会说，既然你已经做了这些一段时间了，那么我们实际上可以让你负责一些服务器工作，从中你将获得一点点运*系统管理员经验。再快进一年，你就可以说：“好吧，也许你可以开始关注与 DevOps 相关的问题。”刚接触运*的人会觉得很难，因为他们不了解软件和服务器，这就引出了一个问题：他们到底在操作什么？

我敢肯定，外面有一些职位描述写着他们在寻找初级 DevOps 工程师。我只想问，谁能做得好这个工作？是一个开发者，喜欢捣鼓服务器，还是一个服务器管理员，懂得一点脚本编写和编码？我真的不知道，但我知道的是，我没有一个很好的答案来回答你的问题。搞笑的是，现在有很多课程说你可以做 DevOps，但它们只教你一个像 Jenkins 这样的工具，这并不会让你成为 DevOps。

就在此时此刻

Viktor Farcic：我觉得这很有趣，因为每当我去参加会议——比如过去两年——我看到的每个厂商和每个产品都被贴上了 DevOps 的标签。是的，它已经存在很多年了，但今天，所有的产品都被称为 DevOps 产品。就像 Jenkins 一样。我知道你去过很多会议，所以我想知道你对此有什么看法？

Bret Fisher：DevOps 就像是新的云。还记得我们在 2013 年都在开玩笑说，什么是云吗？我们知道的只是，它就是互联网上的服务器。就这么简单。但我们有了这个新词，每个人都得用它。所有这些公司推出了各种各样的产品，而它们的名字里都包含了“云”这个词。

所以，现在，什么是云？云其实并没有什么特别的含义。它只是互联网。我觉得这个词 DevOps 也是朝这个方向走的，尽管我得承认我也是有罪的，因为我的课程标题里有 DevOps。

Viktor Farcic：即使是我以前的书，它们的标题里也有 DevOps——DevOps 工具包系列。

Bret Fisher：我的头衔是DevOps Dude，仅仅因为它有效。我在 LinkedIn 上收到更多面试请求，单纯是因为我的头衔里有 DevOps。

Viktor Farcic：我可以告诉你，如果我把我的书命名为Operations Toolkit而不是DevOps Toolkit，它可能只会卖出七本，而其中六本会被我的亲戚买走。但让我们把焦点转到容器上。我不记得曾经有什么东西能这么快地变得如此流行，所以我在想，为什么会这样呢？

Bret Fisher：每当我做 Docker 101 的讲座时，我都会讲到我们在 IT 行业工作了很长时间，过去，我们做这些事情并没有得到报酬，但实际上我们还是在做。我们是为了好玩而做的，但现在我们能因为好玩而拿到报酬。我那时在技术行业，还是在我们拆掉主机机房，换成 PC 的时候，而这些 PC 实际上只是运行 DOS 操作系统。我们还必须在 PC 上装上鼠标，因为它们要装 Windows，而我们必须在没有互联网的机器上安装 Windows。然后，最终我们终于得到了 TCP/IP 协议套件，并能够将所有计算机连接到互联网。

然后，在互联网之后，我们有了虚拟化。在那些日子里，我是那家有五十万员工的大公司里，四处走动的人，告诉大家：“虚拟化是未来。”与此同时，其他人都在说：“你傻，你疯了，服务器会变慢，我们永远无法构建安全性。”这些论点，今天我们听到的关于容器的论点，去年我们听到的关于云计算的论点，都是一样的。现在，云计算基本上就是将我们的数据放到互联网。你把数据从数据中心拿出来，放到互联网，并让别人来管理它。尽管那是在亚马逊 AWS 服务发布的 11 年前，但今天仍然在发生。即使我们都曾说过：“哦，每个人都会去的。”但事实是，并不是每个人现在都在那里。

Viktor Farcic：出于兴趣，你会说现在的云计算是什么版本？

Bret Fisher：我会说是容器。仅仅三年前，我就转行专注于容器。为什么？因为我参与了足够多的这种技术转型，知道容器是下一个技术。如果你看这些浪潮，每一波—从大型主机到个人电脑，从个人电脑到互联网，从个人电脑到虚拟化，从虚拟化到云计算，现在是容器—每一波似乎都比前一波来得更快。至少，这是我的理论。

虚拟化花了十年时间，但它被快速接受了。但是对于许多公司而言，迁移到云计算的速度比虚拟化要快得多。今天，我们看到容器的采用速度比虚拟化快得多，至少与虚拟化相比。我认为这就是我们行业所处的状态，所以无论下一个技术是什么，它将比容器出现得更快。

Viktor Farcic：当我想想这件事时，它可能持续的时间也会更短。

Bret Fisher：这可能会持续那么长时间。但问题是：这可能会更不稳定，最终我们会得到如此优秀的容器，以至于我们根本不再需要大多数虚拟化技术。也许未来虚拟化将变得不再必要。

Viktor Farcic：但是，如果变化这么快，人类如何跟得上呢？

Bret Fisher：不能。

Viktor Farcic：每次我读到某个新版本的东西——比如说 Docker——我感觉自己还没有完成上一个版本的学习，而新的版本又出来了，结果我完全不知道发生了什么。

跳过一个世代——这是好主意还是坏主意？

Bret Fisher：没错，所以有些公司会跳过一个世代。例如，X 公司现在可能正在做虚拟化，他们其实并没有做过云计算，所以跳过了这一部分，但现在他们将转向使用容器，而不仅仅是在云中做虚拟化。

Viktor Farcic：但你能做到吗？跳过一个世代是个好主意吗？

Bret Fisher：没有你的痛苦增加是不可能的。痛苦增加是因为你是团队的一部分，组织学习意味着我们都要知道你永远不是一个知识孤岛。整个团队必须一起学习，因此，即使你雇佣了一位容器专家，在一个良好的规模组织中，还是需要几年的时间才能让整个团队掌握所有这些技术。

如果这些公司还没有做云计算，而你要把它们带到云上，但现在它们也要做容器，那会很糟糕。它们可能会犯更多错误，但最终还是会做到的。你只是会经历更多的痛苦和折磨。CloudBees 的工程总监 Laura Frank 其实为此创造了一个新术语，她称之为“滞后税”。

“我们仍然有一些人使用大型机，仍然有一些人没有完全虚拟化。还有一些公司在运行 10 年前的服务器，这些服务器从未被虚拟化。”

—Bret Fisher

如果你曾经看到过那张钟形图，图中显示了技术刚开始时，最前面的是那些最早开始使用的人，然后是处于技术起步阶段的人，接下来是大多数人，最后是那些滞后者。Laura 描述的滞后税就是，如果你在采用技术上非常缓慢——比如我们这儿的云计算——实际上从长远来看会让你付出更高的代价，因为你可能不得不完全跳过一个技术代际。然而，问题是，这些都不是绝对的。我们仍然有一些人使用大型机，仍然有一些人没有完全虚拟化。还有一些公司在运行 10 年前的服务器，这些服务器从未被虚拟化。

Viktor Farcic：我认识一些人，我不是开玩笑，他们仍然在学习 COBOL 语言。

Bret Fisher：即使展望十年后，仍然会有一些人没有使用容器，而只是做虚拟化或类似的事情。

几周前，在 GOTO 芝加哥大会上有一场很不错的演讲，演讲者谈到了 30 年前的技术生活是多么美好，因为那时如果你全身心投入社区，你就能对大多数事情都有一些了解。你可能会对大多数编程语言和技术有所掌握。但他特别提到，现在没有人对任何事情了解。我们每个人对于当前技术所掌握的知识都只是一*部分。即使是在一个团队中，你可能也根本不知道现有编程语言的十分之一。我们怎么可能做出完全了解所有可用技术的明智决策呢？答案就是，我们做不到。

“没有人对任何事情了解。”

—Bret Fisher

作为一个行业，我们在黑暗中摸索，只关注眼前对我们有效的东西。在你被黑客攻击之前，根本没有对错，直到你被黑了，你才会发现自己错了。这个行业中失败的首要原因就是等到你的产品被黑了，然后突然每个人都会把所有问题都归咎于你。但只要你没有被黑，只要它能正常工作，其实也没什么大问题。

我记得在 GOTO 大会上，我曾激烈批评过，如何走进一家普通公司——我这里所说的“普通”并不是指谷歌或 Netflix 那类公司——然后开始批判他们技术栈中的各个部分。在那家公司里，至少会有六个方面值得登上头条。公司 A 仍然把密码存储在电子表格里，而公司 B 甚至没有监控他们最关键的 DNS 服务器。或者公司 C 的服务器根密码已经用了五年，期间已经有 30 人离职，但密码始终没有改变。你会在每个公司中发现这些问题。如果一切都这么混乱，甚至一切都很糟糕，或者仅仅是幸运，我们才没有完全崩溃失败，那么我认为，最终真正重要的是让一切正常运作，并在那个时刻做到最好。它永远不会完美，也永远不会出色。

使用容器

回到你之前的问题，我认为 DevOps 的定义本身就意味着妥协。任何公司的运*和开发人员都必须做出妥协，才能让系统协同工作并加速进展。也许在安全性或测试方面做了妥协。也许我们的测试周期不再是四周的用户测试；也许只是在上线前的四天？但在很多情况下，我们不能仅仅加速进程，而不做出某种妥协，而这种妥协能让所有相关方都能接受。

*克托·法尔奇奇：我们再多谈谈你，布雷特。从我的理解来看，大多数时候，你是在帮助公司或个人适应使用容器。你认为我们应该将所有东西都打包成容器吗？作为一个如此投入这个概念的人，你有没有坐下来思考过，实际上不，这些东西保持原样——我们不打算使用容器？

布雷特·费舍尔：显然，我们可以说，技术上讲，一切都可以在容器中运行。真正需要问的问题是，你愿意经历多少痛苦和折磨，才能让你的“东西”在容器中运行。

在我自己的经验中，如果我开始一个与客户的项目，我会先了解他们将要使用的工具或技术，然后我们一起尝试想象最终目标是什么。如果这是在容器中，这将如何使他们的产品或服务变得更好？如果他们的目标是数据库，而我们每六个月才更新一次该数据库的引擎，他们就不需要每月修补它。它们不会在环境中移动，已经在一个拥有冗余电源、冗余内存、冗余交换机和冗余网卡的服务器上运行，这就是许多数据中心的情况。

“我总是倾向于选择那些他们每天/每周都会更新的东西，而不是那些会一直稳定存在，几个月都不变的东西。”

—Bret Fisher

许多私有数据中心仍然非常注重硬件冗余，这与云计算恰恰相反。对我来说，我总是倾向于选择那些他们每天/每周都会更新的东西，而不是那些会一直稳定存在，几个月都不变的东西。通常，这意味着你的网站 API 或你的 PHP 工作者的后台新任务会不断变化；这些都是我尝试让他们首先做的事情。然后，等到我们要处理那些需要大规模且复杂数据库的工作时，通常公司已经没有钱了，所以我们也不会做这些事情，它们就会停留在原地。

很多公司，特别是当它是一个新产品或应用时，通常会首先将数据库容器化。但我总是告诉他们，“不要把数据库作为第一个放入容器的东西！”任何持久性数据，无论是放在容器内还是外，都会变得更加复杂，所以我建议一开始尽量避免这样做。但如果是全新的项目，如果我能给他们提供一个 Docker 文件，让他们将其放入容器中——即使它不在编排中，它也只是放在服务器上的一个容器里，而且服务器上只有这个容器，且永远不会移动——那也可以。我会很高兴。因为，至少在那时，它已经在容器中，他们就不会再写 Shell 脚本去执行apt-get安装 MySQL 了。

Viktor Farcic：假设有人对容器一无所知，你会建议他们从头开始学习，像我们四年前接触容器时那样吗？我们先让他们从容器入手，再转到调度器，还是直接跳进调度器的内容？现在的新人该往哪里去？

布雷特·费舍尔：我总是想教他们 localhost。我觉得也许因为它是通用的，即使你不是开发人员，只是一个系统管理员，展示你的 Mac/Windows 机器如何运行 Ubuntu 容器或 CentOS 容器，然后将所有工具都放在你面前，这样你就不必再为如何在 Windows 桌面上安装 curl 而烦恼。我觉得不论你的背景如何，这对每个人都有价值。

也许我是个传统主义者，我不想教你一个编排工具，因为我觉得有时候，通过首先教授编排工具，就像是在你甚至不知道问题是什么的时候就告诉你解决方案。对我来说，就像你是一个数据中心的 Windows 管理员。传统上，你会使用像 System Center 这样的微软工具，或者一些大型企业级的服务器管理工具，但如果你是服务器管理的新手，刚开始就向你展示这个工具会让人感到困惑。对新手来说，它看起来非常复杂，因为新手甚至不知道如何管理一台服务器，更不用说一千台服务器了。如果我在教你这个工具，而你连一两台服务器都不知道怎么管理，我觉得这个工具对你管理一千台服务器似乎没什么用处。

"也许我是个传统主义者，我不想教你一个编排工具，因为我觉得有时候，通过首先教授编排工具，就像是在你甚至不知道问题是什么的时候就告诉你解决方案。"

—布雷特·费舍尔

*克托·法尔奇奇：我有一个疑问。我曾经遇到过许多情况，向别人解释容器技术，结果发现我是在向一些对 IT 非常陌生的人解释。"我向你解释这些有什么好处呢？"我觉得我想问他们，"如果你没有先经历过痛苦，怎么能看出这些的好处呢？"

布雷特·费舍尔：这确实很难，但也是可能的。如果你回到 2013 年，你会记得 Docker 的创始人所罗门·海克曾谈到过为什么我们都在教授 Docker。他提到了地狱矩阵，里面有许多*问号框框，他还解释了为什么我们有这些系统和修补程序来应对各种问题。

假设你想在我的本地机器上安装一个 Ruby 应用，而我的开发团队有不同的操作系统，包括 Windows、Mac 和 Linux。然后，我也有一些 Linux 服务器，其中一些是在云上运行的不同 Linux 发行版，而且我使用的是不同的包管理器。现在，我有了这些不同的环境。我的目标是在所有这些环境中安装相同的东西，并确保它们的运行方式完全一致。希望这能让你意识到你有两个选择。你可以想：“好吧，这听起来很痛苦，”或者同样的，“我可以只做一件事，并不断重复。”所以，也许如果你是全新手，应该了解一下“为什么选择 Docker？”的整个问题。

Viktor Farcic：是的，这不应该包含在课程中吗？这有点像是在说：“我要让你在没有 Docker 的情况下完成所有任务，以便你意识到 Docker 或者容器的一般好处。”

Bret Fisher：没错，这就像是先说：“我们将首先在 Ubuntu 上做这件事。我们将在 Ubuntu 上安装你的 Node.js 应用，然后我们将使用 Node v10，这意味着你不能使用最新的 apt-get。抱歉，你得去找其他东西。你必须自己构建它，然后我们会让你在 CentOS 上做这件事。之后，我们会让你在 Red Hat 企业版 Linux 上做这件事。哦，顺便说一下，我们还会让你在 Windows 上做这一切。但我们还没完呢。在这四个系统上做完之后，我们现在会在 Docker 上做这件事。这会浪费他们很多时间。简单的事实是，他们可能根本不想这么做。但也许你只需要做一个安装文档，说明：这是你需要做的事情。你只需向他们展示这 12 页的文档，告诉他们如何做，也许这就够了。”

操作系统的未来

Viktor Farcic：我有一种印象，除了 Docker 容器之外，很多操作系统让我们质疑了许多事情，比如我们是否真的需要 Ubuntu 和 Red Hat？

Bret Fisher：这就是分发问题。Linux 发行版不想听到它们变得不再重要的事实，但事实是它们确实正在变得不那么重要。我毫不怀疑它们中的几个将成功地让自己在容器领域变得更加相关，并且它们会推出一些工具，让我觉得使用 Ubuntu 来运行容器比选择其他东西更有价值。某种程度上，今天这已经是事实，因为我会选择其中一个而不是另一个，仅仅是因为它带有一个更现代的内核，能够更好地与 Docker 配合。如果你有一个五年前的内核，还是在 3 系列上，我知道我不会因为你现在让我更新内核，才开始安装 Docker，而偏爱你。所以这就是第一步。

“Linux 发行版不愿听到它们变得越来越不重要的事实，但事实是它们确实变得越来越不重要。”

—布雷特·费舍尔

*克托·法尔奇：回到你说的先学基础，再学问题再学解决方案的观点。我一直在说像 TCP/IP 这样的东西，你待得够久就知道，当我们开始时，我们读的书就是一本叫做TCP/IP的书。

布雷特·费舍尔：我实际上一直在试图压抑那个记忆，而你刚刚把它带了回来。谢谢！

*克托·法尔奇：我记得那本书实际上叫做TCP/IP Unleashed，而且是第 4 版或第 5 版，因为他们总是不断重新发布书籍，这就是我们在谷歌时代之前学习的方式。这意味着，多年来，我一直认为自己很幸运，第一次构建网络。我们主要是从 IPX 切换到 TCP/IP、厚网和薄网，以及所有这些不同的协议和标准到以太网。因此，我必须学习 TCP 数据包大*、头部、不同的协议，等等。

布雷特·费舍尔：但现在的问题是，你可以问任何 30 岁以下的人，要求他们讲解 OSI 层次结构是什么，他们可能什么都不知道，但他们仍然可以找到工作并做得很好。

*克托·法尔奇：这倒是件好事。

布雷特·费舍尔：这既是好事，也是坏事。我曾经长时间坚信，最终，我们将拥有这样一个世界，只有很少的人甚至理解网络是如何工作的。一切将开始在缺乏知识的重压下崩溃。在你的团队中，当事情开始出错时，你会觉得我们根本不知道我们使用的其他东西是如何工作的，因为它一直都在正常运作。

这就像公共基础设施。我们中有多少人知道如何修复电力网？没有人知道。然而，当它坏了，我们都希望我们真的能帮忙。但我们还没有遇到问题，所以我不知道，也许这根本不是大问题。不过，当我面试人时，我仍然会问他们一些问题，比如，“交换机在哪一层操作？”或“路由器在哪一层操作？”

*克托·法尔奇：你有没有得到过答案？

布雷特·费舍尔：有时是这样，但这真的取决于你问谁。如果他们要成为开发人员，他们不会在乎这些。但是如果我要雇佣一个系统管理员之类的人员，那么他们就应该了解这些。他们都必须认真思考，因为在我看来，这就是一切事物如何相互通信的基础。如果你连基本的东西都不了解，那你怎么可能解决一个计算机问题，哪怕是在 Docker 中？

我们在 Docker 中创建了所有这些虚拟网络，但一旦你遇到 IP 地址冲突，突然你必须开始关注子网和子网掩码。

*克托·法尔奇：这揭示了一个问题。

Bret Fisher：是的，那就得让别人来解决了。

Viktor Farcic：我有一种感觉，实际上这正是我们在行业中正在前进的方向。我在编程中也看到了类似的情况。现在几乎没有人知道如何编程了，我们都只知道如何使用库来完成任务。

Bret Fisher：这是个很好的观点。如果你做的只是使用库，而如果你必须完全自己编写代码，你会怎么做呢？听起来我们都一开始是通过抄写书中的代码来学习的，我就是这样学会 BASIC 的。

Viktor Farcic：我不知道这在你所在的地区是否发生过，但当我还是个孩子的时候，我会拿到一些计算机杂志，杂志上大约有四到五页代码，你需要阅读并写下来。

Bret Fisher：我不记得杂志的名字了，但我记得爸爸曾带回家一本厚厚的 3 英寸书籍，里面有五六个程序。我记得的是，整个周末我都没有出门，一直坐在计算机前，从书上逐行输入代码，制作应用程序或游戏。

Viktor Farcic：让我猜一下，它不是强类型语言。你需要完成它才能发现是否有问题吗？

Bret Fisher：是的！因为如果代码不能运行，你必须逐行检查，所有 600 行代码。这个过程是在 Tandy 彩色计算机上完成的，型号是 TRS-80。最大的问题是保存设备是磁带录音机。因此，你必须插入一个模拟线路，这个线路发出的声音就像调制解调器一样，用来将数据录入磁带。唯一知道保存是否成功的方法就是关掉计算机然后再打开，播放磁带，然后希望程序能运行。如果不能运行，你只能重新输入所有 600 行代码。

我记得有一个周末，我把计算机开着一整晚，因为我还没完成。星期天我把它录到磁带上，播放时却没有成功。我可能是把声音调得太大了，或者有其他问题，造成了失真。所以，我只好重新输入整个程序再试一遍，这是一种非常痛苦的学习方式。

Viktor Farcic：我发现自己经常讲这样的话：“你们这些孩子根本不知道自己在做什么。”但随后我又发现自己在想，我听起来像是我妈妈说新一代根本不知道该做什么一样。

Bret Fisher：是的，你的故事很无聊，但你完全正确，这也是为什么这个故事很无聊。因为每个人的第一个网站都很激动人心，不管你多大年纪。当你第一次让程序或你写的任何东西成功运行时，那总是让你非常激动，而对别人来说却是非常无聊的。

展望未来

Viktor Farcic：如果你有一颗水晶球，你会预测我们在接下来的一年、十年，甚至更远的未来会去哪里？显然，现在前沿技术是容器技术，但之后会有什么呢？

Bret Fisher: 我认为在编排变得普遍之前，我们需要很长时间。

Viktor Farcic: 我的意思是，我们才刚刚开始。

Bret Fisher: 现在比将来要难得多，必须让它变得更简单，才能让大多数人开始使用它。我真的很喜欢每个虚拟机一个容器的概念，比如 Linux 的 Clear Containers。VMware 做了一些，微软也在做，Docker 也在用 LinuxKit 做。我不一定知道我们是否最终会进入一个世界，那里只有每个虚拟机一个容器，或者是一个虚拟机中有许多*型容器的世界。但我认为，锁定的应用，无论未来容器是什么样子，都将成为常态。

"我不知道接下来会是什么，也不了解什么会取代容器。但我认为我们需要很长时间才能在操作系统层面上提出一个新概念。"

—Bret Fisher

十年后，如果你是一家软件公司，卖的软件没有以某种形式的容器镜像发货，那将会很奇怪。我的意思是，这现在就有点奇怪，取决于你在行业中的位置。下载镜像会变得非常正常。如果我们最终到了那种地步，拥有一堆下载的包管理器也不足为奇。现在，你必须使用 docker pull 来获取 Docker 镜像，但我可以看出它将来会像 apt-get 那样使用。yum 的未来就是下载镜像，下载容器镜像的 tarball，并且它会在后台运行 containerd 或其他类似工具，但这对这些应用来说将是正常的。

但我认为这会花费我们更多的时间。我不知道接下来会是什么，也不了解什么会取代容器。但我认为我们需要很长时间才能在操作系统层面上提出一个新概念。每个人都在谈论 unikernels（单内核），但我并不完全相信这一点。

Viktor Farcic: 我没听说过有人真正谈论使用 unikernels。

Bret Fisher: 不，我认为发行版的战争已经结束了。未来是自定义发行版。所有的发行版包将变得更加模块化，所以你使用的是什么发行版实际上并不重要。我喜欢 LinuxKit 的想法。那是我支持的。

Viktor Farcic: 我也是。

Bret Fisher: 我希望构建自己发行版的想法能够流行开来，并变得更加主流和受欢迎。我很想能说我在 DigitalOcean 上，或者我在 AWS 上——无论我在哪儿——只要有我喜欢的发行版。我会有一个 YAML 文件来生成它，然后我只需要将其交给这个，而不是让我选择 Ubuntu、Amazon 或 CentOS。我只需上传我的 YAML 文件，然后它们会为我制作操作系统并将其放入虚拟机中。我不知道这会不会成为未来，但我希望这能成为可能。

Viktor Farcic: 无服务器计算会取代容器吗？

Bret Fisher: 我个人认为无服务器和容器是相辅相成的。你真的无法做到很好的无服务器服务，而不依赖容器。

Viktor Farcic: 谢谢！你是第一个这么说的人。我尝试向大家解释无服务器和容器是如何互相支持的，但他们看我的眼神就像是，不行。

Bret Fisher: 对我来说，无服务器（Serverless）就像是容器即服务。

Viktor Farcic: 但这是否意味着，低于编排工具和容器级别的所有东西都会变成商品化的？比如你提到的操作系统，你还需要关心它们的情况吗？

Bret Fisher: 我真的不这么认为。我们之前讨论过这个问题。如果我们展望未来，五年确实是很长的时间。我的意思是，五年前，根本没有容器编排工具。五年的时间大约是当前这些工具生命周期的两到三倍。所以，当然。

让我解释一下。对我来说，任何我要推荐给别人的新工具，必须至少能替代一个现有工具。它不能是一个净增加的工具，因为没人有时间去学习新东西。如果一个工具不能替代至少一个——理想情况下是两个——工具，它很可能不会被采用。但是现在，我感觉编排工具并不会完全替代任何单一工具。

Viktor Farcic: 这真是太对了。

Bret Fisher: 我仍然需要 Ansible、Chef 或 Puppet 来部署我的服务器。但现在，像 InfraKit 这样的工具虽然还没有大规模流行，但它类似于 Terraform 和 Swarm 的结合。它基本上是一个概念，意味着同一个工具既可以是我的编排工具，又可以同时部署和管理我的基础设施。这听起来像是一个更好的选择，也是对别人更有吸引力的推销。

现在，你已经有了一个管理基础设施的工具，但对这个基础设施进行更新非常麻烦。那么，如果我给你一个工具，不仅能够做这些更新，还能自动化管理所有内容，那会怎样呢？也许五年后我们会走到这一步。我知道今天它可以管理你的基础设施，但那并不是默认的常开选项。

也许最终，无论我们现在使用什么工具，都会变成一个统一的工具来创建基础设施、更新基础设施和部署应用程序。所有这些事情都会默认发生，而不需要额外的包或额外的工具。这一切都作为工具的单一分发包提供。我觉得这就是我们让人们采纳它的唯一途径。因为你必须要去掉一些东西。也许这意味着你会真正丢弃那些已经不再使用的工具。比如，我们可以去掉 Puppet、Chef 或 Ansible，而只需要这个工具。

Viktor Farcic: 因为这确实是一个问题。我有一种印象，就是我还没有找到任何一家大企业完全移除了某些东西。也许是我运气不好，但我从未见过这种情况。

结束语

Bret Fisher: 我最后想说的是，这既难，也罕见。一个工具必须非常棒，才能成为你当前正在做的一切之上的增值，Docker 做到了这一点。Docker 本身足够有利，你可以继续使用你的 Ansible、Puppet 等工具。你还可以继续使用 VMware、所有的apt-get和其他安装工具，比如 npm 和 composer。你拥有的是这个堆栈中的额外工具，人们使用它。这种情况不会经常发生，所以接下来的事情可能不会像这样。但我还是不确定，可能只是因为我持怀疑态度。

Viktor Farcic: 很棒！我知道我们现在时间不多了，所以我想说谢谢你今天抽空和我交谈。我很享受和你的交流，希望很快再与你聊天。

Bret Fisher: 没问题！和你交谈也很愉快，Viktor。

第四十七章

16

第四十八章：*尔马尔·梅塔

技术顾问

第四十九章：介绍 Nirmal Mehta

Nirmal Mehta 是 Booz Allen Hamilton 战略创新*组的首席技术专家，专门从事新兴技术的研究、实施和集成，以服务 Booz Allen 的联邦政府客户。他领导公司的数字研究与开发、沉浸式机器智能和新兴技术战略方面的工作。此外，他是容器化领域的主题专家和 DevOps 实践的思想领袖。他曾是备受关注的 GSA 集成奖环境 AWS 云平台的首席架构师，负责实施首个以开放源代码、数据为中心、基于微服务的分布式应用程序，该项目在公共部门具有开创性意义。他对机器学习、沉浸式技术、开源、DevOps 以及将新兴技术与客户需求结合充满热情。他致力于将前沿技术引入企业系统，为商业和公共部门客户提供服务。他是 Docker Captains *组成员。你可以在 Twitter 上关注他，账号是@normalfaults，在 LinkedIn 上访问他： www.linkedin.com/in/nirmalkmehta/，以及在网上访问：nirmal.io。

Viktor Farcic：我想从简单地请你介绍一下自己，Nirmal，以及你与 DevOps 的关系开始。

Nirmal Mehta：在我的职业生涯中，我有机会看到许多组织走上 IT 转型之路，通过这些经历，我见证了在我们行业中什么有效，什么无效。我努力在新兴技术、方法论和解决方案方面传播知识——尤其是通过 DevOps！

Viktor Farcic：那么 Nirmal，"DevOps"对你来说意味着什么？

DevOps 的含义

Nirmal Mehta：DevOps 是将上世纪的过程改进技术应用到我们现代 IT 文化中的一种方式。如果我需要提供一个更全面的定义，我会说，DevOps 是一种 IT 运营模式，专注于利用工具和文化变革来简化和自动化 IT 服务的交付。它借鉴了上世纪 W·爱德华兹·戴明等人优化的制造模型。

更简单地说，DevOps 正在将组织的文化转变为一种实现共同目标的思*方式，而不是传统上在组织内设立的各个部落。

“DevOps 正在将组织的文化转变为一种实现共同目标的思*方式，而不是传统上设立的各个部落。”

—Nirmal Mehta

Viktor Farcic：谢谢你，Nirmal，看到每个人都有如此不同的方式来定义 DevOps，真是很有意思。那么，你认为 DevOps 和敏捷有什么区别？

Nirmal Mehta：我认为敏捷的十二个原则是指导方针。更重要的是，我认为敏捷本不该像今天这样被商业化并完全占据主导地位。我认为那些采纳敏捷的组织有些过度思考了这一点。

另一方面，DevOps 是将敏捷方法应用于整个组织，而不仅仅是它的开发流程。也许我的区分只是语义上的，但广义来说，你可以说 DevOps 包括了敏捷方法论。DevOps 就像是一个超集。

Viktor Farcic：是的，我认为 DevOps 就像是向组织引入更多的专业知识，甚至是更多的自动化。当然，这可以在组织中开辟新的职位——有时我甚至看到一个组织里 DevOps 工程师的数量极为庞大。老实说，我甚至不知道其中某些职位到底是什么——你会如何定义 DevOps 工程师？

什么是 DevOps 工程师？

Nirmal Mehta：这就是争议所在，因为根本没有 DevOps 工程师这样的职位。甚至不应该有 DevOps 团队，因为对我来说，它更像是一种文化和哲学方法论。这是一种过程，一种关于事物的思考方式，以及在 IT 组织内部的沟通方式。

“根本没有 DevOps 工程师这样的职位。甚至不应该有 DevOps 团队，因为对我来说，它更像是一种文化和哲学方法论。”

— Nirmal Mehta

但回到定义上，我认为 DevOps 工程师这个职位意味着，组织不再雇佣开发者和运*人员，而是想要少一个人，却做双倍的工作。

Viktor Farcic：我喜欢这个描述。尽管除了你，没人会承认，但现实中确实经常如此。你可以从 DevOps 工程师职位的招聘广告中看出来。

Nirmal Mehta：我认为组织只是想要一个既愿意构建又愿意操作软件的人。这些 DevOps 工程师的职位随处可见，但对于 DevOps 工程师到底是什么，至今没有一个统一的定义。

其原因在于，DevOps 工程师实际上涉及两件截然不同的事情：工具和文化。我认为 DevOps 更多的是关于文化，但 DevOps 过程中也有一些工具，这些工具会自然地引导组织向更多的 DevOps 实践倾斜。那么，DevOps 工程师可以被定义为实施这些工具和一些哲学思想的人。

当然，单单安装一些工具并不能意味着一个组织自动成为 DevOps 组织——你可以滥用任何工具，不管它有多神奇。因此，重要的是还要指出，DevOps 工程师更像是一个咨询角色，而不是仅仅操作这些工具并保持它们运行的人。

通常，组织只希望有人进来实施这些工具。然后，最终他们被要求只是一个也要操作东西的开发者。

Viktor Farcic：是的，我常常看到现有团队只是被重命名了。他们继续使用相同的流程和工具执行相同的任务，只不过换了一个更流行的名字。

Nirmal Mehta：我曾经参与过一个项目，他们要求有一个单独的 DevOps 团队，这对我来说根本没有任何意义。DevOps 团队是另签合同的，因此他们甚至不是为组织工作。所以，这个项目有开发人员、安全团队、运营人员和一个 DevOps 团队。

现在，你告诉我，那个 DevOps 团队应该做什么？他们唯一的工作是在部署到生产环境之前的最后一步。那个 DevOps 团队什么都没做，除了在代码进入生产环境之前进行签字确认。那根本不是 DevOps 团队，他们只是一个没有目的的随机团队，随便一个权威。

Viktor Farcic：这让我想起了系统管理员被改名为 DevOps 的情况。

Nirmal Mehta：是的，那个 DevOps 团队本质上是一个被削弱的质量保障团队，改名为 DevOps 只是因为这个名字听起来很吸引人。

今天，DevOps 仍然有很多“粉饰”。正如我在一次演讲中所说的，如果你花了超过一个月的时间试图搞清楚你们组织的 DevOps，或者已经花了 15 次会议来讨论 DevOps 是什么，那么你就是在过度思考它。

"如果你花了超过一个月的时间试图搞清楚你们组织的 DevOps…那么你就是在过度思考它。"

—Nirmal Mehta

不是一切都必须复杂！你可以决定在任何时刻，想要在工作中加入多少复杂性。仔细看看你们的组织，挑选一些痛点，然后从那里开始。阅读一些书籍并实施其中一两部分流程，可能比花一个月时间争论 DevOps 是什么要好，这也是我们在 IT 中喜欢做的事。我们喜欢争论一些事情，却什么也没做成。

我们喜欢待在自己的*圈子里，我们喜欢推卸责任，我们有争论和对立的需求，我认为 DevOps 和敏捷有助于重新定义这个对立面是谁。DevOps 不是让我们在内部*组之间产生摩擦，而是将我们的对抗性精力集中在我们为客户解决的问题上。DevOps 让我们与实际问题发生冲突，而不是彼此之间。

Viktor Farcic：但最终我们会遇到那些顾问，他们卖给我们为期一个月的培训，号称能把我们转变成敏捷专家？

Nirmal Mehta：没错，这也是我可以深刻探讨的一个话题：为什么我们必须为敏捷进行这么多培训？我认为所有这些培训本质上是与敏捷的目标背道而驰！我们发现自己被复杂的细节包围，忘记了敏捷的核心原则。

我想这也是为什么敏捷的创始人们提出了敏捷宣言，他们想迫使我们把它打印出来并贴在墙上。他们知道，如果我们不时提醒自己敏捷的核心理念，我们就会忘记我们真正想要实现的目标。

Viktor Farcic：这听起来像是对敏捷的误解和过度复杂化，敏捷的本质其实非常简单。

过度思考 DevOps

*尔马尔·梅塔：作为一个行业，我们喜欢把所有事情想得过于复杂，我认为 DevOps 也有类似的问题。

DevOps 非常简单。DevOps 是应用一些用于流程改进的技术，这些技术是一些初创公司、运作良好的组织和聪明的人所实施的。它们被展示给了其他人，其他人说：“是的，听起来不错；这帮助我们提高了效率，降低了成本，或提升了质量，你知道吗，我们也许应该采纳它！”

“作为一个行业，我们喜欢把所有事情想得过于复杂，我认为 DevOps 也有类似的问题。”

—*尔马尔·梅塔

让我们不要把 DevOps 复杂化。当需要减肥时，简单来说，就是摄入的卡路里少于消耗的卡路里。这是简单的事实。不要被复杂的饮食方法分散注意力，因为你想找到捷径。DevOps 也是一样，理念很简单：走出自己的路。

DevOps 理念——走出自己的路

DevOps 的理念是走出自己的路。但这当然太难了，所以我们试图找到捷径。这个捷径可能是一个工具，一个顾问，一些 YouTube 视频，或者一本书。但最终，我们无法避免必须遵循这个理念。我们可以整天使用 Jenkins，但如果不遵循理念，我们什么也达不到。

“DevOps 的理念是走出自己的路。但这当然太难了，所以我们试图找到一个捷径。”

—*尔马尔·梅塔

这是今天组织中正在发生的根本性转变——一个认识到，实际的、有效的变化必须稍微有些痛苦。这是一次深刻的文化转变，我们必须处理人们、他们的态度，以及所有相关的事情——包括那些根本不想改变的人。

今天我们行业中关于 DevOps 有很多误解，这主要是因为没有人愿意听到一些简单但重要的真理，比如“更多的卡路里消耗”，而且很多人不愿面对变化。你认为像 Facebook 和谷歌这样的组织，是否也在进行这些辩论？

*克托·法尔西奇：我预计谷歌和 Facebook 现在一定在进行一些重要的辩论，其他人会在十五年后才参与，关于机器学习和神经网络的讨论。但谷歌也一直在讨论 SRE，例如？

*尔马尔·梅塔：是的，像谷歌这样的组织，已经将一些最新的辩论转化为服务级别协议和站点可靠性工程（SRE）理念。这些痛苦是无法逃避的。

DevOps 与 SRE

*克托·法尔西奇：那我们来探讨一下谷歌的 SRE 与 DevOps 之间的关系吧。你如何定义 SRE 呢？

*尔马尔·梅塔：站点可靠性工程师是基于谷歌 DevOps 方法论，支持开发团队和生产系统的 IT 运*工程师。

SRE（站点可靠性工程）哲学中的一个重要观点是，预算中与项目团队修复问题所需的*时数相关的风险。

你可以部署任何你想要的高风险软件，但如果你耗尽了那个预算，那就是你的责任。如果你提供的服务不那么关键，那么你就有更高的预算，可以承担更多的风险。或者你可以说，“你知道吗，我需要将这些预算储备到某些年份的特定时段，或某些事件中，这样可以平衡一下。”

谷歌的 DevOps 方法论中的这种方式去除了规避痛苦的能力，因为它把痛苦放到了最前面和最中心。

解决关键痛点是许多组织面临的困难问题，这也是敏捷中一个非常常见的问题。例如，如果你正在从瀑布式开发转向敏捷，那么项目经理、领导和所有者都会希望采用敏捷——但还是带有截止日期的敏捷！

Viktor Farcic：你是说经理们希望别人采用敏捷方法，但他们自己却不愿意调整自己的工作方式吗？

Nirmal Mehta：是的，正是这样，那些人希望有带有截止日期的敏捷方法，因为截止日期让他们可以把责任推到别人身上。

截止日期是逃避的捷径，而敏捷则迫使你以更规律的节奏、或通过优先级来思考实施，并且更频繁地做出决策。

没有一个领导者喜欢像敏捷要求的那样频繁做决策，因为决策意味着责任。许多组织及其成员都是规避责任的高手。敏捷方法强迫在一开始就进行这种讨论，而不是等到截止日期后或临近截止日期时才讨论优先级。

“没有一个领导者喜欢像敏捷要求的那样频繁做决策，因为决策意味着责任。”

——Nirmal Mehta

DevOps 也是一样，因为它强迫你理解如何将项目投入生产，并且在周期的开始就为此支付费用。在 DevOps 中，你要在周期开始时就捕捉问题，而不是等到最后。

我们今天面临的许多问题，都是因为有人能够在最后一刻才做出决策——也就是说，直到被迫做出决策时，他们才会行动。他们可能已经知道自己的决策是什么，只是直到被迫做出决定时，才对这个决策有信心。

敏捷和 DevOps 强迫你更频繁地做决策，而且是从一开始就要做。我认为人们很难具备做出决策所需要的信心，或者对失败的接受，这使得他们能够做到这一点。具有讽刺意味的是，DevOps 和敏捷比传统方法更容忍你频繁做出错误决策！

更频繁地做出[错误]决策

Viktor Farcic：你是说，IT 部门中的组织和人员应该更频繁地做出错误决策吗？

*尔马尔·梅塔：如果你每年部署四次，那你只有四次机会做出决定，因此每个决定都具有巨大的影响。如果你处于敏捷环境中，你会做出很多*的决策。如果你做了一个错误的决定，你可以在下一个截止日期修正它，而且你损失的很少。这就是讽刺所在。

“如果你处于敏捷环境中，你会做出很多*的决策。如果你做了一个错误的决定，你可以在下一个截止日期修正它，而且你损失的很少。”

—*尔马尔·梅塔

当然，如果你做了一个错误的决定，仍然会感到痛苦，但不知为何，我们人类觉得每两周就必须做一次决定更让人痛苦。

我认为这类情况在其他行业也会发生，有时甚至在风险更大的情况下。例如，在航空、制造或建筑行业，当你做出一个重大的错误决策时，会有几百万美元的后果。这些行业的组织已经发展出了自己的技术来迫使做出增量决策。

*克托·法尔奇：在过去的几年里，我在各种会议中看到 DevOps 的兴趣大幅增长。这种兴趣通常集中在一些特定主题上——不可变基础设施、容器和调度程序。它们之间是否存在某种关系，能够解释这么多的兴趣呢？

DevOps 模式

*尔马尔·梅塔：是的，它们之间确实存在关系。而且它们之所以引起如此大的兴趣，是因为它们反映了一些人们目前开始采纳的重要模式。

也许只有十%的人真正知道今天在 IT 行业中自己在做什么，而且他们不可能同时在每个组织里工作。当然，是否有人真知道自己在做什么，这也是一个值得讨论的问题，因为我敢打赌，如果你问这十%的人，他们会说：“我不知道我在做什么！”

那些十%的人知道的是，当他们这样做时，他们的压力会减少。当他们这样做时，他们的网站更可靠。当他们那样做时，他们每次都会多一个客户。所以他们是这样看的：“如果我这样做，我可以获得额外的一百万美元投资；如果我这样做，我的评价会上升；如果我这样做，我没有关上门，因为我仍然具备竞争力。”这些就是我们行业里唯一的启发式方法。

现在，让我们以一位 IT 职业人士为例，也许在他们的职业巅峰期，他们平均在三到六个不同的地方工作过。

*克托·法尔奇：是的，找到在一家公司工作一辈子与每几个月就换工作之间的平衡确实很难。

Nirmal Mehta：是的，那么我们在职业生涯中做了什么？每年我们都会想，“嘿，那样好像有效，我花了六个月的时间做了这个，结果它有效。”我们在 DevOps 中尝试做的，就是从每个人那里收集尽可能多的经验法则，然后以某种方式将其提炼，直到有一天我们能说：这就是最优的经验法则。

比如，曾在 Docker 工作的 Aaron Huslage，现在在 Red Hat Ansible，他过来对我说：“你们为什么要修补？直接销毁服务器，把容器迁移到新的修补过的服务器上。不要进行回溯修补，始终向前推进。”好吧，这是个好主意！这样节省了我时间，因为现在我少了一件需要担心的软件。

我认为我们在 DevOps 中所做的一切就是不断地寻找、寻找、再寻找这些想法。每一个想法的背后，都需要一个相应的文化变革。当你采纳这些做法时，发生的文化变革就叫做 DevOps。

Viktor Farcic：你是在说 DevOps 只在与新想法的关系中存在，而新想法需要 DevOps 来管理组织向文化转型吗？

Nirmal Mehta：我认为 DevOps 可以存在于这些想法的有无之间。我的意思是你可以用 DevOps 进行补丁修复。你也可以拥有传统的 DevOps 运*方式。只要你理解其中的沟通机制，并且准备好持续检查和理解你的流程——并随时准备改进它们。

毕竟，关于 DevOps 的采纳没有时间表，也没有宣言说你必须实现更大的软件部署。

“没有关于采用 DevOps 的时间表，也没有宣言说你必须实现软件部署的增加。”

—Nirmal Mehta

在我的客户群体中，软件更快地部署并不总是最迫切的需求。有些组织甚至不关心成本。在我的客户中，一个很常见的情况是，如果他们今年没有花完预算，明年将会得到更少的资金，因此他们想要花更多的钱。

这并不意味着 DevOps 在这些情况下对组织没有应用：它们仍然可以从 DevOps 中获得其他需求，比如变得更加安全，从而变得更加可靠。

可靠性是一个大话题。从本质上讲，服务的可靠性是今天你看到 DevOps 兴趣激增的一个主要驱动力。用更少的人做出更高可靠性的服务，这就是我认为 DevOps 的意义所在。存在一种风险，那就是这些做法可能减少像我们这样的人才需求。

Viktor Farcic：你说的“像我们这样的人”指的是谁？

Nirmal Mehta：我的意思是开发人员和运*人员。随着这些服务越来越多地转向 SaaS 模式，我认为未来某个时刻，新的软件开发将更接近初级水平，像是预设的商业对象，比如 Azure 或亚马逊 Web 服务。

*克托·法尔奇奇：那么，你对开发人员和运*的未来不抱希望吗？

*尔马尔·梅塔：我直觉上认为，在未来，我们会看到大多数 IT 组织中开发的定制软件减少。相反，新的软件开发将是在硬件上进行的。

唯一需要注意的是机器学习，它已经成为软件开发的一个全新世界。通过将不同的深度学习和神经网络组合在一起来进行编程，可能会成为软件开发的一个新领域，这可能会是许多人的转变。我们将不再整天为 Web 应用程序制作 API，而是将专注于优化机器学习，并且我们将变得更加程序化。最终，80% 的服务将由四个霸主服务提供商提供，就是这样。

“最终，80% 的服务将由四个霸主服务提供商提供，就是这样。”

—*尔马尔·梅塔

*克托·法尔奇奇：说实话，如果我年轻并且还有职业生涯的岁月在前，我会感到非常害怕，因为我认为大多数人只是无法跟上这不断增长的速度。

那些专门从事单一领域的人面临着变得过时的更大风险。我的意思是，当公司决定转向云时，那些花了多年时间工作在基础设施上的人会发生什么？当然，他们可以申请在 AWS、Azure 或 Google Cloud 工作，但我担心对许多人来说，门槛可能太高了。

*尔马尔·梅塔：我们已经在行业中看到了这一点；看看有多少组织正在迁移到 Office 365，以及有多少地方有自己的 Exchange 服务器。这个数字越来越少。长期以来，这是 IT 的核心角色，管理 Active Directory、Exchange 和 MS SQL，但那些日子已经过去了。

*克托·法尔奇奇：我猜这使得公司处于一个甜蜜的位置，他们可以将大部分资源投入到真正为他们带来价值的事情上。当你想想这个问题时，管理 Exchange 对一家公司来说是否真的有价值？

*尔马尔·梅塔：不，不是这样的。但我认为有趣的是，这是一种愤世嫉俗的观点，即许多这样的公司中有很多低 hanging fruit（易于获取的机会）！

对于那些已经建立了垄断地位或通过竞争创造了足够大壁垒的公司，或者在这个领域内工作或竞争的公司已经趋于集中的公司来说，这一点尤为真实。对于这样的公司，增加价值可能没有得到任何回报。对于这样的公司，完美并不需要。他们甚至不需要没有错误的代码；他们只需要发布一些东西，即使它不怎么样。

DevOps 的真正敌人

我们在这里讨论的是 DevOps 和敏捷的真正敌人。这个真正的敌人不是供应商，不是对 DevOps 的错误标签，也不是那些难搞的 IT 商店。DevOps 的真正敌人是当我们试图实现的所有基本平衡不再重要时。DevOps 的真正敌人是当更高质量的东西变得不重要时——当一个组织只是在努力把东西推出去。

“DevOps 的真正敌人是当更高质量的东西变得不重要时——当一个组织只是在努力把东西推出去。”

—*尔马尔·梅赫塔

我在会议上遇到的很多人都是 IT 人员，他们中的大多数显然在努力从中获取更多价值，打出自己的烙印，降低成本，或者保持工作。但在大多数组织的某个层级，如果你遇到一个非 IT 人员，他们可能会认为目前的状况已经足够好，他们可以继续榨取这个“苹果”。

*克托·法尔西奇：我认为我们在速度上存在严重的差距。尽管我们已经习惯了事物经常变化，而且速度越来越快，但世界仍在努力搞清楚这意味着什么。非 IT 人员仍然不习惯于这样的事实：昨天有效的东西今天可能完全不同。

*尔马尔·梅赫塔：是的，他们只需要每六个月更改一次网站的颜色，就可以了。还需要更改产品的名称。

这就是为什么竞争是好事，因为 DevOps 的真正敌人会在 IT 组织中显现出来，在这些组织里，“足够好”的质量比我们任何人想要工作的质量都要低。

从这个角度看，DevOps 只是一种方式，通过减少两三个员工的工作，做到“足够好”，在组织转型为完全的软件即服务（SaaS）模式之前。这才是 DevOps 试图对抗的真正逆境和冷漠。

敏捷也在试图对抗这种冷漠。瀑布式方法一直是在生产前的最后一刻做决定，对吧？敏捷要求这些决策提前做出，这样你就不能对任何事情漠不关心。相反，你必须今天就决定你要做什么，以及你希望别人做什么。敏捷的目的是创造一种激励，迫使人们做决策。

DevOps 在这一点上非常相似，我们为人们和组织创造了一种激励，让他们做出关于要部署什么样的代码或要部署什么样的服务的决策。

*克托·法尔西奇：我认为你关于 DevOps 角色的看法是对的，但我也认为决策是许多人试图避免的。这可能是我们在 DevOps 的定义与实际实施之间存在如此巨大差异的原因。今天许多组织面临的一个关键决策领域是安全。那么，DevOps 如何融入 IT 安全部门呢？

DevOps 在安全部门

*尔马尔·梅塔：我认为 IT 安全非常重要，但我也知道，我们很容易低估有多少人现在根本不在乎安全。而这正是因为，对许多人来说，安全问题就像污染问题一样。IT 安全和气候变化从这个角度来看几乎处于同样的局面：它们都具有负外部性。

让我解释一下。如果消费信贷报告机构 Equifax 被黑客攻击，像它曾经那样，并且我们的所有信用信息都被泄露，但 Equifax 在这样做时没有承担任何成本，那么这就像我建造了一座电厂，却不为我排放的污染支付代价。这是一种负外部性，与成本没有关联，而这种情况如果没有政府介入，是无法自行修复的。这本质上就是政府的作用——消除这种公地悲剧。我认为安全正陷入一种公地悲剧的境地，在这里没有任何后果。

“我认为 IT 安全非常重要，但我也知道，我们很容易低估有多少人现在根本不在乎安全。”

—*尔马尔·梅塔

如果我投入 100 美元来提升我的安全性，而我的竞争对手投入 0 美元来提升他们的安全性，然后我们俩都被黑了，那我们俩都没有后果。我失去的只是 100 美元，而我的竞争对手没有失去 100 美元。这就是唯一的区别。

*克托·法尔西奇：我在与企业公司合作的经验告诉我，安全总是最后发言，但与此同时，大多数人并不真正理解。安全往往只是标记 Excel 表格中的一些字段，而没有真正帮助 IT 团队开发安全的应用程序。太常见了，安全部门的唯一目标似乎就是能够说：“这不是我们的错。”

*尔马尔·梅塔：这就是我们所面临的不幸局面，我想即使在 Spectre 和 Meltdown 漏洞之前，我们就已经面临了这样的问题。这种大规模的安全漏洞并不会消失，但我们没有足够的头脑空间去理清安全问题有多严重。因此，我们作为一个文明和现代社会，在隐私和 IT 安全方面，通常选择埋头于沙中。我认为，除非行业中出现真正的后果，否则我们将继续这样做，甚至即使那样，我认为变革也不会发生，因为那基本上意味着要摧毁 IT。

想象一下，如果开发人员必须为他们编写的代码投保，就像医生必须购买医疗事故保险一样。如果有类似于计算机或开发者工程过失的保险，它会在一夜之间摧毁整个行业。有些开发者如果有钱可能会购买，但作为一个行业，我们已经在人才和资源上感到捉襟见肘，这最终会导致该领域 90%的开发者被淘汰。

此外，我们曾经承诺可以成为开发者的所有人，因为我们通过自动化摧毁了他们的工作，必须为他们切换职业时可能导致的初始代码问题投保。除非一切变得更贵，否则这个想法根本不切实际，安全也不会有所不同。

Viktor Farcic：我很惊讶之前没有听到过关于代码保险的这个想法。越想越觉得这有道理。为什么软件会与其他有保险的事物不同呢？我们都在使用它，我们都依赖它，故障可能导致严重的损害甚至死亡。它符合许多我们认为理所当然的、被投保的事物的描述。

但是，正如你所说，保证代码质量会在一夜之间摧毁整个行业的一大部分。我们已经习惯了软件并不总是有效，而黑客攻击也成了生活的一部分。没有太大的激励去确保我们所创造的东西真正安全——至少不是在每个地方。

Nirmal Mehta：这并不意味着公司不能在安全上与众不同。看到像苹果这样的公司，和其他公司不把我们当作产品来对待，感觉很好。

“我认为改变不会发生，因为这本质上意味着要杀死 IT。”

—Nirmal Mehta

现在，当你谈到商业对商业（B2B）安全，或者电子商务安全时，我认为答案是，事情将会转向更多基于 SaaS 的服务。

当你和组织谈论迁移到云时，你会开始看到它如何真正让一切变得更安全。为什么？因为组织必须面对现实：他们必须实际做他们说过的安全工作，但实际上并没有做到！当然，亚马逊云比许多自己运作的地方要安全得多，因为亚马逊有一个巨大的财务激励，而许多政府服务缺乏这个激励。

DevOps 有一个真正的机会，可以增加许多组织中缺失的安全激励。然而，良好的 IT 安全仍然需要强有力的领导。

Viktor Farcic：IT 中缺少什么需要这种强有力的领导？是更多的资金投入，更多的教育，还是更好的实践？今天我们在安全方面缺少什么？我问这个问题是因为在我访问的公司中，我不断遇到合作伙伴，他们会说：“看，你需要满足那 35,000 个要求，然后你就安全了。”我认识的任何人都没有成功完成他们的所有要求。

Nirmal Mehta：这里有几个不同的问题。第一个是，修复一个 bug 或安全问题没有荣耀，而部署一个新特性总是有荣耀的。

第二点是，修复漏洞、发现安全漏洞并以正确的方式做事情，通常需要更多的耐心、更多的思考、更多的工程时间、更多的时间和更多的成本。这些东西大多数组织一开始就没有。大多数组织甚至没有足够的资金或资源来完成他们最初的目标，尤其是在软件方面。那些东西通常排在清单的后面。

“修复一个漏洞或安全问题没有什么荣耀，而部署一个新功能却总是充满荣耀。”

—Nirmal Mehta

第三点是经验和理解。有多少人真正理解推测执行和处理器的工作原理？如果你去那些编程训练营，学习成为一个网页开发者，坐在那里导入了 15,000 个 npm JavaScript 库，他们有告诉你 CPU 是怎么工作的吗？没有。

Viktor Farcic：而且你根本不知道那些库做了什么。

Nirmal Mehta：没错，懂得这些的人是昂贵且稀缺的。现有的软件套件并未将他们的经验和知识进行编码。安全软件行业在适应更频繁的部署和整合关于常见漏洞和渗透测试的整体情况方面，远远落后。

当然，这一切都使得一个组织的开销比那些选择不做这些事情的竞争对手要大。也许失去一个客户会有后果，但并没有全球性的后果。

Viktor Farcic：直到它发生之前。

Nirmal Mehta：是的。我直觉上感觉很多地方的安全性没有我们想象的那么好，而保险模式只是在支付这个问题，而不是让他们去解决它。支付问题比支付每年 25 万美元雇一个安全人员要便宜。

支付问题带来了很多问题，其中之一就是，如果一个组织不是像谷歌、脸书或苹果这样的一流公司，那么那里的安全人员可能根本不是专家。他们很可能只是做过一些培训并获得了认证。是的，他们可能对 SQL 注入和网络钓鱼攻击非常了解，但他们很可能只是负责这些工作的一个*团队成员，而且他们更关心下班后能不能去吃饭。

当然，他们有这个秘密武器，其他 IT 组织的人都没有，那就是无条件地说“不”的能力。

Viktor Farcic：你不得通过！

Nirmal Mehta：这就像一种认知偏误，它像是一种虚假的权力……但它其实不是虚假的权力——它是真正的权力！而且与负面情绪作斗争要困难得多。

安全不是一个司法系统；你不是在证明你无罪之前就是无辜的。在安全领域，确实有充分的理由认为你在证明无辜之前就是有罪的，这也是我们有那些检查清单的原因。

“安全不是一个司法系统；你不是在被证明无罪之前就是无罪的。你被认为是有罪，直到被证明无罪，这就是我们有那些清单的原因。”

—Nirmal Mehta

但这也意味着，你的假阳性和假阴性都会飙升，因为在这种情况下不说“不”太难了。

Viktor Farcic：如果我在未被证明无罪之前就是有罪的，那么我无法证明自己是无罪的。

Nirmal Mehta：没错，根本不存在 100%无误、无漏洞的软件。我们面对的是非确定性复杂系统，而这就是挑战所在，因为每个人都希望得到 0/1、是/否的答案，但在非确定性复杂系统中并没有“是/否”，只有接受的概率和百分比。

问题在于，安全性往往把一切视作是有/无的决策，并附带一定的风险，而每个人都需要将安全性看作是一种概率。同时，没有人愿意处理困难的事情。

这里的难点在于，如何在不引入所有这些工具的情况下编写优质软件，并且实际审视所有代码，查看你正在使用的开源工具，验证你所做的事情，实现互相 TLS 验证，更新你的证书，并确保你的域名启用双重认证。

这些问题是安全的基础，跟“输出的热量大于输入”是同样的道理，但我们都在寻找捷径。而安全人员的捷径就是直接说：“不，这是一个症状清单。”

清单只是过去曾经出现过的症状。它不是解决办法，也不是对系统的诊断。它只是一个症状清单。你打喷嚏了吗？没有，好吧。你咳嗽吗？没有，好吧。你发烧了吗？没有，好吧。那么你就不是安全风险。

打击安全威胁

Viktor Farcic：如果我们能够应对的话，如何应对安全威胁？一个人通过利用我们的系统漏洞能够造成严重损害。如果我们能给出一个数字，我们需要多少人来防止那个人攻击我们？

Nirmal Mehta：到目前为止，我们想出的就是这些，不是吗？我们如何为这个问题买单？需要多少人？那是因为一切都是反应性的。

然而，这个问题不仅仅如此。IT 安全的核心利用了与现代技术公司能够在比以往更少的人手下完成令人惊叹的事情相同的力量。但问题在于：这种让技术能够大幅提升单个员工杠杆效应的能力，也同样作用于攻击你的人。

这与我们面临的恐怖主义问题相同。一个人成为自杀炸弹袭击者只需 500 美元，但防止这种自杀袭击发生却需要 1.5 万亿美元。那些攻击你基础设施的袭击者，拥有与你创造公司所用的相同，甚至是 1000 倍以上的优势。

“攻击你基础设施的攻击者拥有与你用来使公司存在的相同的 1000 倍或更多的优势。”

——*尔马尔·梅塔

除非你将你的数据送到太空，否则要真正防止这种情况几乎是不可能的。那么，这一切意味着什么呢？这意味着你必须决定在 0% 到 100% 的安全失败概率谱上，自己最能接受的位置。

你仍然不会将等同比例的实际资金投入到安全风险中，因为这比你想象的要昂贵得多。必须有一个平衡——某种成本/效益评估，让我们在尽可能少的投资下获得最大的利益。

*克托·法尔西奇：接下来十年我们会面对什么？

未来技术

*尔马尔·梅塔：我的工作的一部分是研究未来技术，现如今我正专注于云计算领域。某个时刻，我对云计算的理解有了深刻的领悟。

让我告诉你吧。那是在我看到 AWS re:Invent 上的一张幻灯片时；它只是一个柱状图，x 轴是 2011、2012、2013 和 2014 ——这些年份；而 y 轴上不是新服务，而是 AWS 提供的功能年增长百分比。图表中的第一年是 50%。他们增加了另外 50%，所以下一年是 100%。接着是 500%。再之后是 1000%，然后是 4000%。

如果你是一个内部 IT 组织，正在构建服务，并且看到这张图表，而我正在推销云计算和利用云服务来组合并构建你自己的应用程序，你该如何抵制呢？

对我来说，亚马逊、Azure 和 Google 正在垂直发展是显而易见的。它们希望尽可能多地进行垂直整合，因为每当它们向上移动一层时，就能获得更高的价值，因此商品和价值都会提升。

“对我来说，亚马逊、Azure 和 Google 正在垂直发展是显而易见的……”

——*尔马尔·梅塔

如果你每年以 4000% 或 5000% 的速度发展，最终你会耗尽所有可以开发的东西。你是告诉我，没有一个服务可以让你将三个东西拖放到屏幕上，然后得到一个完整的商业应用程序吗？当然有。这正是那张图表的必然结果。

如果这种趋势得以持续，即使它没有持续下去，即便他们回到 50%，他们只需要在各个方面增加一点点，做得更好地将现有的服务连接起来，那么你就没有理由再开发自己的软件。你只需有业务用例，选择语言和容器格式，选择 CICD 流水线，然后就完成了。

一年前，我参加了一些 Azure 培训，我们必须构建一个带认证的 Web API。它会接收一个 JSON 格式的字符串，将其转换为中文，进行情感分析，搜索 Twitter，然后提供一个关于下一词的机器学习预测。

如果五年前我遇到这个挑战，我就得建立一个架构，可能还得用一些机器学习。我甚至都不知道该如何启动一些 EC2 实例。那时候容器技术还没有普及，但也没有 Docker，所以我可能不得不将这些东西拼凑起来，花费 99%的时间去进行网页连接认证和运行 EC2 实例，仅仅是让这些东西启动并运行起来。

相比之下，我们在培训中用十五分钟就完成了所有这些工作。我们将一个框拖到窗口中；然后又拖了一个包含 Cortana 翻译服务的框，并画了一条箭头，所以情感分析由 Cortana 完成。我们将 API 密钥放进去，一切准备好后点击部署，它就变成了一个完全负载均衡的 API，自动创建，认证和证书都已经搞定。我们把 JSON 发过去，轰的一声。现在我们可以把它打包并放到市场上，在那里我们可以按每次 API 调用的 1% 来出售它。

Viktor Farcic: 我可能需要发出几亿次 API 调用，但归根结底，这些花费仍然只是我可能永远无法独立完成这项工作所需成本的一*部分。

Nirmal Mehta: 没错，因此在那次培训中我说过：“我们可能会继续做顾问，为这些项目构建这些东西，也许再有十五年，但未来总有一天，绿地开发将不复存在；那时我们将只是在亚马逊、Azure 或 Google Cloud 上构建商业智能应用程序。”

“我们可能会继续做顾问，为这些项目构建这些东西，也许再有十五年，但未来总有一天，绿地开发将不复存在。”

—Nirmal Mehta

未来可能会有其他服务将这些服务组合在一起，但在某个时刻，这一切将会完全垂直整合。事实上，你现在已经可以在亚马逊的视频编辑工具中看到这一点。他们发布了一堆 3D 网页 VR 工具，所以他们已经开始挑战这些行业，曾经让人难以想象这些东西能够在云端完成，但现在它已经做到了，因此在某个时刻，你就不再需要去构建你自己的服务了。

我的意思是，Lambda 允许按调用付费，因此如果你是一个初创公司，你甚至不需要再运行服务器，而且你的成本可以和客户获取的数量完全成正比。

Viktor Farcic: 对于初创公司而言，刚开始时成本基本为零，因为在最初的几个月里，你很不可能达到免费的使用限制。

*尔马尔·梅塔：我预测这将是未来的趋势。业务负责人和内部 IT 团队之间将不再有对话。业务负责人将直接进入 Azure。然后，业务用户——不是开发人员，不是运*人员，也不是安全人员，而是业务用户——将拥有他们的 Azure 帐户。

业务用户将是一个精明的实习生，业务负责人可能会说类似于：“好吧，我需要一些东西来告诉我我们竞争对手的物流运输路线。”对此，业务负责人会说：“好，砰，这里有一个地理空间服务。”然后，业务负责人会添加一些机器学习模块，放入一个 API，点击部署，测试一下，就完成了。接着，他们会直接把账单交给业务负责人。

这让我感到害怕，但当这些东西真正起飞时，我们的 DevOps 职业生涯几乎就结束了。如果我现在开始我的职业生涯，我会选择做带有数据科学和机器学习的 DevOps，因为如果你能收集数据并从中学习，那就是今天和未来几年真正的价值所在。

“如果我现在开始我的职业生涯，我会选择做带有数据科学和机器学习的 DevOps。”

—*尔马尔·梅塔

*克托·法尔奇奇：就像你说的，没问题，对吧？这就像气候变化一样；在我退休之前是不会发生的。你有什么最后的评论吗？

*尔马尔·梅塔：我最后的评论是，我有时会高估转向新系统的动力，低估*持旧系统运作的惯性。我的意思是，人们在 IT 领域接受非常糟糕的系统，比你想象的要久得多。

这是我离开的思考。我们可以对容器、CICD 和 DevOps 本身感到兴奋，但无论如何，在未来的某个时刻，这些都将不再需要。

第五十章

17

第五十一章：格雷戈里·布莱德索

敏捷、精益和 DevOps 顾问

第五十二章：介绍格雷戈里·布莱德索

最近加入 MThree Consulting 后，格雷戈的工作重点之一是帮助企业实现敏捷交付转型。此前，他曾在 SolutionsIQ 担任敏捷、精益和 DevOps 咨询师。格雷戈还广泛撰写关于 DevSecOps、内核和虚拟化的文章。你可以在 Twitter 上找到他，账号是 @geek_king。

*克托·法尔奇奇：嗨，格雷戈！在我们深入探讨 DevOps 的世界之前，先告诉我们一些关于你自己的事吧。

格雷戈里·布莱德索：到目前为止，我的职业生涯完全归功于我曾是一名非常成功的工程师，正因为如此，人们将我提拔到了管理岗位。然而，我认为这并不是最佳的方式，因为优秀的工程师并不一定能成为优秀的管理者。没人给我们这些工程师提供任何关于如何管理的培训，也没有人花时间向我们解释作为管理者究竟该做些什么。因此，我不得不重新塑造自己进入这个管理角色，实际上，我已经将工程学原则，如快速失败、实验和衡量结果来观察发生了什么，应用到了管理中。所有这一切发生在 DevOps 这个词还不存在的时代；但是，回顾过去，我发现自己已经将 DevOps 的原则作为我在行业中做事的核心部分。在这个过程中，我意识到，你不能同时扮演工程师和管理者的角色。

“DevOps 这个词的意思可能是外界最根本被误解的问题。”

—格雷戈里·布莱德索

随着时间的推移，我继续在不同的公司工作，逐渐地，我被邀请参加越来越多的会议。快进到今天，我最新的工作是在埃森哲/Solutions IQ 这家管理咨询和专业服务公司，以及 MThree Consulting，我专注于培训并为《财富》100 强企业提供新兴人才。但回到 DevOps 的话题，我发现在我的新工作中，我正在完善 DevOps+ 方法论。值得一提的是，我加入了“+”符号，因为该方法论不仅包括 DevOps，还包括敏捷和精益。

DevOps 与戴明的第九原则

*克托·法尔奇奇：这正好引出了我第一个问题，那就是：DevOps 这个词究竟是什么意思？我曾与许多人交谈，其中许多人的名字也出现在这本书中，当我问到这个问题时，我发现我从未收到过相同的答案。你是怎么看的？

Gregory Bledsoe：定义 DevOps 这个词的整个想法可能是最基本上被误解的问题。这并不是说问题本身是错误的，因为虽然有许多有效的答案，但有无数个无效的答案，这基本上是我们面临的问题。即使人们给出了有效的答案，它们也只是部分答案，给出答案的人并没有完全理解问题的整体范围。作为一个行业，我们不断地学习新的经验，并吸收新的东西，而 DevOps 是收集每个人最佳实践的一种方式。因此，我已经停止尝试简单地定义它，因为定义每天都在变化。

你知道吗，从美国工程师和统计学家 William Deming 的 14 点哲学中，核心概念 DevOps 这个词的意思就产生了？在那个列表中，第九条原则是，“打破部门之间的障碍”。这就是 DevOps 和 Ops 的名字的来源。因此，你无法定义 DevOps 而不包括 Deming 的概念在内。当我们开始 DevOps 时，我们不知道我们是否在专门实施 DevOps 或 Deming 的 14 点，但在某个时刻，我们弄清楚了。让我们说你正在应用精益方法；在 2018 年，它远远超出了最初的范围。我们意识到我们真正在做的是逐步将 Deming 的 14 点引入到软件开发中。一旦我们做到了这一点，我们就必须继续消除恐惧，同时不断改进并让每个人都参与进来。然后，我们必须让每个人成为变革的推动者。如果你不理解所有这些事情都隐含在定义 DevOps 的过程中，并且它们没有包含在你的 DevOps 定义中，那么你的 DevOps 定义可能是错误的，或者至少是不完整的。

Viktor Farcic：我实际上认为这是一个很好的观点。你所做的是展示了在这个词背后的许多思考，这通常被省略了。但在 Gregory Bledsoe 的词典中，DevOps 这个词的下一个定义是什么？

Gregory Bledsoe：正如我们所讨论的，在我给出答案之前，我需要提出一个不会改变的 DevOps 定义。因为它是所有 DevOps 都属于的总体概念，我的 DevOps 定义是“围绕业务价值重新组织 IT”。在这个定义中，我们通过引用包含了精益方法，同样地，我们也包含了所有经典的 DevOps 元素，我们已经整合了，但并没有排除任何未来的最佳实践。我认为现在应该推广这一定义，这使得我们不会排除新的创新。因为，当这种情况发生时，比如说 DevOps，变得如此明确，它最终会排斥新的创新。

“我的 DevOps 定义是‘围绕业务价值重新组织 IT’”

—Gregory Bledsoe

我并不特别喜欢那些声称能够解决所有问题的规定性框架，因为我们这个行业面临的问题变化得太快，无法做到这一点。事实上，一切都必须对解释和变化保持开放态度，因为上下文本身也在不断变化。我们所期望的 DevOps 定义，应该是能从根本上告诉我们它是什么，但又不排除那些我们还没有想到的新创新，它们正朝我们走来。我们已经拥有了一个可能性的管道，像无服务器架构和 unikernel（微内核）这样的技术，开始进入越来越多的领域。但是，随着我们与技术的交互方式将在未来两年内发生不可预测的变化，所有这一切可能会被完全推翻，换成其他的东西。

一个很好的例子是直接神经接口的出现。我们已经拥有了虚拟现实形式的人工现实，以及人工智能。如果我们将人工智能的反馈直接输入到，例如，人工现实或虚拟现实环境中，那么我们就是在使用直接神经接口。我们面临的问题是，我们根本不知道两年后的世界会是什么样子，也不知道如何调整我们的流程以适应即将到来的变化。事实上，我们需要做的，是放弃认为我们可以为 DevOps 制定五年规划的想法，因为，正如我们刚才讨论的，我们甚至无法预测两年后的未来。相反，我们可以做的是，现在开始实施最佳实践，尽力使其成熟，但最终要做好准备，快速地重新解读、忘记并重新学习。

*克托·法尔奇奇：这是一个很棒的答案。从问题背后的思*方式来理解真的是非常好。我看到的唯一问题，类似于你提到的我们无法预测两年后会发生什么的情况，是我有一种印象，许多公司，尤其是大公司，甚至不知道今天发生了什么。

代际之间的接力

格雷戈里·布莱德索：你想知道一个秘密吗？事实上，许多大公司实际上并不知道他们现在的环境是什么样的。那些环境的元素已经变成了一个黑箱，而最初构建这些大公司环境元素的人已经离开了。问题是，现在公司里没有人真正知道这些元素是如何运作的。那些脚本和部署，都是从前代人手中传下来的经典，但在当前的这一代中，几乎没人愿意深入挖掘并试图改变它们。

神圣的经典不容置疑。经过一段时间后，你甚至不知道它是如何运作的。所以，我认为你完全正确。即使是大公司，也不知道他们自己环境中今天发生了什么。

Viktor Farcic：话虽如此，我个人并不认为那是坏事。最糟糕的情况是，有些公司确信他们知道今天发生了什么。

Gregory Bledsoe：这是我其中一个重要的观点。我总是以一种方式表达，说这些公司的高层管理就像在玩“传话游戏”。在这个游戏中，有一长串人，一个人把信息悄悄传给下一个人，然后下一个人再传给下一个人，以此类推。这个游戏的思路是每个人都尽力传达他们听到的内容，但当信息最终传到另一端——在这个情况下是传到高层管理——你会发现信息发生了彻底的变化，当他或她比较两端传出的信息时，大家都会笑。

所有的信息都经过了如此多层的过滤，而过滤的动机并非是透明的，或者提供准确的信息。所以，最好的情况是，他们无法获得最好的和最准确的关于发生事情的图景。与此同时，最糟糕的情况是，一切信息都被过滤成了：我的老板想听什么？ 在链条的顶端，你根本不知道真正发生了什么，而你越是认为自己知道，越会发现自己错了。除非你真的去衡量——这正是 DevOps 的一部分——并且进行文化和满意度调查，否则你会发现自己不得不深思哪些指标才是重要的。

此外，除非你知道你在有效地收集信息，且除非你知道这些信息意味着什么，以及如果数据上升或下降你将采取什么行动，否则你根本无法了解发生了什么。我们可以假装知道，但这完全不可能。对我来说，过去 15 年 IT 领域的进步始于极限编程。然后，随着敏捷方法和正式的《敏捷宣言》以及敏捷原则，意味着我们在逐步学习停止假装知道我们不知道的事情。

Viktor Farcic：我喜欢这种有效地承认我们不知道某些事情的想法。

Gregory Bledsoe：没错！我们正在摧毁这些人的傲慢——这些贵族——他们通过教育、出身、血统或其他某些因素，更容易做出所有的决策并过滤所有这些信息。

我们必须在可能的最高点做出每个决策，因为只有在最高层的人才真正知道发生了什么。我们需要做的是停止假装那是真的，因为实际上，那恰恰与真实情况相反。真正的真相是，我们需要在可能的最低点做出每个决策，因为在那里可以找到准确的信息。

我们的组织必须发展出一种自主神经系统，在这个系统中，大部分决策是在低于战略关注层次的地方做出的。如果他们发现高管不得不参与日常运营，那么一定是出了非常严重的问题。你的高管应该做的是进行元分析，制定战略并提出正确的问题。然后，我们的预测性自主神经系统的对齐就会完全错乱，这正是 DevOps、敏捷和精益方法从根本上正确的地方。

我们正在尝试打破这些孤岛，消除那种“保住自己”的文化——指责别人、争功劳、推卸责任——以创造一种赋权文化，让人们真正感到自己拥有成果的一部分，而不仅仅是过程中的一*块。如果人们能够解决自己的问题——并且他们必须摧毁整个其余的过程——从根本上来说，他们会这样做，因为那时你会听到这样的话：“这不是我的工作，应该由别人来担心。”这正是这些跨职能协作团队从根本上解决的问题，它通过让每个人都成为结果的主人来实现。

诺基亚——巨人的陨落

Viktor Farcic：不久前，我和一位在诺基亚工作的朋友聊过。我问他，诺基亚真的没看到智能手机的到来吗？因为你会记得，曾经诺基亚处于行业顶尖的位置。它的诺基亚 1100 系列手机，至今已经售出了超过五亿部，依然是——结合 2003 年和 2005 年的型号——全球最畅销的两款手机之一。事实上，所有历史上十大畅销手机中，有七款是诺基亚设备。然而，在 2017 年第四季度，这家公司仅占据了 1%的市场份额，仅售出 440 万部手机。

我问我的朋友，诺基亚真的没看到智能手机的浪潮以及智能手机对行业的影响吗？他回答说，诺基亚的每个人都知道即将到来的一切，更重要的是，他们知道该做什么，但没有人敢把这些告诉管理层。这就是我们面临问题的核心。我称之为文化产物，因为每个人都知道上面的人想听什么。他们知道自己会因为什么得到奖励，但同样也知道自己会因为什么受到惩罚，而告诉高层管理真相并进行艰难的对话，是他们知道可能会因此受到惩罚的事。但对我来说，问题是：在这样的组织中，谁能真正发起变革？

发起变革/承担责任

Gregory Bledsoe：每个人都可以发起变革，因为归根结底，这都是我们的责任。如果你和你的舞伴跳舞，想改变舞蹈，你不能强迫舞伴改变他们的舞步，但你可以改变自己的舞步，而当你改变了自己的舞步，舞伴就必须适应。

我记得我第一次担任主题演讲的是关于克服 DevOps 障碍的会议。我提到的一点是，任何人都可以发起变化，这种变化会产生涟漪效应。如果你理解这种涟漪效应，你就可以利用它。你可以识别你的盟友；你可以影响有影响力的人，管理你的上司，并传播这种良好的变化。这是你可以在组织的任何地方做的事情。你能够激励他人；你可以用经济和数学术语以及通过测量来阐明论点。你随时可以开始这样做。你可以推动变革的进程，这也是在组织中任何位置上唯一能做到的。

“每个人都可以发起这种变化，因为最终，这一切都是我们的责任。”

—格雷戈里·布莱索

现在，显然，如果你已经在组织中拥有职位上的权力，你可以更有效地做这件事。但即便是在组织的底层——这是我觉得让我成为一名优秀工程师的原因之一——我也能让人们认同我想做的事情。我能够让那些没有个人动机帮助我完成某事的人提供支持。那么，为什么会这样呢？因为我们可以把这个共同的目标推销给我们的经理，作为我们所创造的价值的一部分。但我必须让他们认同这个价值，我必须做出经济上的论证。

如果你处在组织的底层，做出经济论证并开始改变你的舞步，通过引入更多的合作者并开始推动变革的进程，设定自己的位置，目的是不是为了赢得今天的争论，而是为了赢得明天的争论，通过玩长远的游戏。变革是渐进的，因此人们在真正感受到变化之前，并不会意识到事情已经发生变化，直到有足够多的人希望这种变化。然后，变革就变得不可避免，无论高层管理者希望与否。

没有职位权力的人低估了他们拥有的力量。同时，管理层也低估了他们的权力，因为他们习惯了进入会议后说：“告诉我问题是什么，告诉我所有可能的解决方案，”然后只是让别人执行某个解决方案。这是一种根本上倒退的管理方式，但它却是我们通常采用的方式。

这是泰勒主义的产物，工业革命后，弗雷德里克·泰勒是唯一的管理思想，大家都接受了这种理念。但现在是时候改变了。我知道我之前说过，但在一个大公司里，你必须识别你的盟友，你必须影响那些有影响力的人，而且你必须管理你的上司。如果你能做到这些，那么你就可以开始转型，并且在组织的任何位置上引领这一变革。

*克托·法尔奇奇：但随之而来的是时间的问题。当我与人交谈，并开始给他们讲故事时，我经常会得到这样的回答：“是的，但我不知道该做什么。我不知道从哪里开始，已经有 20 年我在持续进行一个原本应该昨天就完成的项目。”

格雷戈里·布莱德索：所以，这是另一个你必须提出经济论点的地方。这是敏捷原则中的可持续步伐。许多实施敏捷的人希望做到灵活范围，但固定日期，这实际上是你不想做的事情。你想要的是固定范围和灵活日期。当你做灵活范围和固定日期时，你只是在不断加重人员的负担，最终这些人变得超负荷工作。现在，没有人有时间去思考如何改进，更别提实际去做改进了。这是精益原则中的另一个方面，在这里，你同样可以把它当作经济论点提出。你必须把它卖给你的经理，并且你必须帮助你的经理把它卖给他们的经理。

“你必须把它卖给你的经理，并且你必须帮助你的经理把它卖给他们的经理。”

— 格雷戈里·布莱德索

现在我们必须做的就是为改进腾出时间。再一次，这完全是经济学问题。你可以绘制一张图表，显示你的技术债务在不断增长，因为你只是一直在构建东西，却从未修复它们。最终，这会导致系统停滞不前，任何你想触及的东西都会把一切弄坏。随着时间的推移，系统变得越来越脆弱。这些都是你可以提出的经济论点，因为它们是数学上的确定性问题，甚至毫无疑问。

*克托·法尔奇奇：那么，要改变他们所处的工作环境，人们需要向他们的老板提出经济论点吗？

格雷戈里·布莱德索：没错。如果你想开始改变你所处的工作环境，那么你必须为改进腾出时间。你需要了解实施变革背后的数学和经济学原理。这是你可能需要在自己的时间里做的事情，因为再一次，你的交付需求已经让你不堪重负。

一旦你开始这样做，并且当你开始提出并最终赢得经济论点时，这会发生的，因为如果你足够一致地提出这个论点，它是数学上的必然性，那么你就可以真正开始推动变革。关于人们的另一个基本点是：我们会模仿有效的做法。即使我们不知道为什么它有效，我们仍然会尝试模仿，如果随着时间的推移，足够多的人做对了，我们就能够阐明它为什么有效。只有这样，它才会真正开始被采纳，并且采用率会显著提升。

你只需要看看爱德华·戴明的理论是如何在美国被拒绝的，因为他们认为自己已经知道该做什么。爱德华去了日本，突然间，日本开始在市场上击败美国制造商。只有那时，美国人才注意到，并开始尝试模仿日本的做法，但他们花了很长时间才采纳这个方法。直到 30 年后，他们才弄明白，因为他们没有去真正理解为什么它根本有效，他们只是试图模仿过程中的例子。但差别远远不止这些。

区分那些在工作中关心结果的人和那些只是在打卡、按指令行事然后离开、毫不在意的人之间的差别是什么？德鲁克和戴明指出，如果你能把一个打卡人放在一个不同的环境中，让他对结果产生投入，他的表现会完全不同。相同的人在两种不同的文化中会产生截然不同的结果。

这就是日本人从戴明那里早早学到的秘密，当你将这些理念根植于你的文化土壤时，它能让你赋能于人，改进过程。你奖励他们指出问题，而不是惩罚他们，因为我们不在乎失败的感知，我们在乎成功的现实。

*克托·法尔奇克：但在你看来，是什么阻碍了我们去理解，而不是盲目模仿事物？是虚荣还是缺乏能力？

格雷戈里·布莱德索：这是一种自豪、傲慢、虚荣、懒惰和贪婪的混合体。没有人愿意对自己说，过去 15 到 30 年里，他们所经营的事业方式是错误的，而且他们通过适应病态的系统成功了。但在今天的世界里，这样是行不通的，因此我们必须从根本上改变我们的做法。这是一个极其困难的事实。人们总是想做出经济上的决定，选择最容易的做法。但我们天生就是这样。我们想做最容易的事来获得我们想要的结果，如果我们没有花时间真正去弄明白什么是最容易的方式来达成目标，那么我们就会做看起来最简单的事。

“只有当激励机制一致时，合作才会发生。激励不一致是企业文化和由部门壁垒产生的激励结构的产物。”

—格雷戈里·布莱德索

举个例子，作为一家公司，我们就会安装 Jenkins。我们会从尝试复制这些流程示例的工具开始。但如果这不奏效，我们就会组建一个试点团队，给他们成功所需的一切，并把所有的注意力集中在他们身上。我们为此付出了很多努力。我们清除了所有障碍，然后，这就成了一个轰动成功的案例，并且我们建立了一个持续交付的流水线。但接着，你尝试在试点之外复制这些成果时却失败了，因为试点拥有所有的意图和清除障碍的关注，而其他团队并没有。当试点团队不再拥有这些支持时，他们在流水线中构建的所有集成都会中断，这时就变成了：谁负责修复它们？好吧，没人负责，因为集成是协作的功能。

只有当激励机制一致时，合作才会发生。激励机制不匹配是企业文化和由“信息孤岛”产生的激励结构的产物。简而言之，为了重塑文化，你必须攻击激励结构。但这与我们一直以来的做事方式根本不同，完全不兼容，这让人很难接受。

修复数字化转型

*克托·法尔西奇：你说的部分内容让我想到了数字化转型。每家公司可能已经进行了数字化转型多年，并且都成立了新的部门，但成员依旧是同样的人。他们引入了 Jenkins、Kubernetes 等工具，但我至今没有看到这些数字化转型带来任何改进。也许我是偏执的，夸大了问题，但我实在看不到任何进展。

格雷戈里·布莱德索：首先，你并不是偏执或夸大其词。在一家财富 500 强公司里，你所描述的情况是正常的。这些公司多年来一直在尝试进行这些变化，但它们的处境和美国制造业当时一样，无法成功，他们也不知道为什么，因为他们从根本上没有理解。还记得德明吗？正是他曾被问到：“如果日本能做到，为什么我们（美国）不能？”他的回答是，美国人只是期待奇迹。他们想复制这些流程示例，并期望得到相同的结果，但问题在于，这些公司不知道该复制什么。

"美国企业没有给予员工合作的激励。"

—格雷戈里·布莱德索

这就是现在美国大多数企业正在经历的数字化转型故事。整个组织没有进行深入思考或共享愿景以建立共识，也没有激励机制来促进合作。人们在建立复杂的自动化框架上投入了大量工作，但却没有建立一个将 DevOps 共享部分纳入其中的复杂协作框架。美国企业没有给予员工合作的激励。

但与此同时，你希望激励合作的人并不一定理解其中的关键因素。你可以让他们参加功能细化会议，但直到工作被分配到某人的桌面作为工作项，他们才会开始思考实际上需要一起做什么。这是他们习惯的做法。我们等着工作被“抛过墙”给我们，然后才开始思考我们到底需要怎么做。但功能细化、故事细化和敏捷的整体目的是，我们希望尽早发现我们不知道但需要知道的内容。

Viktor Farcic：那么，我们该如何解决这个问题呢？对我来说，这听起来像是能解决我们所谈论的许多问题。

Greg Bledsoe：我们需要开始采用左移思*。我曾参加过故事功能细化会议，在会议中没有人提问，也没有人发表意见。第一次会议完全浪费了。它没有意义，因为人们习惯于只是等待工作。例如，开发者打开 IDE，开始写一个大的if循环，然后才开始思考自己到底需要怎么做才能完成这项工作。但此时已经太晚了。

你仍然会遇到在瀑布文化中一样的问题，就是你没有意识到你没有所需的一切。但现在，在最后一刻，每个人都会开始拼命地尝试让事情运作，做出根本性的改变来适应其他组件。关键是要尽早开始开发。

从上到下改变这种思*方式并不是一件容易的事情，但它是你必须做的第一件事，才能理解如何改变。我们大多数时候甚至还没有跨过这个障碍，但什么是赋能的协作文化呢？人们正在尝试做这些数字化转型，但他们甚至不理解从基层来看它应该是什么样子。没有一个宏大的愿景，你无法在基层进行一致的变革。但是没有理解这些变革如何影响基层人的宏大愿景是没有用的。它必须来自两个方向，这就是你的协作框架必须发挥作用的地方。

Viktor Farcic：但是，接下来我们面临第三个影响，我认为这是外部的影响。假设我引入了一个工具，目的是让自己获得 DevOps 认证。或者我引入了这个顾问，我们开始做每日站立会议。我有一种感觉，就是你经常参加各种会议，大家都在试图推销这些“天堂”。

格雷戈里·布莱德索：当然，这其中有一定的道理。向人们说他们想听的话的市场确实很大。卖东西最简单的方式，就是告诉他们你有一个灵丹妙药，能解决他们所有的问题，他们就会欣然接受，甚至说：“哦，太好了！我们要买这个！”但这种方式行不通，因为购买者并不知道他们需要问什么问题，而销售者此时已经达成了交易。但到了那时，他们已经把脚插进了门里，而随着更多的失败，他们就能收取更多费用。这种激励结构从根本上是错误的。

向人们说他们想听的话的市场太大了，有太多人愿意进入这个市场。我们必须从两个方面来改变这一点。作为顾问，如果我们真的想改变这种工作方式，从而最大化我们为客户创造的价值，那么我们必须以根本不同的方式进行销售。我们必须进入客户账户，直接告诉他们艰难的事实，让他们习惯听我们说真话，而不是想着：我们只会告诉他们他们想听的话。我们会答应他们能做任何事，然后一旦我们进入了，他们开始试图与客户进行艰难的对话。但这种方式行不通，因为现在，你会被他们的文化吞噬，而你无法改变他们的文化。你最终只能融入到是的的文化里，因为此时他们什么也不想听了。他们只想听到“是的”，你是无法改变这一点的。你一开始就搞错了方向，而这很难改变。作为顾问，我们必须以不同的方式处理这些客户关系。我们必须愿意直接告诉他们真相，让他们习惯接受我们会直言不讳。但事实是，初始的震惊过后，人们会非常感激这种诚实，他们明白，自己现在正在解决正确的问题。

在 DevOps 中，我们处理三件事：人、流程和工具——顺序是有原因的，因为人推动着流程。一旦你理解了流程应该是什么样的，你就需要找到填补流程空白的工具，帮助你消除浪费、减少等待时间和摩擦。但是，真正的问题是，买个工具后，往往太容易围绕它去构建流程，甚至强迫人们使用它。

"向人们说他们想听的话的市场太大了，有太多人愿意进入这个市场。我们必须从两个方面来改变这一点。"

—格雷戈里·布莱德索

Viktor Farcic：但问题在于，我认为几乎每个工具都是某种流程和文化的产物，Kubernetes 就是一个典型例子。它是关于不同的组织，最终形成了一个平台。我不明白的一点是，为什么人们会认为在完全不同文化中开发的东西，能够在他们的文化中奏效。

Gregory Bledsoe：你完全说对了。简单的回答是没有区别。你必须理解的第一件事是：在你们文化的背景下，你们组织的价值观以及组织的具体业务背景下，这个理念是什么？你们需要什么样的流程？为了以最短的等待时间交付价值，你们的理念是什么？只有在你回答了这些问题之后，你才能去寻找你们需要的工具。你必须先问那些基本的存在性问题：我们为什么存在？人们为什么愿意给我们钱？我们如何以最有效的方式兑现这个价值？如果你不从这些问题开始，你就无法得到正确的答案。

敏捷与 DevOps —— 真的有区别吗？

Viktor Farcic：但如果从概念角度忽略实现，那么敏捷和 DevOps 之间真有实质性的区别吗？

Gregory Bledsoe：是的，确实有。埃森哲最近收购了 SolutionsIQ，这是一家专门致力于构建业务敏捷性的咨询公司。SolutionsIQ 在建立深厚和信任的关系方面非常擅长，他们敢于告诉客户艰难的真相，并帮助他们逐步迈向更少病态、更加经验性的结构和交付链。

SolutionsIQ 将 DevOps 视为你敏捷基础设施和流程的交付方法，这并没有错。但我认为 DevOps 包括了敏捷并且扩展了它，因为 DevOps 一开始就从敏捷中汲取了很多内容。例如，跨职能协作团队：我们已经对其进行了扩展。我们合并了额外的部门，因为我们希望开发和业务能够在敏捷中更好地协作。然后，随着 DevOps 的发展，最初我们希望开发人员和运*人员能够很好地合作。但随后我们想：“为什么要停在那里呢？”到这时，你会意识到你还需要引入监控和安全人员，很快你会意识到你还需要引入测试人员，然后几乎所有其他人都要参与进来。你必须扩展这种协作的范围，让每个人都向左移动，尽早解决所有问题，因为如果这种方法效果不好，最后再把安全性加上去也是行不通的。你必须改变这一点，并把它全部向左移。这就是 DevOps 的心态，它拥抱了扩展版的敏捷。

敏捷和 DevOps 就像精益三明治中的花生酱和果酱。它们真的非常契合，不能单独依赖其中之一而取得巨大的成功，尽管这个比喻可能并不适用于所有地方。在德国，你可以说，这就像是香肠和酸菜。关键是，敏捷和 DevOps 相辅相成，能够很好地扩展彼此的优势。

有趣的是，我注意到的另一个问题是，那些完全接受规定性敏捷框架的人，真的会对节奏、步伐和体验产生依赖。但是在 DevOps 中，你会到达一个阶段，你不必等到冲刺才能交付；你可以在一切准备好时立即交付。当它准备好进入生产环境时，就进入生产环境，之后你要做的就是缩短准备生产所需的时间。在我看来，随着你在 DevOps 和敏捷方面的成熟，冲刺周期可以融入持续交付。但如果你死死依赖那个规定性的框架，你就会碰壁，这也是我不喜欢它们的原因。你可以把它们当作指导方针，但它们不是经典，也不是神圣的。它们没有教给你任何东西。Scrum 和看板中的所有元素都是为了教你原则，而不是成为终极的机制。

Viktor Farcic：但它们可能是为了教你原则而设的。我在实践中没见过这样的情况。我的意思是，人们常常说：“哦，我会做敏捷。” 但事实上没有，因为从那些原则中，我们并没有在实践这个。

"在我看来，随着你在 DevOps 和敏捷方面的成熟，冲刺周期可以融入持续交付。但如果你死死依赖那个规定性的框架，你就会碰壁，这也是我不喜欢它们的原因。"

—Gregory Bledsoe

Gregory Bledsoe：没错，这也是为什么当你尝试做一些新事物时，一个规定性的框架在一段时间内可能是有帮助的。但同样重要的是要知道，什么时候它的价值已经下降到一个地步，所引入的浪费和开销已经超过了它带来的好处。问题在于，这是一个对每个组织都不同且难以计算的难题。

一个规定性的框架可以帮助你摆脱瀑布模型的文化，完全从心理上脱离瀑布是有益的，但你必须超越这些基本的规定性元素。你需要根据你的组织进行调整，就像 DevOps 一样。但正如我们之前所说，没有一种适用于所有的 DevOps 方式。你必须根据你的组织来适应它。这也是 DevOps 实施中另一个大的问题。人们总是希望有人告诉他们具体该做什么。它们希望生活在一个别人为他们思考的世界中，但答案是否定的。你需要让组织中的每个人都去思考这些问题，只有这样你才能得到最佳的答案。

Viktor Farcic：但这不就是一个恶性循环吗？少数人试图改变大多数固守旧有工作方式的人。然后，如果少数人成功改变了一些东西，他们又开始做同样的事，因为现在没有人会从这个新的位置上移动。

Gregory Bledsoe：这可能会变成一个恶性循环。有一些非常重要的人类学和社会学原因，解释了为什么信仰和习惯会固守，而且我们有一个可以称之为相同性或一致性偏见的东西。这个观点是，我们希望今天和明天与昨天相同，因为我们已经理解了昨天的威胁和机遇，而不断重新调整我们的认知机制以应对新的威胁和机遇是非常困难的。我们正进入指数变化的时代，在这个时代，每一天都将比前一天更不同，直到我们能够发展出一种系统化的方式来经验性验证你的变化——当你做到这一点时，改变就不再那么可怕了。

以创新的周期为例，最初创新传播和被构建所需的时间是千年。然而，后来它变成了几个世纪，接着是几十年、几年，现在已经缩短到了几个月。不久之后，它会变成几周，接着是几天，最终创新将会是瞬时的、没有暂停的。为什么？因为我们正在进入一个指数变化的时代。我们必须理解为什么我们很难适应、改变，我们必须明白，变革不能脱离我们的超结构，因为我们有这种文化和意识形态的超结构，它们赋予我们像价值观和伦理这样的东西。

在 20 世纪，我们学到，当你试图一口气改变所有东西，且尝试脱离所有这些超结构时，得到的结果可能并不好。只需看看 20 世纪，200 million 人被他们自己的政府杀害，而这些政府试图脱离社会的所有超结构。因此，对我们来说，关键是我们不仅要学会如何管理这种变化，还要学会如何拥抱它。

Viktor Farcic：这难道不是我们无法停止的事情吗？

Greg Bledsoe：关键是我们无法阻止它，它必然会发生。我们需要做的，就是把它锚定到某个东西上，而这个锚必须是我们的价值观。但问题在于，我们必须理解这个价值观是什么，对于很多人来说，这意味着要回到启蒙时代的哲学。这也是为什么这些会议演讲、书籍和播客类似于一个黑暗的知识网络，互相联系形成新的超级结构。这些将引导我们进入前所未有的指数级变化时代的新超级结构，锚定于现代性和启蒙时代的价值观，我们正在回归这些价值观，发现它们确实有效。我觉得我们现在进入了后后现代主义时代，反反革命因此也开始了。但关键是，DevOps 是这一切的尖端。

我知道这听起来有些宏大，但当你真正理解这一切如何运作时，你会发现它与西方自由民主的运作原理是一样的。赋能个人，并将社会的成功与个人的成功和自由联系起来，让个人感到被赋权，并对自己生活的掌控感，是非常强大的。与一百年前相比，今天世界上的生活水平简直难以置信，而我们几乎没有庆祝这一点，因为我们太忙于担忧那些仍然糟糕的事情。但如果我们能够接受这种变化和这种新的后后现代主义，那么我们甚至可以加速这种积极的变化。如果是这样，那谁知道它会走到哪里呢？

2019 年的 DevOps——成功还是失败？

Viktor Farcic：那么你会说 2019 年的 DevOps 是一个成功的故事吗？我可以去一家公司，然后说：“看，很多人都参与了，他们取得了成功，因此他们做得很棒。只有你没有跟上潮流。”还是说，我们只是看到了转型的开始，真正的普及还未到来？

Gregory Bledsoe：在大多数情况下，采纳是表面的。它试图将一个过程示例强加于一个病态文化上，因为文化是偶然形成的。几乎没有人是有意去构建他们想要的文化的，通常都没有目标。这是对事件的反应的积累。文化的形成通常是这样的。要有意识地解构并重建它是困难的，这也是真正转型的一个重要部分。只有少数人有意识地去做这一点。那一定是解锁赢家与输家的下一步，因为这样做所带来的市场优势是巨大的。你将超过你的竞争对手。你必须这么做，因为你正在将最强大的脑力投入到每一个问题中。这是其中的一个真正的秘诀。

也许你的高管是房间里最聪明的人，或者也许不是，但房间里最聪明的人不可能比所有其他人加起来更聪明。当没人敢发声，因为他们知道房间里最聪明的人不愿意听某些话时，你就会锁死所有这些解决问题的能力。这就是为什么市场比中央计划更有效的原因，因为世界上最聪明的中央计划者也不能比市场上其他所有人加起来更聪明。

他们的集体智慧是一种涌现特性。从很多方面来说，这就像是蚂蚁群体。蚂蚁群体是一个涌现特性，每只蚂蚁都在根据自身的本能和指定的职责做非常简单的事情。它在跟随信息素的踪迹，携带食物。但整个蚂蚁群体在整体上是极其高效和聪明的，类似于市场的运作方式。我们需要做的是让我们的组织转变成这样的形态。因为那些能够成功转型为这种形态的组织一定会更成功，这是一个数学上的必然。

Viktor Farcic：这是不是意味着未来的趋势是从金字塔型结构向更扁平化的结构转变？

Gregory Bledsoe：是的，因为我相信我们将从等级制度转向基于能力的制度。Holacracy（全员自治）这一概念已经被提出，我确实认为人们正在进行相关实验。我不确定 Holacracy 是否就是我们最终会采用的模式，但我们最终会形成某种赋能的宪法型组织，在这种组织中，每个人都有权成为自己工作的老板。我认为这是一种极致的表达，任何组织都可以朝这个方向发展。我不知道这是不是会成为正式的 Holacracy，或者是类似的东西，或是完全不同的东西。但问题是，任何组织中的领导者都可以自愿停止使用强制力，开始使用激励与启发。

这才是真正的领导力，而不是管理。当你开始这样做时，你自然会开始扁平化层级结构，并且你也会自然开始构建更多的基于能力的机制。所以，可能当我们开始根据不同的素质来选拔领导者时，这种情况就会在没有像 Holacracy 这样正式的框架下发生。但这将是生存下来的组织与死掉的组织之间的区别。

Viktor Farcic：没错。说到未来，你觉得未来会给我们带来什么？我不会让你预测十年后的事情，因为正如我们之前讨论的，我们甚至不知道两年后会发生什么。

预测 DevOps 的未来

Gregory Bledsoe：谁知道呢？有一些短期和长期的事情，我确实认为我们可以预测。我认为“DevSecOps”这个术语将会消失。人们会意识到，DevSecOps 实际上是对 DevOps 的成熟过程，在这个过程中，你没有忘记安全性是一个问题，并且你在将其提前并纳入设计讨论中。人们将能够提出这样的问题：“嗯，这看起来像是一个 SQL 注入的机会。你有考虑过这个吗？”

我有一个个人痛点，就是 SQL 注入仍然存在，因为在开发过程中没有问过这个问题。开发人员没有动力去关心安全问题，他们也深陷其中，无法在完成功能发布的同时去考虑安全问题。这必须改变，这将彻底改变安全性。DevSecOps 是对 DevOps 的良好成熟，它是在将安全性提前。我认为这个术语将被并入到 DevOps 中。现在，它之所以成为一个术语，是因为人们正在发现我们必须将安全性、合规性和审计纳入其中，因为这是我们能够在大规模上适应的唯一方式。

Viktor Farcic：那么，DevOps 这个术语呢？你认为将来这个词的含义还会保持不变吗？

Gregory Bledsoe：我认为“DevOps”这个术语将成为 IT 的同义词，因为每个人都会至少明白，现在就是这样做的，如果你不这样做，那就是做错了。我认为这将被普遍理解，而这仍然会导致结果的分化。有些人会做得比其他人好得多，那些能够最快忘记旧的做法并重新学习的人将获得持续的竞争优势。他们将站在前列，这也是为什么人们现在必须拥抱并采纳这一做法的原因。你等得越久，成功的几率就越低。这并不取决于你业务周围护城河有多深。

“DevOps 将成为 IT 的同义词，因为每个人都会至少明白，现在就是这样做的，如果你不这样做，那就是做错了。”

—Gregory Bledsoe

看看那些大银行。它们的业务周围有巨大的监管护城河，但这并没有拯救它们。它们仍然在被一点一点蚕食，能够适应的银行才是能够抵御金融科技（FinTech）挑战的银行。看看交通行业或酒店行业的整体情况。它们曾认为收购了所有这些物业就是对抗市场的对冲，但现在它们真正的竞争对手甚至没有拥有任何物业，而是 Airbnb。进入市场的成本比以往任何时候都低，而且只会变得更低。

对于沟通来说，是否拥有通过社区布设电缆的通行权并没有关系，其他人没有，你认为那是你的护城河，因为 5G 正在到来。5G 将改变游戏规则，您通过物理电缆和物理光纤提供的服务将变得不再重要，进入门槛也会比以往更低。每个人都会被打乱，这只是看你是否会自己打乱自己，还是外部竞争者会打乱你。那些弄明白并理解必须适应这种指数级变化的人将会生存下来，而其他人将会灭亡。这是长期的预测。

Viktor Farcic：但是在你被打乱之后，仍然有生存的时间吗？

Gregory Bledsoe：是的，确实有那个窗口，但它正在缩短，我们实际上不知道这个窗口有多短，这就是为什么每个人现在都必须开始做的原因。那些真正能让自己处于未来-proof 状态的人，是那些在问这些生死存亡的问题的人，那些愿意深入思考这个问题的人。他们才是能成功的人。

你不能仅仅开始说：“好吧，我们没有 DevOps 就无法生存，那我们就把 Jenkins 部署到各处；但是接着我们再创建一个孤岛来管理。”你只是在加剧你最根本的问题。那些知道这不是你应该做的事，并且知道真正的方式是德明的 14 条原则，其中最重要的一条是把每个人都变成转型的推动者的人，才是那些能成功并且能够最好地应对指数级变化时代的人。

Viktor Farcic：完全正确，尤其是当你提到 Jenkins 时。我持续访问很多公司，没有开发人员能触及它。

Gregory Bledsoe：必须是，如果你建立它，你就得运营它。

Viktor Farcic：没错。但这很困难，因为它是一场革命。如果有权力斗争，你不能告诉我，如果我建立了整个虚荣工厂，那就意味着我昨天已经在运营它了。

Gregory Bledsoe：这是真的。权力斗争不仅仅是组织层面的，还是意识形态层面的。它是科学管理或泰勒主义与精益之间的较量，这就是事实。那些能够拥抱精益并成功改变整个组织思*的人，这才是关键。

Viktor Farcic：但是我们还需要多少时间，因为软件开始有一段时间了，但我们仍然认为它是一个工厂。

Gregory Bledsoe：让我这样告诉你。回到 2014 年，有人发现，75 年前，《财富》500 强公司平均寿命是 75 年。快进到 2014 年，这个数字降到了 10 年。这些公司正在被新兴、更灵活的公司所取代，这些公司仍在努力扩展市场。

这是另一个我认为人们并不完全理解的秘密，一旦你停止尝试扩展市场，开始尝试保护市场时，你实际上是在优化保护市场而不是扩展市场，而你已经开始走向衰亡。那些更*、更灵活的公司，拥有更少的开销和基础设施，正在等待在你还没完全倒下时就开始吞噬你的尸体。

你就像把腿放进了食人鱼池里，而食人鱼饿了。吃掉*鱼的不是大鱼，而是快速游动的鱼吃掉慢速游动的鱼。我们将会看到《财富 100》与《财富 500》公司之间的更替将会非常巨大。我认为这些公司在榜单上的平均寿命将下降到 5 年，甚至 3 年，然后你会看到这些榜单上出现巨大的变动。那么，我们还有多少时间呢？嗯，余生。假如你的主降落伞失败了，你有多长时间可以拉开紧急降落伞？余生。

Viktor Farcic：完全正确。我会用这个比喻的，我太喜欢了。我真心觉得你对 DevOps 背后思*的定义非常聪明。

Gregory Bledsoe：谢谢！你大概能看出来，我简直可以每天、整天聊这个话题。最有趣的是，讨论真的是没有尽头的。

Viktor Farcic：再次谢谢。

Gregory Bledsoe：谢谢。

第五十三章

18

第五十四章：Wian Vos

Red Hat 的解决方案架构师

第五十五章：介绍 Wian Vos

Wian Vos 是一位经验丰富的 DevOps/云计算顾问，在信息技术和服务行业有着丰富的工作经验。他擅长 PaaS、敏捷方法论、DevOps 和云技术。你可以通过 Twitter 上的 @wianvos 关注他。

Viktor Farcic：嗨，Wian！在我们深入讨论 DevOps 之前，你能告诉我们一点关于你自己的情况吗？

Wian Vos：我目前是全球最大开源公司之一——位于阿姆斯特丹的 Red Hat 的解决方案架构师。在 DevOps 这个术语出现之前，我就已经从事相关工作，2005 年以来一直参与基础设施自动化，2013 年以来投身于容器化的推进。在我的职业生涯中，我曾在荷兰的 ING 银行、Rabobank 以及一些其他较*的政府机构工作。最近，我在 Zaandam 的 CINQ ICT 担任 DevOps 管理顾问，之前我还在波士顿的 XebiaLabs 工作了两年。

定义 DevOps

Viktor Farcic：我想从我在这本书中问过其他所有人同样的问题开始：什么是 DevOps？每个人给出的答案都不一样。就我个人而言，我不明白为什么每个人的定义都不一样，但希望我们能在讨论中涉及这个话题。

"DevOps 在不同的时间点意味着不同的东西。"

—Wian Vos

Wian Vos：实际上，这正是我所预期的。我认为 DevOps 在不同的时间点意味着不同的东西。当这个术语最初被提出时，它基本上是基于 DevOps 宣言，推动一种新的工作方式，当时我觉得这个想法是有意义的。但后来，DevOps 变得流行了，正如所有流行的事物一样，大公司纷纷跟风——包括我目前的雇主，Red Hat——并将其变成了一个营销术语。

那么，DevOps 对我来说是什么？DevOps 是一种管理 IT 业务文化的范式。如果你从最纯粹的词义来看，它是一种将开发和运*放在同一个团队中，共同朝着相同的商业目标努力的方式。我从事 DevOps 已经九年了，但我从未加入过那些传说中的团队，也从未见过这些团队真正有效地运作。但我做过的是与 DevOps 类似的实践和工具密切相关。通过我的经验，我发现 DevOps 基本上就是关于文化和工作方式。

Viktor Farcic：如果你从未见过 DevOps 的实际运作，我必须承认，我也很少见过它真正发挥作用。这是因为公司失败了吗？还是因为这些公司根本没有尝试过按照应有的方式实施 DevOps？

Wian Vos：如果你想在公司实现 DevOps，你会面临一些障碍。首先是开发和运*之间的实际关系。当你面对一个新的初创公司或正在实施全新应用的公司时，这些关系不算大问题。为什么？因为你可以把一个团队聚在一起，他们可以各自做自己的事。

但是如果你看看传统公司基本上的组织方式，你会发现开发和运*之间总是存在着传统的分裂，而这基本上是因为它们各自有不同的视角。一方面，开发致力于追求稳定性，另一方面，运*则由业务推动，追求变革。在传统公司中将这两者结合起来，而不是在初创公司环境下实现，是非常困难的。

Viktor Farcic：如果是这样，你认为公司在想要在组织中实现 DevOps 时，面临的最大问题是什么？

Wian Vos：我一直认为 DevOps 公司是那些从底层投入技术的公司。它不仅仅是创建一个团队，更重要的是团队之间相互倾听，技术变革应该从底层决定，而不是由上层传达下来。

你问的是公司今天面临的最大问题。实施真正的 DevOps 时，我见过的最大挑战之一就是人员流动。为什么？因为这些团队——开发和运*——已经互相对抗了多年，而现在你又让经理去把这些人组织成一个团队。然后，旧的经理被替换成一个新的经理，他有不同的方法。

"我一直认为 DevOps 公司是那些从底层投入技术的公司。它不仅仅是创建一个团队，更重要的是团队之间相互倾听。"

—Wian Vos

如果不是为了那些有具体人数的员工，经理到底是为了什么？假设我是一个经理，有 20 个人，现在我要裁掉 10 个人。那么我现在是什么？嗯，我已经是曾经的半个经理了。我知道这听起来很严厉，甚至有些不尊重在座的经理们。从 DevOps 的角度来看，我遇到过好的经理。但是要让这种方式发挥作用，需要一种非常开放且非常特别的公司文化。

我认为 DevOps 是过去 10 年中我们所见到的巨大的开源技术推动的一个重要催化剂。但是在实践中，它是可怕的。嗯，说它可怕其实不准确，它只是根本无法实现。

什么是真正的敏捷…以及 Kubernetes 的重要性

Viktor Farcic：那么我再问一个后续问题。你见过多少公司是真正敏捷的？

Wian Vos：我见过很多真正敏捷的开发团队。我在 Xebia 工作了足够长的时间，足以真正了解敏捷是什么，在哪里实现，以及该寻找什么。

但要真正做到敏捷需要毅力，而这在今天的企业环境中是很难找到的。这不仅仅是两周站在一个白板前，贴满了便签。它远不止这些；它是一种思*方式。这并不是进入那个“我现在要这个功能，因为我有钱”的思*陷阱。而是更多地说：“好吧，让我们来规划这个，将它放入待办事项列表，并进行分类。”

我没有见过很多真正敏捷的公司，但我见过一些尝试变得敏捷的公司，在此之前，还有一些公司在尝试精益——从某种意义上来说，这是好的，因为这些公司努力将敏捷和精益融入其中，这最终会对它们的公司文化产生积极影响。但这并不意味着它们就变得敏捷、精益或 DevOps。如果你经营的是一个持续业务的运营商店，敏捷是最难做到的。

Viktor Farcic：那么，公司的文化在达到一定规模后就不再改变了吗？

Wian Vos：我不是这个意思。我想说的是，DevOps 涉及的技术本身不是问题。问题在于人，而一旦涉及到人，他们是非常难以改变的，尤其是在企业文化中。但是，记住，我从来没有在初创公司工作过。所以，我没有那种初创公司的经验。

Viktor Farcic：我想初创公司是另一个层面的事情，因为它们*，理论上可以做任何事情。它们没有什么负担需要去除。

但这是我在拜访公司时遇到的一个问题，尤其是当我试图向他们解释技术的全貌时。以微服务为例，它们是某种文化和某种环境下的产物，像其他任何技术或过程一样，最终它们变成了工具。

Wian Vos：或者是一个过程，或者是一个流行词。

Viktor Farcic：但如果你没有真正将其实施，或者只是简单地采用了工具，那么你会处于一个非常糟糕的境地，就像微服务的情况一样。没有自给自足的团队，能有微服务吗？没有改变文化，能有自给自足的团队吗？

至少根据我的经验，这种做法会失败得非常惨。但回到工具上，我们都曾为软件供应商工作过，根据我的经验，我有这样的印象：世界上每一个软件供应商现在都将他们的工具重新品牌化为 DevOps。在今天的会议上，所有的内容都是 DevOps。对我而言，我过去 10 年使用的所有工具都可以算作 DevOps。

Wian Vos：我不想说这本身就是一个问题，因为通常被购买的工具就像是不存在的 DevOps 神奇子弹。但将这些工具贴上 DevOps 标签确实有助于高层管理人员的采纳。如果某样东西被贴上 DevOps 标签，那么作为工程师或开发者的你就更有可能去使用它。

“……通常，购买的工具就像是那些不存在的 DevOps 神奇子弹。”

—*安·沃斯

如果你问我，“它们基本上从我们这里拿走了 DevOps 并且发展了下去，这是坏事吗？”我的回答是，我不知道。我确实反对那种观点——如果你有足够多酷炫的新工具和开源工具，那么你就可以称自己的公司为 DevOps 公司。这个我真的是受够了。我不知道这是好事还是坏事，因为它确实带来了许多酷炫的东西让我们去玩。

*克托·法尔西奇：接下来，我们聊聊 Kubernetes。现在 Kubernetes 是唯一统治一切的吗？

*安·沃斯：在接下来的两年里，这可能是对的。在我成为 Puppet 工程师之前的十年里，我在 Puppet 和 XebiaLabs 做了各种各样的工作，建设了平台即服务（PaaS）相关的东西，那时候很容易做出预测。早在 2001 年，大家就很容易说我们会在接下来的三到四年里使用 WebSphere ND，甚至可能在更长的时间内。

所以，在这个世纪的第一个十年里，很容易预测你未来五年会做什么，应该在哪里投资，应该专注于哪些领域。但是自 2009 年，甚至 2010 年以来，我就毫无头绪了。首先是平台即服务（PaaS）和资源配置。然后是容器化，或者说——我不知道你是否记得——不可变基础设施（immutable infrastructure），有 Foundry、Heroku 等那种酷炫的东西。

然后是 Docker 的出现，那简直是，啊！ 但我们不能忘记，那个技术自 1990 年代末期就已经存在了。Docker 只是让它变得可用，而且在当时，Docker 是最酷的公司：每个人都听说过它，大家都想和它合作。但突然间，Kubernetes 横空出世，这有点搞笑，因为它和 Docker 几乎同龄，现在 Kubernetes 无处不在。每个人都在标准化它，大家都在使用它，大家都必须用它，大家都想和它一起工作。我认为这是过去十年里我见过最具说服力的技术，尤其是因为我们需要理清楚这个公共云的局面，而 Kubernetes 完美契合这一点。或许在三四年后，我们会对它感到厌倦，因为它本身就是个庞然大物。它很复杂，有时也很难搞定。它由 Google 和我们共同控制。

*克托·法尔西奇：我觉得关于 Kubernetes 最有意思的是，我不记得在我职业生涯中，最后一次见到一个软件、平台、应用——无论你怎么称呼它——被全球所有软件供应商全面采用是什么时候。即便是那些通常会等到其他人都采用新技术之后才跟进的传统软件供应商，也都支持 Kubernetes，这点我真的是没想到。

*安·沃斯：在 1970 年代，主机计算曾非常流行。但说实话，我认为上一次类似的情况发生在 Java 应用服务器的时候。所以，我不得不同意你的看法，这确实是一个朝着 Kubernetes 大规模发展的趋势。不过，大多数人其实并没有真正理解 Kubernetes 是什么，因为大部分人谈论 Kubernetes 时，都是在谈容器工作负载调度，这在一定程度上能够覆盖负载问题。

但如果你看它的真正优势以及为什么它会获胜，你会发现它为任何云平台提供了一个通用接口。通过实现一个 Kubernetes 集群，你可以在 AWS、Google Cloud、Microsoft Azure、电力云或任何云平台上几乎透明地部署工作负载，只要你不选择他们提供的本地容器解决方案。

看云计算的未来

*克托·法尔奇克：但这样不就成了对那些云供应商的威胁吗？如果一切都那么透明，我可以很容易地从一个云服务切换到另一个。

*安·沃斯：我认为这对我们作为消费者来说是个好局面。但这也促使这些供应商更激烈地争夺我们的业务。在过去五到六年里，如果你和 IT 界的任何大佬聊，话题无非就是云。在这段时间里，我们经历了前所未有的经济繁荣。所以，我在想，一旦经济开始衰退，会发生什么：人们会再次削减成本吗？如果是，那会怎样？我们会回到硬件时代吗？

*克托·法尔奇克：但云计算比本地部署更贵吗？

*安·沃斯：是的。

*克托·法尔奇克：我有一个理论，虽然我可能错了，那就是当你计算每个 CPU 的价格时，如果我们把管理本地基础设施的成百上千人算在内，我实际上认为当你考虑到人工成本时，云计算并没有那么贵。

*安·沃斯：只要你的云基础设施足够*，你可能是对的。但如果你看大规模的云实现，假设你在谈论成千上万的节点分布在多个云平台上，它们依然需要很多经过认证的，非常昂贵的专业人员来运行。我可以告诉你，拥有 AWS/Google Cloud 认证的人，远比那些一辈子只会操作 Cisco 交换机的人要贵得多。

*克托·法尔奇克：这确实很有道理。

*安·沃斯：所以，你可能用一个云专家的钱，聘请两个专家。

*克托·法尔奇克：我曾和一个人谈过，他的公司最初是在本地部署的，然后他们转向了云。最终，这家公司又回到了本地部署，理由是“哦，我们终于在云端学到了如何做好事情，所以现在我们终于知道自己需要在本地做什么了。”

Wian Vos：我认为这是一个正确的陈述。因为，基本上——我只对 AWS 非常熟悉——如果你看看 AWS 的工作原理，它基本上为你提供了与自己数据中心相同的所有组件。不同之处在于，它还为你提供了控制权，作为工程师或开发人员，你无需与网络人员就各种问题进行无休止的讨论——这个防火墙设置，或者那个防火墙设置——也不需要提交变更请求来来回回地沟通。不，你只需要坐在那里，做，改——好，完成。

你仍然需要知道你在做什么。并不是说亚马逊有一个神奇的网络设备，能够自动生成连接。它并不是那样工作的。因此，从这个角度看，我认为将你的基础设施搬到 AWS 是很好的，因为它澄清了你一直做错的很多事情。我认为这对所有情况都可持续吗？可能不行。

Viktor Farcic：但这对你的客户设定了某些期望。如果你是一个基础设施团队，而其他所有人都在使用 Azure、AWS、Google Cloud Platform 等，而你们还在本地，那么你们需要提升自己的水平，不是吗？

Wian Vos：是的，这就是我们将在接下来的三四年中看到的事情。公司将尝试弄清楚，最终，如何做到这种混合模式，既有你始终需要的 60%的生产能力，保存在本地。你将采用灵活的容量，这样你就能快速将产品推向市场。我真的认为这就是我们所需要的最佳状态。

Viktor Farcic：事后看来，你可能无法回答这个问题，因为你为一家公司工作，但我今天看到的一个问题是困惑。假设我们为一家公司工作，并且最终决定选择 Kubernetes。然后我们面临的问题是如何从 57 种流行版本和 500 种不太流行的版本中选择一种，这让我们面临了一个问题：“那我们现在该怎么办？”

Wian Vos：我只能给你一个建议：选择我们的——开玩笑的。话虽如此，我认为 Kubernetes 发展得太快，不适合在企业中选择自建（DIY）用于生产。我并不是说如果你经营一家初创公司，就不应该选择 DIY Kubernetes，因为 Kubernetes 的功能推送非常棒，说实话，如果我在上一个工作中有机会，我可能也会选择 DIY。但那只是自负而已。实际上，企业认为他们能够自己做 DIY Kubernetes，这是非常傲慢的。整个过程是一个大型项目，发展速度快得前所未见。

“我认为 Kubernetes 发展得太快，不适合在企业中选择自建（DIY）用于生产。”

—Wian Vos

基本上，在开源中，Kubernetes 的提交几乎比实际的 Linux 内核还要多。因此，我肯定会选择发行版，因为发行版为你解决了许多安全性问题，或者可能选择托管服务，其中你可以获得真正的 Kubernetes——而不仅仅是别人池中的保留命名空间，而是一个真正的 Kubernetes 服务。

Viktor Farcic：你提到了提交的数量和诸如此类的事情。对我来说，这很令人困惑，但它也表明 Kubernetes 需要放慢速度，以便人们能够真正理解它。因为现在，即使是选择 Ingress 网络也是一周的工作量。

Wian Vos：你提到这点真有趣。今天早上我正好讨论了 Kubernetes Ingress 的整个问题！但是是的，我非常同意。仅仅选择你的网络插件、边缘路由器之类的东西，很容易因为你做出的一些选择而自食其果。

Viktor Farcic：我认为这就是为什么每当有人告诉我要自己在 Kubernetes 上动手的时候，我的问题就简单地是，“为什么？”

Wian Vos：确实！你为什么要这样做呢？

Viktor Farcic：你不会花费别人花在整合上的同样时间，即使是和 Kubernetes 这样的人们一起度过了他们一生的人，比如 Kelsey，例如 Mike Powers。这有点像，“我不知道该选择什么，因为今天早上刚出现了一个新东西。”

Wian Vos：这确实就是这样。它是一个大家伙。事实上，这在早期的 2000 年代与 Linux 非常相似。如果你看看当时实际可行的 Linux 发行版数量，那简直是奇怪。有那么多不同的风味和你可以做的事情，但最终都归结为现在的两三个主要 Linux 发行版。所以，我认为 Kubernetes 会像 Linux 一样发展。

我觉得当前的生态系统很好，因为它带来了竞争，这也带来了变化。但我认为 Kubernetes 肯定会长久存在，因为我们的数据中心变得更加复杂。我知道我在与之前说的话相矛盾，但这就像是数据中心的核心，可能会在未来十年或二十年内持续存在。但生态系统会更少，选择也会减少。

企业的问题

Spotify 并没有进行自己的 DIY Kubernetes，这让我思考。因为工程上来说，Spotify 是最杰出的公司之一。如果你看看他们在做什么，他们推出的东西，以及他们遇到的少量故障，他们一定是在做一些正确的事情。如果像他们这样的公司说，“不，我们不会自己动手做 Kubernetes”，那对其他人来说应该是一个信号，“好吧，如果班里最聪明的孩子不去做，我应该做这个吗？”

Viktor Farcic：但这不正是企业普遍存在的大问题吗？每个企业都认为自己比所有聪明人都聪明，认为自己是与众不同的。这个我经常听到：“我们将自己推出去，就像十年前我们推出自己云服务时失败的方式一样，唯一的区别是这一次，我们一定会成功！”

Wian Vos：我同意。在我目前的职位上，我为许多企业提供有关 DevOps 和容器化的咨询。是的，特别是在技术水平较低的企业中，很多人做了资源配置的工作，带来了这些变化，并使公司进入了不同的轨道。

大家都在想 Kubernetes 就像是实现 Puppet 或 Jenkins 一样。但你必须把 Kubernetes 当作一种不同的东西来看待，否则它会突然跳出来咬你。我不是在吓唬你，也不是说你不应该尝试它。因为，最终，它是有趣的，且是一次很好的体验。它能帮助你更好地理解 Kubernetes 是如何运作的，希望最终你会得出这样的结论：如果你足够聪明，你就不会自己去做这件事。

Viktor Farcic：好吧，那么假设我们得出了结论，不打算自己做这件事。我们将选择一个现有的平台——那接下来怎么办？我们是不是把老旧的数据库放进 Docker 镜像，然后在 Kubernetes 中部署？

“DevOps 中最大的问题永远是持久化数据。”

—Wian Vos

Wian Vos：哦，天哪！这是个棘手的问题。我想你知道，首先，DevOps 中最大的问题永远是持久化数据，也就是数据库中的数据，其次是传统数据库并不是为了良好配合而设计的。大型企业中的典型数据库非常昂贵，更不用说管理起来是多么的糟糕。所以，我会建议你从公司里先把这些东西剔除出去。

Viktor Farcic：好的，这一点我们达成共识。但对我来说，最让我感兴趣的是，我有种感觉，企业完全没有意识到，在 Kubernetes 之外，它们需要做多少额外的工作才能让事情在里面成功，即使是他们自己应用的情况也是如此。

Wian Vos：这不仅仅是实现问题，也不仅仅是构建 Kubernetes 集群。是第二天和第三天的操作会让你头疼。

Viktor Farcic：这确实非常真实。

Wian Vos：再次强调，并不是说你必须将你做的所有事情都迁移到 Kubernetes 平台。将数据库运行在 Kubernetes 之外完全没问题。问问自己这个问题：你真的需要数据库集群如此高的灵活性吗？你可能需要，但并不是每个人都需要。那么，你真的需要 Kubernetes 吗？我不知道。

Viktor Farcic：但对我来说，这是一个很有意思的问题，因为我不得不问自己，几年后，Kubernetes 还能算是一个选择吗？是的，我们确实可以选择不使用 Kubernetes。但如果其他所有厂商都在 Kubernetes 上发布新版本，那这真的是一个选择吗？

Wian Vos：我认为它应该是一个选择，因为如果它不再是一个选择，那么创新就死了，如果真是那样，我们将不得不为操作系统创造一个全新的生态系统，而这永远不会再发生。但在整个 Kubernetes 场景以及它周围发生的事情中，确实有一些有趣的变化。例如，我们收到了大量关于在裸机上运行 Kubernetes 的问题，我认为这是未来三个月左右的一个大趋势。因为，为什么要在 Kubernetes 上做虚拟化呢？我不知道——告诉我，为什么你想在虚拟机（VM）上运行 kubelet，而不是直接在裸机上运行？

Viktor Farcic：没有什么特别的理由。但另一方面，有些人使用虚拟机，因为他们仍然不知道自己在做什么。

Wian Vos：是的，这非常正确。

Viktor Farcic：我把它看作是一种演变，一旦你真正明白你在做什么，你就会把虚拟化层去掉——但不会在这之前。

Wian Vos：也许吧。我认为其中一个最大的问题是，我们有一代 IT 人才进入这个领域，他们从未在虚拟机以外的地方工作过。

大规模 DevOps 杀手

但是，如果你看看 Kubernetes 和你在做的事情，实际上在上面加一个虚拟化程序是没有任何意义的。因为对 Java 虚拟机（JVM）来说，它本质上是操作系统和应用程序之间的虚拟化层，而你是在容器中运行它。可以说，它就像是一个虚拟的隔离层。这不是虚拟化，但你明白我的意思。然后，如果再在下面加一个虚拟化层，就会导致你把所有的东西从 CPU 和内存中拉得很远。

Viktor Farcic：这可能是对的，但那服务器无状态呢？那是下一个趋势吗？

Wian Vos：我认为无状态就是 DevOps 的最大杀手。

Viktor Farcic：什么意思？

Wian Vos：我认为这基本上和我们在 1990 年代末以及 1970 年代时所做的是一样的。作为开发者，你不希望被操作团队正在做的事情困扰，因此，我们有六到七年的时间，我们大家都在假装共同协作。但现在出现了一个新事物，实际上是一个旧事物，你只需要将代码放进去，设置一个路由，就可以开始了！基本上，它将操作团队的工作抽象化了，因为总还是得有人负责那个无状态系统。

Viktor Farcic：那时，毕竟还是有服务器的。

Wian Vos：是的，这是真的。但记住，还是需要有人来安装和*护它，因为，当然了，无服务器系统永远不会出问题——就像 IT 中的其他任何东西永远不会出问题一样，对吧？我认为这是终结 DevOps 的范式。

这也是我认为无服务器是 DevOps 的“大杀手”的原因。

Viktor Farcic：现在我是在谈论原则层面的东西，而不是具体的实现：我困惑的是，无服务器和 Kubernetes 到底有何真正不同？

Wian Vos：其实并没有真正的不同；这就是关键。我确实想区分一下无服务器范式和实际的无服务器平台。Kubernetes 只是一个强大的无服务器推动者，而无服务器范式则是这样说的：“好了，我是一个开发者，我有代码，我把它放到这里，任务就完成了。”我认为，真正的无服务器平台自从平台即服务（Platform-as-a-Service，PaaS）时代就已经存在。如果你有一个实施得很好的平台即服务，那对于应用开发者来说，使用它简直是显而易见的。

我认为有一个大范式从 DevOps 的阴影中走了出来，并且实际上是有效的：站点可靠性工程（SRE）。拥有一个优秀的 SRE 团队，为你提供一个开发者可以直接使用的平台，真是太棒了。但这算是无服务器吗？我不确定。在 SRE 模型中，你仍然需要一位 SRE 工程师来帮助你将代码集成到平台中。现在，如果你将足够的功能抽象化，开发者就不再需要那位工程师了。那么，嘿，没问题，一个无服务器平台——你不再需要担心服务器了。但不要忘记，背后依然有服务器，而且背后有一个 SRE 团队实际管理着这些东西并在其上进行创新。

所以，对于你作为开发者来说，这变成了无服务器。但随之而来的是，开发者和工程师之间的互动再次丧失了，我认为这将再次阻碍创新，因为没有人会从不和别人交流中变得更好。

Viktor Farcic：没错。当你最初说 DevOps 死了的时候，我很困惑。但现在，我同意了。

Wian Vos：如果没有别的，DevOps 就是应用开发人员和构建平台的工程师之间的沟通。我曾经写过一篇博客文章说过这一点，结果得到了非常糟糕的反馈。所以，让我再明确一下。我不是说仅仅是那种沟通，但我确实认为它是一个非常重要的组成部分。

DevOps 工程师的角色

Viktor Farcic：但如果 DevOps 的重要组成部分是开发人员和运*人员之间的沟通，那么 DevOps 工程师的角色到底是什么？当我看到职位描述时，我觉得 DevOps 工程师的职位目前似乎比其他任何职位都要重要。

Wian Vos：基本上，这只是为了混淆招聘。

Viktor Farcic：还有 DevOps 部门！

*安·沃斯：想象一下，假设你和我要成立一家公司。我们需要一个 DevOps 团队，因为我们有一个迫切的愿望要推出这个超棒的应用程序。然而，在我们的情况下，我们只能雇佣五个人。那么，当我们组建 DevOps 团队时，我们面临的问题是，“我们要雇佣谁？”以及“我们要雇佣什么？”

我们会雇佣 DevOps 工程师吗？不会。在那个团队里，我们需要最优秀的应用开发人员，最优秀的测试人员，也许还有一位优秀的基础设施专家以及前端/后端开发人员。我希望 DevOps 团队里的成员是具有特定角色且能够良好协作的人员。

当 DevOps 成为软件公司的一个营销术语时，招聘也赶上了这一潮流。红帽公司正在组建一个 DevOps 团队，所以我们现在需要一个 DevOps 工程师，招聘团队表示他们会为你找到一个 DevOps 工程师。但正如你所说，对于市场上的许多人来说，这依然是一个非常有吸引力的职位，因为职位名里包含了 DevOps 这个词。在那个人的脑海中，他们不再做工程工作；他们现在做的是 DevOps。

*克托·法尔奇克：在这一点上，我必须感谢敏捷方法。你永远不会看到一位敏捷工程师。

*安·沃斯：不，他们没有 DevOps 工程师，但他们确实有敏捷教练，这其实是另一种说法，就是不穿领带的经理。不过，公平地说，敏捷教练的视角确实与众不同。具体来说，更偏向于辅导和支持，而不是推动和让别人负责。如果你看敏捷和项目管理，敏捷是胡萝卜，而项目管理则是大棒。它们是不同的方式，而我可以告诉你，胡萝卜总是更有效。

*克托·法尔奇克：那么，你的工作就是拜访公司，向他们展示隧道尽头的光明，目标是帮助他们改进。我很好奇，当你拜访公司时，最讨厌的是什么？实现你目标的主要障碍是什么？

*安·沃斯：我认为问题几乎总是出在人身上。我曾经遇到过的最大问题，以及花费我最多时间和精力的事情，就是在实施 DevOps、平台即服务（PaaS）等新型基础设施或新型应用程序使能技术时，许多公司仍然有一批老旧的架构师。这些人实际上是与新技术和平台打交道的，如果他们看到新平台的好处，他们很快就能在新的平台或无服务器平台上运行他们的应用程序（不管你怎么称呼它）。虽然外面有一些很好的架构师，但公司中的架构师则是另一回事，特别是在政府部门。在政府部门，如果你有一个计划，而且这是一个好计划，它只有在那儿发明的才算是好计划。

比如，在一个政府部门，我们基本上在没有架构批准的情况下就开始构建新平台，然后在项目进行到四个月时才去争取架构批准。幸运的是，我们的赞助人位高权重，董事会成员中有足够影响力的人，能够推动这个项目。如果他们没有这样做，整个平台就会被架构师们取消——架构师们可能会说，“是的，但是有一个*细节我们不喜欢”，之类的。就像是，“好吧，我们没有考虑到这个，所以这一定不好。”

还有另一个政府机构，我在那也做了同样的事情。我们让 CTO 告诉我们：“好了，我只希望你们把这个做出来。我不在乎你们怎么做，但要尽最大努力做好，事后再告诉架构师们，完成后把文档交给我。”有很大的可能性，我们实现了一个新特性，三个月后，一个架构师会过来说：“你们没告诉我这个功能已经实现。” 是的，好吧，但我们三个月前就实现了这个功能，而且我们构建的平台非常成功。我的意思是，如果有开发人员来找我们说，“嘿，能不能改这个或那个？”，我们可以在一两次发布中做出更改，发布大概在三周后。但是如果你必须经历整个老派的企业架构过程，那么你就完了；你就没戏了。

Viktor Farcic：是的。我在规划方面也有同样的问题。

Wian Vos：顺便说一下，我曾在几次场合被称为架构师。对我来说，区分一个好架构师和一个普通架构师的标准是，你绝不能设计任何你自己至少无法实现 80%的东西。

Viktor Farcic：这些架构师中有多少人实际在实施东西？我的意思是，我遇到的大多数架构师，他们的工具是微软办公软件——他们在写 Word 文档——而一个成功的架构师是那种能够写超过 200 页文档的人。

Wian Vos：去年，我参加了 CLOUDBUSTING，这是一场由 Software Circus 组织的迷你会议，Software Circus 是我们在荷兰的一个聚会*组。在这次会议上，我听到了一位讲者分享了几个很好的例子，说明当你让传统的 IT 架构师进入公司时，建筑失误是如何发生的。因为你可以写出一份出色的架构文档，交给实际构建的人员，结果发现它根本行不通。特别是在今天的软件世界里，认为你能预见一切是非常自大的。尤其是当你从未亲自构建过它时——你根本不知道什么有效。

“我最喜欢的架构风格是进化式架构。我们需要供应工具，那就选三个工具，先试用一周，真正给它们来一次全面的测试，看看哪些有效。”

—Wian Vos

我最喜欢的架构风格是进化式架构。我们需要进行预配置，所以我们可以选择三个工具，测试一周，真正地把它们用到极限，看看哪个有效。一周结束时，你可以说：“好，这个可以用，但另外两个不行。所以我们就基于这个进行创新。可是，我们要如何实现它？让我们尝试三到四种不同的方式，看看哪个最好，然后在那个基础上创新。”

所以，我真的认为，架构过程不应成为障碍，而且你需要在团队中有架构师。如果你正在运营一个为客户构建平台的 SRE 团队，确保具备架构技能——更重要的是具备架构责任感的人——在这个团队中，与大家一起构建它。就像一个领导工程师一样，有权与团队其他成员一起做决策。

Viktor Farcic：没错。我唯一想补充的是，他们也需要感同身受。我相信如果一个人无法感受到那些决策背后的痛苦，他或她就不应该做任何决策。通常，架构只是，“给你一个图表，帮助你去实现它。”

Wian Vos：没错，但话说回来，最初 DevOps 的核心就是这个。你将一部分业务责任交给一个团队，由他们去构建和运行。所以，如果一个应用程序开发人员写出了有问题的代码，它无法正常运行，那么凌晨两点钟被叫醒的不会是运*人员，而是实际的应用程序开发人员，因为这样，他们会更有动力去构建一个能正常运行的东西。

Viktor Farcic：太棒了。我不想占用你太多时间，但你有什么总结性的评论吗？

Wian Vos：我只想说这一点：在整个 DevOps 讨论中没有绝对的对与错。这更多的是关于我认为 DevOps 已经变成了一种文化推动力，我认为让实际使用和构建平台的人选择他们知道适合公司的东西是非常重要的。但同时，他们也需要被允许在公司内分享他们的知识。

庆祝你的失败

我知道这有点感性，但实际上，了解的一个关键点是也要庆祝你的失败。如果你没有表达自己失败的事实，并探索为什么以及怎样失败，你就错过了一个学习的机会。一旦你开始庆祝失败，人们会不再害怕失败。我还认为，最具创新精神的工程师是那些敢于创新的工程师。

Viktor Farcic：我们只需要说服管理层，在失败时不要解雇员工。

Wian Vos：没错！这是作为经理在 DevOps 中需要进行的最重要的思*转变之一。

Viktor Farcic：但这不就是在接受不可避免的失败吗？是在说你知道自己最终会失败吗？

Wian Vos：没错，但如果你不接受失败，你的团队会替你掩盖问题，他们什么也学不到。或者即使失败的人能学到些什么，其他人也什么都学不到。我想这就是 GitLab 大概一年前做的——admin 55——那件事。

Viktor Farcic：完全正确！在那之后，我对他们的尊敬无法用语言表达。GitLab 是我的英雄，完全是因为他们处理失败的方式。

Wian Vos：他们说，“嘿，我们搞砸了。来，看看我们怎么做的。”

Viktor Farcic：是的，我记得。我在看他们的视频直播，他们修复问题时就像在看一部拉丁美洲肥皂剧。太棒了。

Wian Vos：那太棒了，我认为这应该是大多数公司愿意做的事情。但现在，我们离这个目标还有很长的路要走。

Viktor Farcic：非常长。至少当我访问公司时，我感觉自己还没有资格像那样表现。

Wian Vos：嗯，我得说，在荷兰情况已经在变好。正如我之前所说，我还在美国工作过两年，那里的情况完全不同。

Viktor Farcic：我觉得这里是个很好的停顿点。感谢你的时间，我真的很享受这个过程。

Wian Vos：没问题，非常感谢。

第五十六章

索引

A

亚当·桑多尔

关于 262

关于集群的观点 281

关于使用 DevOps 的观点 262-265

关于 Kubernetes 的观点 270-275

关于 Kubernetes 问题解决的观点 265-267

关于 Red Hat 需求的观点 275-281

关于技术探索的观点 267-270

关于 Ubuntu 需求的观点 275-281

安迪·克莱门科

关于 204

关于公司可视化的观点 207-209

关于 DevOps 的观点 204-207

关于未来的观点 224-229

关于行业诚实的观点 209-229

关于行业中的个性的观点 209-229

现场服务经理协会（AFSM） 1

B

布雷特·费舍尔

关于 392

关于容器使用的观点 402-407

关于 DevOps 的观点 392-399, 416

关于操作系统未来的观点 407-411

关于编程未来的观点 411-415

关于跳过一代的观点 399-402

C

克里斯·赖利

关于 234

自下而上的方法 vs 自上而下的方法 244-247

DevOps 部门 247-252

DevOps 在技术行业中的观点 240-244

DevOps 旅程 256-257

关于 DevOps 的观点 235-238

关于软件外部化的观点 252-256

变革速度，DevOps 5, 6

D

达米安·杜波塔尔

关于 38

关于亚马逊的观点 57-58

关于会议的观点 49-50

关于容器的观点 44-49

关于 DevOps 的观点 38-39

关于 DevOps 用于促进同理心的观点 39-41

关于 Docker 的观点 6-11

关于教育系统的观点 44-49

关于谷歌的观点 56-58

关于微软的观点 56-58

关于软件公司的观点 49-50

关于供应商的观点 49-50

达蒙·爱德华兹

关于 316-318

关于 Agile 的观点 338-339

关于 DevOps 的观点 319-322

关于 DevOps 商业化的观点 322-330

关于公司 Inc 的观点 319-322

关于质量认知的观点 330-334

关于 Rundeck 的观点 319-322

关于票务系统的观点 329-334

关于工作影响的观点 330-334

DevOps

关于 3-6

DevOps 工具包系列 1

参考链接 1

E

EmpathyOps 18

G

格雷戈里·布莱德索

关于 Agile 与 DevOps 的观点 476-481

关于公司环境的观点 460-463

关于公司高层管理的观点 460-463

关于 DevOps 的观点 457-460, 481-483

关于修复数字化转型的观点 471-475

关于 DevOps 未来的观点 484-488

关于代际的观点 460-463

关于启动变革的观点 464-471

J

詹姆斯·特恩布尔

关于 131

关于 DevOps 的观点 130-132

关于 Kubernetes 的观点 137-143

关于微服务的观点 134-137

关于单体架构的观点 134-137

关于 RHEL 的观点 137-143

关于技术栈可用性的观点 132-134

关于 Ubuntu 的观点 137-143

杰夫·萨斯纳

关于 12

关于 Agile 与 DevOps 的观点 29-34

关于 DevOps 的观点 12-16

关于比较 DevOps 的观点 22-26

关于改变 DevOps 文化的观点 26-29

关于 DevOps 同理心的观点 18-22

关于 DevOps 团队环境中的观点 16-18

朱莉娅·比罗

关于 1

关于避免复杂性增加的观点 302-304

关于 DevOps 的观点 295-299

关于 DevOps 概念的观点 304-308

关于定义 DevOps 的观点 287-290

关于灵感瞬间的观点 286-27

关于 SRE 与 DevOps 的观点 291-295

关于技术挑战的看法 299-302

关于技术未来的看法 299-302

Julian Simpson

关于 183

配置管理团队 187-193

DevOps 问题 187-190

DevOps 团队 187-192

DevOps 定义 183-185

DevOps 与敏捷的对比 184-187

基于 UI 的环境 191-193

关于解决供应商锁定问题的看法 196-198

K

Kevin Behr

关于 62

DevOps 之路 63-65

关于成为经理的看法 65

关于弥合 CEO-CTO 差距的看法 68, 69

关于客户端-服务器的看法 67

关于 DevOps 中协作的看法 80-84

关于对人控制的看法 71-72

关于创建社会技术系统的看法 83

关于 DevOps 的看法 62, 63, 67-69

关于 DevOps 模式的看法 98-99

关于 DevOps 团队愿景的看法 85-89

关于 DevOps 中同理心的看法 78, 79

关于看板发明的看法 102, 103

关于 Lean Coffee 方法的看法 90

关于误解 DevOps 的看法 83, 84

关于 DevOps 最佳环境的看法 103-106

关于帕累托原则的看法 77

关于自给自足团队的看法 77

关于丰田的看法 34, 35

关于在《Visible Ops》书中使用 ITIL 语言的看法 69, 70

关于《Visible Ops》书的看法 69

关于阴阳情况的看法 97-98

Kohsuke Kawaguchi

关于 345

关于会议的看法 352

关于容器的看法 350-352

关于 DevOps 的看法 345, 346

关于 DevOps 未来的看法 356-359

关于 DevOps 工具包的看法 345-349

关于开源的看法 353

关于组织影响的看法 345-349

关于美国与中国的看法 354, 355

L

Liz Keogh

关于 148

关于敏捷的看法 160-167

关于行为驱动开发（BDD）的看法 155-160

关于太空中的汽车的看法 175-178

关于 Cynefin 框架的看法 151-155

关于 DevOps 的看法 160-167

关于 DevOps 与敏捷结合的看法 148-151

关于 DevOps 中多样性的看法 171-173

关于培养创新的看法 168-170

关于 DevOps 中性别角色的看法 171-173

关于 DevOps 中表现的看法 171-173

M

Mike Kail

关于 110

关于容器的看法 120-124

关于 DevOps 的看法 124-126

关于 DevOps 云计算的看法 116-120

关于 DevOps 成本的看法 116-120

关于 DevOps 基础设施的看法 116-120

关于迭代的看法 111-113

最*可行产品 (MVP) 161

N

Nirmal Mehta

关于 420

关于应对安全威胁的看法 445, 446

关于决策的看法 430

关于 DevOps 的看法 421, 425, 435, 436

关于 DevOps 工程师的看法 422-426

关于 DevOps 模式的看法 431-434

关于 DevOps 哲学的看法 436, 427

关于未来技术的看法 446-450

关于谷歌 SRE 的看法 428, 429

关于谷歌的 DevOps 的看法 428, 429

关于在安全领域使用 DevOps 的看法 439-445

S

Sean Hull

关于 366

与数据库合作 366, 367

关于应用程序的看法 379, 380

关于 AWS 的看法 380

关于云计算的看法 371, 375, 376

关于容器调度器的看法 381

关于 DBA 的看法 375

关于 DevOps 的看法 380, 381

关于开发数据库执行的看法 371

关于 DevOps 未来的看法 383, 387

关于处理新版本发布的看法 375, 376

关于实施 API 网关更改的看法 370

关于无服务器方法实施的观点 369, 370

关于基础设施的观点 369

关于数据库流程与自动化集成的观点 372-374

关于 Lambda@Edge 的观点 383

关于加载测试用无服务器函数的观点 371

关于迁移工具的观点 8

关于安全性的观点 377, 378

关于 SQL 的观点 371

关于供应商锁定的观点 380

关于零停机时间应用部署的观点 374

Skool

URL 298

Stack Overflow

参考链接 296

T

测试驱动开发（TDD） 7, 155

V

虚拟私有云（VPC） 132

W

Wian Vos

关于 492

关于敏捷方法的观点 495-497

关于敏捷教练的观点 511

关于云计算的观点 500

关于云供应商的观点 501

关于 DevOps 的观点 492, 493

关于 DevOps 挑战的观点 494, 495

关于 DevOps 工程师角色的观点 510-515

关于 DevOps 实施的观点 493, 494

关于企业问题的观点 505

关于 Kubernetes 的观点 508, 509, 513-516

关于 Kubernetes Ingress 的观点 503

关于本地部署的观点 501

关于 Kubernetes 版本选择的观点 502, 503

关于无服务器架构的观点 508-510