他们对DevOps说了很多。 我们只对真正实施和遵循DevOps原则的人们的意见感兴趣。 碰巧的是，这样的人被纳入了DevOpsConf俄罗斯计划委员会。 利用我的正式职位，我问了他们八个相同的问题：
- 您认为DevOps方法的主要优势是什么？
- 什么最有可能阻碍公司进行DevOps转型？
- 如何将安全专业人员整合到软件交付过程中？
- 您如何看待SRE周围不断增加的炒作？
- 无论他们在哪里谈论DevOps，如今都有哪些工具？
- 在DevOps方面，优秀工程师与劣质工程师有何区别？
- 进入该行业最合乎逻辑的方法是什么？
- 如何学习和阅读什么？ 您最常在哪里阅读行业新闻？
答案非常好奇，同时让我们给那些在会议
安排上花了很多力气和一点心血的人留下深刻的印象。 例如，第一个问题的答案比缩短产品上市时间要广。 关于SRE的意见分歧，但每个人几乎都建议阅读《 DevOps手册》，但他们也提出了很多建议-紧随其后的是cat。
Yandex.Verticals的首席技术官
Danila Shtan提倡DevOps，重视软技能而不是专业技能，并且喜欢聊天。 例如，去年在RootConf上，Danila
谈到了如何使用相当简单的技术解决方案，流行的软件产品和团队中的协议来构建自组织服务基础架构。
-您认为DevOps方法的主要优势是什么？他们的责任不是他们的螺母在8点，而是要确保用螺栓将两个零件固定在一起。
-在DevOps转型中最有可能阻碍公司发展的因素是什么？“我不会做别人的工作。” 通常，将
工作分为“一个人”和“另一个人” 。
-如何将安全专家整合到软件交付过程中？例如，与设计师大致相同。 他们讲出主题领域的基本概念和要求，然后参加审查和接受。
-您如何看待SRE周围的炒作？他只是站起来吗？ 在我看来，他来这里已经很长时间了。
SRE是荣耀的行动 ，我不太喜欢这个概念。
-今天谈论DevOps的工具肯定存在吗？键盘，屏幕和耳机:)
-就DevOps而言，优秀工程师与劣质工程师有何区别？希望成为世界上最好的8种坚果专家。
-进入该行业最合理的方法是什么？ 您是否退出了Dev或Ops？最合乎逻辑的事情就是爱自己在做什么 ，一切都会在那里共同成长。 我通常来自项目。
-如何学习和阅读什么？ 您最常在哪里阅读行业新闻？我喜欢
highscalability.com上的收藏集，Reddit上的论坛以及不同大小的公司的工程博客。
Vyacheslav Kuznetsov从项目初期开始就领导Ecwid的IT运营团队。 Hangops_ru在线社区会议的组织者之一。
-您认为DevOps方法的主要优势是什么？DevOps可以极大地
加快从构思到发布
的软件
开发过程 ，消除开发和维护过程中的问题。
-在DevOps转型中最有可能阻碍公司发展的因素是什么？不想改变的人可能是最令人不安的事情。 并非每个人都希望改变，有些人担心他们在新奇的世界中将没有一席之地。
不幸的是，在实施DevOps方法时，并不是所有问题都可以通过工具和流程变更来解决。 需要决策者的支持。 我们需要了解表演者，没有人打算剥夺他们的工作。
-如何将安全专家整合到软件交付过程中？保安人员应尽早参与开发。 在这种情况下，有必要进行对话并建立流程，以使安全工具像liner或代码审查一样自然。
-您如何看待SRE周围的炒作？在我看来，
SRE只是DevOps做法的一种实现，在上面还有一点点。 Google撰写的SRE书籍汇集了许多实践。 他们以开阔视野而著称，但并不是每个公司都需要所有这些。
-今天谈论DevOps的工具肯定存在吗？聊天，CI / CD，K8S。
-就DevOps而言，优秀工程师与劣质工程师有何区别？一个好的工程师的行动是基于整个团队的需求，而不仅仅是团队中最亲密的团队的需求。
-进入该行业最合理的方法是什么？ 您是否退出了Dev或Ops？DevOps方法必须解决您工作中的实际问题，然后将其出售给团队，这一点很重要。 我没有离开Ops，这不是练习DevOps所必需的：)我们的Ops团队撰写了大量文章，并不断使其工作自动化。 反过来，开发团队则与基础架构紧密合作，还负责值班并调查事件。
-如何学习和阅读什么？ 您最常在哪里阅读行业新闻？有一些不错的书揭示了DevOps的精髓：
- DevOps手册。
- 凤凰计划。 关于DevOps如何使业务更好的小说。
我还喜欢David J. Anderson所著的《看板：成功的技术业务变革》。
为了及时了解行业新闻，Telegram上有很多出色的新闻通讯和频道：Gareth Rushgrove的
Devops Weekly ，Devops Deflope（Telegram的
播客和
频道 ），
Hangops Ru 。 但是，精选最多的行业新闻在Twitter上飞向我。 最主要的是跟随正确的人
德米特里·扎伊采夫（Dmitry Zaitsev）在Humaniq担任SRE，但在以下多个行业拥有经验：Gamedev，AdTech，大数据，金融科技。 在尚不流行的时候开发DevOps和SRE实践。 将它们与ITIL和Cobit结合在一起，而它们仍然很流行。 此外，参加会议
Hangops_ru的组织。
-您认为DevOps方法的主要优势是什么？产品和业务的速度变化迅速，在瞬息万变的世界中具有很高的适应性。
-在DevOps转型中最有可能阻碍公司发展的因素是什么？无需转换。
-如何将安全专家整合到软件交付过程中？以及维护专家，将他们的工作沿价值传递链尽可能向左移动。
-您如何看待SRE周围的炒作？老实说，我看不到他。 SRE只是许多优秀的sysadmin长期以来使用的一组实践。
-今天谈论DevOps的工具肯定存在吗？-就DevOps而言，优秀工程师与劣质工程师有何区别？一个好的工程师专注于整个价值
链的交付速度 ，而一个不好的
工程师则只
专注于整个价值
链的一部分。
-进入该行业最合理的方法是什么？ 您是否退出了Dev或Ops？在拥有数字产品的公司中
找到工作 。 我本人是从办公室管理员开始的，然后又是Linux，Gamedev，开发和开发。
-如何学习和阅读什么？ 您最常在哪里阅读行业新闻？我建议阅读：
- The Visible Ops系列，DevOps手册。
- “ Google SRE图书”是一套好的sysadmin做法。
- Jez Humble和David Farley的“ Continuous Delivery”，作为CD答案书。
- Hiz兄弟的“变革之心”，作为改变人们的指南。
我还可以为Hangops社区及其俄罗斯早午餐Hangops_ru提供建议-作为品尝该行业的一种方式。 我个人阅读，因为通常在这里讨论最重要的新闻，而且我每周查看不同的邮件，例如devops / sre / k8s。
Valeria Pilia在德意志银行担任基础架构工程师。 从事部署自动化和对产品团队的支持。 在此之前，她曾在Video International，Megafon和OneFactor担任运营工程师，并支持和开发基于Hadoop生态系统的平台。
-您认为DevOps方法的主要优势是什么？缩短了上市时间，并使所有人都参与其中。
-在DevOps转型中最有可能阻碍公司发展的因素是什么？惯性 。
-如何将安全专家整合到软件交付过程中？利用
安全拥护者的想法。
-您如何看待SRE周围的炒作？对于任何不打架的混战，我都是值得的，这可以为您围绕专业实践及其在您特定公司中的应用提供思考的机会。
-今天谈论DevOps的工具肯定存在吗？- 任何版本控制系统。
- 任何软件配置管理。
- 持续集成/持续交付的任何东西。
-就DevOps而言，优秀工程师与劣质工程师有何区别？能够查看过程中
的瓶颈并加以解决
的能力 。
-进入该行业最合理的方法是什么？ 您是否已离开Dev或Ops？我来自Ops。 在我看来，
如果有愿望 ，您可以从测试人员
那里得到 。
-如何学习和阅读什么？ 您最常在哪里阅读行业新闻？在Hangops_ru上进行了精彩
的书籍
讨论 ，我没有比这更好的了。 另外，您可以推荐Nassim Taleb和The DevOps Handbook的书。
我在
Devops Deflope上阅读了行业新闻。
Mikhail Chinkov -
AMBOSS的基础架构工程师。 以及DevOps文化的传播者和Hangops_ru社区的成员。
-您认为DevOps方法的主要优势是什么？能够从技术方面尽快，高效地检验技术公司发展假设的能力。
-在DevOps转型中最有可能阻碍公司发展的因素是什么？也许流行的答案是管理者或执行者的惯性。 我将
市场称为
垄断 。
在竞争对手出现之前，即使是技术公司也不需要真正的DevOps。 如果没有竞争对手，钱已经在滴滴，那么没人愿意付出额外的努力。 我曾在一家这样的公司担任工程师，但很快就陷入了垄断，因为技术流程的主要瓶颈正在缓慢地，缓慢地发展。
-如何将安全专家整合到软件交付过程中？再训练 说明世界在变化，
职业偏执狂的
程度应逐步降低 。 足够的专家将迅速适应业务需求。
-您如何看待SRE周围的炒作？与落入著名
技术炒作周期的任何事物一样。 很快，人们将开始了解SRE的真正含义，屏幕保护程序/公司中的职位将消失，最终，站点可靠性工程将仅保留在真正需要它的公司中。
我认为，
仅在规模过大且
紧急云平台/服务的强度不足以满足所有运营需求的
紧急情况下才需要SRE 。 全球最多有20–25家此类公司。
-今天谈论DevOps的工具肯定存在吗？分开“说”和“做”很重要。 大多数公司谈论DevOps已有几年了，但事情仍然存在。
人们真正尝试实施实践的地方包括：
公共云 （最常见的是AWS），
Kubernetes和
Terraform 。 其余条款因情况而异。
-就DevOps而言，优秀工程师与劣质工程师有何区别？愿意
分担产品责任，以业务为中心（一个人不做不会增加业务价值的事情），愿意
主动 （例如，希望提高产品的技术方面而不是接受坏处和理所当然的愿望），对立的兴趣来自内部和外部客户的沟通。
-进入该行业最合理的方法是什么？ 您是否退出了Dev或Ops？在我看来，现在在公司
中驱动DevOps的
专业（无论他们如何称呼）已经发展成为一个单独的主题领域，并且立即学习公司中所需的那些东西是最合乎逻辑的：云，监控，交付管道等。 编码技能本身是生存所必需的。
我本人离开了本地的奔萨大学的管理室，甚至没有时间品尝VLAN和iSCSI存储支持功能，所以我的例子并不是最好的：)
-如何学习和阅读什么？ 您最常在哪里阅读行业新闻？最好从DevOpsLinks，
WebOps每周邮件列表中获取文章。 Corey Quinn撰写了很棒的AWS新闻。
从必读书籍中，这是：
- DevOps手册。
- 基础架构即代码：在云中管理服务。
- 约翰·奥尔斯帕（John Allspaw）的“ Web Operations”。
- “ Unix和Linux。 即使您将“ admin”一词称为“系统管理员指南”。
- Jez Humble和David Farley的“连续交付”。
- 您选择用于编码基础结构的编程语言的顶级书籍。
Andrei Shorin开始与以前从未考虑过的人们进行互动。 在任何地方，他都看到了改变的机会，并热爱于实现。 为hh.ru（2011-2017）的运营结果感到骄傲。
-您认为DevOps方法的主要优势是什么？产品随时可以在任何开发阶段（甚至是最早的阶段）进行调试。
-在DevOps转型中最有可能阻碍公司发展的因素是什么？任命有罪 。 汇报。
-如何将安全专家整合到软件交付过程中？与DBA相同。 邀请他们提出建议并在积压中设置任务，同时放弃阻止发布的权利。
这并不容易 。
-您如何看待SRE周围的炒作？我对SRE的想法和实践很满意。 炒作可以使更多人意识到它的存在。
当团队深入研究本质并看到炒作背后的森林
时，我会喜欢上它 。
-今天谈论DevOps的工具肯定存在吗？- 不仅监视服务器的状态，还监视产品的每个功能单元的运行状况。 我最喜欢的是okometer。
- 代码审查 。 重要的不是工具，而是处理任务的综合途径。
- 持续集成 -每个团队都根据自己的工作方式选择特定的工具。
-就DevOps而言，优秀工程师与劣质工程师有何区别？与同事不断合作为用户做工作的愿望。
-进入该行业最合理的方法是什么？ 您是否退出了Dev或Ops？不仅对算法和代码感兴趣，还对产品的内容及其对用户的价值感兴趣。 我从运营转向了DevOps，因为通过这种方法，IT世界变得越来越好。
-如何学习和阅读什么？ 您最常在哪里阅读行业新闻？无论您从事哪种专业，都应考虑产品的整个生产周期。 对我来说，除了我的直接工作之外，在会议上的演讲和有关主题的文章也起了重要作用。
一个方便的时刻，可以通过有关DevOps的报告来提醒YouTube频道的地址，并提供订阅新闻通讯的内容 ，在其中我们可以轻松地谈论新文章和会议。
Vitaliy Rybnikov帮助产品团队实施DevOps和SRE方法和实践。 由SRE Tinkoff银行提供支持。
-您认为DevOps方法的主要优势是什么？不断提高产品质量。
-在DevOps转型中最有可能阻碍公司发展的因素是什么？缺乏意识形态引擎将导致这个话题。 缺乏业务的支持和需求。 在做旧事情或什么都不做的同时获得新结果的愿望。
-如何将安全专家整合到软件交付过程中？他们应该通过添加和支持检查程序来增强自己的能力并整合到Pipeline中。 加上对基础架构的定期审核，将有助于自动猴子补丁的支持和开发。
-您如何看待SRE周围的炒作？所以，这是...我正在提出它：)在莫斯科DevOps mitaps和DevOpsConf上与我们讨论，我们将进行讨论；
-今天谈论DevOps的工具肯定存在吗？-就DevOps而言，优秀工程师与劣质工程师有何区别？他们与主人的关系以及对主人的承诺。
-进入该行业最合理的方法是什么？ 您是否退出了Dev或Ops？我认为离开开发人员是最合逻辑的，我本人也离开了开发人员。 而且您对开发人员有了更好的了解，而且我敢肯定，没有什么是不可能的。
-如何学习和阅读什么？ 您最常在哪里阅读行业新闻？从亲身经验和实践中学习良好 。 实习或课程也可能会有所帮助。
我建议您阅读所有与同事相同的内容。 我自己最常阅读会议的应用程序，即Telegram中的主题频道。 会议上的脱机通信是紧跟潮流和趋势的，这是不可替代的。
DevOpsConf俄罗斯已经在10月1日和2日。 来到Infospace，将聚集500名一流的专家来整合所有内容，我们将共同解决所有问题。