上周DORA发布了State of DevOps 2021的报告，BB君也一起带读者来详细解读一下这份新鲜出炉的报告（烫烫烫）。

背景介绍

先简单介绍一下背景，毕竟DORA在国内不像Gartner的魔力象限有那么高的知名度。DORA的全称是DevOps Research and Assessments，从2014年开始，每年会出一份关于整个DevOps行业的报告，2020可能是因为疫情的关系没有出，所以总共加上今年的一共有7份报告（往年的报告链接都附在了2021年报告的最后）。DORA一开始是一家独立的研究机构，不过在2018年底加入了Google Cloud。总体来讲DORA的报告是整个DevOps行业里面最为专业和客观的，这也应该是他当初受到Google青睐的原因。即使是加入Google后，它的报告也基本可以保持中立性，所以DORA的报告可以当作整个行业权威的风向标。好了，让我们正式进入报告。

首先进入广告时间：）我们先来看看这次报告的赞助商，背后的大金主Google Cloud就不提了。然后Deloitte是做IT实施咨询的，CD Foundation是持续交付的组织算是一个站台，剩下的都是DevOps领域相关的商业化公司:

• GitLab是一站式的DevOps平台。

• armory和circleci是做CI/CD，其中前者是开源项目Spinnaker背后的商业化公司。

• sysdig是做Secure DevOps这块的，这块现在缩写成DevSecOps，也是GitLab/GitHub近来发力的重点。

• PagerDuty已经上市，是做值班，监控，告警的。

• Liquibase和redgate则是做Database DevOps的，分别是开源的Liquibase以及Flyway背后的商业公司。Liquibase和Bytebase的名字也有点像，没错这两位也是Bytebase最直接的竞争对手：）

顺便去看了一下2019年的sponsor，貌似只有redgate没有Liquibase，其实并不是，只是因为Datical把名字换成了Liquibase，也就是他们所基于的开源项目的名字。所以这两位好基友之前就一直出双入对了。不过从这里其实可以获得一个开源项目branding的tips，就是商业公司最好可以和他们的开源项目使用统一的名字。

第一章Executive Summary直接略过，跳到第二章

第二章 - How do we compare?

4大核心指标

和往年报告一样，一开始就把DevOps的4个指标给抛了出来，这是整个DORA报告最精华，也是绝大多数研发效能组织最能借鉴的部分。国内最近研发效能的文章特别的火，各种指标飞来飞去，各种术语方法论，其实很容易被绕晕。而DORA列的这4个指标不多不少，恰到好处，同时也具备采集和改进的实操性。国内所有搞研发效能的团队其实都可以丢掉其他的目标，就以这4个指标作为牵引，一方面从采集侧提高指标的覆盖率，精确度和实时性，另一方面就是去提升这些指标。只要坚持这个方向，组织的整体研发效能就能稳步提升。当然现实总是不尽如人意，耳闻目睹的种种乱象，也都是因为大家剑走偏锋，想走捷径，快速拿结果，这里设计个打分规则，那边计算个人均节省时间，更夸张的还要计算给业务贡献的价值，结果就走火入魔了😮‍💨

精英团队的效能

这里展示的elite和low performer的效能对比是挺夸张的，不过根据BB君的职业经验，这个数字还是比较的合理。即使精英团队和普通团队之间，产生10倍以上的效能差距也很正常。1个10人精英团队和1个100人普通团队，看似是10倍人数的差距，但普通团队，可能其中80人在内耗，能产出的20人又因为在人员素质，工具，流程，文化各处失分，整体效率会远远不及10人的精英团队。当前国内软件行业整体还是处在人海战术阶段，许多业务主管还是会陷入靠堆人就能解决问题的迷思，而忽略了工具，文化以及单独个体能带来的影响。其实如果看一下从最早的HP，IBM，到Apple，Microsoft，再到Google，Facebook以及现在的Stripe, 科技公司员工人均市值的增长是很明显的。许多公司不吝惜人力投入到前线的业务，却不审视一下内部的工具链，梳理一下协同流程，其实是挺可惜的。步兵坦克依然重要，因为需要靠他们去最后占领城市，但现代战争已经是靠空军，导弹，信息化所主宰的了。

第三章 - How do we improve

Cloud

前面描述DORA报告的中立性是加了「基本」这个定语，就是因为这里有一个不那么中立的地方。把Cloud放在How do we improve的第一项并没有问题，但用大量的篇幅介绍multi-cloud还是体现了Google Cloud的私心。如果让行业的领导者AWS做这份报告，一定是不会这么写的：）。BB君对于multi-cloud也持相对保留的态度，采用multi-cloud其实有点像一家公司的关系数据库既用了MySQL，又用了PostgreSQL，可以对外解释集各家所长，MySQL性能好一些，上手容易，PostgreSQL有好的Geospatial，JSON支持，但事实上这些收益是抵不上运维两套数据库带来的额外开销。multi-cloud希望是能提高整体系统的上限，实际上往往是拉低了系统的下限。

SRE and DevOps

BB君分别在蚂蚁集团和Google任职过，应该是国内外SRE实践最多的两家公司。文中谈到了SRE和DevOps职能边界的划分，BB君也同意其中关于SRE职能定位的观点。顺便再补充一点，研发团队应该自己承担服务的研发以及运维工作，也就是所谓的DevOps。而SRE应该制定框架层的东西，给出比如SLI/SLO的指引，做横向的拉通，研发通用工具。但是当前SRE和Dev的合作普遍还存在如下问题：

1. SRE仍然带有非常深的运维团队烙印，虽然团队具备线上应急能力，但缺乏研发所需要的系统架构能力，以及工具开发能力，这使得SRE的各种横向拉通有如空中楼阁，没有坚实的系统架构和工具作为基础。

2. 研发团队因为SRE的存在，只管开发上线，不管后续的运维，把各种线上问题丢给SRE。但SRE并不是系统真正的开发者，一是缺乏对于系统的认识，二是也缺乏足够的ownership。结果导致的是研发做设计不考虑可运维性，而SRE又被定位成一个应急资源，缺乏归属感，幸福度不高。

要解决这个问题，BB君认为Dev还是应该承担Ops的责任，而SRE也应该从Ops走向Dev，本质上SRE和Dev都是DevOps团队，只是SRE维护的是横向产品，Dev维护的是垂直产品。只有划清楚各自的产品阵地，才能避免踩踏和甩锅。

Documentation

啊，文档啊。文档系统本就是通用协同办公的核心，而对于追求效率的研发工程师来说，对于文档的要求就更加挑剔。当下业界还没有出现一个针对研发类信息集大成的方案，但是已经出现往这个方向上突破的苗头：

1. GitBook自从正式商业化后脚步走的很快，不少国外公司最近都把技术文档从Notion搬到了Gitbook。

2. Atlassian的Compass以及孵化自Spotify的开源项目Backstage也都在解决研发元数据组织和检索的问题。

Security

这块BB君的经验相对匮乏一些，就不做过多解读。这个领域GitLab/GitHub都通过收购做了相关的布局，GitLab频繁在他的博客里提到了DevSecOps的概念，而如果大家用GitHub维护开源项目，应该也能感受到他在CodeQL，dependabot上做的许多工作。

Technical DevOps capabilities

好了，终于到了Database change management登场的时候了，这块也就是Bytebase聚焦的领域。这里划圈的部分讲的也很清楚，提取几个关键字, collaboration，teams。团队协同的风已经把研发工具吹了一大半，长出了Slack，GitLab这样的平台级应用，但是这股风还没有吹到Database领域，这也正是Bytebase想完成的事情，做成业界在团队协同的场景下，最好的database工具。

最后这里讲到了Open source。感觉Open source的篇幅有些少了，而且整个Technical DevOps capabilities部分的次序有些凌乱，前面的summary list和之后的具体段落介绍的次序不一致。对于Open source的论述是整篇报告略显瑕疵的地方，Open source之于DevOps的重要程度是足够可以在这第三章单独成为专题的，而不需要挤在Technical DevOps capabilities的部分。

抛开Open source的瑕疵不谈，第三章的内容安排上还有一个细节，就是这章的主题是Improvement，而专题排列的次序是Cloud -> SRE and DevOps -> Documentation -> Security -> Technical DevOps capabilities。根据BB君的经验，这样的排序也是合理的，既务实又保证了政治正确：）

总结

其他一些关于Covid，Culture和数据样本的内容就略过了。时隔两年之后出炉的DORA报告总体没有让人失望，整个DevOps行业仍然在加速地演进中，事实上从2018开始本来的State of Devops报告名字前就加上了Accelerate。从报告的benchmark上也可以看到强者愈强，处在高速发展期，能够顺应变化，从文化，组织，工具层面完成转型的，自然可以乘风破浪。而那些无法转型的，还希望依靠堆人解决问题的组织，会感到越来越力不从心。而也正因为处于这样的变革期，Bytebase这样面向下一代的DevOps工具才有了更好打破市场格局的机会，或许在5年之后，读者也会在DORA报告的sponsor列表中看到Bytebase的名字，一股来自东方的神秘力量🐲

[1] 2021 DORA报告 - https://cloud.google.com/blog/products/devops-sre/announcing-dora-2021-accelerate-state-of-devops-report

我们同时也在招募「前端架构师」和「全栈工程师」，请查阅「Bytebase的第一次对外招聘」