Anton Weiss，Otomato Software 创始人兼董事，以色列首个 DevOps 认证的发起人和讲师之一，在去年的大会上发表了讲话 关于混沌理论和混沌工程的主要原理，还解释了未来理想的 DevOps 组织如何运作。
我们准备了该报告的文本版本。
早上好！
连续第二年在莫斯科举行 DevOpsDays，这是我第二次登上这个舞台，你们中的许多人也是第二次来到这个房间。 这是什么意思？ 这意味着俄罗斯的 DevOps 运动正在增长、倍增，最重要的是，这意味着 2018 年是时候谈论 DevOps 是什么了。
认为 DevOps 在 2018 年已经成为一个职业的举手？ 有这样的。 房间里是否有任何 DevOps 工程师的职位描述为“DevOps 工程师”？ 房间里有 DevOps 经理吗？ 不存在这样的。 DevOps 架构师？ 也没有。 不够。 真的没有人说自己是 DevOps 工程师吗？
所以你们大多数人认为这是一种反模式？ 这样的职业不应该存在吗？ 我们可以想怎么想就怎么想，但就在我们思考的同时，业界正在DevOps的号角声中庄严前行。
谁听说过一个名为 DevDevOps 的新主题？ 这是一项新技术，允许开发人员和开发人员之间进行有效的协作。 而且也不那么新了。 从 Twitter 来看，他们四年前就已经开始讨论这个问题了。 而直到现在，人们对此的兴趣越来越大，那就是有一个问题。 问题需要解决。
我们是富有创造力的人，我们不只是安逸地休息。 我们说：DevOps这个词还不够全面；它仍然缺乏各种不同的、有趣的元素。 我们走进秘密实验室，开始产生有趣的突变：DevTestOps、GitOps、DevSecOps、BizDevOps、ProdOps。
逻辑是铁定的吧？ 我们的交付系统无法正常运行，我们的系统不稳定，我们的用户不满意，我们没有时间按时推出软件，我们不符合预算。 我们要如何解决这一切？ 我们会想出一个新词！ 将以“Ops”结束，问题就解决了。
所以我称这种方法为“Ops，问题就解决了。”
如果我们提醒自己为什么会想到这一切，那么这一切都会消失在背景中。 我们提出了整个 DevOps 的概念，以使软件交付和我们自己在这个过程中的工作尽可能不受阻碍、无痛、高效，最重要的是，尽可能令人愉快。
DevOps 是从痛苦中诞生的。 我们厌倦了苦难。 为了实现这一切，我们依赖常青实践：有效协作、流程实践，以及最重要的系统思维，因为没有它，DevOps 就无法发挥作用。
什么是系统？
如果我们已经在谈论系统思维，那么让我们提醒自己什么是系统。
如果你是一个革命性的黑客，那么对你来说这个系统显然是邪恶的。 它就像一片乌云笼罩着你，迫使你做你不想做的事情。
从系统思维的角度来看，系统是由部分组成的整体。 从这个意义上说，我们每个人都是一个系统。 我们工作的组织是系统。 你和我正在构建的东西被称为系统。
所有这一切都是一个庞大的社会技术系统的一部分。 只有当我们了解这个社会技术系统如何协同工作时，我们才能真正优化这件事。
从系统思维的角度来看，系统具有各种有趣的属性。 首先，它由部件组成，这意味着它的行为取决于部件的行为。 此外，它的所有部分也是相互依赖的。 事实证明，系统的部件越多，理解或预测其行为就越困难。
从行为的角度来看，还有另一个有趣的事实。 该系统可以做一些其各个部分都无法做到的事情。
正如拉塞尔·阿科夫博士（系统思维的创始人之一）所说，通过思想实验很容易证明这一点。 例如，房间里谁知道如何编写代码？ 有很多手，这很正常，因为这是我们职业的主要要求之一。 你知道怎么写，但是你的手能脱离你而独立地写代码吗？ 有人会说：“不是我的手写代码，而是我的大脑写代码。” 你的大脑可以与你分开编写代码吗？ 嗯，可能不会。
大脑是一个神奇的机器，我们甚至不知道它是如何工作的 10%，但它不能脱离我们身体的系统而独立运作。 这很容易证明：打开你的头骨，取出你的大脑，把它放在电脑前，让他尝试写一些简单的东西。 例如，Python 中的“Hello, world”。
如果一个系统可以做一些其任何部分都无法单独完成的事情，那么这意味着它的行为不是由其部分的行为决定的。 那么它是由什么决定的呢？ 它是由这些部分之间的相互作用决定的。 因此，部件越多，交互越复杂，理解和预测系统的行为就越困难。 这使得这样的系统变得混乱，因为系统任何部分的任何，甚至是最微不足道的、看不见的变化都可能导致完全不可预测的结果。
这种对初始条件的敏感性首先由美国气象学家埃德·洛伦兹发现并研究。 随后，它被称为“蝴蝶效应”，并导致了一场被称为“混沌理论”的科学思想运动的发展。 该理论成为 20 世纪科学的主要范式转变之一。
混沌理论
研究混沌的人称自己为混沌学家。
实际上，写这份报告的原因是，在与复杂的分布式系统和大型国际组织合作的过程中，在某个时刻我意识到这就是我想要的人。 我是一名混沌学家。 这基本上是一种聪明的说法：“我不明白这里发生了什么，我不知道该怎么办。”
我想你们很多人也经常有这样的感觉，所以你们也是混沌学家。 我邀请你加入混沌学家协会。 亲爱的混沌学家同事，你和我将研究的系统称为“复杂自适应系统”。
什么是适应性？ 适应性意味着这种适应性系统中各个部分的个体和集体行为会发生变化和自组织，以响应系统中的事件或微事件链。 也就是说，系统通过自组织来适应变化。 这种自组织能力是基于自由自主主体的自愿、完全去中心化的合作。
此类系统的另一个有趣的特性是它们可以自由扩展。 作为混沌学家兼工程师，我们无疑应该对什么感兴趣。 那么，如果我们说一个复杂系统的行为是由其各部分的相互作用决定的，那么我们应该对什么感兴趣呢？ 相互作用。
还有两个更有趣的发现。
首先，我们明白复杂的系统不能通过简化其组成部分来简化。 其次，简化复杂系统的唯一方法是简化其各部分之间的交互。
我们如何互动？ 你和我都是人类社会这个庞大信息系统的一部分。 我们通过一种共同语言进行互动，如果我们有它，如果我们找到它的话。
但语言本身是一个复杂的适应性系统。 因此，为了更有效、更简单地交互，我们需要创建某种协议。 也就是说，一些符号和动作的序列将使我们之间的信息交换更简单、更可预测、更容易理解。
我想说的是，一切事物都可以追溯到复杂性、适应性、去中心化、混乱的趋势。 在你和我正在构建的系统中，以及在我们所属的系统中。
并不是没有根据的，让我们看看我们创建的系统正在如何变化。
我明白，你在等这个词。 我们正在参加一个 DevOps 会议，今天这个词将会被听到十万次，然后我们会在晚上梦见它。
微服务是第一个针对 DevOps 实践而出现的软件架构，旨在使我们的系统更加灵活、更具可扩展性，并确保持续交付。 她是怎么做到的？ 通过减少服务量、缩小这些服务处理的问题范围、缩短交付时间。 也就是说，我们减少和简化了系统的各个部分，增加了它们的数量，相应地，这些部分之间相互作用的复杂性必然增加，也就是说，出现了我们必须解决的新问题。
微服务并不是终结，总的来说，微服务已经是昨天的事情了，因为无服务器即将到来。 所有服务器都被烧毁，没有服务器，没有操作系统，只有纯粹的可执行代码。 配置是独立的，状态是独立的，一切都由事件控制。 美丽、干净、安静，没有事件，什么也没有发生，秩序井然。
复杂性在哪里？ 当然，困难在于互动。 一个功能单独可以做多少事情？ 它如何与其他功能交互？ 消息队列、数据库、平衡器。 发生故障时如何重新创建某些事件？ 问题很多，答案却很少。
微服务和无服务器就是我们这些极客潮人所说的云原生。 一切都与云有关。 但云的可扩展性也存在固有的限制。 我们习惯于将其视为分布式系统。 事实上，云提供商的服务器位于哪里？ 在数据中心。 也就是说，我们这里有一种集中式的、非常有限的分布式模型。
今天，我们了解到，物联网不再只是一个大词，即使根据适度的预测，在未来五到十年内，连接到互联网的数十亿设备正在等待着我们。 大量有用和无用的数据将被合并到云端并从云端上传。
云不会持久，因此我们越来越多地谈论边缘计算。 或者说我也喜欢“雾计算”这个精彩的定义。 它笼罩在浪漫主义和神秘主义的神秘色彩中。
雾计算。 关键是云是水、蒸汽、冰和石头的集中团块。 雾是散布在我们周围大气中的水滴。
在雾范例中，大部分工作是由这些液滴完全自主地或与其他液滴协作完成的。 只有当他们确实感到压力很大时，他们才会转向云。
也就是说，再次去中心化、自治，当然，你们中的许多人已经了解这一切的走向，因为你不能在不提及区块链的情况下谈论去中心化。
有些人相信，这些人投资了加密货币。 有些人相信但又害怕，比如我。 还有一些人不相信。 在这里你可以区别对待。 有技术，有新的未知事物，有问题。 与任何新技术一样，它提出的问题多于它回答的问题。
围绕区块链的炒作是可以理解的。 抛开淘金热不谈，这项技术本身就蕴含着对更光明未来的非凡承诺：更多自由、更多自主、分布式全球信任。 什么是不想要的？
因此，全球越来越多的工程师开始开发去中心化应用程序。 这是一种不能仅仅通过说“啊，区块链只是一个实施得很差的分布式数据库”就可以忽视的力量。 或者正如怀疑论者喜欢说的那样：“区块链没有真正的应用程序。” 如果你想一想，150 年前他们对电力也说过同样的话。 他们在某些方面甚至是正确的，因为今天电力所带来的一切在 19 世纪是不可能实现的。
对了，谁知道屏幕上是什么标志？ 这就是超级账本。 这是一个在 Linux 基金会的支持下开发的项目，包含一套区块链技术。 这确实是我们开源社区的优势。
混沌工程
因此，我们正在开发的系统变得越来越复杂、越来越混乱、适应性越来越强。 Netflix 是微服务系统的先驱。 他们是最先了解这一点的人之一，他们开发了一套被称为“Simian Army”的工具，其中最著名的是 。 他定义了后来被称为 .
顺便说一句，在编写报告的过程中，我们甚至将这篇文章翻译成俄语，所以请访问 、读、评论、骂。
简而言之，混沌工程的原理如下。 复杂的分布式系统本质上是不可预测的并且本质上是有缺陷的。 错误是不可避免的，这意味着我们需要接受这些错误并以完全不同的方式使用这些系统。
我们自己必须尝试将这些错误引入我们的生产系统，以便测试我们的系统是否具有同样的适应性，即自组织和生存的能力。
这改变了一切。 不仅包括我们如何将系统投入生产，还包括我们如何开发它们、如何测试它们。 代码不存在稳定或冻结的过程；相反，存在持续不稳定的过程。 我们正在努力消灭这个系统并让它继续生存。
分布式系统集成协议
因此，这需要我们的系统做出某种改变。 为了使它们变得更加稳定，它们需要一些新的协议来实现各部分之间的交互。 这样这些部分就可以达成一致并形成某种自组织。 各种新工具、新协议出现，我称之为“分布式系统交互协议”。
我在说什么？ 一、项目 。 有些人试图创建一个通用的分布式跟踪协议，这是调试复杂分布式系统绝对不可或缺的工具。
进一步 - 。 我们说我们无法预测系统会发生什么，就是我们需要增加它的可观察性、可观察性。 Opentracing 属于一系列为我们的系统提供可观察性的工具。 但我们需要可观察性来确定系统的行为是否符合我们的预期。 我们如何定义预期行为？ 通过定义某种政策、一些规则。 开放策略代理项目正在努力定义这套从访问到资源分配的规则。
正如我们所说，我们的系统越来越由事件驱动。 无服务器是事件驱动系统的一个很好的例子。 为了让我们在系统之间传输事件并跟踪它们，我们需要一些通用语言，一些通用协议来描述我们如何谈论事件以及如何将它们相互传输。 这就是一个项目的名字 .
不断的变化流冲刷着我们的系统，不断地破坏系统的稳定性，这是一种连续的软件工件流。 为了让我们保持这种持续的变化流，我们需要某种通用协议，通过它我们可以谈论什么是软件工件、它是如何测试的、它通过了哪些验证。 这就是一个项目的名字 。 即软件工件的通用元数据协议。
最后，如果我们希望我们的系统完全独立、自适应和自组织，我们必须赋予它们自我认同的权利。 项目名为 这正是他所做的。 这也是云原生计算基金会赞助的一个项目。
所有这些项目都很年轻，它们都需要我们的爱，我们的认可。 这都是开源的，我们的测试，我们的实现。 他们向我们展示了技术的发展方向。
但 DevOps 从来都不是主要关注技术，它始终关注人与人之间的协作。 因此，如果我们希望我们开发的系统发生改变，那么我们自己就必须改变。 事实上，无论如何我们都在改变；我们没有太多选择。
有一个美妙的 英国作家雷切尔·博茨曼 (Rachel Botsman) 在书中讲述了人类历史上信任的演变。 她说，最初，在原始社会，信任是局部的，也就是说，我们只信任那些我们亲自认识的人。
然后是一个很长的时期——一个信任集中化的黑暗时期，当时我们开始信任那些我们不认识的人，因为我们属于同一个公共或国家机构。
这就是我们在现代世界中看到的情况：信任变得越来越分布式和去中心化，并且它基于信息流动的自由和信息的可用性。
如果你仔细想想，这种可访问性使这种信任成为可能，这正是你和我正在实施的。 这意味着我们的协作方式和工作方式都必须改变，因为旧的集中式、分层式 IT 组织已不再有效。 它们开始死亡。
DevOps 组织基础知识
未来理想的 DevOps 组织是一个由自治团队组成的去中心化、自适应系统，每个团队都由自治个人组成。 这些团队分散在世界各地，通过异步通信和高度透明的通信协议相互有效协作。 非常漂亮，不是吗？ 一个非常美好的未来。
当然，如果没有文化变革，这一切都是不可能的。 我们必须具有变革型领导力、个人责任感、内在动力。
这是 DevOps 组织的基础：信息透明度、异步通信、变革型领导、权力下放。
倦怠
我们所属的系统和我们构建的系统越来越混乱，我们人类很难应对这种想法，很难放弃控制的幻想。 我们试图继续控制它们，这往往会导致倦怠。 我是根据我自己的经验这么说的，我也被烧伤过，我也因生产中不可预见的故障而瘫痪。
当我们试图控制本质上无法控制的事情时，就会出现倦怠。 当我们精疲力尽时，一切都失去了意义，因为我们失去了做新事物的欲望，我们变得防御性并开始捍卫我们所拥有的东西。
正如我经常提醒自己的那样，工程职业首先是一个创造性的职业。 如果我们失去了创造东西的欲望，那么我们就会变成灰烬，变成灰烬。 人们精疲力尽，整个组织都精疲力尽。
在我看来，只有接受混沌的创造力，只有根据其原则建立合作，才能帮助我们不失去我们职业的优点。
这就是我对你的祝愿：热爱你的工作，热爱我们所做的事情。 这个世界以信息为食，我们很荣幸能够提供信息。 因此，让我们研究混沌，让我们成为混沌学家，让我们带来价值，创造新的东西，好吧，正如我们已经发现的那样，问题是不可避免的，当它们出现时，我们只会说“Ops！”，问题就解决了。
除了混沌猴还有什么？
事实上，所有这些乐器都非常年轻。 同一个 Netflix 为自己构建了工具。 构建您自己的工具。 阅读混沌工程的原理并遵守这些原理，而不是试图寻找其他人已经构建的其他工具。
尝试了解您的系统如何崩溃，并开始对其进行分解，看看它们如何维持下去。 这是第一位的。 您可以寻找工具。 各种各样的项目都有。
当你说系统不能通过简化组件来简化时，我不太明白，并立即转向微服务，微服务通过简化组件本身和复杂化交互来简化系统。 这本质上是两个相互矛盾的部分。
没错，微服务总体来说是一个非常有争议的话题。 事实上，简化零件可以提高灵活性。 微服务提供什么？ 它们给了我们灵活性和速度，但它们肯定没有给我们带来简单性。 它们增加了难度。
那么，在DevOps理念中，微服务不是什么好事呢？
任何好事都有反面。 好处是它增加了灵活性，使我们能够更快地进行更改，但它增加了复杂性，从而增加了整个系统的脆弱性。
不过，哪个更强调：简化交互还是简化部件？
当然，重点是简化交互，因为如果我们从与您合作的角度来看，那么首先我们需要关注简化交互，而不是简化工作。我们每个人分别。 因为简化工作意味着变成机器人。 在麦当劳，当你有指示时，它会正常工作：在这里你把汉堡放在这里，在这里你把酱汁倒在上面。 这在我们的创造性工作中根本不起作用。
难道你所说的一切都生活在一个没有竞争的世界里，而且那里的混乱是如此仁慈，而且这混乱之中没有任何矛盾，没有人想吃或杀任何人？ 竞争和 DevOps 应该如何发展？
嗯，这取决于我们谈论的是哪种类型的竞争。 是职场竞争还是公司之间的竞争？
关于服务存在的竞争，因为服务不是几家公司。 我们正在创造一个新型的信息环境，任何环境都离不开竞争。 到处都有竞争。
同样是Netflix，我们以他们为榜样。 他们为什么想出这个？ 因为他们需要具有竞争力。 这种灵活性和移动速度正是非常有竞争力的要求；它给我们的系统带来了混乱。 也就是说，混乱不是我们有意识地做的事情，因为我们想要它，它是因为世界需要它而发生的事情。 我们只需要适应。 而混乱，正是竞争的结果。
这是否意味着混乱就是缺乏目标？ 或者那些我们不想看到的目标？ 我们在家里，不了解别人的目标。 事实上，竞争是因为我们有明确的目标，我们知道下一个时刻我们会到达哪里。 在我看来，这就是 DevOps 的本质。
还看一下问题。 我认为我们都有相同的目标：生存并与之共存
最大的荣幸。 任何组织的竞争目标都是相同的。 生存往往是通过竞争来实现的，你对此无能为力。
今年的会议 将于 7 月 11 日在 Technopolis 举行。 我们在 XNUMX 月 XNUMX 日之前接受报告申请。 如果您想发言，请联系我们。
参与者注册现已开放，门票价格为 7000 卢布。 加入我们！
来源： habr.com