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