加速应用程序部署的需求催生了 DevOps 运动。然而，尽管 DevOps 承诺的好处是毋庸置疑的，但许多 IT 组织仍难以理解并开始实施 DevOps 战略和项目。
在最近的 Cloud Luminary 炉边谈话中，Bernard Golden 与两位专家从业者探讨了该主题：Cloud Technology Partners 副总裁兼首席云架构师 Mike Kavis 和 Chef 高级解决方案架构师 Matt Stratton。
该网络广播侧重于实施 DevOps 流程的实用性，包括以下主题：谁需要参与；确定需要更改的内容；合规和安全需求；构建 DevOps 工具链；以及 DevOps 的组织方面。
以下是讨论的录音和文字记录。
关于嘉宾
Cloud Technology Partners 副总裁/首席架构师 Mike Kavis
Mike 在软件开发和架构方面拥有超过 25 年的经验，曾担任过 CTO、首席架构师和副总裁等多个技术职位。 Mike 是云计算领域的先驱，曾带领团队在亚马逊公有云中构建了世界上第一个高速交易网络，并赢得了 2010 年 AWS 全球创业挑战赛。他是 Forbes、The Virtualization Practice 和 DevOps.com 的分析师和博主，着有 《构建云：云计算服务模型（IaaS、PaaS、SaaS）的设计决策》 。
Matt Stratton，高级解决方案架构师，厨师
Matt Stratton 是 Chef 的解决方案架构师，他展示了 Chef 的自动化平台如何为客户的基础架构提供速度和灵活性。他致力于持续交付和基础架构即代码等概念，他的车牌上写着“DevOps”。他是流行的 “Arrested DevOps” 播客的创建者和联合主持人。
Matt 在 IT 运营方面拥有超过 15 年的经验，曾任职于摩根大通等大型金融机构和包括 Apartments.com 在内的互联网公司。他曾在 Microsoft 赞助的活动、ChefConf、DevOpsDays、Interop 以及芝加哥地区的各种本地团体中发表过演讲。
他和他的三个孩子住在芝加哥，对 神秘博士 、 萤火虫 和 权力的游戏 有着不健康的痴迷。
谁需要参与？
Bernard： 在之前的会议中，我们讨论了企业 DevOps 及其驱动力，以及一些挑战。我们还没有真正讨论过的一件事是，它触及了谁？我最近完成了 Gene Kim 在这个领域的一本非常有名的书，叫做“凤凰计划”......其中一件有趣的事情是，随着他们越来越深入这个项目，他们不断发现有越来越多的东西涉及的团体，还有越来越多他们没有真正意识到的事情。那么让我开始吧...谁需要参与？而且，你如何确定谁需要参与？
Matt： ...我对这个问题的一个词的回答是“每个人”，这实际上是为了油嘴滑舌，但在某种程度上是正确的。关键是，DevOps 是一个不幸的名字，因为它似乎暗示我们只在谈论这两个群体……你说这涉及到很多群体，这是绝对正确的。这些线是模糊的。与其说“谁需要参与”更重要——因为我不认为每个组织都一样……真正重要的是能够识别他们并尽可能地让他们参与进来。
有几种方法可以做到这一点。有能力进行自己的研究以接触到人们，但你需要把你的帐篷做大并鼓励人们和你一起去。这就像，例如，在 GE Capital，当他们开始进行这种转变时，他们说，“好吧，我们将邀请人们参与其中。”如果你选择不参与其中，安全小组、测试组或产品组的不同部分不想成为它的一部分，没关系。但你需要邀请那些下的人......
...任何对你的产品的价值流有既得利益的人，让我们这样说吧。这就是来龙去脉。如果你看看产品从一个想法到出现在客户面前所需要的东西之间的区别，任何接触它的人都应该是你的 DevOps 过渡的一部分，因为他们是该产品的一部分。
Bernard： ...在 DevOps 的背景下，当您使用术语“价值流”时，您指的是什么意思？
Matt： 我的意思是，我认为这实际上与我们考虑制造原则时您正在考虑的概念非常相似。价值流是，当我创造一个东西时它需要什么？...John Willis 谈到了这个想法，“这是 [between] commit to cash” 从我提交对源代码控制的更改到现在它的收入。这可能是描述价值流的一种方式......
当你在做那种映射时……我要做的是思考，“我的组织中的流程是什么？我如何追踪它？”在制造业中，您可以通过说“我正在跟踪一辆汽车穿过工厂”来跟踪它。我是说，它经历了每一步。这是它实际移动之前的流。
那么，当涉及到软件时，您的组织是如何发生这种情况的呢？它是，我是一个产品负责人，我想到了一个功能......所有的部分是什么，之前发生的所有流程实际上是在某种客户面前，在那里我可以获得关于是否我的想法真的很有价值吗？...所以当你追踪它时，每个接触它的人，每个接触那个神器的人，他们都应该参与进来。
伯纳德： 好吧，迈克，让我谈谈这件事的另一面……我参与过一些面临挑战的组织，你邀请了所有人，有人说，“我受不了，我”我们有更重要的事情要做。我要留在家里用牙线清洁猫……”好吧，好吧，你不想卷入其中。然后当真正将其投入生产时，他们会说，“哇，等一下，你还没有看过安全性。”我不会挑安全问题，还有其他团体......他们会说，“我这里有一个 vito。我不会接受它。”你怎么处理那件事呢？
迈克： 相信我，我已经看到了很多，并且有自上而下驱动的计划，C 级人员正在推动它，但其中大多数是基层的。大多数情况下，战壕里有些人厌倦了“传呼机”和手机响个不停，他们是从头开始的。他们是为解决问题而进行艰苦战斗的男男女女，而许多其他人并没有真正投入其中，因为文化是沉默的。基本上你所看到的是，他们会创造小的胜利，但要真正进入最终游戏，他们必须让每个人都参与进来。
当你没有得到那种参与时，你真的必须在管理链上工作并尝试获得支持，而且很多时候你直到看到结果才得到它。所以这就是第 22 条军规：你必须用你所拥有的做你能做的，显示结果，在你实施这些方法之前捕捉你的指标……然后销售。我的意思是，你成为销售人员。
没有简单的答案。每一种文化都是不同的。我看到一家公司，一开始，安全人员说，“不，不，不”。他们在做什么——这更像是一个平台团队——他们站在云上，他们想围绕它建立护栏并为开发人员创建服务。他们使用 Chef 并实现了整个基础架构的自动化，他们邀请的应用程序团队作为他们的试点工作做得很好。他们实施了 CI 和 CD。安全组一开始是反对的，后来他们开始邀请安全组。
安全团队甚至在项目开始之前就开始在零冲刺时进行安全审查……然后他们会给他们一个风险评分。如果有高风险，比如如果有移动支付，他们将不得不通过很多结构，但如果是网页或其他东西，他们允许事情溜走。他们还与做 Chef 的人密切合作，所以他们把所有的安全策略都放在那里。随着时间的推移，那些安全人员成为了该平台的最大粉丝，因为现在他们能够以抽象的方式导入他们的策略并且得到执行。所以当人们来找他们说，“我想构建 X、Y、Z”时，他们会说，“你可以在那个平台上构建。如果你不在那个平台上构建，我不想和你说话。”他们把它从抑制者变成了最大的粉丝，但这花了很多时间。
马特： 我只是想回应你说的两件非常有趣的事情。一是，我们已经开始看到一些事情——这绝对是真的……其中很多都是风起云涌的事情——但我们现在看到的是自上而下的事情。高级 IT 领导说，“我想要这个”，这是个好消息。作为内部布道者或内部利益相关者，需要完成的推销技巧较少。真正引起我共鸣的是你谈到支持的时候。安全团队应该喜欢自动化，他们也确实喜欢。我总是喜欢说，“人们会撒谎；电脑不会说谎”。因此，如果审计是，“嘿迈克，你这样做了吗？”你会说，“当然这样做了！”那有什么好处？但是 [自动化] 对此非常有用。当我进来谈论 Chef 时，我在公司中看到了这一点。越来越多的网络安全或信息安全人员参与了这些对话。
但这一切归结为，你在实施什么？因为你真的不应该实施 DevOps。你应该做的是解决你遇到的问题。如果您正在为他们解决问题，您的员工将会加入并投入其中。做到这一点的一种方法是，当你把人们带到帐篷里时，就像 Bernard [说的那样]，“嘿，我们要进行 DevOps 过渡。每个人都来加入我们”，他们就像，“我太忙了。这个 DevOps 是一群胡言乱语和嬉皮士之类的。”如果你说，“嘿，我们每周都会有一个棕色袋子，或者我们将讨论如何改进我们的流程，让事情变得更好。让我们用前两个棕色袋子来谈论我们的痛点并找出要解决的问题”，人们一起来了。这很有趣，因为如果你看“凤凰项目”，标题会说一些关于 DevOps 的东西，但贯穿整个他们实际上并没有做出 DevOps 的改变。他们试图解决一个问题，并且他们正在用这些东西来实现它。
“我看到一家公司，一开始，安全人员说，‘不，不，不’......随着时间的推移，那些安全人员成为了该平台的最大粉丝，因为现在他们能够导入他们的政策以一种抽象的方式，他们正在得到执行。”
Mike： 很快，我想添加两个经常被遗忘的组。一是产品经理。通常情况下，产品所有者会被激励去创建功能，但不知何故，他们并没有被激励去追求质量和可靠性，而这些是我们正在努力改进的结果。因此，即使我们让所有这些 IT 人员一起合作并说我们需要改进这些东西，但如果确定优先级的人不关心这一点，他们只关心下一个功能，那么你就不会得到最终结果.说“那是 QA 的问题”或“那是安全的问题”太容易了。如果我是打造下一代 BMW 的产品负责人，我必须在其中安装安全气囊……我们也应该考虑这样的 IT 系统；你拥有一切。
第二组是运营：帮助台，服务台。我见过同一家公司在自动化基础设施方面做得很好，在 CI/CD 方面做得很好。他们按下部署按钮，每个人都很高兴，直到出现问题。他们真的没有想过什么东西坏了会发生什么。现在开发团队应该修复它。好吧，他们必须创建一张票才能获取日志文件。他们没有将其与运营联系起来。你必须把那些男孩和女孩也带到那里。
Matt： 进入运营的那一部分。这实际上是一个我没有想过的非常有趣的点，也就是说，那些像我这样头发花白的老系统管理员总是说，“你们这些该死的 Dev 家伙从不谈论 Ops”，然后我们与 DevOps 一起出现，你就像, “服务台呢？”我们就像，“那些人？去他妈的那些家伙。他们不是真正的行动”。我喜欢。
伯纳德： 我有时认为最大的挑战之一是人们的心态......就像，它一直是这样，它会是这样......我正在举办一个研讨会，我首先谈论什么是云计算和它的特点。我从这个定义开始，“第一个特征是自助服务……就像在亚马逊上买书一样。你填写一个网络表格，然后点击提交。它熄灭了，十分钟后你就有了资源。”......那个人说，“是的，一旦系统管理员审查它然后执行它。”我说，“嗯，这不是真正的观点。这得到了自动化，所以没有人需要参与。有人只是填写了一张表格……”他说，“是的，一旦系统管理员审查并批准它。”……我终于意识到这就像哥斯拉和魔斯拉，我们将继续下去。我说，“好吧，让我们继续第二个特征”，后来想想，他并不是在刁难，而是他无法想象一个不必发生这种情况的世界。
确定需要更改的内容
Bernard： 在 IT 价值链中，您如何确定需要更改的内容？他们在凤凰计划中做到了这一点。他们反复检查并说：“这是一个瓶颈。”迈克...您如何确定需要更改的内容以及如何确定应该替换它的内容？
Mike： 我们做的正是他们在 Phoenix Project 中做的事情。很多时候，当我们进入一个帐户时，他们只关注一个域……您坐在那里，从需求开始，到后端运行操作。您让他们完成整个过程并找出瓶颈。然后真正重要的部分是确定这些瓶颈的优先级。读过目标的人 [知道] 如果你不首先解决正确的瓶颈，你只是在其他地方堆积问题。
你做那些价值流映射练习。你采访了很多人。如果可以的话，我们也会让业务人员参与进来，因为他们对瓶颈的看法可能与 IT 人员不同，而且很多事情都会冒出来。你尽可能优先考虑，然后开始攻击它。
我不久前写了一篇文章——我见过的最重要的瓶颈。我看到的第一个是不一致的环境，这是最重要的……我看到的第二个最流行的——我只关注技术方面，肯定有组织方面和流程方面——是配置时间，比如一个地方[其中] 需要六个月才能启动服务器。如果这些是你的瓶颈，而你单独解决这两个问题，你就可以大大提高生产率。
但随后也经常出现流程瓶颈。回到那个做了所有自动化的客户，他们仍然有这个遗留的 ITIL 流程。 ITIL 不需要消失，但他们需要让 ITIL 变得敏捷。因此，我没有自动化我的部署，但我必须每周进行一次 CAB 审查以获得批准，按下按钮，还有 20 个其他人在排队，所以需要两周的时间......我们在这方面做了什么在这种情况下，我们将大量信息自动化并自动批准——那些风险较低的信息——并将 CAB 审查转变为事后审查，而不是停止审查。之类的，你看看流程。。。为什么要四个月才换防火墙之类的。
Matt： 首先，我将 100% 同意你的观点，因为像 Eli Goldratt 这样的人和比我们更聪明的人已经弄清楚了这一切……这个约束理论。好消息是这些东西实际上并不是超级吓人的。你可以在这个大的整体层面上做到这一点，但有时这听起来对一个组织来说真的很有挑战性。它可以只是一个非常简单的练习，即“好的，产品负责人，你有一个功能。让我们通过映射。它有什么作用？”这并不意味着您拥有某种奇特的软件。把它画在一张纸上。那么你就明白了。
问题是在您的组织中可能很少有人了解整个流程。他们了解他们的输入以及他们将其踢出的位置。当我在做更多 ITSM 的工作时，Serena Software 的 Kevin Parker 讲过一则轶事。他在谈论改进您的变更管理流程。他会告诉 CTO 或 CIO 将此作为练习：将更改放入您的更改请求系统中，这实际上是什么都不更改，然后查看该更改需要多长时间才能完成整个过程，它可能会大约需要三个星期。
同样，只需说，“好的，我将完成练习。如果我真的有一个功能怎么办？什么是所有的停止？你会看到，你会说，“这适用于三个不同的团队，然后存储会做这件事……现在它会坐下来等待三个星期。哇。这是一个约束条件。”
所有这一切中最重要的部分是，你不能挑剔你的瓶颈……你要找出你的瓶颈。这很好，因为您需要知道它们都是什么，但您只能处理一个。这不是您认为最重要的问题，因为它看起来很重要或者很容易……[领导层可能会说]“我们无法改变这一点，所以去解决其他问题吧。”……您必须在组织上购买，我们必须做出一些艰难的决定，即使它们并不有趣。解决最重要的瓶颈通常不是一件很有趣的事情。这不是性感的工作。它通常会修复大量蹩脚的技术数据。真的，有很多，“用你的靴带把你自己拉起来，穿上你的涉水靴，努力工作。”
确保满足合规性和安全需求
Bernard： 让我们谈谈安全合规性。 DevOps 如何确保这些问题得到解决？根据我的经验，这些通常是非常重要的瓶颈……因为它是带外的。就像，“我已经到了这一步，现在我必须提出这个特殊要求，”然后它就进入了一个循环，这个循环本身就结束了，而且可能人手短缺。这可能非常具有挑战性。
您需要安排与安全组的会议来审查这一点。他们日历上的第一个议程是两周后……你如何处理这些事情？您如何确保在 DevOps 上下文中解决了这些问题？ DevOps，至少是它的一部分，是您希望从某人签入代码的时间到它在生产中运行的时间尽快结束的概念。
Matt： 尽可能多的速度。这是一个真正重要的区别。我跳到这里是因为这是我们目前在 Chef 做的核心工作。这是我们理念的核心部分，是速度合规的理念。 “尽可能快地移动东西”听起来像是，“乱七八糟，该死的鱼雷，我没有时间进行安全检查。我们必须运送一些东西。”那不是高速，那只是速度很快……我认为很多这些想法实际上可以真正实施你正在谈论的那些事情……就像你说的，我们触及了一点点，很多这个工具真的很强大。
Phoenix 项目最重要的教训之一是安全人员——当我们考虑审计时，这对我们来说很常见……总是，“我们不能这样做，因为我们的审计要求和合规性”...因为当我们谈论合规性时，我们习惯做的是，就像 Phoenix Project 中的那个人一样，我们有我们的三环活页夹，里面有我们必须做的所有清单。
我们关心的是清单，而不是它的用途……伯纳德，回到你的观点[关于]那个人说，“我们不能这样做。你把它放进去，然后系统管理员审查它。”......对于那个家伙来说，重要的是系统管理员审查它，但真正重要的是为什么系统管理员要审查它？因为我们需要确保我们信任它。但我们可以用不同的方式做到这一点，并且仍然能够做到这一点。
我认为很多时候，当我们审视审计和合规性之类的事情时......我们已经围绕我们如何进行合规性创建了这种仪式，我们更关心的是仪式而不是我们首先这样做的原因.这是一个具有挑战性的部分。它明白，这又是一项艰苦的工作。直接说“我有我的活页夹，我们必须在活页夹中的方框上打勾”要容易得多。
什么是通用 DevOps 工具链？
Bernard： 让我们谈谈工具和工具链。迈克，你看到人们做什么？什么是通用工具链？首先我要说的是，我去过很多 DevOps 营地，他们总是非常鼓舞人心，因为人们站起来讲述这些令人难以置信的故事。但它们看起来总是像自己的雪花。就像，“好吧，我抓住了这个开源项目，我做了这个，我写了一堆胶水代码……”就像，是的，但是现在你有一堆你放在一起的修补玩具。上帝禁止你离开组织，因为谁会知道那里有什么？
Mike： 我是工具不可知论者，所以我在这个游戏中没有猫，但我确实看到了你所描述的：人们抓住了很多不同的工具。这真的归结为我们定义 DevOps 工具的范围是什么？我看到的东西就...从看板管理项目的工具和类似的东西，一直到监控、日志记录工具和介于两者之间的东西：测试工具、脚本工具（如 Chef 和 Puppet）、容器。而且我确实看到了大量的开源使用，因为如果你要为所有这些工具付费，这样做的投资回报率可能看起来不太好。
Matt： 老实说，仅仅因为它是开源的并不意味着它是免费的。对于为什么在 DevOps 中如此多地利用开源，我有不同的想法，但其中一部分也是尽可能多地使用免费工具。
迈克： 是的。我认为人们大量使用这些工具的原因之一是因为他们不一定需要上链并获得许可，因此他们可以插入东西并快速测试。许多工具都专注于管道：我们如何进行构建？我们如何进行测试？我们如何运行安全扫描？我们如何运行代码扫描？...有很多工具。我以前看过一张幻灯片，上面可能有 100 个徽标，你走进任何一家商店，它们都有很多。
Matt： 这实际上是一种风险，在很多方面都是如此。这种自上而下采用的好处之一是……因为当您自下而上时，您正在做您可以做的事情。肯定存在挑战，有人将这个在 webrespondo.com 工作的工作流程拼凑在一起，并破解了他们正在工作的这个初创公司。我在企业中没有看到这一点。也许他们这样做是为了他们的 POC，但我要进入和销售 Chef 的地方……这些东西是标准化的。他们正在围绕开源工具构建标准......
“随着我们自上而下地采用 DevOps，并且在您的组织内将事情作为标准实施，即使它们是多种技术的组合......对我来说，这是一件有价值的事情......如果我是那些只想使用它的人，我不必去做那些泥饼，因为从理论上讲，它们是我的组织为我做的。”
......有人仅仅因为它很有趣而做某事是有风险的。随着我们自上而下地采用 DevOps，并且在您的组织内将事物作为标准实施，即使它们是......多种技术的组合，这确实很强大，这种组合特定于 GE 或 JP摩根大通。我们在那些地方一直有建筑师......对我来说，这是一件有价值的事情......如果我只是想使用它的人，我不必去做那些泥饼，因为理论上，它们是我的组织为我制作的。
伯纳德： 我的描述方式是……“不要建立新的遗产。你正试图将自己从遗留系统中抽离出来……你现在有了洞察力。”
迈克： 不过，我可以澄清一件事吗？他们正在标准化脚本工具——他们会选择一个 Chef、一个 Puppet、一个 Ansible，但是有太多不同的功能和工具需要他们来自动化管道。你需要代码扫描，你需要安全扫描，你需要测试工具。当我说他们正在拼凑一堆工具时，他们在每个领域都选择了一个标准，但通常需要大约 12 个工具来完成整个链条。
Matt： 你是说在一个组织内，不同的团队使用不同的工具来实现相同的功能吗？
迈克： 有时。
Matt： 我只想知道我们在谈论什么，因为指示整个行业在工具链上进行标准化是愚蠢的。我是供应商，我并不是说整个行业都应该使用 Chef。使用适合您的东西……您不应该做的是拥有五种不同的 CM（配置管理）工具，因为我们将做很多重复的工作……下一个发展是聚集在一起并说，“。 ..这是我们工作方式的定义管道，”现在您可以使用它，因为这是应该发生的事情。我作为开发人员的工作...不是喜欢构建 CD 管道。我的工作是支持我的业务并做到这一点。因此，这些东西越快摆脱困境，它就是一种促成工具……它是达到目的的一种手段。
迈克： 当它是自上而下的时候你就会明白，但是很多这样的公司，他们有多个基层。
马特： 嗯，我认为这就是我们现在看到的转变……但它也必须双向发展，对吧？你也必须有支持......当我们在我的节目中有比尔乔伊时，我们谈到了合规与承诺的想法。合规意味着我做这件事是因为我的 CTO 说过，如果不这样做，我就会被解雇。承诺是，我确实相信这是正确的做法，我现在就加入了。也许我当时处于我们组织中不同意的适当位置，但现在我们已经做出决定，我们正在向前迈进。如果它只是自上而下的，你就不会得到承诺。但出于同样的原因，你不会得到支持，如果都是草根阶层，你就不会获得一致性。你必须在中间见面。
DevOps 会减少中断吗？
Bernard： 我们提交了一个我认为很有趣的问题：DevOps 是否也会减少停机？...Mike，你对此有何看法？
Mike： 这不是 DevOps。是实施您正在实施的任何事情的人。 DevOps 的心态就是持续改进，构建更好的质量和可靠性。但最终结果并不是 DevOps，而是组织中的人员将工具和流程落实到位。最大的谬误之一是，“哦，我现在有了 DevOps。我已经解决了所有这些问题。”不，现在你遇到了一个新问题——你需要学习如何操作这个新模型。
Matt： 它可以帮助您为创新人士提供便利。我对这个问题的回答是一个问题：中断的数量或影响是减少了吗？这更有助于减少对 DevOps 的思考，更多地考虑小批量以及理解变化和变化的影响。
如果你说 DevOps 是持续交付的理念，那么你可能会遇到更多的中断，但中断的规模可能会小得多。中断的可能性上升，但影响却大大降低。这对很多组织来说都是一个挑战，要了解这实际上可能没问题。我的看法是，除非你运行的是空中交通管制、核反应堆或医院之类的东西，否则你可以中断 30 秒并影响 10% 的流量，这没关系。
伯纳德： 我们向使用我们产品的人宣传真正开始减少发布的大小，更频繁地发布，而且您不一定会中断。您可能拥有的是您发布的功能，然后在发布时撤回；把它放在那里，要么它不能正常工作......要么不管它是什么，你需要有能力快速退出它。
Matt： 这些变化的影响要小得多……中断是因为某种变化变坏了……如果你改变了很多东西并且出现了可怕的错误，那么很多事情都会发生被打破。如果你正在改变一件小事，但它出了可怕的错误，那么一件小事就会彻底坏掉。就像 Bernard 所说的那样，要么取消它要么迅速解决它要容易得多。
伯纳德： 你也可以更快地找到它。
马特： 是的，完全正确。而且你不会惹恼所有其他参与这种变化的人。他们的改变并没有破坏任何东西，但他们的东西也被回滚了，因为它在骑手账单上。
NoOps 怎么样？
Bernard： 我听过人们谈论 NoOps。关于 NoOps，我最初是从 Netflix 的首席架构师那里听到这句话的，他声称他们没有运维人员。基本上，开发人员将其投入生产并运行……那个概念怎么样？
Matt： 首先是……我们还用这个词吗？我以为这就像两年前一样，我们不再谈论它。但这很重要，因为我看到很多时候人们想到 DevOps，他们想到的是 NoOps。他们认为这是全栈工程师、10x 工程师，所有这些神话般的废话。我的想法是，有一定比例的聪明创意和有能力的人可以成为每个人的一切……你有一定比例的人可以做 NoOps。 NoOps 并不意味着“没有操作”。这只是意味着每个人都做所有事情。是全栈工程师。问题是，每个人都认为有无限多的全栈工程师，不管他们是否存在。 It certainly doesn't scale.
"I think Netflix is a great organization...But to think that Netflix does it that way, that Clorox can do it...just to pick any company at random...that would be like me saying, “I'm going to buy the same running shoes that Usain Bolt buys and I'm going to be as fast as Usain Bolt."
- Bernard Golden
I think you can have examples...That could work if you hired those people, those 100 people that can do that work and are willing to do that work — they came to work at Netflix, awesome. But that doesn't mean that I can go cargo-cult that over to the Board of Trade...or to a different organization, not even because it's "enterprise versus internet." I think if you do NoOps and it works, you got lucky. You got people that are willing do it.
Mike: I always kind of interpreted NoOps as, the system kind of runs itself, we don't need people running the system. I think the problem was, people assumed that there wasn't anyone. If you look at the help-desk, service-desk type operations, people think that's gone too. There's nothing further from the truth. If you go to Netflix and you look at the 100,000 monitors on the wall, there's people keeping a close eye on it. To me, the end-game would be nice if I could run self-healing, self-running systems and have as little people hand-holding stuff as possible. That's a highly automated, high-performing system.
Bernard: LessOps, that's the term we should use, LessOps.
Mike: Me personally, I would love to get to a place where most everything that makes sense is automated. But to get there, you have to build a system that creates a ton of data...so systems can tell us when things are going wrong. That's another part people forget is, if you want to have less people touching it, you've got to produce more intelligence through your system.
Bernard: Interestingly, at my previous company we booked a day with an analyst firm to review our approach...They said, “You know, we have enterprises marching in here all day, every day, saying how can I be like Netflix?” I think Netflix is a great organization...But to think that Netflix does it that way, that Clorox can do it...just to pick any company at random...that would be like me saying, “I'm going to buy the same running shoes that Usain Bolt buys and I'm going to be as fast as Usain Bolt.” That's just never going to happen...people sort of look at that and go, “Oh, I could do that,” instead of, “What's realistic within the kind of frame I have?”
The Organizational Side of DevOps
Bernard: Does DevOps mean people losing their jobs?...Mike, what about the organizational side?
Mike: I have many answers for this one. My first one is just kind of a snide remark. If you're going to fight DevOps, you might be out of a job some day. Holistically, though, what's really happening here is, once you start automating these things, removing the bottlenecks, becoming a more high-performing company — that's how I describe DevOps — especially on the systems administrator side, you're freeing [developers] up to work on higher value tasks...You're not configuring the same machines over and over. You're getting the waste out of the system and these people can focus on higher value things.
Where I have seen it have an impact on headcount, we had one company who was very strategic top-down, and they were trying to build, like, "What are we going to be in five years?"...Using the assumptions that they were going to automate a lot of tasks, they said, “We're not going to need the budget for as many resources going forward.” So they weren't getting rid of people, but their future state organization is going to be less dependent on people.
Matt: ...I absolutely agree 100% with what Mike said...John Allspaw said this about Etsy...people are like, “You have so much automation at Etsy, why do you need a web operations team?” He's like, “Are you kidding? They have tons of work to do, but what they are not doing is copying files around and doing rote mundane things.”
"...once you start automating these things, removing the bottlenecks, becoming a more high-performing company — that's how I describe DevOps — especially on the systems administrator side, you're freeing [developers] up to work on higher value tasks...You're getting the waste out of the system and these people can focus on higher value things."
Now what can happen — this is where I could see it could mean someone losing their jobs — is either A...In an organization where they had, it was some ridiculous number like 1:10 admin-server ratio...so when they did automation, they were clearly over-staffed by a ridiculous amount...Or if you have folks who, their only skill and their only desire to have skill is to copy files and be a click-next-admin, then yeah, then you probably will lose your job, and that might be okay.
This is happening a lot in Microsoft. Microsoft will say the days of the click-next-admin are over, and there's an awful lot of Microsoft admins who are pissed about this. They say, “Oh, this is all baloney. It's all this DevOps crap. There's always going to be the need for this.” The answer is, yeah, there will always be a need for server-janitors, but it's not going to be well-paying work and it's not going to be very interesting. That's the thing. If you're towards the end of your career...then keep doing what you're doing, that's awesome. But If you want to be around for a little while...you've got to keep learning. Things are changing.
Bernard: My response is sort of an extension of what you just said, Matt, which is, I think the challenge for lots of people is that as you move toward automation, obviously you need fewer people who are just...shove the CD in and click next. You need people who can design automated systems and implement them. That, to me, is clearly a next-level-up skill. Automating a system is much more difficult than actually having the skills to do it. I think the challenge for many people is, are they able to up-skill? Are they motivated to up-skill?...It's sort of the difference between being able to work on an assembly line and attach a part, and design an assembly line that incorporates robotics.
Matt: The thing is that most of the people you have doing this rote thing do have a higher level of skill than doing the rote thing because you can't do the rote thing without having the higher level of skill. There's that great quote in the Continuous Delivery book, which is, “The problem is these manual tasks actually can't be done by someone who has a low level of skill because they have to be able to deal with it when it doesn't work.”
When I was doing consulting around this, I would go and talk to stakeholders around doing a DevOps transition, the question I asked every stakeholder group was, “I have a magic IT wand and I'm giving you one wish. What is your one wish?” And every group of stakeholders had different answers, except for Ops. Almost without question, every Ops group I ever talked to had the exact same wish. You know what that wish was? More people in Ops. And It's because they don't have enough time to do all the things they want to do because they're doing all the other crap.
So the thing is these teams and these people, they actually do have skills and things that need to be done, but they are not able to do it because there is not enough time. The automation frees that up. You're right Bernard, there are people where that particular skill set of being able to take from being able to do, and learning how to design automation around it...might not be for everyone, but that's not the only thing for an Ops person to do when they are leveling up. If you're not leveled up, then yeah, maybe that particular type of career doesn't exist anymore.
Bernard: Retrain as a COBOL programmer.
Matt: Again, there are still people employed as COBOL programmers and there's still people who are employed as Windows 2003 server admins. The jobs will be there. They just aren't really very fun.
Bernard: Well, we're reaching the top of the hour...I really appreciate both of you participating and contributing and sharing your experience, it's been fantastic. I've really enjoyed it. I'm sure our audience has really enjoyed it and found it educational.
Next Steps
Follow on Twitter:
- Bernard Golden: @bernardgolden
- Mike Kavis: @madgreek65
- Matt Stratton: @mattstratton
Learn more about the Cloud Luminary Fireside Chats: http://fireside.activestate.com.