上月 DORA 发布了 State of DevOps 2021 的报告，本人也一起带读者来详细解读一下这份新鲜出炉的报告（烫烫烫）。
先简单介绍一下背景，毕竟 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 直接略过，跳到第二章
和往年报告一样，一开始就把 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, 科技公司员工人均市值的增长是很明显的。许多公司不吝惜人力投入到前线的业务，却不审视一下内部的工具链，梳理一下协同流程，其实是挺可惜的。步兵坦克依然重要，因为需要靠他们去最后占领城市，但现代战争已经是靠空军，导弹，信息化所主宰的了。
前面描述 DORA 报告的中立性是加了「基本」这个定语，就是因为我们来到了不那么中立的地方。把 Cloud 放在 How do we improve 的第一项并没有问题，但用大量的篇幅介绍 multi-cloud 还是体现了 Google Cloud 的私心。如果让行业的领导者 AWS 做这份报告，一定是不会这么写的：）。BB 君对于 multi-cloud 也持相对保留的态度，采用 multi-cloud 其实有点像一家公司的关系数据库既用了 MySQL，又用了 PostgreSQL，可以对外解释集各家所长，MySQL 性能好一些，上手容易，PostgreSQL 有好的 Geospatial，JSON 支持，但事实上这些收益是抵不上运维两套数据库带来的额外开销。multi-cloud 希望是能提高整体系统的上限，实际上往往是拉低了系统的下限。
本人分别在蚂蚁集团和 Google 任职过，应该是国内外 SRE 实践最多的两家公司。本人同意文中关于 SRE 职能定位的观点，顺便再补充一点。研发团队应该自己承担服务的研发以及运维工作，也就是所谓的 DevOps。而 SRE 应该制定框架层的东西，给出比如 SLI/SLO 的指引，做横向的拉通，研发通用工具。但是当前 SRE 和 Dev 的合作普遍还存在如下问题：
SRE 仍然带有非常深的运维团队烙印，虽然团队具备线上应急能力，但缺乏研发所需要的系统架构能力，以及工具开发能力，这使得 SRE 的各种横向拉通有如空中楼阁，没有坚实的系统架构和工具作为基础。
研发团队因为 SRE 的存在，只管开发上线，不管后续的运维，把各种线上问题丢给 SRE。但 SRE 并不是系统真正的开发者，一是缺乏对于系统的认识，二是也缺乏足够的 ownership。结果导致的是研发做设计不考虑可运维性，而 SRE 又被定位成一个应急资源，缺乏归属感，幸福度不高。
要解决这个问题，本人认为 Dev 还是应该承担 Ops 的责任，而 SRE 也应该从 Ops 走向 Dev，本质上 SRE 和 Dev 都是 DevOps 团队，只是 SRE 维护的是横向产品，Dev 维护的是垂直产品。只有划清楚各自的产品阵地，才能避免踩踏和甩锅。
啊，文档啊。文档系统本就是通用协同办公的核心，而对于追求效率的研发工程师来说，对于文档的要求就更加挑剔。当下业界还没有出现一个针对研发类信息集大成的方案，但是已经出现往这个方向上突破的苗头：
GitBook 自从正式商业化后脚步走的很快，不少国外公司最近都把技术文档从 Notion 搬到了 Gitbook。
Atlassian 的 Compass 以及孵化自 Spotify 的开源项目 Backstage 也都在解决研发元数据组织和检索的问题。
这块本人的经验相对匮乏一些，就不做过多解读。这个领域 GitLab/GitHub 都通过收购做了相关的布局，GitLab 频繁在他的博客里提到了 DevSecOps 的概念，而如果大家用 GitHub 维护开源项目，应该也能感受到他在 CodeQL，dependabot 上做的许多工作。
好了，终于到了 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 的名字，一股来自东方的神秘力量。
作者介绍：
陈天舟, 个人公众号 cloudthought。曾在蚂蚁集团负责整个研发工具，生产力协同工具以及数据库工具团队。也曾在 Google 硅谷总部云数据库团队担任技术负责人。目前是 bytebase.com 的创始人，研发一款面向工程师和 DBA 的开源数据库 schema 变更协同工具。
