State of DevOps DORA 2022 报告深度解读
前言
上月 Google 旗下的 DORA 发布了一年一度的 State of DevOps 2022 报告。Bytebase 作为一家面向 DevOps 团队,研发数据库 CI / CD 开源工具的厂商,每年都会对 DORA 进行深度解读。去年的解读见「State of DevOps DORA 2021 报告解读和评注」。
背景
DORA 在国内不像 Gartner 有那么高的知名度,它的全称是 DevOps Research and Assessments,从 2014 年开始,每年会出一份关于整个 DevOps 行业的报告,2020 因为疫情的原因没有出,所以加上今年的一共有 8 份报告。DORA 一开始是一家独立的研究机构,不过在 2018 年底加入了 Google Cloud。总体来讲 DORA 的报告是整个 DevOps 行业里面最为专业和客观的,这也应该是他当初受到 Google 青睐的原因。即使是加入 Google 后,它的报告也基本可以保持中立性,所以 DORA 的报告可以当作整个行业权威的风向标。好了,让我们正式进入报告。
和 2021 年报告的不同
相比于去年的报告,今年的报告有不小的变化:
- 首先是侧重点上,今年是 DORA 历史上首次重点突出一个主题,软件供应链 Software Supply Chain。
- 今年受访人群工作经验分布出现了很大的变化,小于 5 年经验的占比达到 35% (相比于 21 年的 14%),而超过 16 年经验的占比只有 13% (相比于 21 年的 41%)。
- 评定团队软件交付表现 (Software delivery performance) 的等级从 4 大类变成了 3 大类,取消了精英级 (Elite)。
- 结合软件交付表现和运行稳定性表现,又引入了一个新的等级划分,有 4 大类,Starting/Flowing/Slowing/Retiring - 启动/流动/缓动/止动。
主旨
今年的报告更加突出了三大 Performance 主题, Software delivery performance (软件交付表现), Operational performance (运行表现,主要是稳定性),Organizational performance (组织表现,指公司业绩),而去年只是一句话带过。
赞助商
今年的赞助商相比于去年有了一些变化,这是去年的阵容,红色的是今年不在的。 
去年的老面孔
- armory 和 circleci 是做 CI/CD,其中前者是开源项目 Spinnaker 背后的商业化公司。
- Deloitte, IT 实施咨询。
- GitLab 是一站式 DevOps 平台。
- Liquibase 和 Bytebase 一样,是做 Database DevOps 的开源商业化公司。
- sysdig 是做 Secure DevOps 这块的,这块现在缩写成 DevSecOps,也是 GitLab/GitHub 近来发力的重点。
今年的新面孔
- Broadcom Software ,有点意外的面孔,Broadcom 算是一家比较传统的软件厂商,和 DevOps 相关的产品线多来自于 2018 年对 CA 的收购。总部在硅谷,当年 CA 大大的 Logo 还挂在 Highway 101 旁的唯一一栋高楼上。
- JetBrains ,大名鼎鼎的 IDE 厂商,因为推出 JetBrains Space,所以也切入了软件交付领域。JetBrains Space 的 slogan 是 「A complete software development platform」,和 GitLab 的 「The One DevOps Platform」针锋相对。总部在捷克。
- JFrog , Software Supply Chain 领域的领导者,和今年的主题很贴切。他的总部在硅谷,门面很低调,隐形冠军,当年开车时经常路过。
- Octopus Deploy ,专门做持续交付 CD 的厂商,也是这个领域的领导者。总部在澳大利亚。
可以看到 DevOps 领域的公司分布在全球,毕竟面向开发者的工具共性很强,没有太多的地域性差异。
消失的面孔
- redgate ,和 Bytebase,Liquibase 类似的 Database DevOps 工具商。和 Liquibase 重复了,所以今年不出现也合理。
- PagerDuty ,故障应急领域的领导者。这次没有来,让赞助商阵容失色了一些。
- CD Foundation ,持续交付的民间组织。
总体来讲今年赞助商阵容在整个 Software Development Life Cycle (SDLC) 里覆盖的领域更全面了。要说缺席的领域还有这么几个:
- 故障应急 (代表性公司 PagerDuty)
- 监控告警 (代表性公司 Datadog)
- Feature Flag (代表性公司 LaunchDarkly)
- API 生命周期管理 (代表性公司 Postman)
- 云基础设施 (代表性公司 HashiCorp)
Cloud




使用任何云计算平台,无论是公有云还有私有云,都能对于公司文化和工作环境产生积极的影响(比如说,自发式的文化,更低的过劳度,更加稳定,更加高的员工满意度)。使用云的用户在文化方面的得分比非云用户高出 16% 。
使用云计算服务对于整个组织的绩效有积极的影响。使用云的受访者相比于不使用云的受访者,有高出 14 % 的可能性能达到组织绩效的目标。
算经济账需要看对于整体业绩指标的影响,而这点 DORA 的报告中也明确指出了,使用 Cloud 的组织相对于不使用 Cloud 的组织,在业绩指标 (Organizational Performance) 上是有更好的表现。贵的往往是划算的。
SDO Performance
Software Delivery and Operational Performance 的 4 大核心指标没变: 
Software development has seen reduced innovation in terms of practices, tooling, and information sharing. This could be the result of the ongoing pandemic hampering the ability to share knowledge and practices across teams and organizations
我也认同 reduced innovation 这点,但我感觉更可能的原因是 Software Delivery / DevOps 经过那么多年的发展,最佳实践开始大规模普及了,所以头部差距缩小,而不是疫情的关系。 

SRE and DevOps
今年报告的一个亮点在于更加辩证地阐述了 Reliability 的重要性:
Across this breadth of teams, the data reveal a nuanced relationship between reliability, software delivery, and outcomes: when reliability is poor, software delivery performance does not predict organizational success. However, with better reliability, we begin to see the positive influence of software delivery on business success.
这段颇为精妙
广泛的团队数据呈现了,在稳定性,软件交付和业务结果之间的一种微妙关系:当稳定性糟糕的时候,快的交付速度无法带来组织的业务成功。然而,当稳定性提升后,我们就会看到快的交付速度和业务成功是正相关的。
光快不行,要快而不乱,才能获得业务上的成功。 
as teams adopt more SRE, they reach an inflection point where the use of SRE starts to strongly predict reliability, and in turn, organizational performance.
Software Supply Chain

- 相对于传统的 CI/CD 确实是一个更加新颖的话题,也是行业接下来的一个热点,比如 GitLab 也从讲 DevOps 到讲 DevSecOps 。
- 是一个很好的角度去评估其他主题。
- 比如可以看出 CI/CD 的情况:Software Supply Chain 做的不好,多少也反映了 CI/CD 系统有很大问题。
- 还比如通篇报告一直在讲 people, process and tooling,而在 Supply Chain 这个专题的最后,把这三者串在了一起。
当然也有可能这份报告在 Google Cloud 和各大商业赞助商的影响下,往大客户/CSO/CIO/CTO 更关注的安全方向倾斜了。
- 比如可以看出 CI/CD 的情况:Software Supply Chain 做的不好,多少也反映了 CI/CD 系统有很大问题。
一些遗憾
今年报告的最大问题应该是样本分布出现了大的变动,受访者中初级/资深的分布和去年采样比例完全对调。这导致了不少数据出现了异常,而因为又是第一年,所以也不容易下明确的结论。 


结语
当样本量足够大的时候,总会出现不同的声音。而这其中有两类人可以帮助我们做更好的决策,一类是和自身背景相近的,另一类则是和自身背景相对的。前者可以告诉我们适合做什么,而后者能告诉我们不适合做什么,而许多时候不适合做什么的反向信号要清晰强烈的多。我们来看看前文提到的主张离开Cloud 的 DHH 的个人背景: 
- Lead Time for Changes (变更上线周期)
- Deployment Frequency (部署频率)
- MTTR - Medium Time to Recovery (故障恢复时间)
- 以及 Change Failure Rate (变更失败率)
今年 DORA 报告的解读就到此结束了 ,我们的产品 Bytebase 提供了围绕数据库 DevOps 的完整解决方案,通过审核 (review),变更 (change),留档 (version),回滚 (rollback)的一站式能力,帮助团队提高这 4 个研发效能的核心指标,也进而如 DORA 报告中所指出的一样,最终帮助组织拿到更好的业务结果。Bytebase 也是唯一一款被 CNCF Landscape 收录的数据库 CI/CD 工具,感兴趣的同学可以直接去我们的官网 bytebase.com 5 秒钟下载试用,或者关注 Bytebase 微信公众号获取加入用户群方式,和我们的产品同学实时沟通。
明年再见。
关注公众号
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
-
上一篇
GCC 13 新增 Ampere-1A CPU 支持
CPU 供应商 Ampere Computing 宣布将 AmpereOne 作为其下一代 AArch64 “ 云原生”服务器 CPU 品牌,以取代目前基于 Neoverse-N1 的 Ampere Altra / Ampere Altra Max 处理器。 回到去年 11 月,当时 Ampere Computing 其将下一代服务器处理器“Ampere1” 的支持补丁添加到 GCC,确认 Ampere1处理器正在使用基于 ARMv8.6 的 ISA 和其他基本功能,随后又将 Ampere1 CPU 支持添加到LLVM 中。 虽然 AmpereOne 处理器尚未正式推出,新的 AArch64 核心还是一个原始设计,但 Ampere Computing 已经向 GCC 编译器提交了支持补丁,以支持其最新的 “Ampere-1A” 变体型号。 现在 GCC 13 合并窗口引入了“ampere-1a”,作为新的 CPU 目标。据外媒 Phoronix 介绍,Ampere-1A 有一个更新的指令表、一个新的融合对(A + B + 1 和 A - B - 1),且具有与 Ampere-1(非 A...
-
下一篇
爱上算法,迷人的两度搜索,深度优先(DFS)和广度优先(BFS)
迷人的两度搜索 1、BFS和DFS 深度优先搜索算法(DFS)和广度优先搜索算法(BFS)是一种用于遍历或搜索树或图的算法,在搜索遍历的过程中保证每个节点(顶点)访问一次且仅访问一次,按照节点(顶点)访问顺序的不同分为深度优先和广度优先。 1.1、深度优先搜索算法 深度优先搜索算法(Depth-First-Search,DFS)沿着树的深度遍历树的节点,尽可能深的搜索树的分支。当节点v的所在边都己被探寻过,搜索将回溯到发现节点v的那条边的起始节点。这一过程一直进行到已发现从源节点可达的所有节点为止。如果还存在未被发现的节点,则选择其中一个作为源节点并重复以上过程,整个进程反复进行直到所有节点都被访问为止。属于盲目搜索。 注意: 1:实际上,回溯算法思想就是借助于深度优先搜索来实现的。 DFS负责搜索所有的路径,回溯辅以选择和撤销选择这种思想寻找可能的解,当然代码写起来基于递归(所以代码写起来就是用递归实现的)。 2:DFS跟回溯有什么关系呢? 回溯是一种通用的算法,把问题分步解决,在每一步都试验所有的可能,当发现已经找到一种方式或者目前这种方式不可能是结果的时候,退回上一步继续尝试其他...
相关文章
文章评论
共有0条评论来说两句吧...





当然也有可能这份报告在 Google Cloud 和各大商业赞助商的影响下,往大客户/CSO/CIO/CTO 更关注的安全方向倾斜了。
微信收款码
支付宝收款码