为什么DevOps很好，但却很难落地，大家对DevOps是怎么理解的？
DevOps 涉及到文化、工具与实践三个方面。几位答主已经介绍得比较全面，我主要来介绍一下推行 DevOps 后，落地效果如何度量。
DevOps 的效果如何度量，在行业其实已经有相对成熟的四个关键指标——由 DORA 研究团队提出，所以“DORA 指标”这个名称更为大家所熟悉。DORA 指标并不直接反映文化、工具、实践任一部分的成效，而侧重于 DevOps 实践整体给研发产能与稳定性带来的提升，是四项结果性指标。
什么是 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 指标，验证改进措施的有效性。
度量 DORA 指标，难在哪？
DORA 指标并不是什么新鲜事物，指标只有四个，公式也非常简单明了。但对于许多研发团队来说，要在日常工作中持续自动化地度量 DORA 指标，依然难度不小。
困难在于，DORA 指标度量依赖于变更、部署、故障等研发数据，而许多研发团队并没有获取研发数据的可靠基础设施。原因在于：
首先，研发过程本身是复杂的，通常涉及多个流程、活动和工具，研发过程数据也常常散落在复杂的工具链中（包括代码托管、事务管理、CI/CD 工具等），导致数据难以提取，耗时费力。如果研发团队同时使用同类型的多个研发工具，可能还需要处理不一致的数据概念，比如同一公司内部分团队使用 GitHub 部分团队使用 GitLab，就需要统一 Pull Request 和 Merge Request 两个概念。
其次，不同的组织和项目的研发和交付过程不同，可能会采用不同的数据定义和计算方法。比如，有的团队使用 Git Tag 或某特定分支的合并来识别一次部署，有的团队使用 CI/CD 工具中的事件来识别一次部署。这样非标准化的定义与计算方法，也使得研发数据难以治理，进而给数据的可靠性打了一个问号。
市面上（尤其是 DORA 指标的应用更加成熟的海外），用于度量 DORA 指标的工具非常之多，也侧面反映出四个指标的度量并非易事。如果某个团队考虑度量 DORA ，他们可能需要对比市面上的数十个工具，眼花缭乱中找到恰好能接入当前研发工具链，恰好变更、部署、故障的定义均符合团队实践的那一个。
有没有更简单的解决方案？感兴趣的朋友欢迎继续浏览这篇专栏文章，我们讲述了使用 Apache DevLake，一款免费开源的研发数据治理平台，在15 分钟内搭建起 DORA 看板的实践：