前面的文章中介绍了DevOps的概念以及其落地经验，参考如下：

DevOps究竟能给企业解决什么问题

Devops 落地的核心和13条经验总结

今天我来介绍一下在Devops体系中对项目团队效能方面的考核指标！

度量指标的选择

在度量Devops团队效能方面，避免采用像代码行数、故事点数这种面向过程、局部的度量指标，而是采用像部署频率、前置时间、恢复时间、变更失败率和可用性等等这些面向结果的、全局性指标。具体指标如下：

前置时间

是指从代码提交，到代码成功运行，到生产环境的时间。好的团队的变更前置时间一般不到一个小时。

部署频率

是指团队将应用程序部署到生产环境频率的度量。好的团队会按需部署并且每天都会部署多次

变更失败率

是指应用程序部署到生产环境后需要回滚的百分比。好的团队的变更失败率一般小于百分之十五。

恢复时间

是指服务故障到服务恢复所需要的时间，好的团队恢复时间一般在 1 小时以内，有的业务恢复时间要求5分钟以内。

可用性

是指团队确保软件产品或服务可用的能力，可以通过 SLA 度量，好的团队 SLA可以达到99.99%，即一年 52.6分钟不可用，及个别公司要求业务的SLA达到99.999%，那么一年只有5.26分钟应用时不可用的！

缺陷逃逸率

是指用户或者测试人员在生产环境中发现的问题占整体发现问题的比率。

在制品数量

这个指标以暴露工作内容过载的团队或团队成员，使得每个团队成员的工作更加均衡。

停留时间

该指标用来度量未完成的工作在系统里停留了多长时间，如果超过设置的阈值则进行预警以暴露风险。

指标落地

有了明确的指标，我们就可以考虑如何利用这些指标帮我们准确地定位到项目中存在的问题了，如下图所示：

收集数据

我们可以借助平台记录事件（包括需求、故事点、事故、bug，以及部署频率、前置时间、恢复时间、变更失败率、可用性上述五个指标）的开始时间和结束时间，每个事件都有发生、处理、解决的时间记录。平台具备收集这些数据的能力外，还可以提高统计报表，用更直观的方式进行透明展示（对所有人都展示，类似学生时代的小红花评比）。

分析数据

通过平台的统计数据，找到当前存在的问题。例如：当我们发现需求完成的数量在减少，代码行数在增加，缺陷的数量在增长能说明什么呢？我们可以分析得出结论：项目进入到测试阶段后，问题很多，导致开发团队需要花费大量的时间修复bug，从而影响了正常的需求开发。

调整流程

从上面的分析中，我们可以发现开发人员在开发阶段对软件质量的控制效果不好，开发人员没有进行有效自测。然后跟开发人员进行沟通，发现问题的原因是：需求太多，开发人员的精力都在完成新的需求开发中，并没有时间自测代码！进一步跟需求人员沟通发现，现在的需求提交方式是——前方收到用户的反馈就会作为需求提交，而并没有对需求的有效性进行甄别。最终我们加入了需求评审环节，让有效的新增需求数量大幅度降低，从而给开发人员争取到了自测代码的时间来保障代码质量！

重复执行

重复上面的步骤，不断收集指标，不断观察指标的变化，并根据指标的值调整流程，直到满足要求。