10月29日至30日在圣彼得堡举办了
DevOops会议。 在本文中，我将分享我的见解和见解，以及关于我所听到的报告的简要说明。 一个小小的免责声明：由于我是开发人员，因此某些想法和评论在Dev中可能会比在Ops中存在偏见，但是我将尝试尽可能客观。
DevOops是
JUG Ru Group组织的活动之一。 我必须承认，报告的组织和水平是在水平上。 会议历时两天，分三场进行。 此外，还有用于与演讲者交流的讨论区，讲习班以及闪电演讲-更轻松，更简短的演示，包括那些以前没有表演过并想尝试作为演讲者的人。
主题画布DevOops 2019-云原生。 大多数报告直接或间接地专门针对云计算。 长期以来，这个话题并不是什么新鲜事物，但是在使用云技术的过程中会出现许多显而易见的困难。 许多人故意寻找答案。 在演讲后的质量检查会议上，这一点尤其明显。 向演讲者询问了一些确实令人振奋的实用问题。 几乎每个问题之后都有其他参与者的言论“我们有同样的问题！”，开始了热烈的讨论。
第一天性格，社区和文化：繁荣的重要因素（蒂莫西·李斯特（Timothy Lister），大西洋系统协会公司（The Atlantic Systems Guild Inc.））
该会议由蒂莫西·李斯特（Timothy Lister）开幕，他早在1987年（！）写了一
本关于DevOps实践的
书 。 蒂姆谈到了什么，将一支健康而愉快的氛围的强大成功团队与一支平庸而有毒的团队区分开来。 我特别记得这个想法：
“一家好公司到处都是说“我不知道”的人。”
这是关于团队内部的开放和信任。 如果您有雄心勃勃的目标，那么开放的气氛至关重要。 为此，团队中的每个人都应该感到舒适和自由。 这并不意味着出现问题时，团队成员会立即将其升级为所有人。
开放的
气氛非常重要，并且
随时 都有 能力求助于某个特定的人（无论职位高低）或整个团队，并清楚地指出需要改进或改变的地方。 当每个人都知道如果出现问题时，这种文化会为工作打下平静的背景。
以我的经验，对于生产高效且稳定的操作，此因素非常重要。 毕竟，问题，摩擦和方向的改变将永远存在。 开放的氛围是一种通用工具，可让您应对个人和团队挑战。
在我看来，另一种想法是正确的：在公司中建立文化没有一个真正的公式。
“没有文化可以称为理想。 而且没有一种文化可以称为彻底的失败。”
最新趋势：越来越多的会议包括有关管理，沟通，团队建设和文化的报告。 DevOops也不例外。 我认为这是一个积极的趋势，因为这些因素对最终结果的影响要大于技术难题。
“领导者不是管理团队，而是发展团队。”
用代码（不是YAML）来做！ 释放用于Kubernetes的Kotlin DSL的功能（Victor Gamow，Confluent和Cirrus Labs的Fedor Korotkov）
半正式报告，但它充分表达了编写无尽的YAML文件，它们的支持以及（如果发生错误或拼写错误时，请进行调试）的痛苦。 这甚至导致出现了YAML工程师的不同职位。
这一切是如何开始的？ 从前有脚本。 然后还有更多。 还有更多。 需要统一，简化和扩展解决方案。 因此，在DevOps世界中，YAML格式出现并成为许多工具的标准。
该报告的作者认为并说：“音乐学院里有些事是错误的。”
- 目前尚不清楚如何测试YAML文件。
- 容易犯错误。 而且，有些错误几乎是不可能发现的，并且很难纠正。 例如，您可以轻松地将依赖项的版本指定为数字而不是字符串。 然后很长时间找出配置错误的原因。 而这与类型转换和舍入有关。
- 如果错误是语法错误，则将在CI中足够快地检测到错误。 但这是不准确的。
该报告的重点是将无效的配置上传到Kubernetes，他平静地回答：
错误太多 。
Victor和Fedor提供在Kotlin DSL上编写配置，这有助于解决所有这些问题。 是的，该解决方案既有趣又方便，但不是通用的，仅适用于k8s。 此外，在更新API的情况下，您还必须更新库。
管道和Pod：具有Kubernetes的DevOps（Burr Sutter，Red Hat）
关于Kubernetes的一般概念和主要组件以及其他流行的Ops工具和Ops实践的简短报告。 对于该主题的初学者-需要什么。 它非常适合开发人员大会的日程安排，但是在DevOps专门会议上听到此级别的报告很奇怪。 然而，审查结果证明是好的，简单而明确的。
但是以某种方式使用StringBuilder从Java代码形成JSON太多了。 即使考虑到这是一个演示项目。
DevOps实践中连续更新的模式和反模式（Baruch Sadogursky，JFrog）
在巴鲁克（Baruch）的报告中，很难挑出任何一个想法或方向。 相反，它是个人经验，生活故事，“如何做善事和坏事”，故事，其他黑客和“ fakapchikov”的例子的集合。
特别是从这份报告中，我记得一个
故事，当时由于部署过程中的错误，奈特资本集团（Knight Capital Group）在45分钟内损失了4.4亿美元，并破产了。
最后，巴鲁克讲了一个有关空客A350软件错误的故事。 由于此错误，航空公司被迫每149小时
重新启动飞机 ，因此必须将其植入地面。 如果有人忘记这样做，飞机将冻结。 如此令人不愉快的错误。 问题很简单-代码中发生溢出。 修复也很简单。 但是，假设他们仍然忘记重新启动飞机，它在洛杉矶→伦敦的航班上起飞，降落前3小时，飞行员意识到飞机会在一小时内结冰。 “休斯顿，我们有问题。” “现在我们修复它！”调度员回答，召集了AirBus程序员，对其进行了修复，一切正常。 接下来要做什么？ 在飞机上部署新版本？ 还是不冒险？ 巴鲁克决心：“部署。 情况不会更糟。”
第二天CDK和基础架构作为代码（Sergey Kurson，AWS）
Sergey谈到了AWS CDK（云开发套件）。 这是一组库，使您可以管理代码基础结构。 该决定是有争议的，因为命令式样式的基础结构管理是一种回滚。 所有现代自动化工具都允许您以声明式（即应从中得出的状态）描述基础架构。 但是，这种方法有很多优点。 例如，大大简化了已部署基础架构的测试过程，并且部署和决定部署什么以及如何部署的过程变得更加灵活。 此外，通过事件，属性或指标进行动态，极其灵活的基础架构管理的机会很大。
为什么我们需要服务筛？ （Otomato软件的Anton Weiss）
也许是这次会议上最好，最深刻的报道之一。 所谓“服务筛”，是指服务网格-云基础架构的独立层，用于控制服务之间的通信。 服务网格模式将许多任务从服务级别（即从应用程序开发人员）委托给服务筛子级别本身（在DevOps上）：
尽管Service Mesh作为一种技术已经存在了好几年，但作者对此进行了深入的报告，并分析了其起源，发展史以及未来几年的发展趋势。
该报告对开发人员特别有用，因为Service mesh解决的任务现在通常在服务级别解决。 这将使开发人员花费更多时间，并使其难以集中精力解决业务问题。
加快Internet请求并安然入睡（Sergey Fedorov，Netflix）
Sergey在Netflix工作，以确保该服务尽快为最终用户使用。 其中的所有请求均分为两个大组：
在许多情况下，有必要同时向基础架构的动态和静态部分发出请求。 但是这种方案会产生开销：您需要建立至少两个连接，两次进行TLS握手，等等。
有一种想法是，如果仅向静态基础结构发出请求，则在其上安装智能代理，并委托它代表它向云提出动态请求，这将加快客户端请求的速度。 Netflix团队已经实施了这样的计划，对真实用户进行了测试。 但是，很明显，它并不总是有效，并且并非对每个人都有效，有些请求开始变得更糟。
因此，团队决定采用其他方式。 他们提出了一种方案，该方案允许每个客户端单独决定执行动态请求的利润如何：直接来自客户端，还是将此请求的代理委托给基础结构的静态部分。
这是不必退出技术挑战的一个很好的例子。 如果您要使产品更好，并且使用户的生活更轻松，则需要勇气并选择折中方案。
为什么IT行业正在度过黑暗时期，如何指责DevOps以及为何Capital可以提供帮助（ZEDEDA Inc.的Roman Shaposhnik）
本次会议最“有远见”的报告。 在其中，罗曼谈到了许多技术（与资本）如何相互联系（不可分割）的问题。 我认为这篇论文对工程师来说非常重要，并且理解创造技术来解决人员和企业的特定问题非常重要。 有了这样的思想，就可以更加轻松地确定任务的优先级并了解重要的和不重要的。 罗曼还谈到了为什么封闭的政策和公司（其影响力越来越大）会导致IT行业的全球危机。 以及有关信息技术领域的历史和哲学的整体。
DevOops与发展有关
几位发言者问听众，谁参与了运营和基础架构，谁正在发展。 结果使我感到惊讶：分布大约为50到50。越来越多的开发人员希望了解代码编写后会发生什么，应用程序如何部署以及彼此之间的通信，这是很棒的。 有了这种理解，在编写代码时，您会立即考虑它在生活条件下如何工作以及可以在哪里放置稻草。