我最近访问了由Logrocon主持的DevOpsForum 2019。 在这次会议上，与会人员试图找到解决方案和新工具，以使企业与开发和信息技术服务领域的专家进行有效的互动。
会议取得了成功：确实有很多有用的演讲，有趣的演讲形式以及与演讲者的大量交流。 尤其重要的是，没有人试图向我出售任何东西，而最近大型会议的发言人都对此负责。
仔细阅读Raiffeisenbank的演讲Alfastrakhovanie，Mango Telecom在削减自动化方面的经验以及其他细节。
我的名字叫Yana，我是测试人员，我从事自动化以及DevOps，我喜欢参加会议。 在过去的两年中，我去过Oleg Bunin的会议（HighLoad ++，TeamLead Conf），水罐活动（Heisenbug，JPoint），TestCon莫斯科，DevOps Pro莫斯科，大数据莫斯科。
首先，我注意会议程序。 在较小的程度上，我会看报告的内容，在很大程度上-是针对演讲者的。 即使该报告非常技术性和趣味性，您也不可能在公司中应用该报告中的一些最佳实践。 然后，您需要一名发言人。
Raiffeisenbank管道尽头的光
通常，我会在场边寻找有趣的演讲者。 在2019年DevOpsForum上，来自Raiffeisenbank的发言人Mikhail Bizhan进入了我感兴趣的领域。 在演讲中，他讲述了他们如何在DevOps上稳步建立团队，为什么需要它以及如何将DevOps转型的想法推销给企业。 好吧，总的来说，我谈到了如何看到管道末端的光。
Raiffeisenbank的自动化总监Mikhail Bizhan现在他们的公司没有“ DevOps”。 也就是说，他是真实的，但并非在所有团队中都如此。 在实施DevOps时，无论是从特定工程师的角度，还是从产品需求以及构建该产品的平台的成熟度的角度，他们都依赖团队的意愿。 Misha讲述了如何向企业解释为什么需要DevOps。
银行部门有几个增长动力：服务成本和客户群的扩大。 增加服务成本并不是一个很好的驱动力，但是客户群的增长却恰恰相反。 如果竞争对手生产出客观上很酷的产品，那么所有客户都会去那里，随着时间的推移，市场将趋于均衡。 因此，新产品在市场上的推出及其发布的速度是银行的主要目标。 这正是DevOps的目的，并且企业对此也了解。
以下重要说明：DevOps并不总是会缩短产品上市时间。 DevOps不能单独工作，它只是从开发到生产（从代码到客户端）在市场上创建和发布产品的过程的一部分。 但是代码之前的所有内容都与DevOps没有直接关系。 也就是说，营销人员可以研究市场多年，并一生追上竞争对手。 您需要快速了解客户的需求并计划特定功能的实现-通常这不足以使DevOps正常工作并不能使公司实现目标。 因此，首先，Raiffeisenbank与企业达成一致，有必要学习如何使用DevOps。 为了自动化而进行的自动化对新客户的奋斗没有太大帮助。
总的来说，Misha认为应该实施DevOps，但这是明智的。 而且，您必须为以下事实做好准备：在转换开始时，团队将失去生产力，赚取的钱会更少，但是后来变成了现实。
芒果电信的测试自动化
来自Mango Telecom的Yegor Maslov作为测试人员为我做了另一个有趣的报告。 该演讲被称为“ SCRUM团队中整个测试周期的自动化”。 Egor认为DevOps是专门为SCRUM创建的，但是，与此同时，将DevOps引入SCRUM团队则存在很大问题。 这是因为SCRUM团队始终在某个地方运转，没有时间可以被创新和重建过程所分散。 问题还在于SCRUM并不暗示子团队（测试人员团队，开发团队等）。 嗯，此外，还需要文档来使现有过程自动化，并且在SCRUM中，通常根本没有文档-“产品比某种涂鸦更重要”。
切换到SCRUM后，测试人员开始向开发人员咨询如何测试功能。 逐渐地，功能的数量增加了，缺少了文档，并且他们开始发现该功能中的许多错误，这些错误没有测试范围，并且一般来说，不清楚谁在何时进行测试。 简而言之-困惑和困惑。 我们决定切换到测试自动化。 但是，那完全失败了。 他们吸引了自动化的外包专家，他们在常规测试人员所不知道的内容上进行写作。 自动测试框架确实有效，但是在外包商离开后，他住了两个星期。 然后尝试引入第二项自测。 首先，必须在SCRUM框架内以及在创建文档的过程中，在公司内部构建一切（正确的载体：在内部增加专业知识）。 用于自动化的堆栈应等于产品的堆栈（在此，我将直接指出，而且，请勿使用其他任何方式在JavaScript中测试您的项目）。 在sprint的最后，他们在整个团队的参与下（有用）安排了一个自动测试工作方式的演示。 因此，增加了所有团队成员在自动化过程中的参与度，以及对自动测试的信任，以及这种自动测试将被准确使用的机会（由于持续的失败，一个月之内将不予评论）。
顺便说一句，一个开放的麦克风在DevOpsForum 2019上工作-在我看来，这是一种众所周知的有用的表演形式。 您像这样走路，听报告，然后决定值得在会议框架内讨论主题或问题，并分享解决问题的相关经验。
我还注意到组织者做了一系列简短的报告。 每个报告的持续时间不超过10分钟，然后出现问题。 因此，您可以同时涵盖许多主题，并向感兴趣的演讲者提问。
在两次报告之间，我在会议合作伙伴的看台上走来走去，赢得了很多东西。 恩，我爱razdatku！与Alfastrah开发总监的圆桌会议和DevOps问题
对我来说，DevOpsForum 2019蛋糕上的樱桃是与DevOps专家进行的长达一个小时的全体会议。 邀请了四位参与者从不同角度观看DevOps：Anton Isanin（开发总监Alfastrakhovanie），Naila Zamashkina（金融技术实验室，运营总监），Oleg Egorkin（Rostelecom，敏捷教练）和Anton Martyanov（独立）专家，从业务角度研究了DevOps）。
专家们靠近人们，会议开始了：一个小时后，听众们问了他们的问题，专家们喘不过气来。 有时会出现真正的辩论。 问题有很大的不同，例如：是否需要DevOps工程师，为什么他们不能从系统管理员中成长，是否应该向所有人提供DevOps，其价值是什么等等。
然后，我亲自与安东·伊萨宁交谈。 我们讨论了将DevOps文化带入每个家庭的必要性，并揭示了DevOps转型的阴暗面。
想象每个人都聚集在一起，并决定产品，业务和团队都需要DevOps。 赶紧介绍。 全部解决了。 呼气。 DevOps使我们更接近客户，现在我们可以迅速实现他的所有愿望。 因此，我们有一个大型的Ops部门，具有严格的法规和要求，并且不断找出产品的缺陷，创建了许多应用程序。 此外，即使客户突然想将按钮涂成黄色而不是绿色，所有缺陷都带有“紧急”状态。 项目在不断发展，发行数量也在不断增长，因此，客户对新功能的缺陷和误解也越来越多。 Ops雇佣了另外10个人来跟上缺陷，而Development雇佣了另外15个人来跟上缺陷。 而且，该团队没有引入新功能，而是使用无穷无尽的SD，向用户解释其功能并支持其中的一项功能。 结果，Ops和开发都在工作，但客户和企业都不满意：新功能被卡住了。 事实证明，DevOps似乎在那儿，但似乎没有。
关于实施DevOps的需求，Anton明确表示，这直接取决于业务规模。 如果每年为一个客户提供服务为公司带来了十亿美元的收入，则不需要DevOps（前提是您无需定期向该客户推出新更改）。 一切都那么巧克力。 但是，如果业务增长，就会有更多的客户出现，那么我们必须已经遵守了。 通常，该公司最初没有出色的运营商。 首先，我们看到了产品，然后才了解该产品应该工作，您需要查看服务器，监视交付情况。 然后出现Ops。 尚需了解，Ops作为一个独立的部门，将开始暴露出一系列发展障碍，所有交付工作将开始停滞。 也就是说，在这种情况下，DevOps文化已经很重要，但您一定不要忘记它的阴暗面。