共计 2632 个字符，预计需要花费 7 分钟才能阅读完成。
在这篇文章中，咱们将介绍 DevOps 四个要害指标——DORA 指标，DORA 指标的度量难点，以及如何基于开源工具疾速实现 DORA 指标的度量和继续追踪。如果你相熟 DORA 指标，能够间接跳到本文第二局部。
什么是 DORA 指标？
DORA 的全称是 DevOps Research and Assessment，是一个致力于 DevOps 调研与钻研的组织，2018 年退出 Google Cloud。自 2014 年起，DORA 每年会公布一份行业报告，基于对数千名从业者的调研，剖析高效能团队与低效能团队在 DevOps 实际上的差别。
高效能团队如何定义？可能每个人、每个组织都有不同见解。DORA 的做法是将研发团队体现分为三个方面：软件交付体现、运行稳定性体现和组织业绩体现。在软件交付体现方面，提炼出四个要害的后果性指标进行概括，这就是驰名的 DORA 指标。DORA 指标包含
- 部署频率（Deployment Frequency）：一段时间内应用程序部署到生产中的次数，代表研发团队交付价值的频率
- 变更交付周期（Lead Time for Changes）：从代码提交到将代码部署到生产中的时长，代表团队进行代码评审、测试和部署的速度，也局部反映了团队响应用户需要的速度
- 变更失败率（Change Failure Rate）：变更部署到生产后产生故障、导致服务降级的比例，代表团队交付稳固服务的能力
- 服务复原工夫（Time to Restore Service）：生产环境中产生故障到服务复原的工夫，代表团队疾速监测、定位、诊断故障，并从故障中疾速复原的能力
在以上四个指标中，部署频率和变更交付周期指标次要度量的是 DevOps 交付体现中的 产能维度 （Throughput），而变更失败率和服务复原工夫指标次要度量的是 稳定性维度（Stablity）。
同时度量产能与稳定性，一方面能使二者互相制衡，防止大量低质量变更侵害用户体验，或防止严守品质连累交付效率；另一方面，验证优良的实际可能同时改善产能与稳定性，而不须要研发团队做出取舍，例如小批次的公布策略不仅间接进步部署频率，一旦故障产生也能疾速定位，有利于缩短服务复原工夫。
DORA 指标如何领导具体的实际改良？DORA 调研报告贴心地提供了一系列基准值，分为精英团队（Elite）、高效能团队（High）、中等效力团队（Medium）和低效能团队（Low）。研发团队能够参考业界程度对号入座，从而找到最要害的改良项，并在改良的同时继续度量 DORA 指标，验证改良措施的有效性。
2021 年 DORA 报告中的各级别团队体现
度量 DORA 指标，难在哪？
DORA 指标并不是什么陈腐事物，指标只有四个，公式也十分简单明了。但对于许多研发团队来说，要在日常工作中继续自动化地度量 DORA 指标，仍然难度不小。
艰难在于，DORA 指标度量依赖于变更、部署、故障等研发数据，而许多研发团队并没有获取研发数据的牢靠基础设施：
首先，研发过程自身是简单的，通常波及多个流程、流动和工具，研发过程数据也经常散落在简单的工具链中（包含代码托管、事务管理、CI/CD 工具等），导致数据难以提取，耗时费劲。如果研发团队同时应用同类型的多个研发工具，可能还须要解决不统一的数据概念，比方同一公司内局部团队应用 GitHub 局部团队应用 GitLab，就须要对立 Pull Request 和 Merge Request 两个概念。
其次，不同的组织和我的项目的研发和交付过程不同，可能会采纳不同的数据定义和计算方法。比方，有的团队应用 Git Tag 或某特定分支的合并来辨认一次部署，有的团队应用 CI/CD 工具中的事件来辨认一次部署。这样非标准化的定义与计算方法，也使得研发数据难以治理，进而给数据的可靠性打了一个问号。
市面上 DORA 指标工具之多，也从侧面印证了这仅仅四个指标的度量并非易事。如果某个团队思考度量 DORA 指标，他们可能须要比照市面上的数十个工具，目迷五色中找到恰好能接入以后研发工具链，恰好变更、部署、故障的定义均合乎团队实际的那一个。
不同工具所反对的数据源和指标计算形式各有差别
而这也正是咱们建设并开源了 研发数据平台 Apache DevLake 的起因。咱们认为，无论是研发工具链的接入以及研发数据的定义，都 该当保留肯定水平的凋谢和灵活性。团队依据理论需要收集并治理研发数据，保障数据牢靠，在此基础上度量 DORA 指标，并取得有价值的改良洞见。
开源的模式升高了研发数据的治理老本，同时也吸引更多团队参加建设，不断丰富可接入的数据源和数据计算方法，让平台越用越好用。
基于 Apache DevLake 疾速度量 DORA 指标
正如上文所说，度量 DORA 指标前，你须要先拿到三个研发数据：
- 变更：大多数团队是通过 Pull Requet 来辨认一次变更，因而变更的数据将来自代码托管工具，DevLake 目前已反对 GitHub、GitLab 和 BitBucket
- 部署：部署的数据来自 CI/CD 工具。DevLake 目前已反对 Jenkins、GitHub Actions 和 GitLab CI，CircleCI 正在开发中
- 故障：故障的数据能够来自事务管理工具中的某类型事务，例如 Crash 或 Incident；也能够间接来自监控工具，DevLake 将很快反对 PagerDuty 和 Sentry。
除了手动触发数据收集，DevLake 也反对主动定时拉取研发数据，不便研发团队低门槛地应用 DORA 指标，继续追踪效力体现。
如果 DevLake 尚未反对你的研发工具，你仍然能够应用 webhook 将事件数据推送到 DevLake。
接下来，只需四步，就能够在 DevLake 中看到 DORA 指标和数据看板：
- 配置 DevLake：应用 Docker Compose、Kubernetes、Helm 或 Temporal
- 收集数据：借助 DevLake 插件接入研发工具链，不须要简单的集成与适配，就能够把需要、开发、测试、交付各个环节研发数据归于一处
- 数据看板开箱即用：DevLake 预置了许多指标和数据看板并通过 Grafana 来出现，其中包含 DORA 指标和相应看板
- 自定义：如果你还须要进一步剖析，例如探查某个 DORA 指标异样的起因，只须要几行 SQL 查问就能够创立新的指标或数据看板
👇👇点击文档，应用 DORA 指标给研发效力做个疾速体检！
https://devlake.apache.org/do…
👇👇拜访官网理解更多
https://devlake.apache.org/
👇👇欢送大家扫码退出 DevLake 用户群交换 ♥
