我最近参加了由 Logrocon 主办的 DevOpsForum 2019。 在本次会议上，与会者试图寻找业务和开发以及信息技术服务专家之间有效互动的解决方案和新工具。
会议非常成功：确实有很多有用的报告、有趣的演示格式以及与演讲者的大量交流。 尤其重要的是，没有人试图向我推销任何东西，这是大型会议上的演讲者最近犯过的错误。
摘录自Raiffeisenbank、Alfastrakhovanie的演讲，芒果电信实施自动化的经验等细节切下。
我叫 Yana，我是一名测试员，负责自动化以及 DevOps，我喜欢参加会议和聚会。 在过去的两年里，我参加了 Oleg Bunin 的会议（HighLoad++、TeamLead Conf）、Jug 活动（Heisenbug、JPoint）、TestCon 莫斯科、DevOps Pro 莫斯科、Big Data 莫斯科。
首先，我提请大家注意会议议程。 我较少关注报告内容，而更多关注演讲者。 即使该报告被证明非常技术性和有趣，但事实上您并不能够在您的公司应用该报告中的一些最佳实践。 然后你需要一个扬声器。
Raiffeisenbank 管道末端的曙光
通常，我会在场外寻找我感兴趣的演讲者。 在 2019 年 DevOpsForum 上，Raiffeisenbank 的一位演讲者 Mikhail Bizhan 引起了我的兴趣。 在演讲中，他谈到了他们如何逐渐让自己的团队迷上DevOps、为什么需要DevOps，以及如何将DevOps转型的想法推销给企业。 嗯，总的来说，我谈到了如何看到管道末端的光。
Mikhail Bizhan，Raiffeisenbank 自动化总监
现在他们的公司没有“DevOps”。 也就是说，他在工作，但不是在所有球队。 在实施 DevOps 时，他们依赖于团队的准备情况，既包括特定工程师的准备情况，也包括产品的需求以及构建该产品的平台的成熟度。 Misha 讲述了如何向企业解释为什么需要 DevOps。
银行业有几个增长动力：服务成本和客户群的扩大。 增加服务成本并不是一个很好的驱动因素，但扩大客户群则相反。 如果竞争对手发布了一款客观上很酷的产品，所有客户都会去那里，那么随着时间的推移，市场就会趋于平稳。 因此，向市场推出新产品以及推出速度是银行关注的重点。 这正是 DevOps 的目的，企业也明白这一点。
下一个重要注意事项：DevOps 并不总是能缩短上市时间。 DevOps 不能单独工作，它只是创建产品并将其推向市场的过程的一部分，从开发到生产（从代码到客户）。 但代码之前的所有内容都与 DevOps 没有直接关系。 也就是说，营销人员可以研究市场多年，并用一生的时间来追赶竞争对手。 有必要快速了解客户的需求并规划这个或那个功能的实施 - 通常这不足以让 DevOps 发挥作用，也不足以让公司实现其目标。 因此，首先，Raiffeisenbank同意企业界的观点，即有必要学习如何使用DevOps。 为了自动化而自动化对于争取新客户没有多大帮助。
总的来说，Misha 认为需要明智地实施 DevOps。 我们必须做好准备，在转型之初，团队的生产力会下降，赚的钱会减少，但随后就会变得合理。
芒果电信的测试自动化
作为测试人员，我的另一个有趣的报告是来自 Mango Telecom 的 Egor Maslov。 该演讲的主题是“SCRUM 团队中完整测试周期的自动化”。 Egor 认为 DevOps 是专门为 SCRUM 创建的，但同时，将 DevOps 引入 SCRUM 团队是相当有问题的。 发生这种情况是因为 SCRUM 团队总是在某个地方运行，没有时间因创新而分心并重建流程。 问题还在于SCRUM不涉及团队中子团队（测试团队、开发团队等）的分离。 嗯，此外，为了自动化现有的流程，需要文档，而在 SCRUM 中，大多数情况下没有完全的文档 - “产品比某种写作更重要。”
切换到 SCRUM 后，测试人员开始与开发人员协商如何测试功能。 逐渐地，功能量增加，没有文档，他们开始发现测试未涵盖的功能中的许多错误，并且通常不再清楚谁测试了它以及何时测试。 简而言之——混乱和动摇。 我们决定转向测试自动化。 但即便如此，还是彻底失败了。 他们聘请了外包自动化专家，这些专家在内部测试人员不知道的堆栈上进行编写。 自动测试框架当然有效，但在外包商离开后，它持续了两周。 接下来是尝试引入第二个自动测试。 首先，一切都需要在公司内部、您自己（正确的方向：在内部建立专业知识）在 SCRUM 框架内构建，并在此过程中创建文档。 自动化的堆栈应该等于产品的堆栈（这里我添加它，不要用其他任何东西测试你的 JavaScript 项目）。 在冲刺结束时，他们演示了自动测试如何与整个团队一起工作（有帮助）。 因此，所有团队成员对自动化过程的参与度都增加了，对自动测试的信任度也提高了，而且这个自动测试肯定会被使用的机会（并且不会因为不断失败而在一个月内被注释掉）。
顺便说一句，在 DevOpsForum 2019 上有一个开放式麦克风——这是一种众所周知的、在我看来很有用的演讲形式。 你就这样走来走去，听听报告，然后决定在会议上值得讨论某个话题或问题，分享解决问题的相关经验。
我还注意到主办方做了一系列的简短报道。 每份报告持续时间不超过 10 分钟，随后提出问题。 通过这种方式，您可以一次涵盖许多主题并向您感兴趣的演讲者提问。
在演讲间隙，我在会议合作伙伴的展位上走来走去，偷了/赢得了很多东西。 哦，我喜欢讲义！
与 Alfastrakhovanie 开发总监的圆桌会议和 DevOps 问题
对我来说，DevOpsForum 2019 的锦上添花是与 DevOps 专家进行的长达一小时的全体会议。 四位会议参与者受邀从不同角度审视 DevOps：Anton Isanin（Alfastrakhovanie，开发总监）、Nailya Zamashkina（金融科技实验室，运营总监）、Oleg Egorkin（Rostelecom，敏捷教练）和 Anton Maryanov（独立专家，着眼于 DevOps）从商业角度来看）。
专家们坐在离人们更近的地方，然后事情就开始发生了：整整一个小时，观众中的参与者提出了他们的问题，专家们接受了批评。 有时会有真正的辩论。 问题非常不同，例如：是否需要 DevOps 工程师、为什么不能将他们培训为系统管理员、是否应该向每个人提供 DevOps、它的价值是什么，等等。
然后，我亲自与安东·伊萨宁进行了交谈。 我们讨论了将 DevOps 文化带入每个家庭的必要性，并揭示了 DevOps 转型的阴暗面。
让我们想象一下，每个人聚集在一起并决定产品、业务和团队都需要 DevOps。 让我们去实施吧。 一切顺利。 我们呼出一口气。 DevOps拉近了我们与客户的距离，现在我们可以快速满足他的所有愿望。 因此，我们有一个庞大的运营部门，有着严格的规定和要求，它不断地发现产品中的缺陷并产生大量的请求。 此外，所有缺陷都被分配为“紧急”状态，即使客户意外地希望将按钮颜色设置为黄色而不是绿色。 项目不断增长，版本数量不断增加，相应地，客户对新功能的缺陷和误解也不断增加。 运营部门又雇佣了 10 名员工来跟上报告缺陷的速度，开发部门又雇佣了 15 名员工来跟上关闭缺陷的速度。 该团队没有引入新功能，而是与无尽的 SD 合作，同时向用户解释功能并提供支持。 结果，运营和开发都在发挥作用，但客户和业务部门却不满意：新功能陷入困境。 事实证明，DevOps 看似存在，又仿佛不存在。
对于是否需要实施DevOps，Anton明确表示，这直接取决于业务规模。 如果每年为一个客户提供服务可为公司带来十亿美元的收入，则不需要 DevOps（前提是您不需要定期向该客户推出新的更改）。 一切都被巧克力覆盖着。 但如果业务增长并且出现更多客户，那么您就需要遵守。 一般来说，公司最初并没有很酷的运营团队。 首先我们切割产品，然后我们才明白，为了使产品正常工作，我们需要密切关注服务器并监控供应。 这就是Ops应运而生的时候。 尚待理解的是，运营作为一个独立的部门，将开始为开发设置一系列障碍，所有交付都将开始停滞。 也就是说，在这种情况下，DevOps 文化已经是相关的，但我们不能忘记它的阴暗面。
来源： habr.com