采访了我们的
六月HighLoad ++会议程序委员会成员之一的亚历山大·蒂托夫（Alexander Titov），其中的一部分将专门讨论DevOps。
在讨论DevOps“风”向何方发展的切入点以及该概念的确切方面时，将在论坛上进行讨论。
亚历山大（Alexander）对我们的社区非常熟悉，他是莫斯科DevOps和DevOpsDays莫斯科会议的组织者，他在我们的活动中发言已有数年之久，并帮助他们制定了计划。 他目前是Express 42的执行合伙人，该公司在技术公司中发展DevOps。 从2010年到2012年，亚历山大与奇克（Kik）经历了一次引人入胜的收购之路，从经营一家快速成长的初创公司到在一家大型国际公司微软（Microsoft）运营。 在此之前，他曾在2009年至2010年担任俄罗斯第一个云托管服务Skalaxi的技术总监。-让我们从远处开始：DevOps文化正在发展吗？ 近年来在这方面观察到了什么变化？ DevOps在俄罗斯看起来像什么？当然，在一个技术每三年相互变化的世界中，一切都在不断变化。 最初，基本问题是数字时代软件本身的生产和运营。 围绕这个问题，DevOps运动已经聚集起来。 现在，基本问题已分为许多子类别-基础结构管理，监视，持续集成，持续交付，与人共事（特别是从事开发和开发工作的人精疲力尽的问题），一些技术问题（例如Kubernetes的出现，例如这样的事实，适用于公司中整个基础架构平台）。 也就是说，从许多方面来看，都出现了细节：我们经历了一个阶段，该阶段需要像以前那样做不同的事情，尝试了许多新方法，并形成了一些解决常见（典型）问题的标准化流程。 但是与此同时，世界上许多公司的工具和流程仍然质量低劣或形式化程度很差。
在俄罗斯的背景下，另一个问题是我们不明白为什么所有这些都是必要的。 这使许多人迷失了方向。 我们分别进行了开发，测试和运营，然后引入了一些Kubernetes来解决一些问题，但是他们尝试在不改变人员的过程，方法和能力的情况下实现它。 一切都崩溃了。 以及为什么这些新技术尚不清楚。
-发生这种根本性转变的原因是什么？正如我已经提到的，我们开始解决另一个问题。 最初，经典IT解决了公司内部业务流程自动化的问题。 整个基础结构都已对此进行了调整-数据库，总线等。 自2000年网络泡沫危机以来，IT部门已转向创建可大量提供定制服务并带来一定价值的数字产品。 如果在公司生产某种型号的汽车之前，现在它已转向为每个客户进行定制。 这是另一个问题的解决方案，需要根本不同的方法和技术-不同的软件生产过程。 在这里，不再可能依次进行开发，测试和操作。 现在这些过程同时开始。
顺便说一句，尽管如此，还是有人误以为DevOps是关于操作的。 从事运营工作的传统系统管理员只是简单地重命名为DevOps工程师，从而在原则上抹黑了该术语。 实际上，这个概念更为广泛。 这是一组单独的实践，一个独立的框架，使您可以在一定条件下和具有一定能力的人员一起解决具体问题-不少，不少。 很少有人知道为什么这样做是必要的。 这是我们要通过会议解决的问题之一。
-
计划将哪些报告重点放在西伯利亚HighLoad的各个部分？如果之前有主要的运营报告，那么今年我们想添加有关与开发之间的联系的更多信息，例如，有关持续交付，持续集成，测试的过程。 一个很好的例子是Maxim Lapshin关于RIT ++的报告（作为Spring RootConf 2018的一部分），有关如何在盒子开发中使用DevOps。 这样的公司基本上没有剥削-它制造了一个盒子，出售给客户。 同时，她内部有DevOps。 这种方法打破了模式，但同时也有助于揭露DevOps仅与操作有关的神话。 这是我们的第一个基本重点。
第二个重点是新技术。 现在谈论Kubernetes，Prometheus和其他人已经很时髦了。 我们正在寻找能够在实践中感受到这些技术的人。 也就是说，不仅可以配置并使其正常工作，而且还可以将其包括在他们的开发过程中。 通常，我们尝试在软件生产过程中如何包含所有技术的基础上考虑所有技术-它们解决了什么问题，确定了哪些目标等。 如果您不谈论这个问题，人们就会开始以技术为先驱，开始使用技术：“让我们使用Kubernetes，我们就可以创建Google。” 那样行不通。
-持续集成的概念已经为市场所接受。 除了特定工具外，还有什么要谈的吗？当然可以 甚至可以说一个至关重要的基本概念是，在DevOps的上下文中，不对产品进行持续集成过程中的质量测试。 也就是说，产品在功能上的成熟程度无关紧要。 重要的是检查它的启动情况以及是否准备好与其他组件集成。
这是一个重大变化，因为在一致的开发，操作和测试中存在持续的集成。 但是在那里，在此级别上，将根据用户的要求检查产品的质量，并在DevOps的框架内检查功能质量。 正是这一阶段，可以在微服务基础架构的框架内最快地集成单个服务（如果没有微服务架构，DevOps作为一个整体就不存在）。
-今年重点关注哪些工具？首先，已经提到的Kubernetes。 它出现在前一段时间，但直到最近才可以使用。 现在，任何开发更新的数字服务的公司都可以使用它，例如，通过网站或移动应用程序提供服务。
通常称为Prometheus-监控系统，GitLab-称为连续集成系统。 还有整个HashiCorp堆栈-Vault，Terraform（均由HashiCorp开发）。 好吧，当然，Docker-作为一种交付格式。
-“一切都作为代码”概念的框架最近是否发生了变化？“一切都作为代码”本身的实践显然是有用的。 这是DevOps流程所基于的基本原则之一。 Kubernetes只是在继续这种意识形态。
在DevOps中，主要故事是“基础架构即代码”。 这不仅是一个概念，而且是一个过程，在该过程中，所有组件都以代码的形式呈现，允许基础结构的各个“部分”相互交互。 这里没有发生巨大的变化，但是作为一种实践，它现在正在Kubernetes内部发展。 例如，开发了诸如Helm之类的依赖项管理工具，用于创建单独模块的工具，基础架构描述（例如，运算符）（以及在Kubernetes中出现用于编写语句的框架）等。 换句话说，该仪器健康发展，并且实践在其中渗透。
-“一切都作为代码”的做法是否与值得讨论的工具分开？我们还没有完全形成一个程序，所以我不能说我们是否将专门针对HighLoad ++提出这样的主题。 但这本身是可能的。
有许多方法可以组织基础结构，管理基础结构代码中的依赖性并对其进行测试。 当然，我们将讨论用于实践的概念-例如，应将基础结构代码分为模块。 在我看来，与实践隔离开来，这样的主题不太适合。 但是，也许我们会选择一份报告，其中所有可能的方法都将在单个系统描述的框架内收集。 但是，当人们讲述和展示这些理论概念如何在现实中实现时，它具有更大的价值。 关于作为实践基础的理论，您可以在场外与同一个人交谈。
-有一种观点认为，随着时间的流逝，事件驱动的体系结构越来越流行。 您是否同意这一说法？事件驱动的基础结构一直是chatops方法的一部分-通过事件，我们在聊天中就某个基础结构应该发生什么做出决定。 对于大型公司来说，这个故事是非常必要的，但是对于其他观众来说，它还不是很成熟。 为了对应该发生的事情做出决定（我们应该做什么），有必要为团队内部的规则制定一些框架，以制定我们如何做出这些决定，以便每个人或多或少都一样-从一侧看。 因此，一切都变得很复杂。 开发这种框架的格式是每个人现在都在谈论的：如何将其自动化，带入工具，应如何在团队建设级别上完成以及如何与不同团队进行协调。
-是否以某种方式反映在会议报告中？不，HighLoad ++更多地是关于高负载的系统和工具，因此在这里我们可以讨论工具，而不是开发这样的框架。 但是在秋天，我们将有一个单独的RootConf会议，该会议将于10月1-2日举行。 直到2011年，它一直专注于运营问题（即，整个过程“开发-测试-运营”的一个组成部分）。 2015年，我们在整个DevOps的背景下对其进行了重新设计-因此我们逐渐扩展了该主题。 在RootConf上，我们讨论了如何确保开发人员和维护工程师之间的互动，讨论了新流程和技术，基础架构平台和基础架构管理，它们在DevOps范式中不仅涉及运营，还涉及开发（它们只是执行不同的任务）。
-在过去的几年中，有没有有趣的技术可以提高项目的弹性？ 会在会议上讨论吗？今天，我们遇到了一个与“容错”并不意味着“可靠性”这一事实有关的悖论。 如今，容错能力已被可靠性所取代。
容错是单片系统范式中的一个概念，其中可靠性问题是通过复制，增加资源等方式解决的。 现在，这种方法不再起作用。 可靠性基于根本不同的方法-这意味着系统的“抗脆弱性”。 也就是说，系统变成“软”的：如果我们对它采取行动，它就会改变而不是崩溃。 换句话说，如果您要构建某种新服务，则应提供其行为的此类变体，其中，如果用户或他工作的环境试图销毁该服务，则该服务仅更改其属性，而仍提供该服务，给出了一些结果。
趋势的一个很好的标志是现场可靠性工程的实践和个人专家的出现-现场可靠性工程师（SRE）替代了系统管理员过去的能力。 为了说明这一过程，我将提到Google以关于站点可靠性工程的书的形式发布了其DevOps实施实践，并且正在积极地将这一想法推广给大众。
我们还将在RootConf上讨论这一点。 现在，这个话题是关于西方的炒作，我们（由DevOps Moscow社区提供）正在尝试逐步将其引入我们。