🥇2020 年俄罗斯 DevOps 状况

你如何理解某事物的状态？

您可以依靠各种信息来源（例如网站上的出版物或经验）形成的意见。你可以问问你的同事和朋友。另一种选择是看会议的主题：程序委员会是业界的活跃代表，所以我们相信他们选择相关主题。一个单独的领域是研究和报告。但有一个问题。世界各地每年都会进行DevOps状况的研究，报告都是由外国公司发布的，而关于俄罗斯DevOps的信息几乎没有。

但进行这样一项研究的日子已经到来，今天我们将告诉您所获得的结果。各公司联合研究了俄罗斯 DevOps 的状况“快车42“和”翁蒂科” Express 42 公司帮助技术公司实施和开发 DevOps 实践和工具，并且是俄罗斯最早谈论 DevOps 的公司之一。该研究的作者伊戈尔·库洛奇金（Igor Kurochkin）和维塔利·哈巴罗夫（Vitaly Khabarov）在Express 42从事分析和咨询工作，拥有不同公司运营和经验的技术背景。 8 年来，同事们研究了数十家公司和项目（从初创公司到大型企业），这些公司和项目存在不同的问题，以及不同的文化和工程成熟度。

在他们的报告中，Igor 和 Vitaly 解释了研究过程中存在哪些问题、如何解决这些问题、原则上如何进行 DevOps 研究以及 Express 42 决定进行自己的研究的原因。你可以看看他们的报告这里.

开发运营研究

伊戈尔·库洛奇金开始了谈话。

我们经常在 DevOps 会议上询问观众：“您阅读过今年的 DevOps 状态报告吗？” 很少有人举手，我们的研究表明只有三分之一的人研究他们。如果您从未见过此类报道，那么我们可以说它们都非常相似。最常见的是这样的短语：“与去年相比......”

这里我们遇到了第一个问题，接下来还有两个问题：

我们没有去年的数据。没有人对俄罗斯的 DevOps 状况感兴趣；
方法。不清楚如何检验假设、如何构造问题、如何进行分析、比较结果、寻找联系；
术语。所有报告都是英文，需要翻译，DevOps 的通用框架尚未发明，每个人都会提出自己的框架。

让我们看看世界上 DevOps 状况的分析通常是如何进行的。

历史信息

DevOps 研究自 2011 年开始进行。第一个进行这些测试的是配置管理系统开发人员 Puppet。当时，它是以代码形式描述基础设施的主要工具之一。 2013 年之前，这些研究只是封闭形式的调查，没有公开报告。

2013 年，IT Revolution 出现，出版了所有关于 DevOps 的主要书籍。他们与 Puppet 一起准备了第一份出版物《State of DevOps》，其中首次出现了 4 个关键指标。第二年，以其行业实践和工具的常规技术雷达而闻名的咨询公司 ThoughtWorks 也参与其中。 2015 年，增加了一个方法论部分，他们如何进行分析变得清晰起来。

2016 年，该研究的作者创建了他们的公司 DORA（DevOps 研究和评估），发布了一份年度报告。第二年，DORA 和 Puppet 发布了最终的联合报告。

然后事情变得有趣了：

2018 年，两家公司分拆并发布了两份独立报告：一份来自 Puppet，另一份来自 DORA 与 Google 合作。 DORA 继续将其方法用于影响整个公司关键指标和绩效的关键指标、绩效概况和工程实践。 Puppet 提出了它的方法，并描述了 DevOps 的流程和演变。但这个故事并没有流行起来；2019 年，Puppet 放弃了这种方法并发布了新版本的报告，其中列出了关键实践以及从他们的角度来看它们如何影响 DevOps。然后另一件事发生了：谷歌收购了DORA，他们一起发布了另一份报告。也许你已经看到了。

今年事情变得复杂了。据了解，Puppet 发起了调查。他们比我们早做了一周，而且已经完成了。我们参与其中并了解他们感兴趣的主题。 Puppet 目前正在执行分析并准备发布报告。

但目前DORA和Google方面还没有任何消息。调查通常在五月份开始，有消息称 DORA 创始人之一 Nicole Forsgren 已经跳槽到另一家公司。因此，我们假设今年DORA不会有任何研究或报告。

俄罗斯的情况怎么样？

我们还没有对DevOps进行过任何研究。我们在会议上发言，复述了其他人的结论，Raiffeisenbank 翻译了 2019 年的“DevOps 现状”（您可以在 Habré 上找到他们的公告），非常感谢他们。仅此而已。

因此，我们使用 DORA 方法和研究结果在俄罗斯进行了自己的研究。我们使用 Raiffeisenbank 同事的报告进行研究，包括同步术语和翻译。与行业相关的问题取自DORA报告和今年的Puppet调查问卷。

研究过程

报告只是最后一部分。整个研究过程由四个大阶段组成：

在准备阶段，我们采访了行业专家并准备了一系列假设。在此基础上，我们整理了问题并启动了整个 6 月份的调查。然后我们分析并准备了报告本身。对于DORA来说，这个过程需要3个月的时间。我们用了 XNUMX 个月的时间完成了它，现在我们明白我们的时间几乎不够：只有通过分析，你才能明白需要提出什么问题。

参与者

所有外国报道都以参与者的肖像开始，其中大多数不是来自俄罗斯。俄罗斯受访者的比例每年在 5% 到 1% 之间波动，这并不能让我们得出任何结论。

地图来自 Accelerate State of DevOps 2019 报告：

在我们的研究中，我们成功采访了 889 人——这个数字相当大了（DORA 在其报告中每年对大约 XNUMX 人进行民意调查），在这里我们已经实现了目标：

确实，并非所有参与者都到达了终点：完成率略低于一半。但这足以获得有代表性的样本并进行分析。 DORA 并未在其报告中披露入住率，因此此处无法进行比较。

行业及职位

我们的受访者代表了十几个行业。一半从事信息技术工作。其次是金融服务、贸易、电信等。其中职位包括专家（开发人员、测试人员、运维工程师）和管理人员（团队、小组、领域的领导、总监）：

每两个人中就有一个在中型公司工作。每三分之一的人在大公司工作。大多数人以最多 9 人的团队形式工作。另外，我们询问了主要活动，大多数都与运营相关，大约 40% 涉及开发：

我们就是这样收集信息，对不同行业、公司、团队的代表进行比较和分析的。我的同事维塔利·哈巴罗夫将向您介绍分析结果。

分析比较

维塔利·哈巴罗夫：非常感谢所有完成我们的调查、填写问卷并为我们提供数据以供进一步分析和检验我们的假设的参与者。感谢我们的客户和客户，我们拥有丰富的经验，帮助我们识别行业关注的问题并制定我们在研究中测试的假设。

不幸的是，你不能一方面列出问题清单，另一方面收集数据，以某种方式比较它们，说：“是的，一切都是这样，我们是对的”，然后各奔东西。不，我们需要方法论和统计方法来确保我们没有错误并且我们的结论是可靠的。然后我们可以根据这些数据开展进一步的工作：

关键指标

我们以 DORA 方法为基础，他们在《Accelerate State of DevOps》一书中详细描述了该方法。我们检查了关键指标是否适合俄罗斯市场，是否可以像 DORA 用来回答“俄罗斯工业与外国工业如何对应？”的问题一样使用。

关键指标：

部署频率。应用程序的新版本多久部署到生产环境（计划更改，不包括修补程序和事件响应）？
交货时间。提交更改（将功能编写为代码）和将更改部署到生产环境之间的平均时间是多少？
恢复时间。在发生事件、服务降级或发现影响应用程序用户的错误后，将应用程序恢复到生产环境平均需要多长时间？
不成功的改变。生产环境中的部署中有多少百分比会导致应用程序降级或发生事件并需要修复（回滚更改、开发修补程序或补丁）？

DORA 的研究发现了这些指标与组织绩效之间的联系。我们也在我们的研究中检查了这一点。

但为了确保这四个关键指标能够产生影响，您需要了解它们是否以某种方式相互关联？ DORA 的回答是肯定的，但有一个警告：变革失败率与其他三个指标之间的关系稍弱。我们得到了几乎相同的图片。如果交付时间、部署频率和恢复时间彼此相关（我们通过 Pearson 相关性和 Chaddock 量表建立了这种相关性），那么与不成功的变更就不存在如此强的相关性。

原则上，大多数受访者倾向于回答说，他们在生产中发生的事件数量相当少。尽管我们稍后会看到受访者群体之间在不成功变革的比率上仍然存在显着差异，但我们还不能使用这个指标来进行这种划分。

我们将此归因于这样一个事实：（正如在与一些客户的分析和沟通过程中所证明的那样）对于什么被视为事件的看法存在细微的差异。如果我们设法在技术窗口期间恢复服务性能，这是否可以被视为事件？可能不会，因为我们解决了一切，我们很棒。如果我们必须以正常、熟悉的模式重新滚动应用程序 10 次，我们可以将其视为事件吗？看来不是。因此，不成功的变更与其他指标之间的关系问题仍然悬而未决。我们将进一步澄清。

这里重要的是，我们发现交付时间、恢复时间和部署频率之间存在显着的相关性。因此，我们利用这三个指标根据生产力进一步将受访者分为几组。

克要多少钱？

我们使用层次聚类分析：

我们将受访者分布在 n 维空间中，其中每个受访者的坐标就是他们对问题的答案。
我们将每个受访者声明为一个小集群。
我们将彼此最接近的两个簇合并为一个更大的簇。
我们找到下一对簇并将它们组合成一个更大的簇。

这就是我们如何将所有受访者分组到我们需要的集群数量中。使用树状图（簇之间的连接树），我们可以看到两个相邻簇之间的距离。我们剩下的就是对这些簇之间的距离设定一定的限制，并说：“这两个群体彼此之间很有区别，因为它们之间的距离是巨大的。”

但这里有一个隐藏的问题：我们对簇的数量没有限制——我们可以得到2、3、4、10个簇。第一个想法是 - 为什么不像 DORA 那样将所有受访者分为 4 组。但我们发现这些群体之间的差异变得微不足道，我们无法确定受访者是否真的属于他的群体，而不是邻近的群体。我们还不能将俄罗斯市场分为四类。因此，我们确定了三个配置文件，它们之间存在统计上的显着差异：

接下来，我们按集群确定概况：我们取每组每个指标的中位数，并编制效率概况表。事实上，我们获得了每组平均参与者的最终表现概况。我们确定了三种效率概况：低、中、高：

在这里，我们证实了我们的假设，即 4 个关键指标适合确定绩效概况，并且它们在西方和俄罗斯市场都有效。各组之间存在差异，且具有统计学意义。我想强调的是，尽管我们最初并未按此参数划分受访者，但衡量不成功变更的绩效概况之间的平均值存在显着差异。

那么问题来了：如何使用这一切？

如何使用

如果我们采用任何团队的 4 个关键指标并将其应用到表格中，那么在 85% 的情况下我们将无法获得完整的匹配 - 这只是一个普通的参与者，而不是现实。我们所有人（以及每个团队）都有点不同。

我们进行了检查：我们获取了受访者和 DORA 绩效概况，并查看了有多少受访者符合一项或另一项概况。我们发现，只有 16% 的受访者准确地属于其中一种情况。其余的都分散在两者之间：

这意味着性能概况的范围有限。要初步了解您所处的位置，您可以使用此表：“哦，看起来我们更接近中或高！” 如果您了解下一步要去哪里，那就足够了。但如果你的目标是持续不断的改进，并且你想更准确地知道在哪里发展以及做什么，那么就需要额外的资金。我们称它们为计算器：

朵拉计算器
Calculator Express 42*（开发中）
您自己的开发（您可以创建自己的内部计算器）。

需要它们做什么？要理解：

我们组织内的团队是否符合我们的标准？
如果没有，我们可以在我们公司拥有的专业知识框架内帮助它、加速它吗？
如果是这样，我们还能做得更好吗？

您还可以使用它们来收集公司内部的统计数据：

我们有什么样的团队？
将团队划分为不同的档案；
请参阅：哦，这些团队表现不佳（有点慢），但这些团队很棒：他们每天都进行部署，没有错误，他们的交付时间不到一个小时。

然后您会发现，在我们公司内部，我们为那些仍然不足的团队提供必要的专业知识和工具。

或者，如果你知道自己在公司感觉很好，比很多人都优秀，那么你就可以把目光放得更宽一些。这正是俄罗斯工业：我们能否获得俄罗斯工业所需的专业知识来加速我们的发展？ Express 42 计算器将在这里提供帮助（它正在开发中）。如果您的发展已经超出了俄罗斯市场，那么看看朵拉计算器并走向世界市场。

美好的。如果根据 DORA 计算器，你属于 Elit 组，那么你该怎么办？这里没有好的解决办法。最有可能的是，您处于行业的前沿，通过内部研发和大量资源的支出，可以进一步提高速度和可靠性。

让我们进入最甜蜜的部分——比较。

对照

我们最初想将俄罗斯工业与西方工业进行比较。如果我们直接比较，我们会发现我们的配置文件较少，而且它们彼此之间更加混合，界限更加模糊：

我们的精英员工隐藏在高绩效员工之中，但他们就在那里——他们是精英，是达到了显着高度的独角兽。在俄罗斯，精英和高调之间的差异还不够显着。我们认为，未来这种划分将由于工程文化、工程实践实施质量和公司内部专业知识的提高而出现。

如果我们在俄罗斯行业内进行直接比较，我们可以看到高调团队在各个方面都更好。我们还证实了我们的假设，即这些指标与组织绩效之间存在关系：高知名度的团队不仅更有可能实现目标，而且超越目标。
让我们成为高调的团队，而不是止步于此：

但今年很特别，我们决定检查公司在大流行中的生存情况：高调团队的应对能力明显优于行业平均水平，感觉也更好：

新产品发布频率增加1,5-2倍，
应用程序基础设施的可靠性和/或性能提高了 2 倍。

也就是说，他们已经拥有的能力帮助他们更快地开发、推出新产品、修改现有产品，从而征服新市场和新用户：

还有什么对我们的团队有帮助？

工程实践

我将告诉您我们检查的每项实践的重要发现。也许还有其他东西对团队有帮助，但我们正在谈论 DevOps。在 DevOps 中，我们看到不同背景的团队之间存在差异。

平台即服务

我们没有发现平台的年龄和团队概况之间存在显着关系：对于低团队和高团队来说，平台大约在同一时间出现。但对于后者，平台平均提供更多的服务和更多的软件接口，通过程序代码进行控制。平台团队更有可能帮助他们的开发人员和团队使用该平台，更有可能解决与平台相关的问题和事件，并培训其他团队。

基础设施即代码

这里的一切都很标准。我们发现基础设施代码的自动化与基础设施存储库中存储的信息量之间存在关系。知名团队在存储库中存储更多信息：这包括基础设施配置、CI/CD 管道、环境设置和构建参数。他们更频繁地存储这些信息，更好地处理基础设施代码，并自动化更多处理基础设施代码的流程和任务。

有趣的是，我们在基础设施测试中没有看到显着差异。我将此归因于这样一个事实：高知名度的团队通常拥有更多的测试自动化能力。也许他们不应该因基础设施测试而分心，而他们用来检查应用程序的测试就足够了，而且多亏了他们，他们可以看到他们出了什么问题以及在哪里出了问题。

集成和交付

最无聊的部分，因为我们确认：自动化程度越高，代码处理得越好，获得更好结果的可能性就越大。

建筑

我们想了解微服务如何影响性能。老实说，他们没有，因为微服务的使用与效率指标的提高无关。高调团队和低调团队都使用微服务。

但重要的是，对于高级团队来说，向微服务架构的过渡使他们能够独立开发服务并推出服务。如果架构允许开发人员自主行动，无需等待团队外部的人员，那么这就是提高速度的关键能力。这就是微服务可以发挥作用的地方。但仅仅它们的实施并不能发挥很大的作用。

我们是如何发现这一切的？

我们有一个雄心勃勃的计划来完全复制 DORA 方法，但缺乏资源。如果 DORA 使用大量赞助并且研究需要六个月，那么我们在很短的时间内完成了研究。我们希望建立像 DORA 那样的 DevOps 模型，我们将来也会这样做。目前我们仅限于热图：

我们研究了每个级别的团队之间工程实践的分布，发现平均而言，高级别团队更频繁地使用工程实践。您可以在我们的网站中阅读有关这一切的更多信息报告.

作为改变，让我们从复杂的统计转向简单的统计。

我们还发现了什么？

工具

我们观察到 Linux 操作系统系列使用的命令最多。但 Windows 仍然是一种趋势 - 至少四分之一的受访者指出使用它的一个或另一个版本。市场似乎有这个需求。因此，您可以发展这些能力并在会议上进行演示。

在协调器中，Kubernetes 领先（52%）已不是什么秘密。下一个协调器是 Docker Swarm（约 12%）。最流行的 CI 系统是 Jenkins 和 GitLab。最流行的配置管理系统是 Ansible，其次是我们喜爱的 Shell。

在云托管提供商中，亚马逊目前占据领先地位。俄罗斯云的份额正在逐渐增加。明年，俄罗斯云提供商的感受以及他们的市场份额是否会增加将会很有趣。它们存在，可以使用，这很好：

我请伊戈尔发言，他将提供更多统计数据。

实践的传播

Igor Kurochkin：另外，我们要求受访者说明所考虑的工程实践在公司中是如何分布的。大多数公司都采用由一组不同模式组成的混合方法，并且试点项目非常受欢迎。我们还发现配置文件之间存在细微差别。当小型专家团队改变工作流程、工具并与其他团队分享成功的开发成果时，高层代表更经常使用“自下而上发起”模式。在 Medium，这是一项自上而下的举措，通过创建社区和卓越中心来影响整个公司：

敏捷和 DevOps

业界经常讨论敏捷和DevOps之间的关系。 2019/2020 年敏捷状况报告中也提出了这个问题，因此我们决定比较公司中敏捷和 DevOps 活动的关系。我们发现，没有敏捷的 DevOps 是很少见的。对于一半的受访者来说，敏捷的传播开始得明显更早，大约 20% 的受访者观察到同时开始，低调的标志之一是缺乏敏捷和 DevOps 实践：

团队拓扑

去年年底，这本书《团队拓扑”，它提出了一个描述团队拓扑的框架。我们想知道它是否适用于俄罗斯公司。我们问了一个问题：“你看到了什么模式？”

一半的受访者拥有基础设施团队，以及独立的开发、测试和运营团队。单个 DevOps 团队占 45%，其中高级代表更为常见。接下来是跨职能团队，这在 High 中也更常见。单独的 SRE 命令出现在高、中配置文件中，很少在低配置文件中找到：

DevQaOps 比率

我们在FaceBook上看到了Skyeng平台团队的团队负责人提出的这个问题——他对公司中开发人员、测试人员和管理员的比例感兴趣。我们询问并考虑了配置文件后查看了答案：高配置文件的代表为每个开发人员配备了较少数量的测试和运营工程师：

计划2021年

在明年的计划中，受访者指出了以下活动：

这里可以看到和DevOps Live 2020大会的交集，我们仔细回顾了一下节目：

基础设施作为产品
DevOps 转型
DevOps 实践的分布
开发安全
案例俱乐部和讨论

但我们的演讲没有足够的时间来涵盖所有主题。幕后花絮：

平台即服务和产品；
基础设施即代码、环境和云；
持续集成和交付；
建筑学;
DevSecOps 模式；
平台和跨职能团队。

报告我们的内容很厚，有50页，你可以看的更详细。

总结

我们希望我们的研究和报告能够激励您尝试新的开发、测试和运营方法，并帮助您了解方向，将自己与研究中的其他人进行比较，并确定可以改进自己方法的领域。

俄罗斯 DevOps 状况的首次研究结果：

关键指标。我们发现关键指标（交付时间、部署率、恢复时间和变更失败）适合分析开发、测试和运营流程的有效性。
轮廓高、中、低。根据收集的数据，可以在统计上区分不同的高、中、低组，在指标、实践、流程和工具方面具有独特的特征。高调的代表比低调的代表表现出更好的结果。他们更有可能实现并超越他们的目标。
指标、流行病和 2021 年计划。今年的一个特殊指标是企业如何应对这一流行病。高级代表表现更好，体验到用户参与度的提高，成功的主要原因是高效的开发流程和强大的工程文化。
DevOps 实践、工具及其开发。两家公司明年的主要计划包括开发DevOps实践和工具、引入DevSecOps实践以及组织结构的变化。 DevOps 实践的有效实施和发展是通过试点项目、社区和能力中心的形成、公司上下层的举措来进行的。

我们很高兴听到您的评论、故事和反馈。我们感谢所有参与这项研究的人，并期待您明年的参与。

来源： habr.com