“如何实施 DevOps”这个问题已经存在很多年了，但是好的材料并不多。 有时，您会成为不太聪明的顾问的广告的受害者，他们无论如何都需要出售自己的时间。 有时，这些是关于巨型企业的船只如何在宇宙中航行的模糊且极其笼统的词语。 问题出现了：这对我们来说有什么关系？ 亲爱的作者，您能在列表中清楚地表达您的想法吗？
这一切都源于对企业文化转型成果没有积累多少真正的实践和理解。 文化的改变是长期的事情，其结果不会在一周或一个月内显现出来。 我们需要一个足够老的人来见证这些年来公司是如何建立和失败的。
约翰·威利斯 - DevOps 之父之一。 约翰拥有数十年与众多公司合作的经验。 最近，约翰开始注意到与他们每个人一起工作时发生的特定模式。 利用这些原型，John 指导公司走上 DevOps 转型的真正道路。 请阅读他在 DevOops 2018 会议上的报告翻译，了解有关这些原型的更多信息。
关于演讲者：
拥有超过 35 年的 IT 管理经验，参与了 Canonical OpenCloud 前身的创建，参与过 10 家初创公司，其中两家被出售给 Dell 和 Docker。 目前，他是 SJ Technologies 的开发运营和数字实践副总裁。
接下来是约翰视角的故事。
我的名字是 John Willis，最容易找到我的地方是 Twitter， 。 我在 Gmail 和 GitHub 上有相同的别名。 A 您可以找到我为他们所做的报告和演示的视频记录。
我与各大公司的首席信息官进行了多次会议。 他们经常抱怨他们不明白 DevOps 是什么，而每个试图向他们解释的人都在谈论不同的东西。 另一个常见的抱怨是 DevOps 不起作用，尽管看起来董事们正在按照向他们解释的方式做所有事情。 我们谈论的是已有一百多年历史的大公司。 与他们交谈后，我得出的结论是，对于很多问题来说，最适合的不是高科技，而是技术含量相对较低的解决方案。 几周来我一直在和不同部门的人交谈。 您在帖子的第一张图片中看到的是我的最后一个项目，这是工作三天后房间的样子。
什么是 DevOps？
事实上，如果你问 10 个不同的人，他们会给出 10 个不同的答案。 但有趣的是：这十个答案都是正确的。 这里没有错误的答案。 我对 DevOps 非常深入，大约有 10 年了，并且是第一个 DevOpsDay 的第一个美国人。 我不会说我比所有参与 DevOps 的人都聪明，但几乎没有人在这方面付出了那么多的努力。 我相信，当人力资本和技术结合在一起时，DevOps 就会出现。 尽管我们经常谈论各种文化，但我们经常忘记人的维度。
现在我们有大量的数据、五年的学术研究、工业规模的理论检验。 这些研究告诉我们，如果将一些行为模式结合到组织文化中，您可以获得 2000 倍的加速。 这种加速与稳定性的同等提高相匹配。 这是对 DevOps 可以给任何公司带来的好处的定量衡量。 几年前，我向一家财富5000强公司的CEO谈论DevOps，当我准备演讲时，我非常紧张，因为我必须在5分钟内总结我多年的经验。
最后我给出了以下内容 DevOps 的定义：它是一套能够将人力资本转化为高绩效组织资本的实践和模式。 丰田过去 50 或 60 年来的运营方式就是一个例子。
（以下提供的此类图表不是作为参考资料，而是作为说明。每个新公司的内容都会有所不同。但是，可以单独查看图片并放大
最成功的此类做法之一是 价值流图。 关于这一点已经写了几本好书，其中最成功的是凯伦·马丁 (Karen Martin) 写的。 但在过去的一年里，我得出的结论是，即使这种方法也太高科技了。 它确实有很多优点，而且我已经用过很多次了。 但是，当首席执行官问你为什么他的公司不能转向新的轨道时，现在谈论价值流图还为时过早。 有许多更基本的问题必须首先得到回答。
我认为我的许多同事犯的错误是，他们只是给公司提供了五点指导，然后六个月后回来看看发生了什么。 即使是像价值流图这样的好方案也有盲点。 在与不同公司的董事进行了数百次访谈之后，我开发了一种特定的模式，使我们能够将问题分解为各个组成部分，现在我们将按顺序讨论每个组成部分。 在应用任何技术解决方案之前，我都会使用这种模式，因此，我所有的墙上都贴满了图表。 最近我与一家共同基金合作，最终制定了 100-150 个这样的计划。
坏文化吃好早餐
主要思想是：如果组织文化本身很糟糕，再多的精益、敏捷、SAFE 和 DevOps 也无济于事。 这就像在没有潜水装备的情况下潜入深处或在没有 X 光的情况下进行操作一样。 换句话说，套用德鲁克和戴明的话说：糟糕的组织文化会吞噬任何好的系统而不至于窒息。
为了解决这个主要问题，您需要采取以下步骤：
- 让所有工作可见： 你需要让所有的工作都可见。 并不是说它必须显示在某个屏幕上，而是说它必须是可观察的。
- 综合工作管理系统： 管理体系需要整合。 在“部落”知识和制度知识问题上，十分之九的瓶颈是人。 在书里 问题出在一个人身上，布伦特，他导致该项目比计划晚了三年。 我到处都会遇到这些“布伦特”。 为了解决这些瓶颈，我使用了列表中的接下来两项。
- 约束方法论理论： 约束理论。
- 协作技巧： 协作黑客。
- 丰田卡塔（): 关于丰田 Kata 我就不多说了。 有兴趣的话可以在我的github上 几乎涵盖了所有这些主题。
- 市场导向的组织： 市场导向的组织。
- 左移审核员： 在周期的早期阶段进行审计。
我开始与一个组织合作非常简单：我去公司并与员工交谈。 正如你所看到的，没有高科技。 您所需要的只是可以写的东西。 我将几个团队聚集在一个房间里，从我的 7 个原型的角度分析他们告诉我的内容。 然后我给他们自己一个记号笔，并要求他们在黑板上写下到目前为止他们大声说出的所有内容。 通常在这类会议中，会有一个人把所有内容都写下来，最多只能写下 10% 的讨论内容。 按照我的方法，这个数字可以提高到40%左右。
（此图可单独查看 )
我的方法基于威廉·施耐德的工作。 ）。 该方法基于这样的想法：任何组织都可以分为四个方格。 对我来说，这个方案通常是与分析组织时出现的数百个其他方案一起工作的结果。 假设我们有一个控制水平较高但能力较低的组织。 这是一种极其不可取的选择：每个人都听话，但没人知道该怎么做。
稍微好一点的选择是具有高水平控制力和能力的选择。 如果这样的公司能够盈利，那么也许它就不需要 DevOps。 与一家控制水平高、能力和合作水平低、但同时文化（修养）水平高的公司合作是最有趣的。 这意味着该公司有很多喜欢在那里工作的人，而且劳动力流动率很低。
（此图可单独查看 )
在我看来，具有严格指导方针的方法最终会妨碍实现真理。 特别是在价值流图中，有许多关于如何构建信息的规则。 在我现在所说的工作的早期阶段，没有人需要这些规则。 如果一个手里拿着记号笔的人在黑板上描述了公司的真实情况，这就是了解情况的最好方法。 此类信息不会传达给董事。 此时此刻，打断对方并说他画错了某种箭头是愚蠢的。 在这个阶段，最好使用简单的规则，例如：可以通过使用多色标记简单地创建多级抽象。
我再说一遍，没有高科技。 黑色标记描绘了一切如何运作的客观现实。 人们用红色标记标记出他们不喜欢当前事态的地方。 重要的是他们写的，而不是我。 当我在会议结束后去找 CIO 时，我不会列出需要解决的 10 件事。 我努力寻找公司人员所说的与现有的经过验证的模式之间的联系。 最后，蓝色标记建议了问题的可能解决方案。
（此图可单独查看 )
上面描述了这种方法的一个示例。 今年年初，我在一家银行工作。 那里的安全人员确信他们不应该参与设计和需求审查。
（此图可单独查看 )
然后我们与其他部门的人交谈，结果发现大约 8 年前，软件开发人员解雇了安全人员，因为他们拖慢了工作速度。 然后就变成了禁令，这是理所当然的。 虽然实际上并没有禁令。
我们的会议以一种极其混乱的方式进行：大约三个小时，五个不同的团队无法向我解释代码和程序集之间发生了什么。 这似乎是最简单的事情。 大多数 DevOps 顾问预先假设每个人都已经知道这一点。
然后沉默了四个小时的IT治理负责人在我们谈到他的话题时突然活跃起来，占据了我们很长一段时间。 最后我问他对这次会议的看法，我永远不会忘记他的回答。 他说：“我以前以为我们银行只有两种交付软件的方式，但现在我知道有五种，我什至不知道三种。”
（此图可单独查看 )
该银行的最后一次会议是与投资软件团队举行的。 正是和她一起，事实证明用记号笔在纸上写图表比在黑板上写图表更好，甚至比在智能板上写图表更好。
您看到的照片是我们会议第四天的酒店会议室的样子。 我们使用这些方案来搜索模式，即原型。
所以，我问工人问题，他们用三种颜色（黑、红、蓝）的记号笔写下答案。 我分析了他们的答案的原型。 现在让我们按顺序讨论所有原型。
1. 让所有工作可见：让工作可见
我工作过的大多数公司都有很高比例的未知工作。 例如，一名员工来到另一名员工面前，只是要求做某事。 在大型组织中，可能有 60% 的工作是计划外的。 高达 40% 的工作没有以任何方式记录下来。 如果是波音，我这辈子都不会再登上他们的飞机了。 如果只记录了一半的工作，那么就无法知道这项工作是否正确完成。 所有其他方法都被证明是无用的 - 尝试自动化任何东西是没有意义的，因为已知的 50% 可能是工作中最连贯和清晰的部分，其自动化不会产生很好的结果，而且是最糟糕的事物都处于看不见的一半。 在没有文档的情况下，不可能找到各种黑客行为和隐藏的工作，更不可能找到瓶颈，即我已经讨论过的那些“Brents”。 多米尼加·德格兰迪斯有一本很棒的书 。 她透露 五种不同的“时间泄漏” （时间的窃贼）：
- 在制品 (WIP) 过多
- 未知的依赖关系
- 计划外的工作
- 优先事项相互冲突
- 被忽视的工作
这是非常有价值的分析，这本书也很棒，但是如果只有 50% 的数据可见，那么所有这些建议都是毫无用处的。 如果准确率达到90%以上，则可以使用多米尼加提出的方法。 我说的是这样的情况：老板给下属一个15分钟的任务，但他花了三天； 但老板并不真正知道这个下属还要依赖其他四五个人。
凤凰计划是一个关于一个晚了三年的项目的精彩故事。 其中一个角色因此面临被解雇，他遇到了另一个被描绘成苏格拉底的角色。 他帮助找出到底出了什么问题。 原来，公司有一位系统管理员，名叫布伦特，所有的工作都通过他进行。 在一次会议上，一位下属被问到：为什么每个半小时的任务要花一周的时间？ 答案是排队理论和利特尔定律的一个非常简单的演示，在这个演示中，事实证明，在 90% 的占用率下，每个小时的工作需要 9 个小时。 每个任务都需要发送给另外七个人，这样一小时就变成了 63 小时，7 乘以 9。我的意思是，为了使用利特尔定律或任何复杂的排队论，你至少需要有数据。
因此，当我谈论可见性时，我并不是指所有内容都在屏幕上，而是指您至少拥有数据。 当他们这样做时，往往会发现有大量计划外的工作在不需要的时候以某种方式被发送到布伦特。 布伦特是一个很棒的人，他永远不会说不，但他不会告诉任何人他是如何做他的工作的。
当工作可见时，可以将数据整齐地分类（这就是多米尼克在照片中所做的），可以应用五次泄漏的抽象，并且可以应用自动化。
2. 整合工作管理系统：任务管理
我所说的原型是一种金字塔。 如果第一个做得正确，那么第二个就已经是一种附加组件了。 其中许多不适用于初创公司，对于财富 5000 强等大型公司来说，需要牢记它们。我工作的上一家公司有 10 个票务系统。 一个团队使用 Remedy，另一个团队编写了某种自己的系统，第三个团队使用 Jira，还有一些团队使用电子邮件。 如果公司有 30 条不同的管道，也会出现同样的问题，但我没有时间讨论所有此类情况。
我与人们讨论门票是如何创建的，接下来会发生什么，以及如何规避它们。 最有趣的是，我们会议上的人们说话都很真诚。 我问有多少人对实际上应该给予“重大影响”的门票提出“轻微/无影响”。 事实证明，几乎每个人都这样做。 我不参与谴责，也尽量不去指名道姓。 当他们真诚地向我坦白某件事时，我不会泄露这个人。 但当几乎每个人都绕过该系统时，这意味着所有安全措施本质上都是门面。 因此，无法从该系统的数据得出任何结论。
要解决票务问题，您需要选择一个主系统。 如果您使用 Jira，请保留 Jira。 如果有任何选择，那就让它成为唯一的选择。 最重要的是，门票应该被视为开发过程中的另一个步骤。 每个操作都必须有一个票证，该票证必须贯穿开发工作流程。 票证被发送给团队，团队将其发布在故事板上，然后对其负责。
这适用于所有部门，包括基础设施和运营部门。 在这种情况下，至少可以对事态形成一些看似合理的想法。 一旦建立了这个流程，就可以很容易地确定谁负责每个应用程序。 因为现在我们收到的新服务不是 50%，而是 98%。 如果这个核心流程有效，那么整个系统的准确性就会提高。
服务管道
这同样只适用于大公司。 如果您是新领域的新公司，请卷起袖子，使用 Travis CI 或 CircleCI 进行工作。 说到世界5000强企业，我工作的银行就是一个很好的例子。 Google 找到了他们，并向他们展示了旧 IBM 系统的图表。 谷歌的人困惑地问——这个的源代码在哪里？ 但没有源代码，甚至没有 GUI。 这是大型组织必须面对的现实：古老的大型机上有 40 年历史的银行记录。 我的一位客户使用具有断路器模式的 Kubernetes 容器以及 Chaos Monkey，所有这些都用于 KeyBank 应用程序。 但这些容器最终连接到 COBOL 应用程序。
Google 的人完全有信心他们会解决我客户的所有问题，然后他们开始问问题：什么是 IBM datapipe？ 他们被告知：这是一个连接器。 它连接到什么？ 到斯佩里系统。 那是什么？ 等等。 乍一看：能有什么样的DevOps？ 但事实上，这是可能的。 有些交付系统允许您将工作流程移交给交付团队。
3.约束理论：约束理论
让我们继续讨论第三个原型：制度/“部落”知识。 一般来说，在任何组织中都有几个人知道一切并管理一切。 这些人在组织中任职时间最长，并且了解所有解决方法。
当图表上出现这种情况时，我特意用标记圈出了这些人：例如，事实证明某个卢出席了所有会议。 我很清楚：这是当地的布伦特原油。 当 CIO 在穿 T 恤和运动鞋的我和穿西装的 IBM 人员之间进行选择时，我被选中是因为我可以告诉主管一些其他人不会告诉的事情，而主管可能不喜欢听。 我告诉他们，他们公司的瓶颈是一个叫弗雷德和一个叫卢的人。 这个瓶颈需要被解开，他们的知识需要以某种方式从他们那里获得。
为了解决这类问题，我可以建议使用 Slack。 聪明的导演会问——为什么？ 通常，在这种情况下，DevOps 顾问会回答：因为每个人都在这样做。 如果导演真的聪明的话，他会说：那又怎样。 对话到此结束。 我对此的回答是：因为公司有四个瓶颈，Fred、Lou、Susie 和 Jane。 为了将他们的知识制度化，必须首先引入 Slack。 你们所有的维基百科都是胡说八道，因为没有人知道它们的存在。 如果工程团队涉及前后端开发，大家都需要知道，有问题可以联系前端开发团队或者基础设施团队。 那时 Lou 或 Fred 可能有时间加入 wiki。 然后在 Slack 中，有人可能会问为什么，比如说，第 5 步不起作用。然后 Lou 或 Fred 会更正 wiki 上的说明。 如果你建立了这个过程，那么很多事情就会自行水到渠成。
这是我的主要观点：要推荐任何高科技，你必须首先把它们的基础打好，这可以通过刚才描述的低技术解决方案来完成。 如果你从高科技开始，而不解释为什么需要它们，那么，通常，结果不会好。 我们的一个客户使用 Azure ML，这是一种非常便宜且简单的解决方案。 自学习机本身回答了大约 30% 的问题。 而且这个东西是不涉及数据科学、统计学或者数学的操作人员写的。 这很重要。 这种解决方案的成本是最低的。
4. 协作技巧：协作技巧
第四个原型是对抗孤立的需要。 大多数人已经知道这一点：孤立会滋生敌意。 如果每个部门都在自己的楼层，除了电梯之外，人们之间没有任何交集，那么他们之间很容易产生敌意。 但相反，如果人们彼此共处一个房间，她就会立即离开。 当有人抛出一些笼统的指责时，例如，某某界面永远无法工作，没有什么比这更容易解构这样的指责了。 编写界面的程序员只需要开始提出具体问题，很快就会发现，例如，用户只是错误地使用了该工具。
有很多方法可以克服孤立。 曾经有人请我为澳大利亚的一家银行提供咨询，但我拒绝了，因为我有两个孩子和一个妻子。 我所能做的就是向他们推荐图形化的故事讲述方式。 这是被证明有效的方法。 另一种有趣的方式是精益咖啡会议。 在大型组织中，这是传播知识的绝佳选择。 此外，您还可以举办内部开发日、黑客马拉松等。
5. 教练卡塔
正如我一开始就警告过的，今天我不会谈论这个。 如果您有兴趣，可以看一下 .
Mike Rother 关于这个主题也有一篇很好的演讲：
6、市场导向：以市场为导向的组织
这里有不同的问题。 例如“I”人、“T”人、“E”人。 “我”的人是那些只做一件事的人。 通常，它们存在于具有孤立部门的组织中。 “T”是指一个人擅长一件事，同时也擅长其他一些事情。 “E”甚至“comb”表示一个人拥有多种技能。
康威定律在这里起作用（），最简单的形式可以表述如下：如果三个团队致力于编译器，那么结果将是一个由三个部分组成的编译器。 因此，如果一个组织内部存在高度的隔离，那么这个组织中即使是 Kubernetes、Circuit Breaker、API 扩展性等花哨的东西也会按照组织本身的方式来安排。 严格按照康威的说法，也是为了刁难你们这些年轻的极客。
该问题的解决方案已被描述过多次。 例如，费尔南多·费尔南德斯描述了组织原型。 我刚才讲的那个有问题的架构，加上隔离，是一个面向功能的架构。 第二种是最糟糕的，矩阵架构，是其他两种的混乱。 第三种是大多数初创公司所见，大公司也在尝试匹配这种类型。 它是一个以市场为导向的组织。 在这里，我们进行优化以实现对客户请求的最快响应。 这有时被称为扁平组织。
很多人以不同的方式描述这个结构，我喜欢这样的措辞 建立/运行团队，在亚马逊他们称之为 两个披萨队。 在这种结构中，所有“I”型人都围绕一种服务聚集在一起，逐渐向“T”型人靠拢，如果管理到位，甚至可以成为“E”型人。 这里的第一个反驳是这样的结构包含不必要的元素。 如果可以有一个专门的测试人员部门，为什么每个部门都需要一名测试人员呢？ 我的回答是：这种情况下的额外成本是整个组织未来成为“E”型的代价。 在这个结构中，测试人员逐渐了解网络、架构、设计等。 因此，组织中的每个参与者都充分了解组织中发生的一切。 如果您想了解该方案在工业中的运作方式，请阅读 .
7. 左移审核员：在周期的早期进行审核。 遵守展示的安全规则
可以这么说，这是当你的行为没有通过气味测试时。 为你工作的人并不傻。 如果像上面的例子一样，他们在各处设置了轻微/无影响，持续了三年，没有人注意到任何事情，那么每个人都清楚地知道该系统不起作用。 或者另一个例子 - 变更咨询委员会，需要每周（例如周三）提交报告。 有一群人在那里工作（顺便说一句，工资不是很高），从理论上讲，他们应该知道整个系统是如何运作的。 在过去的五年里，您可能已经注意到我们的系统非常复杂。 五六个人必须就一项他们没有做出且他们一无所知的改变做出决定。
当然，这种方法是行不通的。 我必须摆脱这些东西，因为这些人没有保护系统。 决定必须由团队自己做出，因为团队必须对此负责。 否则，当一个一生中从未写过代码的经理告诉程序员应该花多长时间写代码时，就会出现矛盾的情况。 我工作过的一家公司有 7 个不同的委员会来审查每一项变更，包括架构委员会、产品委员会等。 甚至还有一个强制性的等待期，尽管一位员工告诉我，在十年的工作中，没有人拒绝过这个人在这个强制性的期间所做的改变。
需要邀请审核员加入我们，而不是解雇他们。 告诉他们您编写了不可变的二进制容器，如果它们通过了所有测试，则永远保持不可变。 告诉他们您有一个管道即代码并解释这意味着什么。 向他们展示以下方案：通过所有漏洞测试的容器中的不可变只读二进制文件； 然后不仅没有人接触它，他们甚至没有接触创建管道的系统，因为它也是动态创建的。 我的客户 Capital One 正在使用 Vault 来创建类似区块链的东西。 审核员不需要展示Chef的“菜谱”；展示区块链就足够了，从中可以清楚生产中的Jira票据发生了什么以及谁对此负责。
根据 由 Sonatype 在 2018 年创建，2017 年有 87 亿个 OSS 下载请求。
由于漏洞而造成的损失是惊人的。 此外，您现在看到的上面的数字不包括机会成本。 简而言之，DevSecOps 是什么？ 我马上说，我没有兴趣谈论这个名字有多成功。 关键是，既然 DevOps 如此成功，我们应该尝试增加该管道的安全性。
此序列的示例：
尽管我喜欢所有产品，但这并不是针对特定产品的推荐。 我引用它们作为例子是为了说明DevOps最初是基于工业界的组织范式，它允许你将产品的每个阶段的工作自动化。
我们没有理由不采取同样的安全方法。
总
作为结论，我将给出一些 DevSecOps 的技巧。 您需要让审核员参与创建系统的过程，并花时间对他们进行教育。 您需要与审核员合作。 接下来，您需要对误报进行绝对无情的打击。 即使使用最昂贵的漏洞扫描工具，如果您不知道信噪比是多少，您最终也可能会在开发人员中养成极其坏的习惯。 开发人员会对事件感到不知所措，并会简单地删除它们。 如果您听说过 Equifax 的故事，那几乎就是那里发生的事情，最高警报级别被忽略了。 此外，需要以一种明确的方式解释漏洞，以明确它们如何影响业务。 例如，您可以说这与 Equifax 故事中的漏洞相同。 安全漏洞应该像其他软件问题一样对待，也就是说，它们应该包含在整个 DevOps 流程中。 您需要通过 Jira、看板等与他们合作。 开发人员不应该认为其他人会这样做——相反，每个人都应该这样做。 最后，你需要花精力去培训人才。
有用的链接
以下是 DevOops 会议上的一些演讲，您可能会觉得有用：
- Sergey Berdnikov、Artyom Kalichkin - 成功故事，或“Dev+DevOps+Ops”（, )
- Baruch Sadogursky、Leonid Igolnik - 大规模的 DevOps：三幕希腊悲剧（, )
- 亚历山大·蒂托夫、基里尔·托尔卡乔夫 -
- 蒂莫西·李斯特 -
调查 DevOops 2020 莫斯科 - 还有很多有趣的事情。
来源： habr.com