您在家中使用DevOps方法吗？ 这是部署工作的丈夫代码。 基础设施的妻子准备煎鸡蛋，煮咖啡，熨衬衫。 监视猫及时从脚下滑下，清理其托盘，并大声指示妻子何时偏离既定规程。
在Slurm DevOps的第一天 ，我遇到了该局STO局的Artyom Galonsky。 他讲授CI / CD以及自动化入门。 他谈到了工厂装配输送线及其在IT中的应用。 同时，他分享了一些实际示例，例如建立“公共”管道。
演讲后，我让他喝咖啡休息一下，让我告诉他DevOps在他的专业活动中的位置，以及与此同时他对DevOps工程师职位有什么要求。 Artyom惊讶地说DevOps工程师与粉红色独角兽存在于同一个宇宙中。 对他来说，“ 没有DevOps工程师，没有了解Kubernetes的优秀管理员 。”
关于事业
您已经开发了11年。 从局局开始？
不行 他于2008年以自由职业者的身份开始，然后筹集了几家初创公司。 “ Otfermery”就是这样的一家创业公司。 它存在了两年并形成了。 2011年，他开始为一家保险公司从事CRM系统。 有一个小团队-4人。 在11-12年间，他成为团队负责人。 他曾是领先的开发人员，也是公司开发部门的负责人。 2017年，它成为加里宁格勒RedStart的STO。 在2018年初，我移居了主席团主席团。
是什么吸引了您？
下一步。 他们提供了有趣的条件。 有机会组建您的团队。 加上有趣的项目。 我从加里宁格勒搬到莫斯科。 他在莫斯科工作了六个月。 然后，主席团主席决定我们应该在加里宁格勒开设一个后台办公室。
怎么了
首先，我本人来自加里宁格勒。 我知道加里宁格勒比莫斯科拥有更多高素质和强大的专业人才。 在加里宁格勒，维护任何需求都比较便宜。 而且那里的IT社区很强大。 自由经济区正在逐步推进。
我们在南桥的人认为，该省的潜力尚未充分释放。 由于心理，社会，经济等多种原因，有大量才华横溢的人无法迁往首都。
是的，甚至没有心理原因或什么原因……人们只是不想动弹。
是的，我正在谈论这个。 并非每个人都想搬家。
这不是心理或财务上的问题。 一个人根本不想要。
是的 我同意 “问题”是一个坏词。 而是“安装”。
一个人根本不想要。 他在那里很舒服。 我在莫斯科工作了六个月，收集了一支队伍。 早上我很难花40分钟去地铁。 或者在交通拥堵的情况下甚至更长的时间。 我现在在加里宁格勒这四十分钟，穿过风景如画的地方，湖泊，美丽的房屋。 在这四十分钟里，我享受生活。 并呼吸干净的空气。 20分钟-我在海上。 40分钟-我在欧洲。 另外，许多住在加里宁格勒的家伙发现我要返回时说：“ 好的，来吧，我们很高兴回到您的团队继续与您合作 。” 一年多以来，我们的后勤部门（开发，测试，分析，支持经理）一直位于加里宁格勒。 我们很高兴也很高兴。
在莫斯科？
在莫斯科，我们有一个前台。 管理层，项目经理，董事帐户，界面设计师，设计师和系统管理员。
以及如何互动？
没有任何干扰。 一切都几乎完美。 这完全取决于您的设置方式。
作为服务站，您自己是偏爱的员工还是远程办公人员？
最主要的是建立正确的知识交流。 我省略了工作流程-因为如果没有建立工作流程，则如何交换知识都没有关系。 无论如何，什么都行不通。 但是，通过知识交换，人们可以共享自己的实践-他们的发明，理解，做的-当坐在同一间办公室时，内部情况更好。 他们将以一种或另一种方式开始就此主题进行交流。 当人们偏远时，他们可能不会共享。 因此，创建知识库很重要。 有必要激励人们共享这些信息。 每个星期五，技术化，即每个没有“燃烧”项目的人，都会在星期五的下半年进行自我教育。 然后与他人共享。
关于发展
你如何激励？
我激励发展。 坦白说，所有事情在“网络”中变化非常快，如果您不进行开发，那么您将永远保持这种状态。 就金钱而言，就不会增长，就发展而言。
我从《爱丽丝梦游仙境》中的刘易斯·卡罗尔（Lewis Carroll）中最喜欢的一句话是：“在这里，您必须以同样的速度跑，才能留在同一个地方，但是要到达另一个地方，则需要以两倍的速度跑。”
我们几乎一样。 在我从事网络工作的11年中，技术发生了翻天覆地的变化。 相对而言，两年前，我们还不知道Kubernetes是什么以及如何实现它。 现在无处不在。 一年之内，每个人都有必要。 因为负载会增加。 如果您不汲取知识并在项目中使用它，那么您将被甩在后面。 开始每个项目，我们尝试引入一些新的东西。 不断开发一种产品，要推出一种新产品非常困难。 对我们来说，这更容易一些-开始一个新项目，介绍我们已经研究和测试的新技术。 而且我们正在从一个项目发展到另一个项目。
您现在使用什么技术，您认为哪些是必要的？
我们现在有了我们正在做的事情，堆栈非常简单-react.js前端，对于后端，我们之前和现在曾经部分使用PHP，现在我们试图切换到Go。 我们一直在朝着这样的一条直线前进，将PHP完全留在Go上并在其中进行开发。 这是一项新的，良好的，稳定的技术，可以极大地提高速度-无论是开发还是产品本身的速度。 也就是说，我们的堆栈是React.js，PHP和Go。 这是用于编程语言的。 以及Redis，PostgreSQL，RabbitMQ的标准技术。
您可以回忆起已经过时的技术。 我们最近与这些家伙进行了交谈-因为他们曾经是Perl的专业人士，所以他们互相取笑。
是的 好吧，可能其他人正在使用Perl。 相同的JS在不断发展……不推荐使用ES6之前的版本，或者相同的jpl。 相同的js到达“节点”并成为node.js。 同样的php，有人不喜欢它-版本5不好，现在7.2正在根据当前趋势发展。 对我来说，没有一个是完全过时的。 道德上，也许是。 还是我长于技术。 以前，十年前，我使用MySQL，而现在我要放置的项目中，它几乎无处不在。 我拥有的技术...最有可能的是，我从这些技术中脱颖而出，而不是过时的。
您现在喜欢Go吗？
执行速度，节省。 给大家 我所看到的，与我的架构师，负责人和开发人员进行交流时，让我们说，我们习惯于在脚本php中看到的东西，仍然保留在Go中，并添加了编译语言的功能。 Goroutines，多通道。 相对而言，那不是php中的，而我们是通过php-fpm做到的。 加上强大的数据输入。 以及二进制本身的快速编译。
什么是适合您的优秀开发人员？
对我来说，一个好的开发人员是可以在大约2-3个月内切换到新的编程语言以理解它的人。 自然，他将在2-3个月内什么都不做。 他将在“六月”的阶段，完成简单的任务。 快速泵送-开始完成复杂的好任务。
您与哪个公司有关-橙色，绿松石？
我们不是绿松石。 而是橙色。 具有垂直控制。 我本人是管理方面的小威权主义者。 我们这样做，并且这样做-如果他们不来找我，并通过明显的例子证明这样做会更好，那么很难说服我。 如果没有证明，那么这是没有必要的。 假设一名员工来对他说：“ Artyom，我们需要这样做。 由于这个原因。 您提出了一个坏主意。 是的，您是导演和建筑师。 但是您没有提出一个很好的主意。 我们必须这样做。” 如果我还没有被清楚地证明并100％证明，那么我将继续我的决定。 所以一定不要绿松石。
相对而言，可以说一种新技术已经出现。 如果没有人继续使用它，并且没有代表性示例和实际案例，那么员工如何向您证明值得使用？ 但是，这项技术据说很有前途。
显示宠物项目。 好吧，不只是：“ 看，那是我做的 。” 这必须已经放在一起。 为了使一个人有意识地做到这一点，他试图将其投入生产，给他带来负担。 他来找我说：“ 我发现了这样的功能，语言和技术。 我创建了一个小型的完整产品或微服务 。“ 然后我听。 仍然存在一个问题-在开展严肃的业务时，需要成熟的技术。 我们可以前进并前进。 而我们的客户（有时由于他们非常庞大，尤其是国有客户）非常可怕，他们只准备使用稳定的技术，而不喜欢实验。 我记得两年前，我向某人建议了react.js，最明智的回答是“ 不。 我们不会工作。 怎么了 这是UI的某种库。 不行 Html，Css，Js-非常适合我们。 ” 在大型公司中，国家结构表明，新技术的开发有点晚。 在技术稳定之前，直到他们找到知道该技术并从内部支持该技术的人，他们才会冒险。
关于项目
您什么时候与客户合作容易？
我认为，如果在客户方有好的架构师， 然后工作变得很有趣。 然后，我们得到了一个好的订单，好的任务和好的解决方案。 他们知道如何实现。 而且，在客户那里，只有管理层和产品分析师想要这样的东西时，这就更加困难了。 系统非常大。 我们提供的产品将成为系统的一部分。 他们告诉我们：“ 哦，将这两个产品连接在一起。 这样，用户单击该按钮即可获得此信息…… ”幕后内容很多-授权，数据传输。 然后您问：“ 伙计们，好吧，它应该如何在内部发生？ 你到底想要什么？ “他们回答：” 哦，我们不知道。 最主要的是，一切都应该美丽。 到底是什么-您告诉我们信息安全。 让他们检查它是否运作良好 。”
当您快速并最初解决问题时，您能记得一个例子吗？
我们的项目仅由ESIA授权。 ESIA经常躺下。 当一个人登录时，我们确认是他登录了。 此外，ESIA的数据还证明其护照或其他文件尚未更新。 然后ESIA搞砸了。 我们有一群尝试登录的客户，收到消息“ 您的数据已更改。 请确认 。“ ESIA开始发布新的名字或中间名或新的护照数据。 而且我们无能为力，因为我们的系统配置如此之高，以至于ESIA是我们的中心。 我们暂时停止了授权。 ESIA很快就决定了一切。 我们的用户平衡器级别的管理员已转到“ 对不起，暂时无法正常工作 ”页面。 而且我们很快完成了它，以便只有老客户才能临时登录而无需更新。 并且不允许新用户。 好吧，这不是我们的处境，但我们在那里寻求解决方案。
告诉我，最近对您来说最有趣的挑战项目是什么？ 您从中得到了什么专业的乐趣？
答：我很喜欢。。。我们为Siemens Finance开设了个人帐户。 西门子的子公司，在俄罗斯从事租赁业务。 我们与他们一起开发了个人帐户。 在这里，令人高兴的是，西门子为我们提供了构建良好架构的机会，客户没有进行干预，并播放了“ 伙计们，我们信任您” 。 我们为他们制作了一个不错的UI和UX。 与客户的合作非常愉快。 那不是挑战或克服。 然后我真的很喜欢这项工作。 从最终收到的产品中。 现在，该产品可以正常工作了。 每个人都喜欢他-我也喜欢他。 因此，我们一直面临着挑战。 与大型公司合作时，没有任何方式。 每个公司有12个部门-有一个IT部门，一个基础架构部门，一个业务逻辑部门，以及其他一些部门。 另外，还有很多供应商，像您这样的人集成了他们的CRM。 与所有这些部门协调任何变更都是一个挑战。 您提供您的架构，与主要公司的架构师进行交流，与供应商架构师进行互动...
但是客户公司的架构师不应该解决这个问题吗？
并非总是如此。 有一个时尚的话题-数字化转型。 例如，公司有一名架构师，他直接参与了其解决方案的架构。 例如，计费或银行部门。 但是他作为整个系统的架构师，没有必要的经验和能力。 但是好的专家开始学习。 年龄不大或已经年龄大的人在这里要复杂一些-因为他们很少关注新趋势。 而且，您必须沟通很长时间，并向他们解释，伙计们，让我们尝试这种渐进式解决方案。 在某个地方，有年轻的建筑师在现代的“网络”上长大。 那里非常简单-有条件地，我们像这样进行同步，像这样连接这些模块。 他们迅速而有能力地转向。
所以您已经看到了两代不同的开发人员？
在网路上，是的。 因为现在一切都移到了网络上。 现在，即使内部系统也逐渐进入通过API进行通信的微服务。 该API通常是http和https。 建筑师必须了解其工作原理。 并且是聆听网络工作人员的最简单方法。 我认为。 这种情况经常发生。 客户想要一个新的酷网站。 他可以查看竞争对手拥有的站点，该站点的工作方式。 他来了，要求我们建立网站的整个数字历史，直到CRM。 而且我们只处理该站点。 我们准备与某人的CRM集成。 事实证明，我们已成为特定公司变革的驱动力。
关于技术
数字化转型-您认为需要多少？
像任何宣传主题一样，它是时尚且必要的。 我们有大量订单可以进行excel下载。 大量公司在Excel中工作。 并且他们需要确保已将“ excel”加载，解析，转换为数据库，然后可以使用它，然后将其卸载。 数字化转型应导致向正常工作系统的过渡-CRM，内容系统，CMS。 放弃excel并生活在正常的网络世界中。 有一个很好的例子。 在之前的公司中（我在Bureau-Bureau之前曾在该公司工作），我们有两家客户公司。 而且我们能够详细跟踪一切情况。 在一家公司中，客户服务通过Excel进行。 有一个大型数据库。 那是2012-2013年。 普通CRM不适合在那里-大量的工作流程，并且花费很长时间在普通CRM上进行配置。 一家公司开始在Excel中工作。 第二个花了半年的时间-并写了她的CRM。 结果，第一家公司在销售达到顶峰六个月后就开始与客户合作-倒闭了。 只是他们的通话服务无法提供优质而快速的服务。 相反，第二家拥有CRM的公司则通过一个按钮快速跟踪了客户的类型，客户类型，经理的回答。 他们在增长的顶峰中幸存下来，并且仍在工作。 电子工作流程也是一种趋势。 节省时间。 谁能更快地掌握信息，他的收入就会更快。 所以在一切。 如果没有良好的监控，也没有良好的项目登录记录，则工程师将无法快速理解问题所在。 现在，企业的生存与成功真正取决于它。 因此，不仅有一个漂亮的网站，而且有必要建立一个正确的网站和正确的日志记录系统。 需要数字化转型。 有必要保持最新。 如果有这样的技术，我们必须尝试介绍它们。
您现在看到什么技术在不久的将来会很有希望？ 例如，两年前，Kubernetes被认为很有前途。 现在，这完全是必要的。
未来是机器学习和AI。 在五年内，这将变得有意义。 一年前，出现了加密货币，并且出现了有关炒作的机器学习。 现在一切都安静了。 但是，正如我所认为的那样，在未来五年中，机器学习将蓬勃发展。 工作正在进行中-经验和解决方案正在积累。
人们相信，随着机器学习和人工智能的发展，许多专业将会消失。 这适用于教师和经济学家。 律师们说，区块链技术将在法学领域中移动某些领域。 如您所见，IT的哪些专业将会消失？
我认为，封面将消失。 在我看来，未来三年。 俗话说，记住这条推文。 （笑）最有可能的是，机器学习很快就会写好，这将是一个很好的布局。 他们会想出一些办法。 然后，简单系统的程序员可能会消失。 但是，仍然总会有程序员来设计和编程微芯片内核。 永远会有程序员。
O devops
现在市场上，DevOps工程师存在一定的不足...
听着，我绝对不喜欢DevOps工程师。
怎么了
DevOps是一种实践，它是一种哲学。 DevOps工程师-是谁？ 是抽水的管理员还是可以在管理员中抽水的“后端”？ 对我来说，没有DevOps工程师，对我来说，有懂Kubernetes的优秀管理员。 但是Kubernetes不是DevOps。 我唯一接受的是DevOps传播者。 谁能来公司说：“ 伙计们，我们需要朝这个方向前进。 学习交流和互动 。” 因为DevOps与技术无关。 通常，DevOps的整个哲学都是关于交互的。 学习如何进行交流，开发和质量检查以及进一步的支持。 所有这些DevOps工程师让我想起了三年前Scrum-master的炒作。 每个人都需要Scrum-master，没有他们，任何人都无法工作。 或五年前，每个人都急需一个Jira设置经理。 , «», . , DevOps — .
, - ?
, - . . , — , , «», , . , «». , DevOps. , DevOps-. . — . Kubernetes.
, IT-?
. . . . 90- .
, , ?
. . , . - . — , . , . , , , . . . , . , . , , . — .
Post scriptum
. , , , , - — , , . . , , , , , -. , . ? «Time will tell. Sooner or later time will tell».©