“DORA”指标来自 DevOps Research Assessment，通过 Nicole Forsgren、Jez Humble 和 Gene Kim 的研究得到推广，最终成为强烈推荐的书籍《Accelerate: The Science of Lean Software and DevOps: Building and Scaling》高性能技术组织”。
四个关键指标依次是：
- 部署频率：组织发布到生产环境的频率。
- Lead-Time For Change：从提交到生产所需的时间。
- 更改失败率：在生产中导致失败或事件的部署百分比。
- 恢复服务的时间：组织从生产故障中恢复需要多长时间。
为什么我们认为这些指标很重要？很简单：正确测量，它们非常好地捕获服务的可靠性，以及部署中的摩擦级别。最后，部署频率是团队速度的一个相当准确的代表。
SRE 指标
Google 免费提供的 SRE 书籍中详细介绍了 SRE 指标。同样，要获得深入的指南，请阅读它们。
我们关心 SRE 指标的原因是，它们再次捕获系统的可靠性，以及保持系统运行所需的反应性“修复”工作（“辛劳”）的数量。此外，这些指标提供了一种机制来解决特性与可靠性之间的冲突，并解决许多组织中由于先前失败的发布而经常出现的发布犹豫。
服务水平指标、服务水平目标、服务水平协议
SRE 指标有三个初始概念，它们不是指标，但值得理解：
- 服务水平指标（“SLI”）是顶级概念，它们只是可以指示服务质量的事物，例如延迟或错误率/可用性。
- 就我们而言，服务水平目标（“SLO”）是关键指标：SLO 实际上是我们目标的 SLI 水平。例如，如果我们查看可用性 SLI，则可用性为 99%。
- 服务水平协议（“SLA”）：SLA 是对 SLO 的合同承诺，通常涉及技术、法律和商业方面的所有三个方面。
重要的是首先了解 SLI 和 SLO 之间的关系。
除了DORA-和SRE指标外，我们还有一些其他指标值得关注：
流动时间
流程时间类似于DORA的 "Lead-Time For Change"，不同的是LTFC是从承诺的变更到生产的计算，而流程时间是从接受的工作项目（计划的，即将开始工作的，但没有开始）到生产。因此，流动时间可以给衡量新功能从被接受和完善，到进入生产所需的时间提供更多的细微差别。
流量分布
流程分布，再次为DORA的变更失败率提供了更多的细微差别：流程分布，简单地说，计算了工作在错误、功能、可操作性改进和任何其他类别的工作之间的分布。这是一个有用的指标，可以看出是否有足够的精力用于测试和可靠性，系统是否有足够的可操作性。
公关准备时间和返工
我们会在这里面包括两个指标。
- 公关准备时间（从开放到合并/关闭的时间）
- PR返工（审查后做出修改的PR数量）
除非有必要，我们通常建议不要采用纯粹基于拉动请求的工作流程。为什么？
因为拉动请求来得太晚了：改变的成本、返工的成本、中断的成本，以及作者和审查者的上下文切换，都使基于拉动请求的工作流程变得昂贵。
前期的一点讨论和设计，以及最后的现场1对1的审查，只需要几分钟，有时可以节省几个小时和几天围绕拉动请求的来回奔波。
也就是说，即使采用这种方法，也很有可能在合并到主站之前有名义上的PR。在任何情况下，测量拉动请求的准备时间（从打开PR到合并的时间）是一个开始，但并不能揭示围绕审查的健康状况的全部情况。
我们将使用PR的前置时间作为顶级指标，但也要检查在提出PR后需要多少轮评论和提交，以进一步深入了解变化流的健康状况。
结论
总结一下我们在这篇文章的介绍中写的内容：
如下这样做：
- 使用指标来确定团队中需要改进的领域。
- 使用指标作为潜在问题的预警系统。
- 将团队与自身进行比较。
不要如下这样做：
- 尝试将指标分解到单个开发人员级别！
- 将团队相互比较时要小心，这通常是苹果和橘子。
- 根据指标对团队或个人进行排名。