当然，这是关于 。 如果你不讲细节，那么30月1日和XNUMX月XNUMX日我们将召开开发、测试和运营流程结合的会议，如果你讲细节，请在cat下。
在 DevOps 方法中，项目技术开发的所有部分都是相互交织、并行发生并相互影响的。 这里特别重要的是创建可以实时更改、模拟和测试的自动化开发流程。 这有助于您立即响应市场变化。
在会议上，我们想展示这种方法如何影响产品开发。 如何保证系统对客户的可靠性和适应性。 DevOps 如何改变公司的结构和组织工作流程的方法。
幕后
对我们来说，重要的是不仅要了解不同的公司在 DevOps 方法框架内正在做什么，还要了解为什么要这样做。 因此，我们不仅邀请了专家加入程序委员会，还邀请了从不同立场看待 DevOps 论述的专家：
- 高级工程师；
- 开发商；
- 团队领导；
- 首席技术官。
一方面，这在讨论报告请求时造成了困难和冲突。 如果工程师有兴趣分析重大事故，那么开发人员更重要的是了解如何创建在云和基础设施中运行的软件。 但通过达成一致，我们创建了一个对每个人都有价值且有趣的计划：从工程师到首席技术官。
我们会议的目标不仅仅是选择最炒作的报告，而是展示整体情况：DevOps 方法在实践中如何运作，在转向新流程时可能会遇到什么样的麻烦。 同时，我们构建内容部分，从业务问题深入到具体技术。
会议部分将保持不变 .
- 基础设施平台。
- 基础设施即代码。
- 持续交付。
- 联系我们。
- DevOps 中的架构、CTO 的 DevOps。
- SRE 实践。
- 培训和知识管理。
- 安全、DevSecOps。
- DevOps 转型。
征文：我们正在寻找什么样的报告
我们有条件地将会议的潜在受众分为五组：工程师、开发人员、安全专家、团队负责人和 CTO。 每个小组都有自己参加会议的动机。 而且，如果您从这些立场来看待 DevOps，您就可以了解如何聚焦您的主题以及重点在哪里。
对于工程师来说， 对于正在创建基础设施平台的人来说，了解现有趋势、了解哪些技术现在是最先进的非常重要。 他们将有兴趣了解使用这些技术的现实经验并交换意见。 工程师会很乐意听一份分析一些严重事故的报告，而我们也会尽力选择和完善这样的报告。
对于开发者 理解这样一个概念很重要 云原生应用程序。 也就是说，如何开发软件以使其在云和各种基础设施中运行。 开发人员需要不断收到软件的反馈。 在这里，我们希望听到有关公司如何构建此流程、如何监控软件性能以及整个交付流程如何运作的案例。
网络安全专家 了解如何设置安全流程非常重要，这样它就不会阻碍公司内部的开发和变更流程。 关于 DevOps 对此类专家的要求的主题也很有趣。
团队领导想知道，其他公司的持续交付流程如何运作。 公司采取了什么途径来实现这一目标，他们如何在 DevOps 中构建开发和质量保证流程。 团队领导也对云原生感兴趣。 还有关于团队内部以及开发和工程团队之间互动的问题。
为 首席技术官 最重要的是弄清楚如何连接所有这些流程并根据业务需求进行调整。 他确保该应用程序对于企业和客户来说都是可靠的。 这里你需要了解哪些技术适用于哪些业务任务，如何构建整个流程等。 CTO 还负责预算。 例如，他必须了解需要花多少钱来重新培训专家，以便他们能够在 DevOps 中工作。
如果您对这些事情有话要说，请不要保持沉默， 。 征文截止日期为20月XNUMX日。 您注册越早，您完成报告和准备演示的时间就越多。 所以，不要拖延。
好吧，如果你不需要公开讲话，就 30月1日和XNUMX月XNUMX日过来和同事交流。 我们保证这将是有趣且鼓舞人心的。
我们如何看待 DevOps
为了准确理解 DevOps 的含义，我建议阅读（或重新阅读）我的报告“” 走过市场的浪潮，我观察到DevOps的理念是如何在不同规模的公司中转变的：从小型初创公司到跨国公司。 该报告基于一系列问题，通过回答这些问题，您可以了解您的公司是否正在向 DevOps 迈进，或者是否存在问题。
DevOps是一个复杂的系统，它必须包括：
- 数码产品。
- 开发此数字产品的业务模块。
- 编写代码的产品团队。
- 持续交付实践。
- 平台即服务。
- 基础设施即服务。
- 基础设施即代码。
- DevOps 中内置的维护可靠性的单独实践。
- 描述这一切的反馈实践。
报告最后有一张图表，展示了公司的 DevOps 系统。 它可以让您看到公司中的哪些流程已经简化，哪些流程尚未建立。
您可以观看报告视频 .
现在还有一个奖励： RIT++ 2019 的几个视频，涉及 DevOps 转型的最常见问题。
公司基础设施作为产品
Artyom Naumenko 领导 Skyeng 的 DevOps 团队，负责公司基础设施的开发。 他讲述了基础设施如何影响 SkyEng 的业务流程：如何计算投资回报率、应选择哪些指标进行计算以及如何改进这些指标。
迈向微服务之路
Nixys 公司为繁忙的网络项目和分布式系统提供支持。 其技术总监 Boris Ershov 讲述了如何将 5 年前（甚至更早）开始开发的软件产品转移到现代平台上。
一般来说，此类项目是一个特殊的世界，基础设施中存在一些黑暗而古老的角落，而当前的工程师并不了解它们。 而且曾经选择的架构和开发方法已经过时，无法为业务提供相同的开发和新版本发布的速度。 结果，每一次产品发布都变成了一次令人难以置信的冒险，其中不断有东西掉落，而且是在最意想不到的地方。
此类项目的管理者不可避免地需要改造所有技术流程。 鲍里斯在报告中说：
- 如何为项目选择正确的架构并整理基础设施；
- 使用哪些工具以及在转型过程中遇到哪些陷阱；
- 接下来做什么。
发布自动化或如何快速、轻松地交付
Alexander Korotkov 是 CIAN 的 CI/CD 系统的主要开发人员。 他谈到自动化工具可以提高质量并将代码交付生产的时间缩短 5 倍。 但这样的成果仅靠自动化是无法实现的，因此Alexander也关注开发流程的变化。
意外事故如何帮助你学习？
Alexey Kirpichnikov 已经在 SKB Kontur 实施 DevOps 和基础设施 5 年了。 在三年的时间里，他的公司发生了大约 1000 起不同程度的史诗般的假事件。 例如，其中 36% 是由于将低质量版本投入生产造成的，14% 是由数据中心的硬件维护工作造成的。
公司工程师连续几年维护的报告档案（事后分析）使得获得有关事故的准确信息成为可能。 验尸报告由值班工程师撰写，他第一个响应紧急信号并开始修复一切。 为什么要通过写报告来折磨那些在晚上与 facap 作斗争的工程师呢？ 这些数据使您能够了解全局并推动基础设施发展朝着正确的方向发展。
Alexey在演讲中分享了如何写出真正有用的事后分析报告，以及如何在大公司实施此类报告的实践。 如果您喜欢有关某人如何搞砸的故事，请观看表演视频。
我们理解您对 DevOps 的愿景可能与我们的不同。 了解您如何看待 DevOps 转型将会很有趣。 在评论中分享您对此主题的经验和愿景。
我们已经接受了哪些报告进入该计划？
本周，计划委员会通过了 4 份报告：关于安全、基础设施和 SRE 实践。
也许 DevOps 转型中最痛苦的话题是：如何确保信息安全部门的人员不会破坏开发、运营和管理之间已经建立的联系。 有些公司没有信息安全部门进行管理。 这种情况下如何保证信息安全呢？ 关于它 来自 sudo.su 的莫娜·阿尔希波娃。 从她的报告中我们了解到：
- 需要保护什么以及免受谁的保护；
- 常规安全流程有哪些？
- IT 和信息安全流程如何交叉；
- 什么是 CIS CSC 以及如何实施；
- 如何以及通过哪些指标进行定期信息安全检查。
下一份报告涉及基础设施即代码的开发。 减少手动例行工作量，并且不让整个项目变得混乱，这可能吗？ 对于这个问题 来自 Ixtens 的马克西姆·科斯特里金 (Maxim Kostrikin)。 他的公司使用 Terraform 用于使用 AWS 基础设施。 该工具很方便，但问题是如何避免在使用它时创建巨大的代码块。 维护这样的遗产将变得越来越昂贵。
Maxim 将展示代码放置模式如何工作，旨在简化自动化和开发。
还有一个 我们将听到有关基础设施的信息 Playkey 的弗拉基米尔·里亚博夫。 这里我们讲一下基础设施平台，我们将学习：
- 如何了解存储空间是否得到有效利用；
- 如果仅使用 10 TB 的存储空间，数百个用户如何能够接收 20 TB 的内容；
- 如何将数据压缩5倍并实时提供给用户；
- 如何在多个数据中心之间实时同步数据；
- 如何在顺序使用一台虚拟机时消除用户之间的影响。
这个魔法的秘密就是技术 适用于 FreeBSD 的 ZFS 和它的新鲜叉子 Linux上的ZFS。 Vladimir 将分享 Playkey 的案例。
来自 Amixr.IO 的 Matvey Kukuy 准备好生活中的例子 ， 什么 SRE 以及它如何帮助构建可靠的系统。 Amixr.IO 通过其后端传递客户事件；全球数十个值班团队已处理了 150 万个案例。 在会议上，Matvey 将分享他的公司通过解决客户问题和分析失败而积累的统计数据和见解。
我再次敦促您不要贪婪，分享您作为 DevOps 武士的经验。 服务 为了一份报告，你和我将有 2,5 个月的时间来准备一篇精彩的演讲。 如果你想成为一名倾听者， 阅读包含节目更新的时事通讯，并认真考虑提前预订门票，因为临近会议日期，门票会变得更加昂贵。
来源： habr.com