我向您介绍DevOpsConf的指南-今年的会议规模很大。 从某种意义上说，我们设法构建了一个功能强大且平衡的计划，因此各种专家都喜欢它的开发过程：开发人员，系统管理员，基础架构工程师，QA，团队负责人，服务站以及通常参与开发过程的每个人。
我们建议访问DevOps领域的两个大区域：一个是可以通过代码灵活更改的业务流程，另一个是工具。 也就是说，在我们的会议上，强度内容将是两个相等的，并且值得注意的是流的报告数量。 第一个专门用于工具的使用，第二个专门用于处理被视为代码并作为代码进行管理的业务任务示例的流程。 我们相信技术和流程之间有着千丝万缕的联系，并在我们的演讲者的帮助下系统地显示了这一点，他们在新的公司工作，并通过解决问题和克服挑战分享他们对发展的新认识。
如果您愿意，可以简短地浏览一下我们的DevOpsConf指南：
- 9月30日，会议第一天，在第一会议室，我们将考虑8个业务案例。
- 在第二个房间的第一天，我们将分析更专业的乐器解决方案。 每个报告中都有很多很酷的实践经验，但是，这些经验并不适合所有公司。
- 相反，在10月1日，我们在第一大厅对技术进行了更多讨论，但涉及范围更广。
- 在第二天的第二个会议室中，我们讨论了并非在所有项目（例如企业）中都会出现的特定任务。
但是我会立即注意到，这种分离并不意味着观众的分离。 相反，对于工程师而言，了解业务任务，了解他在做什么的含义以及具有实践经验非常重要。 对于团队负责人或服务站，当然，其他公司的案例和经验很重要，但是您还需要了解内部厨房。 在猫咪的陪同下，我将更详细地讨论所有主题，并帮助制定详细的旅行计划。
该会议将在Infospace和我们称为“金心”的两个主要大厅中举行，这是《银河系漫游指南》中的一艘船，它使用了不可能在太空中移动的原理，并使用了“在宇宙的边缘”作为同一传奇中的餐厅。 此外，我将使用这些名称来指定曲目。 报告站位于“金心”星系区域，更适合主要游客；这是您必须参观的景点。 “宇宙的边缘”为有经验的旅行者提供了有趣的物品。 很少到达那里，但是那些敢于穿越小行星带的眼睛的人敢去那里。
同时，您可以轻松地从一个房间移到另一个房间，并且随时可以找到适合自己的主题。 正如我所说，该计划非常均衡。 我们进行了许多更酷的演示，但很不情愿，程序委员会不得不将它们转移到
HighLoad ++或推迟到圣彼得堡春季会议之前进行，以免破坏平衡并实现最初的想法。 每个计划的主题（连续交付，作为代码的基础结构，DevOps转换，SRE实践，安全性，基础结构平台）都允许使用不同的示例和不同角度来检查会议计划。
现在坐下来，我们的银河飞船跟着所有停靠点。
金色的心9月30日
担任CTO的前90天
会议将由
Leon Fire开幕。 关于过时系统的继承以及通常捆绑在一起的问题。 Leon会告诉您STO如何理解其开始使用的技术系统。 对于一家现代化公司的技术总监而言，管理DevOps流程是主要任务，而Leon将从服务站的角度有趣而幽默地展示
技术和业务部分之间的关系 。
绝对应该由服务站的初学者和想要成为该服务的人参加该报告。 毕竟，成长为公司的技术总监是一回事，而重新担任这一职务又是另一回事，这种特技飞行并非所有人都可以使用。
DevOps基础-从头开始进入项目
下
一份报告将继续该主题，但是
Andrey Yumashev （
LitRes ）将在全球范围内较少考虑该问题，并回答以下问题：在不同团队中开始工作时，您需要了解哪些基本知识； 如何分析问题的范围； 如何制定行动计划； 如何计算KPI以及何时按时停止。
未来的基础设施即代码
接下来，我们讨论基础结构作为代码的主题。 DevOpsConf上AWS的
Roman Boyko解决方案架构师
将讨论新的
AWS Cloud Development Kit ，该
工具包使您可以用熟悉的语言（Python，TypeScript，JavaScript，Java）描述基础架构。 我们将直接学习如何使云更接近开发人员，如何开始使用此工具以及创建可重用的组件以方便基础架构管理。 对于会议参与者来说，这是一个很好的机会来了解俄语世界新闻，了解我们采用的技术细节程度，而西方国家则不然。
从发布到FastTrack
午餐后，我们将回到几个小时的转型问题。 在
Evgeny Fomenko的
报告中 ，我们将遵循MegaFon DevOps的转型：从他们尝试使用传统方法（例如KPI）的阶段开始，到克服一切还不清楚的阶段，您需要拿出新工具并进行自我更改，
直到流程完全重组 。 这是一个非常酷和激励人心的企业经验，此外还让其承包商参与了DevOps转型，Eugene也将谈到。
如何成为跨职能团队
Mikhail Bizhan在为团队进行变革性变更
方面拥有丰富的经验。 现在，作为加速团队负责人的迈克尔·雷芬森银行（Raiffeisenbank）使团队实现了跨职能。 在他的
报告中，我们将讨论缺乏跨职能团队的痛苦，以及为何跨职能团队的挑战不以发明，制造和实施的想法而结束。
SRE实践
关于SRE实践的两份报告正在蓬勃发展并在整个DevOps流程中占据重要地位，正在等待着我们。
Prisma Labs的
Alexey Andreev 将告诉您，为什么初创公司需要SRE做法以及为什么会有所回报。
来自Dodo Pizza的
Matvey Grigoryev将在一家规模不大的初创公司中
展示 SRE的一个例子。 Matvey自己这样说：一个经验丰富的.NET开发人员和一个初学者SRE将分别分享开发人员（而不是一个，而是整个团队）向基础架构过渡的故事。 为什么
DevOps对开发人员而言是合乎逻辑的方式 ？如果您开始将所有Ansible剧本和bash脚本视为完整的软件产品，并对它们应用相同的要求，将会发生什么情况，我们将在9月30日17:00在Matthew的报告中讨论“金心。”
第一天的计划将由
Daniil Tikhomirov完成，他在
演讲中将提出一个重要的问题：
硬件与用户的幸福感如何相关 。 为了解决“一切正常，但用户不满意”的问题，MegaFon已从监视单个系统，服务器，应用程序变为通过用户的眼光监视服务。 我们将找出所有技术专家，客户和供应商如何开始关注这些KQI指标的，我们将在会议的第一天晚上进行发现。 之后，让我们讨论基础架构和非正式的聚会后转型。
9月30日，“在宇宙的边缘”
从工具的角度来看，“宇宙边缘”大厅中的前三个报告将非常有趣。
Maxim Kostrikin（Ixtens）
将 在Terraform中 显示 模式，以应对大型项目和长期项目中的混乱情况和常规情况。 Terraform开发人员为使用AWS基础设施提供了非常方便的最佳实践，但是有细微差别。 Maxim将通过代码示例演示如何不将带有Terraform代码的文件夹变成雪球，而是如何使用模式简化自动化和进一步开发。
来自Lamoda
的 Grigory Mikhalkin 的报告 “为什么我们开发Kubernetes运营商以及我们从中学到了什么教训”将帮助填补关于如何基于Kubernetes实施基础设施实践作为代码的信息不足。 Kubernetes本身包含例如带有yaml文件的服务的描述，但这还不足以完成所有任务。 低级管理需要操作员，如果您想正确管理Kubernetes，此报告非常有用。
下一个话题
Hashicorp Vault非常特别。 但是实际上，无论您在哪里需要管理密码并具有使用机密性的共同点时，都需要此工具。 去年，谢尔盖·诺斯科夫（Sergey Noskov）讲述了他们如何使用Hashicorp Vault管理Avito中的秘密，观看该
报告并来
听 Tinkoff.ru的
Yuri Shutkin的更多经验。
Taras Kotov （EPAM）
将考虑构建包含其自身的核心
IP / MPLS网络的云基础架构的任务更为罕见。 但是经验很酷，报告是核心，因此，如果您知道报告的内容，请务必提交此报告。
傍晚，我们将讨论云基础架构中的数据库管理。
Kirill Melnichuk 将分享他 在Kubernetes集群中使用
Vitess与MySQL一起工作的经验。 Playkey.net的
Vladimir Ryabov 将告诉您如何使用云中的数据以及如何正确使用可用的存储容量。
金色的心，10月1日
10月1日，一切都会相反。 在“ Golden Heart”大厅，将有一条更加注重技术的轨道。 因此，对于在“金心”上旅行的工程师，我们首先建议您深入研究业务案例，然后看看如何在实践中解决这些案例。 然后，管理人员首先考虑可能的任务，然后开始更好地了解如何在工具和硬件中实施此任务。
大型云存储的内幕
第一位发言人是
Artemy Kapitula 。 他去年的报告“
Ceph。 我想，由于故事的深度令人难以置信，与会人员称赞是最好的。 这次，有关Mail.Ru Cloud Solutions解决方案（用于存储设备）和系统故障情况分析的
故事将继续。 该报告对管理人员的明显好处是，Artemy不仅分析技术问题本身，而且分析解决问题的整个过程。 即 您可以了解如何从整体上管理该过程，然后尝试使用您的公司。
逆向分散式部署
叶戈尔·布加坚科（Yegor Bugaenko）也不是第一次讲话，他的报告传统上包含有争议的论点，但它们使您思考。 我们希望，叶戈尔关于分散部署的
报告将引起有趣的，最重要的是建设性的讨论。
再次在云端clouds翔
阿列克谢·瓦霍夫（Alexey Vakhov）的 报告将业务组件和技术进行了强有力的融合；无论从工程方面还是在管理方面，这都将很有趣。 Alexey将介绍Uchi.ru如何具有
Cloud Native基础架构 ：如何使用Service Mesh，OpenTracing，Vault，集中式日志记录和整体SSO。 之后，在15：00，Alexei将举办一个
大师班 ，每个来访的人都可以用自己的双手接触所有这些工具。
阿维托的阿帕奇·卡夫卡：三个轮回的故事
当然，使用Kafka的人也会
对 Anatoly Soldatov关于如何在Avito中如何构建Kafka作为服务的报告感兴趣。 但是另一方面，
内部服务的创建过程也有很好的披露：如何收集对服务的需求和同事的意愿，实现接口，建立团队之间的互动以及在公司内部将服务创建为产品。 从这个角度来看，这个故事对于完全不同的会议参与者也很有用。
使微服务再次轻量级
在这里，从名称看来一切都显而易见。 但是，即使是在程序委员会中，Leroy Merlin
的 Dmitry Sugrobov 提出的论文也引起了激烈的争论。 一言以蔽之，这将成为讨论总体上考虑微服务，如何编写，维护它们等的良好基础。
CI / CD，用于管理BareMetal基础架构
下一份报告还是二合一的。 一方面，
Andrey Kvapil （如WEDOS Internet）将讨论管理BareMetal基础设施的问题，这非常具体，因为现在每个人都主要使用云，并且如果他们拥有硬件，它们的规模就不会很大。 但是，非常重要的是，Andrey
将分享他使用CI / CD技术部署和管理BareMetal基础设施的经验，从这个角度来看，该报告对Timlids和工程师都将很有趣。
该主题将继续
Sergey Makarenko，在
Wargaming Platform中 展示此耗时过程
的后台。
容器可以安全吗？
亚历山大·卡约洛夫 （
Alexander Khayorov）将在“金心大厅”（Golden Heart Hall）中完成该计划，并
提供有关集装箱安全性
的讨论报告。 在RIT ++上，Alexander已经
指出了 Helm的安全性问题和解决方法，这一次不仅限于列出薄弱环节，而且
还将展示用于完全隔离环境的工具。
10月1日，“在宇宙的边缘”
亚历山大·伯采夫 （
Alexander Burtsev） （BramaBrama）将启动并
提出加快站点建设的可能解决方案之一。 让我们看看
仅由于DevOps工具而无需重写代码的情况下成功实现了五倍
加速 。 为了决定是否重写代码，仍然有必要重新创建每个项目，但是牢记这种经验总是有用的。
1C中的DevOps：企业
来自1C的
Petr Gribanov 将试图揭开一个神话，即在大型企业中不可能实现DevOps。 可能比1C：企业平台更复杂，但是由于DevOps的实践即使在那里也适用，因此我认为神话不会成立。
自定义DevOps
Anton Khlevitsky在报告的续篇中，Yevgeny Fomenko
将讲述 MegaFon如何与承包商合作构建DevOps并构建持续部署，包括来自多个软件供应商的定制开发。
将DevOps引入DWH / BI
Gazprombank
的 Vasily Kutsenko 将揭示一个针对不同参与者的非标准但又有趣的话题。 Vasily将分享有关如何在数据开发中发展IT文化并在Data Warehous和BI中应用DevOps实践的实用技巧，并告诉您处理数据的管道有何不同，以及在处理数据的上下文中哪些自动化工具真正有用。
没有安全部门的情况下（您）如何生活
午餐后，
Mona Arkhipova （sudo.su）将向我们介绍
DevSecOps的基础知识，并说明如何将安全作为过程集成到开发过程中，并停止使用单独的安全部门。 这个话题很紧急，该报告对许多人来说应该是非常有用的。
CI / CD大型解决方案中的负载测试
MegaFon
的 Vladimir Honin的
演奏将完美地补充上一个主题。 在这里，我们将讨论
如何在DevOps流程中引入质量 ：如何应用Quality Gate，修复系统内部的各种情况以及如何将所有这些内容纳入开发流程。 该报告特别适合那些使用大型系统的人，但是即使您不使用庞大的账单，您也会为自己找到有趣的方面。
SDLC与合规
下一个主题与大公司更相关-如何将合规性解决方案和标准要求引入流程。 德意志银行技术中心的
Ilya Mitrukov 将证明 工作标准很可能与DevOps兼容 。
最终，
Matvey Kukuy （Amixr.IO）
将分享有关全球数十个团队如何值班，分类事件，组织工作和建立可靠系统的统计数据和见解，并解释它们与SRE的关系。
现在我什至羡慕您一点，因为您只需要前往
DevOpsConf 2019 。 您可以制定自己的计划，并享受报告之间相互补充的有机结合，而且我很可能像任何指南一样，都没有时间仔细研究。
顺便说一句，除了主程序外，我们可以说是露营-mitapnaya，参与者可以在其中进行小型会议，研讨会，大师班并在会议厅环境中讨论紧急问题。 任何参与者都可以
提出mitap ，任何参与者都可以充当程序委员会并投票给其他mitap。 这种格式已经证明了其有效性，尤其是在联网方面，因此请仔细查看时间表的
这一部分 ，并在会议期间遵循
电报频道中有关新mitap的公告。
在Galaxy DevOpsConf 2019见！