当然，这与
DevOpsConf有关。 如果您不讨论细节，那么在9月30日和10月1日，我们将召开一次有关开发，测试和操作流程统一的会议，如果您要深入探讨，我会要求您。
在DevOps方法的框架中，项目技术开发的各个部分相互交织，并行发生并相互影响。 在此特别重要的是创建可以实时更改，模拟和测试的自动化开发过程。 这有助于立即响应市场变化。
在会议上，我们想展示这种方法如何影响产品开发。 系统对客户的可靠性和适应性如何？ DevOps如何将公司的结构和方法改变为工作流程的组织。
后台
对于我们来说，重要的是，不仅要了解作为DevOps方法一部分的不同公司在做什么，而且还必须了解为什么这就是全部。 因此，我们不仅邀请专家加入程序委员会，还邀请从不同角度看待DevOps讨论的专家：
一方面，这在讨论报告申请时造成了困难和冲突。 如果工程师对分析重大事故感兴趣，那么对开发人员而言，更重要的是了解如何创建可在云和基础架构中运行的软件。 但是，通过达成共识，我们正在创建一个程序，该程序对每个人都将是有价值和有趣的：从工程师到CTO。
我们会议的任务不仅是选择更具技术含量的报告，而且还展示了大局：DevOps方法在实践中如何工作，在转向新流程时会遇到什么样的麻烦。 同时，我们构建内容部分，从业务任务到特定技术。
会议的各个部分将与
上次相同。
- 基础架构平台。
- 基础架构作为代码。
- 持续交付。
- 反馈。
- DevOps的架构，CTO的DevOps。
- SRE实践。
- 培训和知识管理。
- 安全性，DevSecOps。
- DevOps转换。
征集论文：我们正在寻找什么报告
我们有条件地将会议的潜在观众分为五类：工程师，开发人员，安全专家，团队负责人和CTO。 每个小组都有参加会议的动力。 而且，如果您从这些位置来看DevOps，您将了解如何集中精力讨论主题以及在何处强调重点。
对于正在创建基础架构平台的
工程师来说，了解现有趋势，了解哪些技术是目前最先进的技术非常重要。 他们将有兴趣结识使用这些技术的实际经验并交换意见。 工程师很乐意听取一份报告，其中包含对一些重大事故的分析，我们将依次尝试并完善该报告。
对于开发人员而言，了解
云原生应用程序之类的概念很重要。 也就是说，如何开发软件使其能够在云和各种基础架构中运行。 开发人员需要不断收到软件的反馈。 在这里，我们想听听有关公司如何构建此过程，如何监视软件性能以及整个交付过程如何工作的案例。
对于
网络安全专业人员来说，了解如何设置安全流程非常重要，这样它就不会停止开发流程和公司变更。 有关DevOps对此类专家的要求的主题将很有趣。
蒂姆利德夫妇想知道其他公司的连续交付过程
是如何
工作的 。 公司采取了什么方式，在DevOps中如何建立开发流程和质量保证。 云原生团队成员也很有趣。 还有-有关团队内部以及开发人员和工程师团队之间的交互的问题。
对于
CTO而言，最重要的事情是弄清楚如何将所有这些流程组合在一起，并根据业务需求进行调整。 他确保应用程序对于企业和客户都是可靠的。 在这里，您需要了解哪些技术将在哪些业务任务下工作，如何构建整个流程等。 CTO还负责预算编制。 例如，他必须了解需要花多少钱来培训专家，以便他们可以在DevOps中工作。
如果您在这些场合有话要说，请保持沉默；
提交报告 。 征文截止日期为8月20日。 您显示的越早，完成报告和准备演示文稿的时间就越多。 因此，请勿拧紧。
好吧，如果您不需要公开演讲，只需
购买一张票，然后在9月30日和10月1日前与同事聊天即可。 我们保证它将是有趣和鼓舞人心的。
正如我们看到的DevOps
为了准确理解DevOps的含义，我建议阅读（或重新阅读）我的演讲“
什么是DevOps ”。 顺着市场的浪潮，我看到了DevOps的概念如何在不同规模的公司中转变：从小型初创公司到跨国公司。 该报告以一系列问题为基础，回答了这些问题，您可以了解您的公司是正在转向DevOps还是存在问题。
DevOps是一个复杂的系统，它应具有：
- 数码产品。
- 该数字产品正在开发的业务模块。
- 编写代码的产品团队。
- 持续交付实践。
- 平台即服务。
- 基础架构即服务。
- 基础架构作为代码。
- DevOps内的独立可靠性实践。
- 描述所有这些的反馈实践。
在报告的末尾，有一个方案可以对公司的DevOps系统有所了解。 它使您可以查看公司中的哪些流程已经调试，哪些仅需构建。
您可以在
此处观看视频报告。
现在会有一个好处： RIT ++ 2019中的一些视频与DevOps转换的最常见问题有关。
公司基础设施作为产品
Artyom Naumenko领导Skyeng的DevOps团队，并负责公司基础架构的开发。 他讲述了基础架构如何影响SkyEng中的业务流程：如何为其计算ROI，应选择哪些指标进行计算以及如何进行改进。
通往微服务的道路
Nixys致力于支持繁忙的Web项目和分布式系统。 其技术总监Boris Ershov讲述了如何将软件产品（大约5年前（甚至更多）开始开发）转移到现代轨道上。
通常，这样的项目是一个特殊的世界，那里基础设施的黑暗和古老的角落使当前的工程师不了解它们。 曾经选择的架构和开发方法已经过时，无法为企业提供相同的开发和发布新版本的步伐。 结果，该产品的每次发行都变成了一次令人难以置信的冒险，在此过程中，某些东西总是在最意外的地方掉下来。
这些项目的管理者不可避免地面临着改变所有技术过程的需求。 鲍里斯在报告中说：
- 如何选择适合该项目的架构并整理基础架构；
- 在转型过程中使用了哪些工具以及发现了哪些陷阱；
- 接下来该怎么做。
发布自动化或如何快速无痛交付
Alexander Korotkov是CIAN CI / CD系统的领先开发商。 他谈到了自动化工具，这些工具可以提高质量并将生产中的代码交付时间缩短5倍。 但是，仅靠一种自动化不可能取得这样的结果，因此亚历山大提请注意开发过程中的变化。
事故如何帮助您学习？
Alexey Kirpichnikov在SKB Kontur中实施DevOps和基础架构已有5年了。 三年来，他的公司大约发生了1,000次不同程度的史诗级fakaps。 例如，其中有36％是由于在生产中推出低质量版本引起的，而14％是由数据中心的铁维护工作引起的。
获得有关事故的准确信息，可以存档报告（事后检验），该报告已由公司的工程师连续进行了几年。 Postmortem写了一位值班的工程师，他是第一个响应有关事故信号的工程师，并开始修理所有东西。 为什么要折磨夜贼，写报告的工程师？ 这些数据使您可以查看整体情况，并朝正确的方向发展基础架构。
在演讲中，阿列克谢分享了如何编写一个非常有用的验尸报告，以及如何在一家大型公司中实施此类报告的做法。 如果您喜欢有关某人如何搞砸的故事，请观看有关该表演的视频。
我们了解您对DevOps的看法可能与我们的观点不一致。 知道如何看待DevOps转换将非常有趣。 在评论中分享您对该主题的经验和看法。我们已经接受了该计划哪些报告？
计划委员会本周通过了4份报告：关于安全性，基础结构和SRE的实践。
DevOps转型中最痛苦的话题也许是：如何确保信息安全部门的人员不会破坏开发，运营和管理之间已经建立的联系。
有些公司没有信息安全部门 。 那么如何保证信息安全呢？ 这
将从sudo.su 告诉 Mona Arkhipova。 从她的报告中我们了解到：
- 需要保护什么和保护谁；
- 常规的安全流程是什么？
- IT和IS流程如何相交
- 什么是CIS CSC以及如何实施？
- 如何以及通过哪些指标进行定期的IS检查。
下一份报告以代码的形式介绍了基础架构的发展。 减少手工程序的数量，而不会使整个项目陷入混乱，这可能吗？
Ixtens的Maxim Kostrikin 将回答这个问题。 他的公司使用
Terraform与AWS基础设施一起工作。 该工具很方便，但是问题是如何使用它来避免出现大量的代码。 维护这样的遗产每年将花费越来越多的钱。
Maxim将展示代码放置模式如何旨在简化自动化和开发工作。
我们将听到
Playkey的Vladimir Ryabov 提交的另
一份有关基础架构的
报告 。 在这里，我们将讨论基础架构平台，我们将学习：
- 如何了解存储容量是否得到有效利用？
- 如果仅使用20 TB的存储，几百个用户将如何接收10 TB的内容；
- 如何将数据压缩5次并实时提供给用户；
- 如何即时在多个数据中心之间同步数据；
- 如何在顺序使用一个虚拟机时排除用户彼此之间的任何影响。
神奇的秘密在于
FreeBSD的ZFS技术及其
在Linux上最新的
ZFS分支。 弗拉基米尔（Vladimir）将分享Playkey的案件。
来自Amixr.IO的Matvey Kukuy随时可以通过实例
讲述 SRE是什么以及它如何帮助构建可靠的系统。 Amixr.IO通过其后端处理客户事件，全球数十个值班团队已经处理了15万起案件。 在会议上，Matvey将分享其公司积累的统计数据和见解，以解决客户问题并分析fakapy。
再一次，我敦促您不要贪婪，并与DevOps-samurai分享您的经验。 申请报告，我们将有2.5个月的时间准备出色的演示文稿。 如果您想成为倾听者，请订阅新闻简讯并提供节目更新，并认真考虑提前预订门票，因为它们的价格将在会议日期附近上涨。