研发效能管理中的经典度量——DORA 指标
有一个组织,每年都会基于对相关从业者的调研和分析,发布一份《DevOps 行业状态报告》,揭秘研发团队的 DevOps 健康状况和平均效能水平,至今已持续了 9 年。目前,全球有超过三万名专业人士参与该调研,而它也成为同类调查中规模最大、持续时间最长的项目。
它就是在 2018 年加入谷歌的 DORA(DevOps Research and Assessment),一个致力于了解如何让研发团队快速交付高质量软件的组织。经过年复一年地洞察和分析,DORA 团队提炼出四个影响软件交付效能的关键指标,即 DORA 指标。
一、什么是 DORA 指标?
DORA 指标涉及吞吐量(Throughput)和稳定性(Stability)两个方面,共包含四个关键指标,分别是部署频率、变更前置时间、服务恢复时间和变更失败率。
- 部署频率 Deployment Frequency
部署频率是一段时间内,研发团队成功将代码部署到生产环境或将其发布给用户的频率。它衡量了研发团队的平均吞吐量和价值交付频率,体现了组织快速响应变化的能力。
- 变更前置时间 Lead Time for Changes
变更前置时间是指从代码提交到在生产环境中成功运行所需的平均时间,反映了研发团队代码审查、测试、部署等效率和敏捷性。
- 服务恢复时间 Time to Restore Service
服务恢复时间,也称平均恢复时间、平均修复时间(Mean Time to Recovery,即 MTTR),是生产环境中发生故障到恢复服务的平均时间,与研发团队监控、定位、识别和解决故障的能力有关。
- 变更失败率 Change Failure Rate
变更失败率是导致生产失败(如服务降级或服务中断)并需要补救的部署的百分比,通过部署失败次数除以总部署次数计算得出。它反映了研发团队交付高质量代码和稳定服务的能力。
其中,部署频率和变更前置时间度量了研发团队的吞吐量水平,而变更失败率和服务恢复时间度量了研发团队的稳定性。
二、如何正确使用 DORA 指标?
除了四个关键指标外,DORA 还通过聚类分析等方式,为各项指标划分低、中、高和精英等不同水平的效能基准值并每年更新,以帮助更多研发团队明晰自身的效能水平和瓶颈。
例如,《2022 年 DevOps 现状报告》指出,可实现按需部署或支持每天多次部署的研发团队,其部署频率指标达到高效能团队水平。
研发团队结合 DORA 参考值,可以直观地了解自己的各项指标在行业中所处的位置,快速定位和识别问题,并制定针对性的优化提升方案,高效管理。在科技革新和技术更迭飞快的今天,产能效率和稳定性正是研发团队提升组织敏捷性,快速响应变化的成功关键。
数据出自《2022 年 DevOps 现状报告》
三、要小心「数字管理」陷阱
DORA 指标明确了研发效能管理的关键对象和参考水平,为原本模糊的研发效能提升提供了清晰的方向。但是,对量化指标的错误理解和滥用常常导致管理动作变形,阻碍研发团队真正进步。
DORA 研究团队成员 Nathen Harvey 曾在一次活动中表示,许多团队容易掉入「数字管理」陷阱,忽略上下文(Context)。他们总是过分关注指标的具体数值,急于给研发团队贴上「能力强」或「能力差」,甚至是「淘汰」的标签,而忽略不同企业、不同团队、不同产品和服务之间都有各自的发展规律或限制,就像 B/C 端产品的部署频率不可共谈、初创公司和谷歌的服务能力也很难相提并论一样。
此外,Nathen 还强调,DORA 指标管理的最终目的是持续学习,持续改进。技术管理者应该以「实现更快、更好地交付研发价值」为目标,而不是将「达到高效能水平」立为军令状。
四、LigaAI 总结
DORA 指标考虑了吞吐量和稳定性两个维度的四个关键指标,分别是部署频率、变更前置时间、服务恢复时间和变更失败率。
研发团队应该以持续学习、持续进步为核心,正确使用 DORA 指标指导改进和优化,以实现更快、更好的价值交付。在研发管理实践中,切忌「数字管理」和动作变形。
LigaAI@oschina 还将持续分享更多研发效能管理、度量体系搭建的实践经验,以及科学的度量指标管理方法。
点击试用 LigaAI - 新一代智能研发协作平台,一起变大变强!

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
【AI思维空间】ChatGPT纵横编程世界,点亮智慧火花 | 京东云技术团队
作者:京东零售 王英杰 概述 该文档记录云交易开发小伙伴儿们在开发过程中的实际应用案例,记录典型案例,以解决开发过程中的实际问题为主,涵盖设计方案、编码、测试、集成、部署等等。 目的:贡献最佳实践,分享心得,共同成长! 1. 怎样构造Prompt 1.1 基本构成 一般情况下,Prompt可以分成以下4个部分: Instruction: 指引,即要解决的问题类型 Context: 上下文,即问题的背景 Input Data: 输入数据,即具体的问题 Output Indicator: 输出指示,即对输出的一些约束 举例: Instruction: 向我说明前端所需技术栈 Context: 假设你是一个前端面试官,我是一个本科毕业的应届生 InputData: 向我说明现阶段前端行业要求应届生掌握的技能情况 Output Indicator: 用尽量简单易懂的语言 1.2 设计原则 清晰,切忌复杂或歧义,如果有术语,应定义清楚。 具体,描述语言应尽量具体,不要抽象或模棱两可。 聚焦,问题避免太泛或开放。 简洁,避免不必要的描述。 相关,主要指主题相关,而且是整个对话期间,不要东一瓢西一瓤...
- 下一篇
限速神器RateLimiter源码解析 | 京东云技术团队
作者:京东科技李玉亮 目录指引 限流场景 软件系统中一般有两种场景会用到限流: •场景一、高并发的用户端场景。 尤其是C端系统,经常面对海量用户请求,如不做限流,遇到瞬间高并发的场景,则可能压垮系统。 •场景二、内部交易处理场景。 如某类交易任务处理时有速率要求,再如上下游调用时下游对上游有速率要求。 •无论哪种场景,都需要对请求处理的速率进行限制,或者单个请求处理的速率相对固定,或者批量请求的处理速率相对固定,见下图: 常用的限流算法有如下几种: •算法一、信号量算法。 维护最大的并发请求数(如连接数),当并发请求数达到阈值时报错或等待,如线程池。 •算法二、漏桶算法。 模拟一个按固定速率漏出的桶,当流入的请求量大于桶的容量时溢出。 •算法三、令牌桶算法。 以固定速率向桶内发放令牌。请求处理时,先从桶里获取令牌,只服务有令牌的请求。 本次要介绍的RateLimiter使用的是令牌桶算法。RateLimiter是google的guava包中的一个轻巧限流组件,它主要有两个java类文件,RateLimiter.java和SmoothRateLimiter.java。两个类文件共有jav...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
-
Docker使用Oracle官方镜像安装(12C,18C,19C)
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- Docker快速安装Oracle11G,搭建oracle11g学习环境
- CentOS8编译安装MySQL8.0.19
- SpringBoot2配置默认Tomcat设置,开启更多高级功能
- MySQL8.0.19开启GTID主从同步CentOS8
- CentOS7,8上快速安装Gitea,搭建Git服务器
- Jdk安装(Linux,MacOS,Windows),包含三大操作系统的最全安装
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果
推荐阅读
最新文章
- CentOS7编译安装Cmake3.16.3,解决mysql等软件编译问题
- Linux系统CentOS6、CentOS7手动修改IP地址
- CentOS7编译安装Gcc9.2.0,解决mysql等软件编译问题
- SpringBoot2更换Tomcat为Jetty,小型站点的福音
- CentOS8,CentOS7,CentOS6编译安装Redis5.0.7
- CentOS7,8上快速安装Gitea,搭建Git服务器
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- CentOS8编译安装MySQL8.0.19
- Jdk安装(Linux,MacOS,Windows),包含三大操作系统的最全安装
- MySQL8.0.19开启GTID主从同步CentOS8