Close

DevOps 指标

在 DevOps 中衡量成功的原因、内容和方法

TOM HALL

DevOps 推广人员和从业人员


像适用于任何其他实践一样,“您无法改善自己不进行衡量的方面”这一古老的格言也适用于 DevOps。为了实现 DevOps 的承诺(更快地交付更高质量的产品),团队需要收集、分析和衡量大量指标。这些 DevOps 指标提供了 DevOps 团队查看和控制其开发管道所需的基本数据。

What are DevOps metrics?


DevOps 指标是指直接揭示 DevOps 软件开发管道性能的数据点,它们有助于快速识别和消除流程中的所有瓶颈。这些指标可用于跟踪技术能力和团队流程。

DevOps 的核心是模糊开发团队和运维团队之间的界限,从而加强开发人员和系统管理员之间的协作。借助指标,DevOps 团队可以衡量和评估协作工作流程,并跟踪实现高级目标的进度,包括提高质量、缩短发布周期和提高应用性能。

四大 DevOps 指标


Though there are numerous metrics used to measure DevOps performance, the following are four key metrics every DevOps team should measure.

变更的提前期

需要跟踪的关键 DevOps 指标之一是变更的提前期。请勿与周期时间(下文会讨论)混淆,变更的提前期是指代码变更提交到主干分支与进入可部署状态之间的时长。例如,当代码通过所有必要的预发布测试时。

变更失败率

变更失败率是指生产后需要热修复或其他补救措施的代码变更百分比。它不衡量在部署代码之前通过测试所捕获和修复的故障。

部署频率

了解将新代码部署到生产环节的频率对于了解 DevOps 的成功至关重要。很多从业人员使用“交付”一词来表示发布到预生产阶段环境中的代码变更,并保留“部署”一词来表示发布到生产环节的代码变更。

Mean time to recovery

Mean time to recovery (MTTR) measures how long it takes to recover from a partial service interruption or total failure. This is an important metric to track, regardless of whether the interruption is the result of a recent deployment or an isolated system failure.

查看解决方案

适用于精英 DevOps 团队的工具

相关资料

团队结构在 DevOps 中的重要性

How to measure, use, and improve DevOps metrics


与 DevOps 生命周期的其他元素一样,持续改进的文化也适用于 DevOps 指标。在开发的每个阶段获得快速反馈的能力以及实现反馈的技能和权利,是高效能团队的标志。在 DevOps“加速”这本书中,作者指出,上面列出的四大核心指标得到了高效能软件团队所采用的 24 项功能的支持。下文将介绍其中的大部分功能(CI/CD、测试自动化、小批量工作、监控和持续学习),但“加速”仍值得大家一读,以便深入了解支持这些实践的相关研究。

变更的提前期

高效能团队通常以小时为单位衡量提前期,而中低效能团队则以天、周甚至月为单位衡量提前期。

测试自动化主干开发和小批量工作是缩短提前期的关键因素。这些实践可让开发人员快速收到有关他们所提交代码的质量反馈,以便他们能够识别和修复所有缺陷。如果开发人员处理单独分支上存在的重大变更,并依靠手动测试进行质量控制,提前期则势必很长。

变更失败率

高效能团队的变更失败率在 0%-15% 的范围内。

可缩短提前期的相同实践(测试自动化、主干开发和小批量工作)与降低变更失败率相关。所有这些实践都使缺陷更容易识别和补救。

跟踪和报告更改失败率不仅对于识别和修复错误很重要,对于确保新的代码版本符合安全要求也非常重要。

部署频率

高效能团队可以按需部署变更,而且通常每天要执行多次。较低效能团队通常仅会每周或每月部署一次。

按需部署的能力需要一个自动化的部署管道,其中包含前面各节所提及的自动化测试和反馈机制,并最大限度地减少人为干预的需求。

平均恢复时间

高效能团队可以快速从系统故障中恢复(通常不到一个小时),而较低效能团队可能需要长达一周的时间才能从故障中恢复。

从故障中快速恢复的能力取决于能否快速识别故障发生的时间,以及部署修复程序或回滚导致故障的所有变更。这通常是通过持续监控系统运行状况并在发生故障时向操作人员发出警报来实现的。运营人员必须拥有解决事件所需的流程、工具和权限。

从传统实践专注于故障之间的平均时间 (MTBF) 转变为专注于 MTTR。它反映了现代应用更高的复杂性,因此故障的预计发生率也会变高。MTTR 还加强了持续学习和改进的实践。团队不会等到部署“完美”来避免各种故障(从而重置旧的 MTBF 记分板),而是持续进行部署。MTTR 不会因为破坏了“完美”的 MTBF 记录而大加指责,而是鼓励无指责的追溯,从而帮助团队改进上游流程和工具。

Other related metrics


另一个相关指标是周期时间,即团队在项目准备交付之前工作花费的时间。在开发领域,周期时间是指从开发人员进行提交到将其部署到生产环节的时间。此关键 DevOps 指标有助于项目主管和工程经理更好地了解哪些方面在开发管道中效果良好。因此,他们可以更好地将自己的工作与利益相关者和客户的期望保持一致,确保团队可更快地完成交付。

项目主管可使用周期时间报告为开发管道建立基准,用于评估未来的流程。当团队针对周期时间进行优化时,开发人员通常会减少正在进行的工作和低效的工作流程。

在精益产品管理中,重点关注价值流映射,即呈现从产品或功能概念到交付的这一流程。DevOps 指标为有效的价值流映射和管理提供了许多必不可少的数据点,但还应使用其他业务和产品指标进行增强,以便进行真正的端到端评估。例如,冲刺燃尽图可以洞察估算和规划流程的效率,而净推荐值则表明最终交付成果是否满足客户的需求。

In conclusion…


持续改进是实践 DevOps 的团队的核心原则。衡量和跟踪变更的提前期、变更失败率、部署频率和 MTTR 性能的能力,让团队能够加快速度并提高质量。详细了解 Atlassian 如何帮助您更好、更快地为客户创造价值,请参阅 Code in Jira 和 Jira 中的部署 (Deployments)

Tom Hall
Tom Hall

Tom Hall 是 DevOps 流程的倡导者和实践者,他热爱阅读,还是一名业余钢琴家。
过去 20 年,他获得了 Novell、EMC、VMware 和 AWS 的认证。2016 年,他在亚特兰大协助主办了 DevOpsDays,之后数年又在德克萨斯州奥斯汀协助主办了 DevOPSDays。


分享这篇文章
下一个主题

推荐阅读

将这些资源加入书签,以了解 DevOps 团队的类型,或获取 Atlassian 关于 DevOps 的持续更新。

Devops 示意图

DevOps 社区

Devops 示意图

模拟研讨会

地图插图

免费试用

注册以获取我们的 DevOps 新闻资讯

Thank you for signing up