Get best of the week

七种DevOps转换原型

“如何实现devopae”这个问题不是第一年，但是没有很多好的材料。有时，您成为广告的受害者，这些广告不是非常聪明的顾问，无论如何，他们都需要浪费时间。有时这些是关于大型公司的船只如何耕low宇宙的范围的晦涩，极为笼统的词语。问题出现了：我们呢？亲爱的作者，您可以通过清单明确提出您的想法吗？

所有这些都来自这样一个事实，即对公司文化变革的结果没有太多的积累的实际实践和理解。文化的变化是长期存在的事情，其结果将不会在一个星期内，一个月内出现。我们需要一个足够古老的人，来看看这些年来公司是如何创建和倒闭的。



约翰·威利斯-DevOps的父亲之一。在约翰的背后-与众多公司合作数十年。最近，约翰开始亲自注意到与每个人合作时发生的特定模式。 John使用这些原型，指导公司走上DevOps转型的真正道路。在DevOops 2018大会的报告翻译中阅读有关这些原型的更多信息。



关于演讲者：

在IT管理领域超过35年，参与了Canonical OpenCloud的创建，并参与了10家创业公司，其中两家由Dell和Docker出售。他目前是SJ Technologies的DevOps和数字实践副总裁。

接下来是代表约翰的叙述。

我叫John Willis，在Twitter上找到我的最简单方法是@botchagalupe。我在Gmail和GitHub上具有相同的别名。而在这个环节，你可以找到我的报告，视频和演示文稿给他们。

我与各种大公司的CIO开会很多。他们经常抱怨他们不了解什么是DevOps，并且每个试图向他们解释的人都在谈论其他东西。另一个常见的抱怨是DevOps无法正常工作，尽管董事似乎正在按照向他们解释的那样做所有事情。我们谈论的是拥有一百多年历史的大型公司。与他们交谈后，我得出的结论是，对于许多问题，不是高科技，而是相对低技术含量的解决方案是最合适的。几个星期以来，我只是和不同部门的人聊天。您在帖子的第一张图片中看到的是我的最后一个项目，经过三天的工作，房间看起来像这样。

什么是DevOps？


确实，如果您问10个不同的人，他们将给出10个不同的答案。但是有趣的是：所有这十个答案都是正确的。这里没有错误的答案。我对DevOps的研究非常深入，大约有10年的时间，它是第一个DevOpsDay的第一个美国人。我不会说我比参与DevOps的每个人都要聪明，但是几乎没有人为此付出过多的努力。我相信，将人力资本和技术结合起来，DevOps就应运而生。尽管我们经常谈论各种各样的文化，但我们常常忘记人的方面。



现在我们有很多数据，经过五年的学术研究，已经在工业规模上建立了理论验证。这些研究告诉我们：如果在组织文化中结合一些行为模式，则可以加速2000倍。该加速度对应于稳定性的相同提高。这是DevOps可带给任何公司的收益的定量度量。几年前，我与《财富》 5000强公司的首席执行官谈论了DevOps，在准备演示文稿时，我非常紧张，因为我需要在5分钟内陈述多年的经验。

我最后给出了DevOps的以下定义：这是一组实践和模式，可以将人力资本转化为高生产率的组织资本。一个例子是丰田在过去50或60年的工作方式。



（此后，这些方案并不是作为参考资料提供，而是作为说明。它们的内容对于每个新公司而言都是不同的。不过，可以通过此链接单独查看和放大图片。）

最成功的此类做法之一是价值流映射。关于此的好书已经写了好几本，其中最成功的作者是凯伦·马丁。但是在过去的一年中，我得出的结论是，即使这种方法也太高科技了。他当然有很多优势，我经常使用他。但是，当首席执行官问您为什么他的公司无法继续发展时，谈论价值流图为时过早。有许多更基本的问题需要首先回答。

在我看来，许多同事的错误在于，他们只是给公司提供了五点指导，然后六个月后再回来看看发生了什么。可以说，即使像价值流映射这样的良好电路也有盲点。在对不同公司的董事进行了数百次采访之后，我制定了一种特定的模式，使我们可以将问题分解为各个组成部分，现在我们将按顺序讨论这些组成部分。在应用任何技术解决方案之前，我都使用这种模式，结果，我的所有墙壁都挂有模式。我最近与一个共同基金合作，最终得到了100-150个这样的计划。

不良的文化会影响良好的早餐方式


其主要思想是：如果组织文化不好，精益，敏捷，SAFE和DevOps将无济于事。这与没有潜水装备或没有X射线的情况下进行潜水一样。换句话说，用德鲁克和戴明的话来解释：不良的组织文化将吞噬任何好的系统，而不会窒息。

要解决此主要问题，必须采取以下步骤：

  1. 使所有工作可见：使所有工作可见。它不是必须在任何屏幕上显示，而是必须可以观察到。
  2. Consolidate Work Management Systems: . «» 9 10 . «Phoenix Project» - , , - . «» . c .
  3. Theory of Constraints Methodology: .
  4. Collaboration hacks: .
  5. Toyota Kata (Coaching Kata): Toyota Kata . , .
  6. Market Oriented Organization: .
  7. Shift-left auditors: .




我非常简单地开始与组织合作：我去公司与员工交谈。如您所见，没有高科技。所有需要做的就是写。我将几个团队聚集在一个房间里，并从我的7个原型中分析他们告诉我的内容。然后，我自己给他们做标记，并请他们在黑板上写下他们到目前为止大声说的所有内容。通常在这样的会议上，只有一个人写下所有内容，最好的情况下，他可以记录讨论的10％。用我的方法，这个数字可以提高到大约40％。



（有关单独的插图，请参见链接。）

我的方法基于William Schneider的作品《 Reengineering Alternative》。）该方法基于任何组织都可以分解为四个正方形的想法。对我而言，此方案通常是与分析组织时出现的数百种其他方案一起工作的结果。假设我们有一个控制力强但能力低的组织。这是一个极其不理想的选择：当每个人都沿着路线走，但没人知道该怎么做时。

具有较高水平的控制和能力的更好的选择。如果这样的公司有利润，那么也许不需要DevOps。与一家控制力强，能力和合作能力低，同时又具有高度文化（修养）的公司合作是最有趣的。这意味着公司有很多人喜欢在那里工作，劳动力流动率低。



（您可以从链接中单独看到此图）

在我看来，带有硬编码建议的方法最终会干扰真相的实现。特别是，价值流映射具有许多有关如何构造信息的规则。在我现在谈论的工作的早期阶段，没有人需要这些规则。如果手中拿着记号笔的人描述了董事会中公司的真实情况，那么这是了解情况的最佳方法。此类信息未传达给董事。此时，切断一个人并说他画错了箭头是愚蠢的。在此阶段，最好使用简单的规则，例如：只需使用多色标记即可创建多级抽象。

我再说一遍，没有高科技。黑色标记表示客观现实，即一切工作原理。人们用红色标记标记在当前情况下他们到底不喜欢什么。他们（而不是我）写这本书很重要。会议结束后去信息技术总监办公室时，我没有列出需要解决的10件事清单。我努力在公司人员的话语与现有的成熟模式之间找到联系。最后，蓝色标记表示可能的解决方案。



（另外，可以在链接上查看此插图）

现在在上面描述了这种方法的一个例子。今年年初，我在一家银行工作。那里的安全部门的工作人员确信，他们不应该来检查需求和设计（设计和需求审查）。



（您可以从链接中单独查看此图）

。然后我们与其他部门的人员进行了交谈，结果发现大约8年前，软件开发人员将安全人员放慢了速度，因为他们的速度变慢了。然后变成了禁令，这是理所当然的。尽管实际上没有禁令。

我们的会议是一个非常令人困惑的举动：大约三个小时，五个不同的团队无法向我解释代码和程序集之间的情况。这似乎是最简单的事情。大多数DevOps顾问都预先假定每个人都已经知道这一点。

然后，沉默了四个小时的IT治理负责人在我们达到他的主题时突然复活，并占据了我们很长时间。最后，我问他对这次会议的看法，我将永远不会忘记他的回答。他说：“我以前认为在我们的银行中只有两种发布软件的方式，现在我知道其中有五种，甚至我都不怀疑这三种。”



（另外，可以在链接上查看此插图）

该银行的最后一次会议是与投资软件团队进行的。正是在她的陪伴下，事实证明，在纸张上用记号笔书写记号电路要比在板上书写要好，甚至要比在智能板上书写要好。



您看到的照片就是会议第四天酒店会议室的样子。然后，我们使用这些模式来搜索模式，即原型。

因此，我向员工提出问题，他们用三种颜色（黑色，红色和蓝色）的标记写下答案。我分析他们的原型答案。现在让我们按顺序讨论所有原型。

1.使所有工作可见：使工作可见。


与我合作的大多数公司的未知工作比例很高。例如，这是当一个雇员来到另一个雇员而只是要求做某事时。在大型组织中，可能有60％的计划外工作。多达40％的工作都没有记录在案。如果是波音公司，那么在我的生活中，我再也不会登上他们的飞机了。如果仅记录了一半的工作，则不知道这项工作是否正确完成。所有其他方法都证明是无用的-试图使某事自动化是没有意义的，因为众所周知的50％可能只是工作中最连贯和清晰的部分，其自动化不会产生很好的结果，并且最可怕的是-在看不见的一半中。在没有文档的情况下，不可能找到各种黑客手段和隐藏的工作，而找不到瓶颈，我已经讲过的那些“布伦特原油”。多米尼加·德格兰迪斯（Dominica DeGrandis）有一本漂亮的书“使工作可见。” 它标识了五个不同的“时间小偷”：

  • 在制品（WIP）过多
  • 未知的依存关系
  • 计划外工作
  • 优先顺序冲突
  • 被忽视的工作


这是一个非常有价值的分析，并且本书非常出色，但是如果只有50％的数据可见，所有这些技巧都是无用的。如果精度达到90％以上，则可以应用多米尼加提出的方法。我说的是老板给下属一个15分钟的任务，这花了他三天的时间。但老板并不真正知道这个下属要依靠另外四五个人。



凤凰城项目是一个关于三年后项目的好故事。正因为如此，其中一位英雄面临被解雇的威胁，他遇到了另一个被描述为苏格拉底的人物。他帮助弄清楚到底出了什么问题。事实证明，该公司只有一名系统管理员，名字叫Brent，所有工作都以某种方式通过了。在其中一个会议上，一位下属被问到：为什么每个半小时的任务要花一个星期？作为回应，随后对排队论和利特尔定律进行了非常简化的陈述，在该陈述中，事实证明，在90％的工作中，每小时工作需要9个小时。每个任务都需要发送给其他七个人，所以这个小时变成63个小时，是7乘9。我这样说，要使用利特尔定律或任何复杂的排队论，至少需要有数据。

因此，在谈到可见性时，我并不是说所有内容都在屏幕上，而是至少需要有数据。当它们出现时，通常会发现有很多计划外的工作，出于某种原因，这些工作被发送到了Brent，尽管这不是必需的。布伦特是个好人，他永远不会拒绝，但他不会告诉任何人他的工作方式。



当作品可见时，您可以准确地对数据进行分类（这就是Dominika在照片中所做的事情），您可以应用五个时间泄漏的抽象并将其自动化。

2.合并工作管理系统：任务管理


我正在谈论的原型是一种金字塔。如果第一个正确完成，则第二个已经是一种附加组件。他们中的许多人都不适合初创公司使用，对于大型公司（例如，《财富》 5000强企业中的公司），必须牢记这些。补救措施在一个团队中，另一个团队编写了自己的系统，三分之一使用了Jira，其他人则通过电子邮件获得帮助。如果公司有30条不同的管道，也会出现相同的问题，但是我没有时间讨论所有这些情况。

我会与人们讨论如何创建票证，下一步如何处理票证，如何规避票证。最有趣的是，我们会议上的人们都真诚地讲话。我问有多少人为应该被分配为“重大影响”的机票设置“轻微/无影响”。事实证明，几乎每个人都这样做。我不会公开谴责，并且会尽一切努力不让别人知道自己的身份。当他们在某件事上真诚地承认我时，我不会背叛一个人。但是，当几乎每个人都绕过系统时，这意味着本质上所有安全措施都是一种装饰。因此，无法从该系统的数据得出任何结论。

要解决票证问题，您需要选择一个主系统。如果您使用Jira，请仅使用Jira。如果有其他选择，那就别说了。最重要的是，票证应被视为开发过程中的另一步骤。任何操作都必须具有必须通过开发工作流程的票证。门票被发送到团队，该团队将其放入情节提要中，然后对其负责。

这适用于所有部门，包括基础架构和运营。在这种情况下，您可以至少对事务状态做出一些合理的想法。建立此过程后，突然发现您可以轻松地确定谁负责每个应用程序。因为现在我们获得的不是新服务的50％，而是98％。如果此基本过程有效，则整个系统的准确性都会提高。

管道服务


这再次仅适用于大型公司。如果您是一个新领域的新公司，请袖手旁观并与Travis CI或CircleCI合作。至于《财富》 5000强公司，我所工作的银行发生的事件就是指示性的。他们是从Google来的，并为他们显示了旧IBM系统的图表。来自Google的家伙们被误解了-它的源代码在哪里？而且没有源代码，甚至没有GUI。大型组织必须与之合作的现实是：在古老的大型机上已有40年历史的银行记录。我的一位客户使用带有断路器模式的Kubernetes容器以及Chaos Monkey（全部用于KeyBank）。但是这些容器最终会连接到COBOL应用程序。

Google的家伙们完全有信心，他们将解决我客户的所有问题，然后开始提出问题：什么是IBM数据管道？他们的回答是：这是一个连接器。它连接到什么？到Sperry系统。那是什么 等等。乍一看似乎是什么样的DevOps？但实际上，这是可能的。有些交付系统使您可以将工作流程转移到交付团队。

3.约束理论：约束理论


让我们继续第三个原型：机构/“部落”知识。通常，在任何组织中，都有几个人了解一切并管理一切。这些是在组织中工作时间最长的人，并且知道所有解决方法。



当这在图表上显示出来时，我特别在这些人周围画了一个标记：例如，事实证明在所有会议上都存在某个Lou。对我来说很明显：这是当地的布伦特。当CIO在我穿着T恤，运动鞋和一个穿着IBM西装的家伙之间进行选择时，我之所以被选中，是因为我可以将其他家伙不会讲的事情告诉导演，以及导演可能不喜欢听到的事情。我告诉他们他们的公司存在瓶颈，这是一个名为Fred的人和一个名为Lu的人。这个瓶颈需要解开，他们的知识需要以一种或另一种方式从他们那里获得。

为了解决这种问题，例如，我可以建议使用Slack。聪明的导演问为什么？通常，在这种情况下，DevOps顾问会做出回应：因为每个人都会这样做。如果导演真的很聪明，他会说：那又怎样。对话到此结束。我的回答是：因为公司有四个瓶颈，分别是Fred，Lou，Susie和Jane。为了使他们的知识制度化，您必须首先引入Slack。您所有的Wiki都是废话，因为没人知道它们的存在。如果工程师团队从事外部和内部开发，并且每个人都应该知道您可以与外部开发团队或基础结构团队联系，请提出问题。就在那时，Lou或Fred可能将有时间连接到Wiki。然后在Slack，有人可能会问为什么它不起作用，例如，第5步。然后Lou或Fred将更正Wiki上的说明。如果您建立了这个过程，那么很多事情都会落到位。

这是我的主要思想：要推荐一些高科技，必须首先为它们奠定基础，然后可以使用刚刚描述的低技术解决方案来做到这一点。如果您从高科技入手，却不解释为什么需要它们，那么通常来说，这并不会带来任何好处。我们的一位客户使用Azure ML，这是一种非常便宜且简便的解决方案。在某个地方，自学习机本身回答了30％的问题。而没有处理数据科学，统计学或数学的运算符就写了这东西。这是指示性的。这种解决方案的成本是最小的。

4.协作技巧：协作技巧


第四个原型是需要与外界隔离。大多数人已经知道这一点：隔离会滋生仇恨。如果每个部门都在自己的楼层上，并且除了电梯外，其他任何人都不会以任何方式相交，则彼此之间的敌对情绪很容易产生。相反，如果人们彼此在同一个房间里，她会立即离开。例如，当有人提出某项一般性指控时，这样的界面将永远无法工作-没有什么比解构这样的指控更容易了。编写界面的程序员就足以开始询问特定的问题，很快就可以清楚地发现，例如，用户只是错误地使用了该工具。

有许多克服隔离的方法。曾经有人要求我为澳大利亚的一家银行提供咨询，但我拒绝这样做，因为我有两个孩子和一个妻子。我能为他们提供的所有建议就是向他们推荐图形化的故事讲述。这是行之有效的。另一种有趣的方式是瘦咖啡形式的会议。在大型组织中，这是传播知识的好方法。此外，您可以举办内部开发日，黑客马拉松等。

5.教练卡塔


正如我在一开始就已经警告过的那样，今天我将不再谈论它。如果有兴趣，您可以看一些我的演讲。

Mike Rother也提供了有关此主题的出色报告：



6.以市场为导向：以市场为导向的组织


这里有各种各样的问题。例如，人“ I”，人“ T”和人“ E”。人“我”是只从事一件事的人。通常，它们存在于具有孤立单位的组织中。 “ T”表示一个人对某件事很了解，但在其他方面也很出色。 “ E”甚至是“梳子”是指一个人具有很多技能。康韦定律



在这里起作用，可以用最简化的形式表示如下：如果编译器涉及三个团队，则结果将是一个由三部分组成的编译器。因此，如果组织具有高度的隔离性，那么该组织中的Kubernetes，断路器，API可扩展性和其他流行事物都将以与组织本身相同的方式进行组织。严格按照康威（Conway）的原则，尽管你们都是年轻的极客。

已经多次描述了该问题的解决方案。例如，费尔南多·费尔南德斯（Fernando Fernandez）描述了组织原型。我刚才谈到的问题体系结构是面向功能的体系结构。第二种是最差的矩阵结构，其他两种则一团糟。第三是大多数初创公司所看到的，大公司也在尝试匹配这种类型。这是一个面向市场的组织。这是实现对客户要求的最快响应的优化。有时称为扁平组织。

许多人以不同的方式描述这种结构，我喜欢构建/运行团队的用语，在亚马逊上，他们称之为两个披萨团队。在这种结构中，所有“ I”类型的人都聚集在一项服务中，并且逐渐变得更接近“ T”类型，如果建立了正确的管理，甚至“ E”也可以成为。这里的第一个反驳是这种结构中有多余的元素。如果您可以有一个专门的测试人员部门，为什么每个部门都需要一个测试人员？我要回答：在这种情况下，超额成本是确保整个组织将来成为“ E”型的价格。在这种结构中，测试人员逐渐了解网络，体系结构，设计等。结果，组织的每个成员都充分了解组织中发生的一切。如果您想了解该电路在工业中的工作原理，请查看Toyota Kata的Mike Rother。

7.左移审核员：在周期的早期阶段进行审核。符合安全法规


这是您的动作没有通过，可以说是气味测试的时间。为您工作的人并不愚蠢。如果它们（如上面的示例）到处都显示了轻微的影响/没有影响，持续了三年，并且没有人注意到任何东西，那么每个人都知道该系统无法正常工作。另一个例子是变更咨询委员会，其中需要报告每个环境。一群人在那里工作（顺便说一句，薪水不太高），理论上他们应该知道整个系统的工作方式。在过去的五年中，您可能已经注意到我们的系统非常复杂。五到六个人必须决定他们没有做出的改变以及他们对此一无所知。

当然，这种方法行不通。我必须摆脱这些事情，因为这些人不能保护系统。该决定必须由团队自己决定，因为团队必须对此负责。否则，当一生中从未编写过代码的经理告诉程序员编写代码需要多长时间时，就会出现自相矛盾的情况。在与我合作的一家公司中，有7种不同的技巧可以介绍每次更改，包括体系结构，产品等。甚至有一个强制的等候期，尽管一位员工告诉我，在十年的工作中，没有人在这个强制期内拒绝过此人所做的更改。

审核员应该自言自语，而不是摆脱审核员。告诉他们您正在编写不可变的二进制容器，如果所有测试通过，它们将永远保持不变。告诉他们您将管道作为代码，并解释其含义。向他们显示下图：通过所有漏洞测试的容器中的不变只读二进制文件；然后，不仅没有人碰它-他们甚至都没有碰到创建管道的系统，因为它也是动态创建的。我有一些客户，Capital One，他们使用Vault创建类似区块链的东西。您不能显示从厨师到审核员的“食谱”，而只能显示区块链，从中可以清楚地知道生产中的Jira票发生了什么以及由谁负责。



根据报告由Sonatype在2018年创建，2017年有870亿个OSS下载请求。



产生的漏洞是禁止的。此外，您在上面看到的数字不包括机会成本。简而言之，什么是DevSecOps。我想马上说我对谈论这个名字的成功不感兴趣。关键是，由于DevOps非常成功，因此您需要尝试为该管道增加安全性。

这样一个序列的示例：


尽管我都喜欢它们，但这并不是对某些产品的建议。我以它们为例来说明，DevOps最初基于行业的组织范例，可让您自动化产品工作的每个阶段。



而且没有理由为什么我们不能采用相同的安全性方法。

总


最后，我将为DevSecOps提供一些技巧。您需要在创建系统的过程中包括审核员，花时间进行培训。有必要与审核员合作。此外，有必要对误报进行绝对无情的斗争。即使您使用最昂贵的漏洞扫描工具，如果您不知道信噪比是多少，也可能最终给开发人员带来极其恶劣的习惯。开发人员将被事件重载，他们将删除它们。如果您听说过Equifax的故事，那就是在那里发生的事情，那里最高危险等级的信号被忽略了。此外，还需要对漏洞进行说明，以便清楚地了解漏洞如何影响业务。例如，我们可以说这是与Equifax故事中相同的漏洞。安全漏洞您需要考虑与软件其他问题相同的方式，也就是说，它们需要包含在整个DevOps流程中。您需要通过Jira，看板等与他们合作。开发人员不应以为别人会这样做；相反，每个人都应该这样做。最后，您需要花费精力来教育人们。

有用的链接


以下是DevOops会议上的一些演讲，可能对您有所帮助：



看一下2020年莫斯科DevOops 计划 -那里也有很多有趣的事情。

More articles:


All Articles