在Mail.ru Cloud Solutions的支持下，莫斯科DevOps社区于12月7日组织了第三
次莫斯科DevOpsDays会议。 除了主要的DevOps从业人员的报告外，参与者还可以参加简短的激励性闪电讲座，研讨会和在露天场所聊天。
我们从六个演讲中收集了重要的见解，并与几位发言人进行了访谈，以找出报告中遗漏的内容。
内部：
- JFrog的Baruch Sadogursky：“让软件像流水一样从供应商流向用户”
- 南桥Pavel Selivanov：“ Dev和Ops的一项共同任务是-制造出可行的产品”
- X5零售集团的Vladimir Utratenko：“企业中的DevOps是无痛苦，无火灾的发展”
- Facebook的谢尔盖·普齐列夫（Sergey Puzyrev）：“生产工程师全面照顾服务：让用户和开发人员都感觉良好”
- AMBOSS的Mikhail Chinkov：“一个部门不能遵循DevOps的道路，整个公司都应该遵循”
- Rosbank DevOps爱好者：“在血腥的企业中实施DevOps的1000天”
1. JFrog Baruch Sadogursky：“让软件像流水一样从供应商流向用户”
每小时更新一次的软件失败会发生在每个人身上。 这只是演讲中的一个令人恐惧的故事：骑士资本在更新失败后每小时损失4.4亿美元。
Baruch谈到了持续更新的DevOps模式，这将有助于避免用户失败和仇恨：
本地回滚 -保留设备上软件的先前版本以防万一。 如果一切都非常糟糕，以至于您无法通过空中发送补丁，这将为您提供保护。
空气更新更好地连续进行。 就像美洲虎的开发人员一样，情况将有所不同：由于制动系统中的错误无法通过空气进行更新，因此有必要召回销售中的汽车。 这既痛苦又昂贵。
持续更新 -在准备好新功能后就不断更新软件。 通过罕见的更新，功能可以分组，关键更新可以等待非关键更新。 像在特斯拉中一样，应该修复随机制动的更新正在等待国际象棋游戏被更新。
自动化部署 -用机器代替人员，因为人们不知道如何执行常规操作。
经常更新 -帮助养成习惯并摆脱恐惧。 罕见的更新会变成紧急事件。
了解设备状态 -测试更新，而不是从头开始安装。 这很重要，因为根据设备的状态，更新的行为可能会有所不同。
金丝雀发布 -向少数用户
发布更新并观看。 如果出现问题，可以减少损坏。
更新无障碍 -让客户只注意到新功能，直到推出更新之前，几周内就不会没有服务。
我们与Baruch Sadogursky讨论了在俄罗斯和西方IT中DevOps的前景如何不同，Cloud是否会很快为我们做一切，以及所有软件服务是否都将滑入aaS方案-请参见访谈：
2.南桥Pavel Selivanov：“ Dev和Ops的一项共同任务是-制造出可行的产品”
实施Kubernetes不会帮助实现DevOps，反之亦然-它会破坏一切。 帕维尔（Pavel）告诉了为什么技术（即使最酷的技术）也无法解决您的所有问题：
项目的复杂性已经超出了代码 。 以前，存在一个复杂的应用程序：项目内部和复杂开发之间的交互，但是结构很简单-部署了管理员，一切正常。 我们切换到微服务：每个服务都是一个简单的应用程序，使用标准协议进行通信并快速开发，但是项目结构变得更加复杂。 具有微服务架构的项目的复杂性并没有消失-它已经超出了代码。 现在，DevOps工程师对此负责。
开发人员在实现DevOps之后不希望更改 。 结果，使用Kubernetes的工作流仍然看起来像是通过墙将任务从Dev扔到Ops，但不再是隐喻的-Git变成了这样的墙。 开发人员将代码放在那里并像以前一样工作，管理员拥有Kubernetes，CI / CD以及其他所有内容。
但是，开发人员需要接受更改 。 当开发人员不知道管理员的工作并且管理员不知道开发人员的情况时，就会产生问题。
如果开发人员没有进行任何更改，他们将不会意识到应用程序的工作是他们的责任-不同的技术技巧将行不通。
随着DevOps和Kubernetes的出现，开发方面将发生很多变化。 开发人员必须胜任Ops，反之亦然。 这些专家具有自己的特定技能，但他们必须了解彼此的工作。 在实施Kubernetes之前，Dev和Ops必须成为朋友，否则您将无法实现。
帕维尔·塞利瓦诺夫（Pavel Selivanov）谈到了5年内Kubernetes将会发生什么以及为现代初创企业构建技术堆栈的方法-请参见访谈：
3. X5零售集团Vladimir Utratenko：“企业中的DevOps是无痛苦，无火灾的发展”
当公司意识到发展太慢并且不符合现实时，他们便开始了DevOps转型，他们渴望更好地发展和更快地推出。
弗拉基米尔（Vladimir）告诉我们这是怎么发生的，有什么收获：
- 首先，公司聘请DevOps工程师。 这是一名高级系统管理员，他从事发布到生产中的部署，开发环境的标准化，建立基础结构，检测和修复各种问题，过程自动化以及其他技术任务。
- 这样一来，DevOps工程师已远远不够，该公司雇用了一个DevOps团队。 这是一个能力中心，可以组织不同工程师的工作，使您可以将精力集中在一个方向上。
- 实际上，DevOps工程师和DevOps团队是DevOps转换的反模式。 由于DevOps与实践和文化有关，因此，在技术公司（SRE，生产工程）中有DevOps的实现。
怎么办 雇用一个临时的DevOps团队来帮助实施DevOps转型将继续实践，培养发展文化和技术文化。
当企业进入游戏并投资DevOps时，可能会出现以下几种情况：起飞时一切都会崩溃； 将保留为SRE /生产工程或嵌入式Ops； 当流程依赖于业务指标时，它将迁移到BizOps。
弗拉基米尔·乌特拉坚科（Vladimir Utratenko）告诉我们企业中真正的“血腥” DevOps以及大型零售店内如何实施实践-请参见访谈：
4. Sergey Puzyrev，Facebook：“生产工程师负责整体服务：让用户和开发人员都感觉良好”
Facebook是一家庞大的公司，拥有许多组件，服务器，人员，数据中心。 尽管规模巨大，但速度非常快-开发人员一天可以多次推出服务。 Facebook也在迅速发展，不仅用户和服务器数量的增加，开发人员的数量也在增加，这使流程变得复杂。
谢尔盖告诉生产工程师在Facebook上的工作：
- 生产工程师编写了很多文章，应该具有系统知识：操作系统，文件系统，数据库，网络等。 必须具有分布式系统和可靠性工程方面的经验，即支持产品的可靠性。 他必须随时待命，即可以随时呼叫。
- 生产工程师在操作方面与软件工程师不同，但实际上是软件工程师的一个子类。 软件工程师编写的代码更多，他们可能具有与数据处理相关的其他技能。 在Facebook上，此类专家也应随时待命，这对许多人来说并不令人意外。
- 公司中生产工程师的需求金字塔始于监视服务器及其生命周期，即接收新硬件，对其进行设置并使其投入运行。 服务级别的下一个级别相同：监视服务及其生命周期。 然后是无缝扩展和高级监视。 在服务生命周期自动化之后，它们会切换到自动缩放。 最后，您需要进行调整，以便有效地进行扩展，从而节省公司的资金和资源。
5. AMBOSS的Mikhail Chinkov：“一个部门不能遵循DevOps的道路，整个公司都应该遵循”
Michael认为DevOps是一个持续发展的过程。 您无法引入任何工具并就此止步。 哪些问题阻止公司成为DevOps？如何实施实践？
了解DevOps的差异 。 福音派人士认为，规范的发展有五个支柱：
- 文化-注重人与合作；
- 自动化-将例程委派给工作流程；
- 精益-强调为用户提供价值；
- 共享-持续的知识共享；
- 指标并在他们的帮助下获得反馈。
公司通常只专注于自动化和向用户交付价值。 但是，您可以通过文化，知识共享和DevOps指标来跟踪开发情况，这是遥遥无期的。
DevOps标准化存在的问题 。 所有公司的产品目标都是不同的；它们无法标准化。 公司中DevOps的状态取决于公司本身，但是许多人对此并不了解，他们认为聘请DevOps工程师就足够了。
为什么我们还没有DevOps？ 有两个关键问题。 在企业中-组织发展缓慢，难以改变数千名员工头脑中的载体。 在初创企业中，缺乏知识资源，这是转型资源分配的问题。
公司内部DevOps的开发阶段 ：
- 首先是云中的基础架构，但是除了一个或两个管理员外，没人知道它是如何工作的。
- 第二-基础架构对所有工程师都是透明且可理解的，但流程并未投入使用；
- 第三-工程师独立启动和修复实时服务；
- 第四-工程师（如果愿意）将为核心基础架构，云中的透明代码以及按钮部署做出贡献。
理想的方案-每个人都可以使用相同的基础架构，所有工程师都可以使用该产品并了解他们在做什么。
关闭所有文化和技术领域的公司后，公司的DevOps转型将考虑业务指标和平台指标的反馈。
6. Rosbank的DevOps爱好者：“在血腥的企业中实施DevOps的1000天”
来自Rosbank的Yuri Bulich，Dina Maltseva和Eugene Pankov告诉了他们三年来DevOps的经历。 有两个目标：解决特定团队中的特定问题并实施集中式工具。
以下是取得的结果：
产品团队的成果 ：组装速度提高了30倍，安装速度提高了6倍，整个周期最多可节省30％。 我们有机会将按钮滚动到富有成效的
平台团队的成果 ：组装和安装速度提高了10倍，安装数量增加了87％，自动测试的覆盖率达到了46％。 集成团队不再是瓶颈
那么，如何在血腥企业中实施DevOps实践呢？
首先，介绍一个试点项目 ：选择团队，决定如何实施体系结构并选择工具。 我们选择了具有开放许可的工具，并在银行中进行了安装并拥有与之合作的专业知识。 在罗斯银行（Rosbank），连同DevOps平台一起，部署了私有云，这在一开始就有所帮助。 在云中，有可能在15分钟内通过一个按钮获取必要的资源，而以前这样的过程可能需要一周的时间。
在银行和其他企业中，您需要事先与信息安全团队一起解决限制，并找到一种解决方案，以使您能够实施更改。
试点之后，必须扩展成功的解决方案 。
- 重要的是要尽可能“拉直”传送带，消除传送带上不必要的链接，突出显示价值提供者，并删除其余组件。 中间体是反模式。 例如，在罗斯银行（Rosbank），许多团队没有内部开发，只剩下外部开发。 这导致了专门的DevOps团队的出现，该团队提供了从外部开发人员到内部开发人员的代码传输。 通过将外部开发集成到CI / CD中，解决了该问题，以便他们不仅将代码从他们自己的代码转移到银行，而且对代码的成功负责。
- 成熟度模型中包括DevOps实践的要素，列出了工具，并考虑了与外部供应商合作的功能-将来，这有助于在新团队中实施时迅速减少积压的任务。
- 需要以软控制和建议的形式进行治理。 DevOps手册运行良好-它是一组组织和工具特征，可帮助团队正确使用平台。
- 值得立即注意文化，然后许多更改将变得更快，更容易。 发展内部社区，举行会议，技术研讨会，培训，有趣的活动。 它产生了成果：人们分享他们的做法，看看谁做了什么，知道该向何处去，公司内部存在着炒作和健康的竞争。
- 与不参与流程的人，不成熟的团队一起工作是没有意义的，最好是对感兴趣的团队和忠诚的人进行投资。
- 所选的解决方案对于使用它的工程师来说应该很方便。
- 外部开发不是障碍，您也可以在那里进行实践，主要是团队本身有一种愿望。
多一点好
来自vdsina.ru的Alexander Chistyakov的DevOps读者应阅读的书籍清单：
- 伊琳娜·雅库琴科（Irina Yakutenko）“意志和自我控制”。
- 丹尼尔·卡尼曼（Daniel Kahneman）：“思考，快和慢”。
- 芭芭拉·奥克利（Barbara Oakley）“数字的思想”。
- Maxim Dorofeev“杰迪技巧”。
- 维克多·弗兰克（Viktor Frankl）“人在寻找意义”。
敬请期待
我们也喜欢DevOps。 在我们的电报频道中，关注
@DevOps和@Kubernetes系列的公告以及其他Mail.ru Cloud Solutions事件：
t.me/k8s_mail