您可以依靠自己的意见，这些意见来自不同的信息来源，例如网站或经验上的出版物。您可以问同事和熟人。另一种选择是查看会议主题：计划委员会是该行业的活跃代表，因此我们信任他们选择相关主题。一个单独的领域是研究和报告。但是有一个问题。世界上每年都对DevOps的状态进行研究，外国公司也发表了报告，并且几乎没有关于俄罗斯DevOps的信息。
但是，进行此类研究的日子已经到来，今天我们将告诉您所获得的结果。Express 42和Ontiko共同调查了俄罗斯DevOps的状态”。Express 42帮助技术公司实施和开发DevOps的实践和工具，并且是俄罗斯最早谈论DevOps的公司之一。该研究的作者Igor Kurochkin和Vitaly Khabarov在Express 42从事分析和咨询，其技术背景来自不同公司的运营和工作经验。在过去的8年中，同事们研究了数十家公司和项目-从创业公司到企业-遇到了不同的问题，以及不同的文化和工程成熟度。
Igor和Vitaliy在他们的报告中指出了研究过程中存在的问题，如何解决它们，以及原则上如何进行DevOps研究以及Express 42为什么决定自行进行研究。他们的报告可以在这里查看。
DevOps研究
伊戈尔·库洛奇金（Igor Kurochkin）开始谈话。
我们经常在DevOps会议上向观众提问：“您是否阅读了今年的DevOps状态报告？” 只有少数人举手，我们的研究表明只有三分之一的人举手。如果您从未见过此类报告，请立即说它们非常相似。最常见的短语是：“与去年相比……”
在这里，我们遇到的第一个问题是，第二个问题是：
- 我们没有过去一年的数据。俄罗斯的DevOps状态对任何人都没有兴趣。
- 方法。目前尚不清楚如何检验假设，如何提出问题，如何进行分析，比较结果，寻找联系；
- 术语。所有报告均以英文撰写，需要翻译，尚未发明通用的DevOps框架，每个人都提出了自己的建议。
让我们看一下一般如何对全球DevOps的状态进行分析。
历史参考
自2011年以来一直进行DevOps研究。第一次是由配置管理系统开发商Puppet举办的。当时，它是以代码形式描述基础架构的主要工具之一。直到2013年，这些研究只是以封闭式调查的形式进行，没有公开报告。
2013年，IT Revolution诞生了，它是所有主要DevOps书籍的出版商。他们与Puppet一起编写了第一本出版物“ DevOps状态”，其中首次出现4个关键指标。次年，以其定期发布有关行业惯例和工具的技术雷达而闻名的咨询公司ThoughtWorks也加入了进来。在2015年，增加了一个方法论部分，很清楚他们是如何进行分析的。
2016年，该研究的作者创建了自己的公司DORA（DevOps研究与评估），并发布了年度报告。次年，DORA和Puppet上次发布了联合报告。
然后有趣的事情开始了：
在2018年，两家公司分拆并发布了两份独立报告：一份来自Puppet，另一份来自DORA与Google一起。 DORA继续将其方法学与影响关键指标和公司范围内绩效的关键指标，绩效概况和工程实践结合使用。 Puppet提供了自己的方法来描述DevOps的过程和演变。但是故事并没有持续下去，在2019年，Puppet放弃了这种方法，并发布了新版本的报告，在报告中列出了关键实践以及它们如何影响DevOps。然后另一件事发生了：谷歌收购了DORA，他们一起发布了另一份报告。你可能见过他。
今年事情变得复杂了。众所周知，木偶已经发起了自己的民意测验。他们比我们提前了一周完成了这项工作，并且这项工作已经结束。我们参加了会议，并了解了他们感兴趣的主题。Puppet当前正在执行其分析，并准备发布该报告。
但是DORA和Google仍然没有公告。在五月份的调查通常开始的时候，就有消息说DORA的创始人之一妮可·福斯格伦（Nicole Forsgren）搬到了另一家公司。因此，我们假设今年不会进行任何研究，也不会收到DORA的报告。
俄罗斯的情况如何？
我们尚未进行任何DevOps研究。我们在会议上发表讲话，重申其他人的结论，Raiffeisenbank翻译了《 2019年DevOps状态》（您可以在Habré上找到他们的公告），这非常感谢他们。这就是全部。
因此，我们使用DORA方法和发现在俄罗斯进行了自己的研究。我们将Raiffeisenbank同事的报告用于我们的研究，包括术语和翻译的同步。行业特定的问题来自DORA报告和今年的Puppet调查。
研究过程
该报告只是最后一部分。整个研究过程包括四个大步骤：
在准备阶段，我们采访了行业专家，并准备了一系列假设。在此基础上，提出了问题，并在整个八月启动了一项调查。然后，我们分析并准备了报告本身。对于DORA，此过程需要6个月。我们开会了三个月，现在我们了解到我们几乎没有足够的时间：只有执行分析，您才能了解需要提出哪些问题。
参加者
所有外国报告都以参与者的画像开头，而且大多数不是来自俄罗斯。俄罗斯受访者的比例每年从5％浮动到1％，因此无法得出任何结论。
《 2019年DevOps加速发展状况报告》中的地图：
在我们的研究中，我们设法采访了889人-这很多（DORA每年在其报告中对约一千人进行民意测验），我们实现了目标：
确实，并非所有参与者都达到了终点：百分比填充量实际少于一半。但这甚至足以获得代表性样本并进行分析。DORA并未在报告中披露填充百分比，因此此处无法进行比较。
行业和职位
我们的受访者代表了十几个行业。其中一半从事信息技术工作。其次是金融服务，贸易，电信和其他。职位包括专家（开发人员，测试人员，操作工程师）和管理人员（团队负责人，团队，指示，董事）：
每秒钟在一家中型公司工作。每三分之一的人在大公司工作。大多数团队最多由9个人组成。另外，我们询问了主要活动，并且大多数活动是与经营相关的，其中约40％与开发有关：
这是我们收集信息以比较和分析不同行业，公司，团队的代表的方式。我的同事维塔利·哈巴罗夫（Vitaly Khabarov）将告诉您有关分析的信息。
分析与比较
维塔利·哈巴罗夫（Vitaly Khabarov）：非常感谢参加我们调查，填写调查表并为我们提供数据以便进一步分析和检验假设的所有参与者。多亏了我们的客户和顾客，我们拥有丰富的经验，这些经验帮助我们确定了行业关注的问题，并提出了我们在研究中检验的假设。
不幸的是，您不能只列出一方面的问题和另一方面的数据，以某种方式比较它们，说：“是的，这就是它的工作方式，我们是对的。”然后分散。不，我们需要方法和统计方法来确保我们没有弄错并且我们的结论是可靠的。然后，我们可以根据以下数据建立进一步的工作：
关键指标
我们以DORA方法为基础，他们在“ Accelerate State of DevOps”一书中对其进行了详细介绍。我们检查了关键指标是否适合俄罗斯市场，能否以DORA用来回答以下问题的相同方式使用这些指标：“俄罗斯的行业如何与外国行业相对应？”
关键指标：
- 部署频率。新版本的应用程序多长时间部署到生产环境一次（计划的更改，不包括热修复程序和事件响应）？
- 交货时间。提交更改（将功能编写为代码）与将更改部署到产品环境之间的平均时间是多少？
- . , , ?
- . ( , )?
DORA在其研究中发现了这些指标与组织绩效之间的关系。我们还在研究中对其进行检查。
但是，要确保四个关键指标可以影响某些方面，您需要了解-它们是否以某种方式彼此关联？ DORA对此表示肯定，但有一个警告：变更失败率与其他三个指标之间的关系稍弱。我们得到了差不多的照片。如果交付时间，部署频率和恢复时间相互关联（我们通过Pearson关联和Chaddock量表发现了这种关联），那么就没有如此紧密的关联，而没有成功的改变。
原则上，大多数受访者倾向于回答他们在生产中发生的事件数量很少。尽管将来我们会发现，在更改成功率方面，各组受访者之间仍然存在显着差异，但对于该划分，我们尚不能使用此指标。
我们将其归因于这样一个事实：（在分析和与一些客户进行沟通时发现）在认为什么是事件方面存在轻微差异。如果我们设法在技术窗口内恢复了服务的可操作性，是否可以认为这是事件？可能不是，因为我们固定了一切，所以我们很棒。如果我们必须以正常的常规模式将应用程序重新推出10次，这是否可以视为事件？好像没有因此，未成功更改与其他指标之间关系的问题仍然存在。我们将进一步完善它。
在这里重要的是，我们发现交付时间，恢复时间和部署频率之间存在显着的相关性。因此，我们采用了这三个指标将受访者进一步分为绩效组。
多少克？
我们使用了层次聚类分析：
- 我们在n维空间中分布受访者，每个受访者的坐标就是他们对问题的答案。
- 我们宣布每个受访者都是一个小群体。
- 我们将彼此最接近的两个群集合并为一个较大的群集。
- 查找下一对集群，并将它们组合成更大的集群。
这就是我们将所有受访者分组到所需数量的集群中的方式。借助树状图（群集之间的连接树），我们可以看到两个相邻群集之间的距离。我们剩下的就是在这些群集之间设置一定的距离限制，并说：“这两个组之间的区别非常大，因为它们之间的距离很大。”
但是这里存在一个隐藏的问题：我们对集群的数量没有限制-我们可以得到2、3、4、10个集群。第一个想法是-为什么不像DORA一样将所有受访者分成4组。但是，我们发现这些组之间的差异变得微不足道，我们无法确定被访者确实属于他自己的组，而不属于相邻的组。我们仍然不能将俄罗斯市场分为四类。因此，我们恰好在三个配置文件之间停了下来，这三个配置文件之间在统计上有显着差异：
接下来，我们通过聚类确定了配置文件：我们采用了每个组每个指标的中位数，并制作了性能配置文件表。实际上，我们获得了每个组中平均参与者的绩效概况。我们确定了三种效率概况：低，中，高：
在这里，我们已经证实了以下假设：这四个关键指标适用于确定绩效概况，并且在西方和俄罗斯市场均有效。两组之间存在差异，并且具有统计学意义。我想强调的是，即使我们最初并未将受访者除以该参数，但根据未成功更改的指标，绩效概况之间的平均值存在显着差异。
然后出现了问题：如何使用所有这些？
如何使用
如果您采用任何团队，4个关键指标并将其应用到表格中，那么在85％的情况下，我们将无法获得完全匹配-这只是普通参与者，而不是实际情况。我们所有人（每个团队）都有些不同。
我们进行了检查：我们收集了受访者和DORA的绩效概况，然后查看了符合特定概况的受访者人数。我们发现只有16％的受访者准确地点击了其中一个配置文件。所有其他散布在之间：
这意味着性能配置文件的范围有限。要了解您的近似位置，请使用以下表格：“哦，看来我们离中或高更近了！” 如果您知道下一步该怎么做，那就足够了。但是，如果您的目标是持续不断的改进，并且您想更准确地了解在哪里开发和做什么，那么您将需要额外的资金。我们称它们为计算器：
- DORA计算器
- Calculator Express 42 *（正在开发中）
- 自己的开发（您可以创建自己的内部计算器）。
他们需要什么？要了解：
- 我们组织内的团队是否符合我们的标准？
- 如果没有，我们可以帮助她-在我们公司拥有的专业知识的框架内使她加速吗？
- 如果是这样，我们可以做得更好吗？
您还可以使用它们来收集公司内部的统计信息：
- 我们拥有哪些团队；
- 将团队划分为个人资料；
- 请参阅：哦，这些团队表现不佳（他们一点也不拉），而且很酷：他们每天都在部署，没有错误，他们的领导时间不到一个小时。
然后您会发现，在我们公司内部，对于那些仍不坚持的团队来说，有必要的专业知识和工具。
或者，如果您了解自己在公司内部感觉很好，比许多人都要出色，那么可以进行更广泛的了解。这就是俄罗斯的行业：我们可以在俄罗斯的行业中获得必要的专业知识来加速自己吗？ Calculator Express 42将在此处提供帮助（正在开发中）。如果您已经超出了俄罗斯市场，那么请查看DORA计算器和全球市场。
好的。如果您属于DORA计算器Elit小组，该怎么办？这里没有好的解决方案。您很可能处于行业的最前沿，由于内部研发和花费更多的资源，可能会进一步加速和提高可靠性。
让我们继续进行最甜蜜的比较。
比较方式
我们最初想将俄罗斯工业与西方工业进行比较。如果直接进行比较，我们会发现我们的配置文件更少，彼此之间的混合更紧密，界限也更加模糊：
我们的精英绩效者被隐藏在高效绩效者之中，但是它们存在-他们是达到了显着高度的精英，独角兽。在俄罗斯，“精英”和“高级”之间的差异还不够明显。我们认为，将来这种分离将与工程文化的改善，工程实践的实施质量以及公司内部的专业知识有关。
如果我们继续在俄罗斯行业内进行直接比较，我们会看到高调团队在各个方面都更好。我们还证实了以下假设：这些指标与组织绩效之间存在关系：高知名度的团队不仅更有可能实现目标，而且超越目标。
让我们成为高知名度的团队，而不是就此止步：
但是今年是特殊的，我们决定检查公司如何在大流行中生存：高知名度的团队表现更好，并且感觉比行业平均水平更好：
- 新产品的发布频率是1.5-2倍
- 提高应用程序基础架构的可靠性和/或性能的可能性提高2倍。
也就是说，他们已经具备的能力可以帮助他们更快地开发，推出新产品，修改现有产品，从而征服新市场和新用户：
还有哪些对我们的团队有所帮助？
工程实践
我将告诉您有关我们检查的每个练习的重要发现。也许还有其他帮助团队的东西，但是我们正在谈论DevOps。在DevOps中，我们看到了不同配置文件的团队之间的差异。
平台即服务
我们发现平台年龄与团队概况之间没有显着关系：低团队和高团队的平台大约同时出现。但是对于后者，该平台平均提供更多服务和更多编程接口，以通过程序代码进行控制。平台团队更有可能帮助其开发人员和团队使用该平台，更经常地解决其与平台相关的问题和事件，并教育其他团队。
基础架构即代码
这里的一切都很标准。我们发现基础结构代码的自动化与基础结构存储库中存储了多少信息之间的关系。高配置文件命令将更多信息存储在存储库中：这是基础结构配置，CI / CD管道，环境设置和构建参数。他们更频繁地存储此信息，可以更好地使用基础结构代码，并且可以自动化更多的流程和任务来使用基础结构代码。
有趣的是，我们发现基础架构测试没有显着差异。我将此与High profile命令通常具有更多测试自动化这一事实联系起来。也许不应该通过基础结构测试来分散他们的注意力，但是用于检查应用程序的测试就足够了，而且由于有了这些测试，他们已经可以看到损坏的内容和位置。
整合与交付
最无聊的部分是因为我们确认您拥有的自动化程度越高，使用代码的能力越强，获得最佳指标的可能性就越大。
建筑
我们想看看微服务如何影响性能。如果确实如此，它们就不会这样做，因为微服务的使用与性能指标的提高无关。高配置文件命令和低配置文件命令都使用微服务。
但是重要的是，对于高级团队来说，向微服务架构的过渡允许他们独立开发服务并进行部署。如果该体系结构允许开发人员自主采取行动，而不是等待团队外部的成员，那么这就是提高速度的关键能力。这就是微服务的帮助。只是它们的实现并不起作用。
我们如何找到所有这一切？
我们有一个雄心勃勃的计划来完全复制DORA方法，但是我们缺乏资源。如果DORA使用了大量赞助，并且研究花费了半年时间，那么我们会在短时间内进行研究。我们希望像DORA一样建立一个DevOps模型，将来我们会这样做。到目前为止，我们将自己局限于热图：
我们查看了每个配置文件的团队之间的工程实践分布，并且发现“高级”配置文件中的团队平均而言更频繁地使用工程实践。您可以在我们的报告中阅读更多有关这一切的信息。
要进行更改，让我们从复杂的统计信息切换到简单的统计信息。
我们还发现了什么？
工具类
我们观察到大多数团队都使用Linux操作系统。但是Windows仍然是趋势-至少有四分之一的受访者表示使用了Windows的一个或另一个版本。市场似乎有这种需求。因此，您可以开发这些能力并在会议上进行演示。
Kubernetes是协调器中的领导者（52％）。下一个协调器是Docker Swarm（大约12％）。最受欢迎的CI系统是Jenkins和GitLab。最受欢迎的配置管理系统是Ansible，其次是我们心爱的Shell。
亚马逊仍然是云托管服务的领导者。俄罗斯云的份额逐渐增加。明年，看看俄罗斯云提供商的感觉以及他们的市场份额是否增长将会很有趣。它们是，您可以使用它们，这很好：
我请Igor发言，他将提供更多统计数据。
传播实践
伊戈尔·库洛奇金（Igor Kurochkin）：另外，我们请受访者指出如何在公司中传播经过考虑的工程实践。大多数公司采用不同模式的混合方法，试点项目非常受欢迎。我们还发现配置文件之间存在细微差异。当小型专家团队更改工作流程，工具并与其他团队共享成功的开发成果时，高知名度的代表通常会使用“从下而上”的模式。在Medium，这是一项高层计划，它通过创建社区和卓越中心来影响整个公司：
敏捷和DevOps
敏捷与DevOps之间的关系是业界的热门话题。2019/2020年敏捷状态报告中也提到了这一问题，因此我们决定比较公司中敏捷和DevOps活动之间的关系。我们发现非敏捷DevOps很少见。对于一半的受访者而言，敏捷的传播开始得更早，大约有20％的人观察到同时开始传播，而低调的迹象之一是缺乏敏捷和DevOps实践：
命令拓扑
去年年底，出版了《团队拓扑》一书，提出了描述团队拓扑的框架。我们想知道它是否适用于俄罗斯公司。我们问了一个问题：“您找到什么模式？”
基础设施团队由一半的受访者以及独立的开发，测试和运营团队组成。各个DevOps团队的参与率高达45％，其中高级代表更为普遍。其次是跨职能团队，在High中也较为常见。单独的SRE命令出现在“高”，“中”配置文件中，很少出现在“低”配置文件中：
DevQaOps比率
我们在Skyeng平台团队负责人的FaceBook中看到了这个问题-他对公司中开发人员，测试人员和管理员的比例感兴趣。我们问了一下，并根据概要文件查看了响应：高级概要文件的代表每个开发人员的测试和操作工程师更少：
2021年计划
在下一年的计划中，受访者指出了以下活动：
在这里您可以看到与DevOps Live 2020会议的交集，我们仔细审查了该计划：
- 基础设施即产品
- DevOps转换
- 传播DevOps实践
- 开发安全
- 案例俱乐部和讨论
但是我们的演讲将不足以考虑所有主题。留在幕后：
- 平台即服务和产品；
- 基础架构，如代码，环境和云；
- 持续整合和交付；
- 建筑;
- DevSecOps模式；
- 平台和跨职能团队。
事实证明，我们的报告十分详尽，共有50页，您可以详细查看。
加起来
我们希望我们的研究和报告能够激励您尝试开发，测试和运营的新方法，并帮助您进行导航，与其他研究参与者进行比较，并确定可以改进自己的方法的领域。
俄罗斯DevOps状态的首次调查结果：
- 关键指标。我们发现关键指标（交付时间，部署频率，恢复时间和不成功的更改）适用于分析开发，测试和运营的有效性。
- High, Medium, Low. High, Medium, Low , , . High , Low. .
- , 2021 . , . High , , .
- DevOps的实践，工具及其开发。公司明年的主要计划包括开发DevOps做法和工具，引入DevSecOps做法以及更改组织结构。在试点项目，社区和卓越中心的形成以及公司上下级的举措的帮助下，DevOps实践的有效实施和发展得以实现。
我们很高兴听到您的反馈，故事，反馈。感谢参与研究的所有人，我们期待您明年的参与。