与 Jeff Smith 一起粉碎播客第 42 集：什么是 DevOps？

在本集中，我们将讨论 DevOps。 它是什么，它是添加到您的 Web 开发弓的字符串吗？ 德鲁麦克莱伦与专家杰夫史密斯交谈以找出答案。

显示注释

• 杰夫在推特上
• Jeff 的书运维反模式，DevOps 解决方案
• 可实现的 DevOps

每周更新

• 弥合设计师和开发人员之间的鸿沟，作者：Matthew Talebi
• Gaurav Khanna 编写的用于使用 TypeScript 构建灵活组件的有用 React API
• Cosima Mielke 编写的针对常见 UI 挑战的智能 CSS 解决方案
• Nataliya Samir 撰写的评估 UX/UI 设计师的提示和技巧
• 在由 Arijit Mondal 编写的 Next.js 支持的电子商务网站中解决 CLS 问题

成绩单

Drew McLellan：他是一名 DevOps 实践者，专注于 DevOps 实施的可达到水平，无论您处于旅程的哪个阶段。 他是数字广告平台 Centro 的生产运营总监，同时也是一名公开演讲者，与全球观众分享他的 DevOps 知识。 他是《Operations Anti-Patterns, DevOps Solutions for Manning Publishing》一书的作者，该书展示了如何在大多数开发人员工作的那种不完美的环境中实施 DevOps 技术。所以我们知道他是 DevOps 方面的专家，但你认识 George克鲁尼认为他是一代人最好的纸飞机制造商？ 我的 Smashing 朋友，请欢迎 Jeff Smith。 嗨杰夫。 你好吗？

杰夫·史密斯：德鲁，我太棒了，你好吗？

德鲁：我很好。 谢谢你。 听起来还不错。 所以我今天想和你谈谈 DevOps 的主题，这是你的主要关键领域之一。 我们的许多听众将参与 Web 和应用程序开发，但可能只对操作方面发生的事情不太熟悉。 我知道我们这些可能在大公司工作的人会有整个团队在做运营。 我们很感激，无论他们做什么，他们都做得很好。 但是我们听到越来越多的 DevOps 被提及，感觉就像是开发人员应该真正理解的事情之一。 那么 Jeff，什么是 DevOps？

Jeff：所以如果你问 20 个人什么是 DevOps，你可能会得到 20 个不同的答案。 所以我会告诉你我的看法，好吧，并且知道如果你在一个会议上提到这个，你可能会和某人打架。 但对我来说，DevOps 真的是关于两者之间的关系，我们专注于开发和运维，但实际上是团队间的关系以及我们如何构建我们的工作，更重要的是，构建我们的目标和激励机制以确保它们是一致，以便我们朝着共同的目标努力。 DevOps 的许多核心思想和概念都来自旧世界，在旧世界中，dev 和 ops 一直是对抗性的，那里存在着不断的冲突。 当你考虑到这一点时，这是因为这两支球队的激励方式。 一个团队被激励推动变革。 另一个团队被激励保持稳定性，这意味着更少的变化。

杰夫：当你这样做时，你就会产生这种固有的冲突，一切都会从那里溢出来。 因此，DevOps 真正是为了使这些团队和目标保持一致，以便我们朝着共同的战略努力，但同时也采用双方的实践，以便开发人员更多地了解运维，运维人员更多地了解开发，以此作为获取和分享的一种方式彼此同理心，以便我们了解对方来自何处的观点。

杰夫：但同时也是为了加强我们的工作。 因为再一次，如果我理解你的观点并在我的工作中考虑到这一点，这对我们每个人都会更有利。 在自动化方面，运维人员可以从开发人员那里学到很多东西，以及我们如何处理事情以使它们易于重现。 所以就是这种融合和技巧。 你现在看到的是这适用于不同的组组合，所以你听到的是 DevSecOps、DevSecFinOps、DevSecFinHROps 之类的东西。 它只会继续增长、增长和增长。 因此，这确实是一个我们可以在整个组织中消除的教训。

Drew：因此，它采用了我们作为开发人员所理解的一些概念，并将我们的想法进一步传播到组织中，同时从运营中学习我们可以做些什么来尝试推动每个人前进。

杰夫：当然，是的。 运维的另一个方面，你在介绍中提到了一点，我们认为这只是针对这些拥有专门运维团队的大型组织和类似的东西，但要考虑的一件事是运维正在你的组织中发生，无论大小。 这只是你在做的问题，或者是否有一个单独的团队在做，但不知何故你正在部署代码。 不知何故，您有一台服务器在某处运行。 因此，无论规模大小，运营都存在于您组织的某个地方。 问题是，谁在做？ 如果它是一个人或一个团队，那么 DevOps 对你来说甚至可能更加突出，因为你需要了解 ops 所做的事情的类型。

Drew：作为专业的开发人员，您认为掌握 DevOps 是什么以及实施它的意义对我们来说有多重要？

Jeff：我认为这非常重要，尤其是在 DevOps 旅程的这个阶段。 我认为这很重要的原因是，当我们再次了解同行在做什么时，我认为我们总是更有效率。 但另一件事是能够在您的设计开发和任何技术的实施过程中考虑运营问题。 因此，我在职业生涯中学到的一件事是，即使我认为开发人员是宇宙的主人，并且了解与计算机有关的一切，但事实并非如此。 事实证明，他们在理解方面将很多事情外包给了运维人员，有时这会导致特定的设计选择或实施选择可能不是生产部署的最佳选择。

杰夫：他们在开发和测试之类的事情上可能还不错，但是一旦你投入生产，那就有点不同了。 所以并不是说他们需要拥有一整套专业知识，但他们至少需要知道足够多的知识来知道他们不知道的东西。 所以他们知道何时尽早参与运营，因为这是我们看到的一种常见模式，即开发做出选择。 我什至不会说做出选择，因为他们甚至没有意识到这是一个选择，但是发生了一些事情导致了对操作的次优决策，而开发人员完全没有意识到。 因此，只要对 ops 有更多的了解，即使这足以说明，也许我们应该让 ops 参与进来，以便在我们继续前进之前了解他们的观点。 显然，这可以节省大量时间、精力和稳定性，因为它与您发布的任何产品有关。

Drew：我看到与您谈论开发与运营之间的关系的方式有很多相似之处，就像我们在设计与开发之间的关系一样，您让设计师研究界面的工作原理和外观，并有很好的理解开发角色实际上将如何构建，并且让开发人员参与咨询可以真正改善整体解决方案，只需进行清晰的沟通和了解彼此的工作即可。 似乎这与 DevOps 的原理相同，真的非常好听。

Drew：当我想到我听到的关于 DevOps 的事情时，我会听到诸如 Kubernetes、Docker、Jenkins、CircleCI 之类的术语。 多年来我一直听说 Kubernetes。 我仍然不知道它是什么，但从你所说的来看，DevOps 似乎不仅仅是……我们在这里不只是在谈论工具，是吗？ 但是更多关于工作流程中的流程和沟通方式，对吗？

杰夫：当然。 因此，过去 20 年我的口头禅一直是人员流程工具。 你让人们接受愿景。 从那里，您可以定义实现该愿景的流程。 然后你带来可以为你的流程建模的工具。 所以我总是把工具放在 DevOps 对话的最后，主要是因为如果你没有那种支持，那也没关系。 我可以想出有史以来最伟大的持续部署管道，但是如果人们不接受将每个更改直接交付到生产环境的想法，那也没关系，对吧？ 工具有什么用？ 因此，这些工具绝对是对话的一部分，只是因为它们是满足我们定义的一些共同目标的标准化方式。

Jeff：但是你必须确保那些被定义的目标对你的组织有意义。 也许持续部署对您没有意义。 也许您不想在每一个更改出现的那一刻就将其发送出去。 并且有很多公司和组织以及您不想这样做的原因。 所以也许像持续部署管道这样的东西对你来说没有意义。 因此，虽然工具很重要，但更重要的是关注将为您的组织带来价值的东西，然后建模和实施实现这一目标所必需的工具。

Jeff：但是不要上网去了解每个人都在做什么，哦，好吧，如果我们要做 DevOps，我们必须切换到 Docker 和 Kubernetes，因为那是工具链。 不，不是这样。 你可能不需要这些东西。 不是每个人都是谷歌。 不是每个人都是 Netflix。 停止阅读 Netflix 和 Google 的帖子。 请停止阅读它们。 因为它让人们都很兴奋，他们就像，这就是我们要做的。 就像，嗯，他们解决的问题与你遇到的问题截然不同。

德鲁：所以如果说我正在开始一个新项目，也许我是一家初创企业，将软件作为一种服务产品。 我有三个开发人员，我有一个空的 Git 存储库，我有 IPO 的梦想。 要完全采用 DevOps 方法来构建这个产品，我应该在人员和流程方面拥有哪些构建块的名称，我应该从哪里开始？

杰夫：所以在你的具体例子中，我首先要开始的是尽可能多地使用它，并使用像 Heroku 这样的东西或类似的东西。 因为你对所有这些 AWS 的东西、Docker 的东西感到非常兴奋，而实际上，仅仅构建一个成功的产品是如此困难。 您专注于其中的 DevOps 部分的想法就像，我会说尽可能多地外包这些东西，直到它真正成为一个痛点。 但如果你在那个时候你说好的，我们已经准备好把这些东西带入内部，我们已经准备好把它带到一个新的水平。 我想说首先要开始的是，你的痛点在哪里？ 是什么导致了你的问题？

Jeff：所以对某些人来说，这就像自动化测试一样简单。 嘿，每次有人提交时我们都需要运行测试的想法，因为有时我们正在运送被我们已经编写的单元测试捕获的东西。 那么也许你从持续集成开始。 也许您的部署需要几个小时才能完成，而且它们非常手动，那么这就是您关注的地方，您会说，好吧，我们需要什么自动化才能使其成为一键式点击事件？ 但我讨厌开一个通用的，这是你开始的地方，只是因为你的特定情况和你的特定痛点会有所不同。 问题是，如果这是一个痛点，它应该对你大喊大叫。 它绝对应该对你大喊大叫。

杰夫：这应该是有人说，哦，你的组织有什么糟糕的事情之一？ 它应该是，哦，我确切地知道那是什么。 因此，当您从这个角度处理它时，我认为接下来的步骤对您来说非常明显，您需要解压缩并开始使用 DevOps 工具箱中的哪些内容。 然后这些最小的增量变化不断出现，你注意到随着你获得新的能力，你对不合格的东西的胃口变得非常小。 所以你从喜欢，哦，是的，部署需要三个小时，这没关系。 你付出了一些努力，接下来你知道，在三周内，你就像，伙计，我不敢相信部署仍然需要 30 分钟。 我们如何从 30 分钟缩短这个时间？ 你对改善的胃口变得贪得无厌。 所以事情就是从那里溢出来的。

Drew：我一直在阅读您最近的书，其中突出了您所说的 DevOps 的四大支柱。 如前所述，它们都不是工具，但如果您愿意的话，对于 DevOps 来说，有这四个主要关注领域。 我注意到其中的第一个是文化，我对此感到非常惊讶，首先，因为我期待你更多地谈论工具，现在我们明白为什么了，但是说到文化，这似乎很奇怪一开始就有的东西。 有一个技术方法的基础。 文化如何影响组织内 DevOps 实施的成功程度？

Drew： ……DevOps 实施在组织内的成功程度。

杰夫：当你想到它时，文化真的是一切的基石。 这很重要，因为文化，我们在书中更深入地探讨了这一点，但文化确实为组织内的规范奠定了基础。 正确的。 你可能去过一家公司，如果你提交了没有自动化测试的 PR，那并不是什么大事。 人们接受它并继续前进。

杰夫：但是还有其他一些组织，这是一个大罪。 正确的。 如果你这样做了，就像，“哇，你疯了吗？ 你在干嘛？ 这里没有测试用例。” 正确的。 不过那是文化。 这种文化正在强制执行这种规范，比如“这不是我们所做的”。

Jeff：任何人都可以写一份文件说我们将拥有自动化测试用例，但是组织的文化是在人们中强制执行该机制的原因。 这只是文化为何如此重要的一个小例子。 如果你有一个组织，文化是一种恐惧文化，一种报复文化。 这就像如果你犯了一个错误，对，那就是亵渎。 正确的。 这无异于叛国。 正确的。

杰夫：您在该组织中创建了对任何可能有风险或可能失败的事情不利的行为。 这最终会在桌面上留下很多机会。 然而，如果你创造一种从失败中学习的文化，就会接受这种心理安全的理念，人们可以在其中进行实验。 如果他们错了，他们可以弄清楚如何安全地失败并重试。 你会得到一种实验文化。 你会得到一个人们对新想法持开放态度的组织。

杰夫：我想我们都曾在那些公司工作过，“嗯，这就是它的做法。 没有人能改变这一点。” 正确的。 你不希望这样，因为世界在不断变化。 这就是为什么我们把文化放在首位和中心，因为组织内的许多行为都是因为存在的文化而存在的。

杰夫：问题是，文化演员可能是好是坏。 正确的。 具有讽刺意味的是，我们在书中也谈到了这一点，改变组织文化并不需要像你想象的那么多人。 正确的。 因为大多数人，有批评者，然后有支持者，然后在涉及任何形式的变化时，还有围观者。 大多数人都是围栏保姆。 正确的。 只需要少数支持者就可以真正扭转局面。 但从同样的意义上说，实际上也只需要少数批评者就可以倾斜天平。

杰夫：就像，改变文化并不需要太多。 如果你把精力投入其中，即使不是高级领导，你也可以真正影响团队文化，最终影响部门文化，最终影响组织文化。

杰夫：作为个人贡献者，您可以做出这些文化变革，只需大声支持这些想法和这些行为并说：“这些就是我们从中获得的好处。” 这就是为什么我认为文化必须放在首位，因为你必须让每个人都接受这个想法，他们必须明白，作为一个组织，这将是值得的并支持它。

德鲁：是的。 我想，这一定是一种生活方式。

杰夫：没错。

德鲁：是的。 我对自动化领域真的很感兴趣，因为在我的职业生涯中，我从未见过一些已经实施的自动化没有带来好处。 正确的。 我的意思是，除了奇怪的事情之外，也许有些事情是自动化的并且出了问题。 一般来说，当你花时间坐下来自动化你一直在手动做的事情时，它总是可以节省你的时间，节省你的头部空间，而且它只是减轻你的负担。

Drew：在采用 DevOps 方法时，您希望在工作流程中实现哪些自动化？ 您希望从手动完成任务中看到什么收益？

杰夫：谈到自动化，就你的观点而言，很少有自动化没有让生活变得更好的时候。 正确的。 人们遇到的困难是找时间建立自动化。 正确的。 通常，在我目前的工作中，对我们来说，这实际上是请求的重点。 正确的。 因为在某些时候你必须说，“我将停止手动执行此操作，我将使其自动化。”

杰夫：可能必须在你收到请求时说，“你知道吗？ 这需要两周时间。 我知道我们通常会在几个小时内完成它，但这需要两周时间，因为这是自动化的请求。” 在确定您自动化的内容方面。 在 Central，我使用的流程基本上是对四个星期内收到的所有不同类型的请求进行抽样，比方说。 我会将它们归类为计划内工作、计划外工作、增值工作、辛勤工作。 辛勤工作并不是真正有用的工作，但出于某种原因，我的组织必须这样做。

杰夫：然后确定那些类似的东西，“好吧，如果我们要实现自动化，我们可以摆脱的低垂果实是什么？ 我们能做些什么来简化这一点？” 一些标准是过程的风险。 正确的。 自动数据库故障转移有点可怕，因为您不经常这样做。 和基础设施的变化。 正确的。 我们说，“我们多久做一次这件事？” 如果我们每年做一次，它可能不值得自动化，因为它的价值很小。 但是，如果这是我们每月获得两到三次的那些东西之一，好吧，让我们来看看。 好的。

杰夫：现在，我们可以做些什么来加快速度？ 问题是，当我们谈论自动化时，我们立即跳到，“我要点击一个按钮，这件事就会神奇地完成。” 正确的。 但是，如果您感到不适，您可以在自动化中执行许多不同的步骤。 正确的。 例如，假设您有 10 个步骤和 10 个您通常会运行的不同 CLI 命令。 自动化的第一步可能很简单，例如运行该命令，或者至少显示该命令。 正确的。 说，“嘿，这就是我要执行的。 你觉得还行吗？” “是的。” “好的。 这是我得到的结果。 我可以继续吗？” “是的。” “好的。 这就是我得到的结果。” 正确的。

杰夫：这样你仍然有一点控制权。 你觉得舒服。 然后在 20 次处决之后，你意识到你只是在击中，是的，是的，是的，是的，是的，是的。 你说：“好吧。 让我们把所有这些东西都串起来，把它们都变成一个。” 这并不是说您必须跳入其中，单击它并立即忘记它。 你可以踏入这一步，直到你感到舒服为止。

杰夫：这些是我们作为自动化工作的一部分所做的事情，很简单，我们如何加快这方面的周转时间并减少我们的工作量？ 第一天可能不是 100%，但目标始终是达到 100%。 我们将从小块开始，我们将自动化其中我们觉得舒服的部分。 是的。 我们非常有信心这会奏效。 这部分我们有点冒险，所以也许我们会在继续之前进行一些人工验证。

Jeff：我们在谈论自动化方面看到的另一件事是，我们为特定流程增加了什么价值？ 这对于运维来说尤其重要。 因为很多时候 ops 充当了流程的中间人。 那么他们的参与无非是一些接入的事情。 正确的。 这就像，好吧，ops 必须这样做，因为 ops 是唯一有权访问的人。

杰夫：嗯，这就像，嗯，我们如何将访问外包，以便人们可以做到？ 因为现实是，我们并不担心开发人员拥有生产访问权限。 正确的。 我们担心开发人员拥有不受限制的生产访问权限。 这确实是一件安全的事情。 正确的。 就好像我的工具箱里只有锋利的刀，我会非常小心把它送给谁。 但是，如果我可以将工具箱与勺子和锤子混合在一起，以便人们可以为工作选择合适的工具，那么将其借出会容易得多。

Jeff：例如，我们有一个流程，人们需要在生产环境中运行临时 Ruby 脚本，无论出于何种原因。 正确的。 需要清理数据，需要更正一些不良记录，等等。 这总是会通过我的团队来实现。 就像，好吧，我们没有为此增加任何价值，因为我无法批准这张票。 正确的。 我不知道。 你编写了软件，所以我坐在你的肩膀上说“嗯，我认为那是安全的”有什么好处？ 正确的。 我没有为输入添加任何价值，因为我只是在输入您告诉我输入的内容。 正确的。

杰夫：最坏的情况，最后，我真的只是你的路障，因为你正在提交一张票，然后你在等我吃完午饭回来。 我吃完午饭回来了，但我还有其他事情要做。 我们说：“我们如何实现自动化，以便将其交到开发人员手中，同时解决我们可能遇到的任何这些审计问题？”

Jeff：我们把它放在 JIRA 工作流程中，我们有一个机器人可以自动执行 JIRA 票证中指定的命令。 然后我们可以在 JIRA 票证中指定它需要几位高级工程师之一的批准。 正确的。

杰夫：更有意义的是，一名工程师正在批准另一名工程师的工作，因为他们有上下文。 正确的。 他们不必坐在那里等待操作。 审计部分得到了答复，因为我们已经在 J​​IRA 中定义了一个清晰的工作流程，该工作流程正在记录为有人批准，有人要求。 我们有自动化功能，可以在终端中提取该命令并逐字执行该命令。 正确的。

杰夫：你不必担心我打错了。 你不用担心我抢错票了。 这增加了这些门票的周转时间，大约是十倍。 正确的。 开发人员畅通无阻。 我的团队并没有被束缚在这方面。 真正需要一周或两周的投资来实际开发自动化和让他们访问所需的许可。

杰夫：现在我们完全摆脱了这一点。 开发实际上能够将其中一些功能外包给组织的较低部分。 他们已将其推送给客户服务。 就像现在，当客户服务知道此记录需要更新时，他们不需要开发。 他们可以提交我们已批准用于此功能的标准脚本。 他们可以通过与开发完全相同的工作流程来运行它。 这真的是一个福音。

杰夫：然后它允许我们在整个组织中将工作推得越来越低。 因为当我们这样做时，工作变得越来越便宜，因为我可以让一个花哨的、昂贵的开发人员来运行它。 正确的。 或者我可以让一个直接与客户合作的客户服务人员，在他们与客户通电话时自己运行它，让客户纠正问题。

Jeff：我认为自动化是任何组织的关键。 我要说的最后一点是，它还允许您输出专业知识。 正确的。 现在，如果我需要在命令行上执行一堆命令，我可能是唯一知道如何执行此操作的人。 但如果我把它放在自动化中，我可以把它交给任何人。 人们知道最终结果是什么，但他们不需要知道所有的中间步骤。 通过将其推向组织并利用我的专业知识并将其编码为可出口的东西，我将我的价值提高了十倍。

Drew：您谈到了自动化频繁发生的任务。 是否有一个论据支持自动化任务的发生频率如此之低，以至于开发人员需要很长时间才能恢复其应该如何工作的速度？ 因为大家都忘记了。 已经这么久了。 已经一年了，也许以前没有人这样做过。 是否也有将这些事情自动化的论据？

杰夫：这是一个艰难的平衡行为。 正确的。 我总是说逐案处理。 我这么说的原因是，DevOps 的信条之一是，如果有痛苦，那就更频繁地去做。 正确的。 因为你做的次数越多，肌肉记忆就越多，你就可以锻炼并消除这些扭结。

Jeff：我们看到的自动化非常罕见的任务的问题是，环境的格局往往会在自动化执行之间发生变化。 正确的。 最终发生的是您的代码对环境做出了特定的假设，而这些假设不再有效。 因此，无论如何，自动化最终都会崩溃。

德鲁：然后你有两个问题。

杰夫：对。 正确的。 确切地。 确切地。 你会说，“我打错了吗？ 或者是这个？ 不，这东西居然坏了。” 所以-

杰夫：打错了，或者这不是，这东西实际上坏了。 因此，当涉及到不经常执行的任务的自动化时，我们真的会逐个案例来了解，如果这不起作用，会有什么风险，对吧。 如果我们弄错了，是我们状态不好还是只是我们没有完成这项任务？ 因此，如果您可以确保这会优雅地失败并且不会产生负面影响，那么值得尝试将其自动化。 因为至少，你有一个理解应该发生什么的框架，因为至少，有人将能够阅读代码并理解，好吧，这就是我们正在做的事情。 而且我不明白为什么这不再起作用，但我清楚地了解至少在编写本文时的设计时应该发生什么。

Jeff：但是，如果您遇到故障可能导致数据更改或类似情况的情况，我通常会谨慎行事并保持手动操作，因为如果我有自动化脚本，如果我找到了一些 confluence 文档那个说运行这个脚本已经三年了，我倾向于对那个脚本有百分之一百的信心并执行它。 正确的。 然而，如果它是四年前记录的一系列手动步骤，我会说，我需要在这里做一些验证。 正确的？ 让我稍微介绍一下，并与几个人交谈。 有时当我们设计流程时，强制这个思考过程是值得的，对吧？ 你必须考虑人类的组成部分以及他们将如何表现。 有时值得让这个过程变得更麻烦一点，迫使人们认为我现在应该这样做吗？

Drew：还有其他方法可以通过监控系统和测量事物来识别应该自动化的内容吗？ 我的意思是，我认为 DevOps 并且我认为仪表板是其中之一，漂亮的图表。 而且我确信这些仪表板不仅仅是看起来漂亮，但拥有漂亮的仪表板总是很好的。 有没有办法衡量一个系统在做什么，以帮助你做出这些决定？

杰夫：当然。 对凸轮的指标部分进行这种划分，对，我们在系统中跟踪哪些内容以了解它们是否有效运行？ 指标的常见缺陷之一是我们寻找错误而不是验证成功。 这是两种截然不同的做法，对吧？ 因此，某些东西可能会流经系统，不一定会出错，但不一定会按照应有的方式完成整个过程。 因此，如果我们将一条消息放到消息队列中，则应该有一个相应的指标显示“并且这条消息已被检索和处理”，对吗？ 如果不是，对，你很快就会出现不平衡，并且系统无法按应有的方式工作。 我认为我们可以使用指标作为一种方式来理解当我们进入那些糟糕的状态时应该自动化的不同事物。

杰夫：对吧？ 因为很多时候这是一个非常简单的步骤，需要采取清理措施，对吧？ 对于已经操作一段时间的人，对，磁盘空间警报，每个人都知道这一点。 哦，我们装满了光盘。 哦，我们忘记了它是月末和计费运行和计费总是填满日志。 然后 VAR 日志正在消耗所有磁盘空间，因此我们需要运行日志轮换。 正确的？ 如果这是你的偏好，你可以在凌晨三点起床。 但如果我们知道那是行为，我们的指标应该能够为我们提供线索。 我们可以简单地自动化日志轮换命令，对吧？ 哦，我们已经达到了这个阈值，执行日志轮换命令。 让我们看看警报是否清除。 如果是这样，继续生活。 如果没有，那么也许我们会叫醒某人，对吧。

Jeff：你在基础设施自动化方面也看到了更多，对，就像，“嘿，我们每秒的请求是否达到了我们的理论最大值。 也许我们需要扩展集群。 也许我们需要在负载均衡池中添加三四个节点。” 我们可以做到这一点，而不一定需要有人干预。 我们可以只查看这些指标并采取行动，然后在基础设施低于特定阈值时收缩该基础设施，但是您必须拥有这些指标，并且您必须将这些挂钩连接到您的监控环境中才能做到这一点。 这就是对话的整个指标部分的来源。

杰夫：另外，能够与其他人分享这些信息也很好，因为一旦你有了数据，你就可以开始在一个共享的现实中谈论事情，对，因为忙碌是一个通用术语，但每秒 5,200 个请求已经很多了更具体，我们都可以推理。 而且我经常认为，当我们就容量或任何事情进行对话时，我们会使用这些随意的术语，而相反，我们可以查看仪表板并给出非常具体的值并确保每个人都可以访问这些仪表板，即它们并没有隐藏在某些只有我们出于某种未知原因才能访问的操作墙后面。

Drew: So while sort of monitoring and using metrics as a decision-making tool for the businesses is one aspect of it, it sounds like the primary aspect is having the system monitor itself, perhaps, and to respond maybe with some of these automations as the system as a whole gives itself feedback on onto what's happening.

Jeff: Absolutely. Feedback loops are a key part of any real system design, right, and understanding the state of the system at any one time. So while it's easy in the world where everything is working fine, the minute something goes bad, those sorts of dashboards and metrics are invaluable to have, and you'll quickly be able to identify things that you have not instrumented appropriately. 正确的。 So one of the things that we always talk about in incident management is what questions did you have for the system that couldn't be answered, right. So what is it, or you're like, “Oh man, if we only knew how many queries per second were going on right now.” 正确的。

Jeff: Well, okay. How do we get that for next time? How do we make sure that that's radiated somewhere? And a lot of times it's hard when you're thinking green field to sit down and think of all the data that you might want at any one time. But when you have an incident, it becomes readily apparent what data you wish you had. So it's important to sort of leverage those incidents and failures and get a better understanding of information that's missing so that you can improve your incident management process and your metrics and dashboarding.

Drew: One of the problems we sometimes face in development is that teammate members, individual team members hold a lot of knowledge about how a system works and if they leave the company or if they're out sick or on vacation, that knowledge isn't accessible to the rest of the team. It seems like the sort of DevOps approach to things is good at capturing a lot of that operational knowledge and building it into systems. So that sort of scenario where an individual has got all the information in their head that doesn't happen so much. 这是一个公平的评价吗？

Jeff: It is. I think we've probably, I think as an industry we might have overstated its efficacy. And the only reason I say that is when our systems are getting so complicated, right? Gone are the days where someone has the entire system in their head and can understand it from beginning to end. Typically, there's two insidious parts of it. One, people typically focus on one specific area and someone doesn't have the whole picture, but what's even more insidious is that we think we understand how the system works. 正确的。 And it's not until an incident happens that the mental model that we have of the system and the reality of the system come into conflict. And we realize that there's a divergence, right? So I think it's important that we continuously share knowledge in whatever form is efficient for folks, whether it be lunch and learns, documentation, I don't know, presentations, anything like that to sort of share and radiate that knowledge.

Jeff: But we also have to prepare and we have to prepare and define a reality where people may not completely understand how the system works. 正确的。 And the reason I think it's important that we acknowledge that is because you can make a lot of bad decisions thinking you know how the system behaves and being 100% wrong. 正确的。 So having the wherewithal to understand, okay, we think this is how the system works. We should take an extra second to verify that somehow. 正确的。 I think that's super important in these complicated environments in these sprawling complex microservice environments. Whereas it can be very, it's easy to be cavalier if you think, oh yeah, this is definitely how it works. And I'm going to go ahead and shut the service down because everything's going to be fine. And then everything topples over. So just even being aware of the idea that, you know what, we may not know a hundred percent how this thing works.

Jeff: So let's take that into account with every decision that we make. I think that's key. And I think it's important for management to understand the reality of that as well because for management, it's easy for us to sit down and say, “Why didn't we know exactly how this thing was going to fail?” And it's like, because it's complicated, right, because there's 500 touch points, right, where these things are interacting. And if you change one of them, it changes the entire communication pattern. So it's hard and it's not getting any easier because we're getting excited about things like microservices. We're getting excited about things like Kubernetes. We're giving people more autonomy and these are just creating more and more complicated interfaces into these systems that we're managing. And it's becoming harder and harder for anyone to truly understand them in their entirety.

Drew: We've talked a lot about a professional context, big organizations and small organizations too. But I know many of us work on smaller side projects or maybe we volunteer on projects and maybe you're helping out someone in the community or a church or those sorts of things. Can a DevOps approach benefit those smaller projects or is it just really best left to big organizations to implement?

Jeff: I think DevOps can absolutely benefit those smaller projects. And specifically, because I think sort of some of the benefits that we've talked about get amplified in those smaller projects. 正确的？ So exporting of expertise with automation is a big one, right? If I am… Take your church example, I think is a great one, right? If I can build a bunch of automated tests suites to verify that a change to some HTML doesn't break the entire website, right, I can export that expertise so that I can give it to a content creator who has no technical knowledge whatsoever. 正确的。 They're a theologian or whatever, and they just want to update a new Bible verse or something, right. But I can export that expertise so that they know that I know when I make this content change, I'm supposed to run this build button.

Jeff: And if it's green, then I'm okay. And if it's red, then I know I screwed something up. 正确的。 So you could be doing any manner of testing in there that is extremely complicated. 正确的。 It might even be something as simple as like, hey, there's a new version of this plugin. And when you deploy, it's going to break this thing. 正确的。 So it has nothing to do with the content, but it's at least a red mark for this content creator to say “Oh, something bad happened. I shouldn't continue. 正确的。 Let me get Drew on the phone and see what's going on.” 正确的。 And Drew can say, “Oh right. This plugin is upgraded, but it's not compatible with our current version of WordPress or whatever.” 正确的。 So that's the sort of value that we can add with some of these DevOps practices, even in a small context, I would say specifically around automation and specifically around some of the cultural aspects too.

Jeff: Right? So I've been impressed with the number of organizations that are not technical that are using get to make changes to everything. 正确的。 And they don't really know what they're doing. They just know, well, this is what we do. This is the culture. And I add this really detailed commit message here. And then I push it. They are no better than us developers. They know three get commands, but it's the ones they use over and over and over again. But it's been embedded culturally and that's how things are done. So everyone sort of rallies around that and the people that are technical can take that pattern.

Jeff: … around that and the people that are technical can take that pattern and leverage it into more beneficial things that might even be behind the scenes that they don't necessarily see. So I think there's some value, definitely. It's a matter of how deep you want to go, even with the operations piece, right? Like being able to recreate a WordPress environment locally very easily, with something like Docker. They may not understand the technology or anything, but if they run Docker Compose Up or whatever, and suddenly they're working on their local environment, that's hugely beneficial for them and they don't really need to understand all the stuff behind it. In that case, it's worthwhile, because again, you're exporting that expertise.

Drew: We mentioned right at the beginning, sort of putting off as much sort of DevOps as possible. You mentioned using tools like Heroku. And I guess that sort of approach would really apply here on getting started with, with a small project. What sort things can platforms like Heroku offer? I mean, obviously, I know you're not a Heroku expert or representative or anything, but those sorts of platforms, what sort of tools are they offering that would help in this context?

Jeff: So for one, they're basically taking that operational context for you and they're really boiling it down into a handful of knobs and levers, right? So I think what it offers is one, it offers a very clear set of what we call the yellow brick road path, where it's like, “If you go this route, all of this stuff is going to be handled for you and it's going to make your life easier. If you want to go another route, you can, but then you got to solve for all this stuff yourself.” So following the yellow brick road route helps because one, they're probably identifying a bunch of things that you hadn't even thought of. So if you're using their database container or technology, guess what? You're going to get a bunch of their metrics for free. You're going to get a lot of their alerting for free. You didn't do anything. You didn't think anything. It's just when you need it, it's there. And it's like, “Oh wow, that's super are helpful.”

Jeff: Two, when it comes to performance sizing and flexibility, this becomes very easy to sort of manage because the goal is, you're a startup that's going to become wildly successful. You're going to have hockey stick growth. And the last thing you necessarily really want to be doing is figuring out how to optimize your code for performance, while at the same time delivering new features. So maybe you spend your way out of it. You say, “Well, we're going to go up to the next tier. I could optimize my query code, but it's much more efficient for me to be spending time building this next feature that's going to bring in this new batch of users, so let's just go up to the next tier,” and you click button and you move on.

Jeff: So being able to sort of spend your way out of certain problems, I think it's hugely beneficial because tech debt gets a bad rap, but tech debt is no different than any debt. It's the trade off of acquiring something now and dealing with the pain later. And that's a strategic decision that you have to make in every organization. So unchecked tech debt is bad, right? But tech debt generally, I think, is a business choice and Heroku and platforms like that enable you to make that choice when it comes to infrastructure and performance.

Drew: You've written a book, Operations, Anti-Patterns, DevOps Solutions, for Manning. I can tell it's packed with years of hard-earned experience. The knowledge sort of just leaps out from the page. And I can tell it's been a real labor of love. It's packed full of information. Who's your sort of intended audience for that book? Is it mostly those who are already working in DevOps, or is it got a broader-

Jeff: It's got a broader… So one of the motivations for the book was that there were plenty of books for people that we're already doing DevOps. 你知道我的意思？ So we were kind of talking to ourselves and high-fiving each other, like, “Yeah, we're so advanced. 惊人的。” But what I really wanted to write the book for were people that were sort of stuck in these organizations. I don't want to use the term stuck. That's unfair, but are in these organizations that maybe aren't adopting DevOps practices or aren't at the forefront of technology, or aren't necessarily cavalier about blowing up the way they do work today, and changing things.

杰夫：我想写信给他们，主要是个人贡献者和中层管理人员说，“你不需要成为 CTO 就能做出这些渐进式的改变，你也不必拥有这个整个销售革命能够获得 DevOps 的一些好处。” 所以这真的是一封写给他们的情书，比如，“嘿，你可以分段完成。 你可以自己做。 你可能认为所有这些都与 DevOps 无关，因为你将其视为工具和 Kubernetes。” 不是每个组织……如果你是纽约州，就像州政府一样，你不会一夜之间进来并实施 Kubernetes。 正确的？ 但是您可以实现团队如何相互交谈、他们如何一起工作、我们如何理解彼此的问题，以及我们如何通过自动化解决这些问题。 这些是你影响范围内的事情，可以改善你的日常生活。

Jeff：所以这确实是给那些人的一封信，但我认为那里有足够的数据和足够的信息，可供 DevOps 组织中的人们收集并说，“嘿，这对我们仍然有用。 ” 很多人，我认为通过阅读这本书很快就能确定，他们不在 DevOps 组织中，他们只是换了一个职位。 这种情况经常发生。 所以他们会说，“嘿，我们现在是 DevOps 工程师，但我们没有做本书中谈到的这类实践，我们如何做到这一点？”

Drew：听起来你的书就是其中之一，但是还有其他资源可以让想要开始使用 DevOps 的人转向吗？ 有学习这些东西的好地方吗？

杰夫：是的。 我认为 Emily Freeman 的 DevOps For Dummies 是一个很好的起点。 它确实很好地整理了一些核心概念和想法，以及我们正在努力的目标。 所以这将是一个很好的起点，只是为了了解一下这块土地。 我认为凤凰计划显然是 Gene Kim 的另一个重要来源。 这很好，这为不在 DevOps 环境中可能产生的问题类型奠定了基础。 它很好地突出了我们在所有类型的组织中一遍又一遍地看到的这些模式和个性。 我认为它在突出这些方面做得很好。 如果你读了那本书，我想你最终会冲着书页尖叫，“是的，是的。 这。 这。” 所以，那是另一个很棒的地方。

Jeff：然后从那里深入研究任何 DevOps 手册。 我会因为这样说而自责，但 Google SRE 手册是另一个值得一看的好地方。 明白你不是谷歌，所以不要觉得你必须实施一切，但我认为他们的很多想法和策略对任何组织都是合理的，并且是你可以采取一些事情的好地方可以说，“好吧，我们要让我们的运营环境更有效率。” 这就是，我认为对于扮演运维角色的开发人员来说尤其重要，因为它确实专注于解决其中一些问题的许多程序化方法。

Drew：所以，我一直在学习有关 DevOps 的所有知识。 你最近在学习什么，杰夫？

杰夫： Kubernetes，伙计。 是的。 Kubernetes 对我们来说是一种真正的阅读和知识来源。 因此，我们目前正尝试在 Centro 实现这一点，作为进一步授权开发人员的一种手段。 我们希望从我们所处的位置更进一步。 我们已经实现了很多自动化，但是现在，当涉及到新服务的加入时，我的团队仍然相当多地参与其中，具体取决于服务的性质。 而且我们不想从事那项工作。 我们希望开发人员能够将一个想法从概念到代码再到部署，并在系统内编纂运营专业知识的情况下做到这一点。 所以，当你在系统中移动时，系统会引导你。 所以我们认为 Kubernetes 是一个可以帮助我们做到这一点的工具。

杰夫：这非常复杂。 这是一大块咬掉的东西。 那么弄清楚部署是什么样的？ 我们如何在 Kubernetes 中利用这些运算符？ CICD在这个新世界中会是什么样子？ 所以有很多阅读，但在这个领域，你一直在学习，对吧？ 不管你在这个领域工作了多久，你做了多久，你在这个领域的某个方面是个白痴。 所以，这只是你适应的东西

Drew：好吧，就像我说的那样，尽管这么多年过去了，虽然我有点理解它在堆栈中的位置，但我仍然真的不知道 Kubernetes 在做什么。

杰夫：我有时也有类似的感觉。 感觉就像它在做每一件事，对吧？ 它是 21 世纪的 DNS。

德鲁：如果你，听众，想从杰夫那里听到更多，你可以在推特上找到他，他在黑暗和书呆子，并在他的网站上找到他的书和过去的演示文稿和博客文章的链接，actainabledevops.com。 感谢您今天加入我们，杰夫。 你有什么临别的话吗？

杰夫：继续学习，走出去，继续学习，与你的同龄人交谈。 说话，说话，说话。 你和你一起工作的人交谈得越多，你就会对他们产生更好的理解，更好的同理心，如果你讨厌组织中的某个人，请确保先与他们交谈。