前面几个课时端到端地介绍了软件开发全生命周期中涉及的最佳实践，经过上面几个步骤，企业在进行 DevOps 转型时技术方面的问题解决了，这个时候我们还缺些什么呢？事实上很多团队和组织在实施 DevOps 时都专注于技术，而忽略了度量和文化方面。度量是实施 DevOps 的关键要素，如果把 DevOps 比作一辆车，那么之前的造工具、搭平台就是这辆车的车身，度量就是车的仪表盘。DevOps 的度量也需要一些指标来指导 DevOps 的持续改进。那么什么样的指标是好指标？如何找到好指标？这就是今天要介绍的内容。
为什么要度量指标？
度量在很多企业里落地的效果并不好。一是因为度量的前提是要有一套打通端到端的 DevOps 平台，否则再优秀的度量也只是局部度量。目前国内很多企业还都处于建设 DevOps 平台的基础阶段，因此落实下来也并不容易。二是，度量本身投入产出比并不像 CICD 效果明显。很多工程只是为了“给上面看看”而完成的任务，并没有从度量的本质上去考虑。
因为这两点原因，度量指标在企业内的落地还存在问题。
我认为“有哪些度量指标”“指标如何获取”这些问题是我们从一开始就要考虑的。原因有以下几点：
& 精益思想的核心理念是持续改进，只有清晰明确的度量指标作为指引，才能达到持续改进的目标。在持续改进这条路上，没有终点，永远在路上。
& 度量能够提供信息来帮助我们知道现在在哪里，距离目标还有多远，我们是在沿着目标前进，还是在倒退，程度如何。
& 度量指标是需要从 DevOps 平台获取的，一开始要考虑有哪些度量指标，如何获取，对 DevOps 平台的设计有指导意义。
这样要强调的是，度量指标不是目的，而是手段；不是控制，而是改进。“目的”容易给人以到达终点的错觉，“手段”是为了发现潜在的问题。“控制”容易给人以一种静态目标的心理暗示，“改进”则是以动态目标植入人心。这有助于我们能够不断地发现问题，改正问题。
什么样的指标是好指标？
关于寻找度量指标这块，在有些企业里都有一个误区，就是要“度量所有内容”。一些企业拍脑袋要度量几百个指标，以期望能从这么多的指标中找到一些重要信息。这种方式是不正确的，有以下几个问题：
& 更多的指标需要投入更多的资源来关注软件研发的各个方面，最终会导致每个指标的效果并不好；
& 以 KPI 的形式完成指标，最终完成的只是数量，不是质量。
那么，度量指标的质量是什么？什么样的指标是好指标？下面这 5 个标准希望能够帮到你。
1.可度量的：指标必须是可衡量的，即是一个定量的指标，而不是“非常好”，“非常快”这种定性的指标。
2.相关联的：指标必须能够度量对业务有重要影响的因素。
3.不可更改的：团队成员不能影响度量指标的结果。
4.可实施的：指标是能够通过技术的手段获取并且数值是真实可靠的。
5.可追溯的：指标必须是能够直接反映软件研发过程中存在的问题。
因此，我们不可能度量所有的指标，要选出哪些满足这些要求的指标，指标不在多，而在精。在找出要跟踪的 DevOps 指标之前，需要确定组织面临的挑战以及要解决的问题。好的指标是用来解决实际业务问题的。因此，应该避免那些不符合 DevOps 时代、对用户没有价值的指标，比如以下几点。
& 传统的工程指标：比如 MTBF（平均故障间隔时间）在 DevOps 时代意义就不大。系统的长期稳定性并不是首要目标，因为 DevOps 时代是通过快速部署来保证系统的稳定性的。基于虚拟化和基础设施即代码的工程实践，可以通过频繁的部署来进行线上测试，这些测试可能会经常失败，但有利于制定更好的方案。这种情况下，MTBF 对业务需求来说并不是好指标。
& 基于竞争的指标：切勿基于团队成员或团队之间的竞争来建立指标。比如按团队成员完成的需求数量进行排名、按开发人员出现的 Bug 数进行排名等。度量指标的目的是用来解决业务问题，不是用来晾晒团队成员技术水平的手段。
& 虚荣性指标：比如每周代码行的统计。不应该以代码行数这样无意义的指标评判开发人员工作量的指标。最终交付功能的及时性和质量才是最重要的。
在度量指标的时候，不要根据获取指标的难易来取舍指标。在一项重要的指标上哪怕花费更多的成本都是值得的，在一项无用的指标上投入再少的时间也是在浪费。
如何选择指标？
在上面也提到了，好的指标是用来解决问题的。当我们在选择指标时的依据也是要解决的问题。在软件开发过程中，需要解决的问题很多。代码质量、团队成员、发布效率的等都有可能成为问题的来源。这些指标中，有些是给上层领导做决策用的，有些是为了提升团队技能水平的，有些则是为了提升软件质量。不管用途是什么，衡量的标准就是解决或改善现有的问题。我举了下面几个例子。
& 缩短产品上市时间：用于衡量从用户需求被提出到最终交付给用户之间的时间，可以使用“前置时间”这个指标。因为更短的上市时间代表了企业在市场竞争中的反应速度越快。
& 提高软件开发的效率：可以使用“流动效率”这个指标，以查看瓶颈点，并将工作重心放在如何改善流动瓶颈的地方。等待的时间越少，软件开发的效率就越高。
& 解决团队正在处理的事项和计划外事项的冲突：可以使用“在制品数量”这个指标，以暴露工作内容过载的团队或团队成员，使得每个团队成员的工作更加均衡。
& 解决未完成的重要工作不被遗忘的问题：可以使用“停留时间”或“过期时间”等指标，来度量未完成的工作在系统里停留了多长时间，如果超过设置的阈值则进行预警以暴露风险。
& 减少生产环境中用户发现的问题数量：可以使用“缺陷逃逸率”这个指标，争取尽可能多的 Bug 是在测试环境或预生产环境中发现，以最大程度建设用户发现的缺陷数量。
如何使用指标？
当根据上面的标准选择好指标后，应该如何使用这些指标？反馈循环是有效改进的基础，通过度量指标的反馈，有助于更加精准的调整团队的行动，改善整个组织的沟通。下图是度量指标的反馈循环，需要有以下几个步骤：
STEP 1：收集数据。
收集关于软件研发过程中的数据，作为后续分析的原材料。在大多数企业，度量面对的问题不是数据准不准确，而是有没有数据的问题。如果要有效地收集数据，需要从两个方面入手。
& 平台方面：平台本身需要具备收集数据的能力。在设计平台时，要有针对度量指标方面的设计。比如每个任务都要有开始时间和结束时间，每个事件都应该有发生、处理、解决的时间记录，事物之间的关联（如代码提交与任务或缺陷的关联，代码库与产品线的关联，流水线构建与代码库的关联等）。平台具备收集这些数据的能力外，还可以提高统计报表，用更直观的方式进行展示。
& 人的方面：团队成员的有效参与能够充分发挥平台的能力。DevOps 平台中，虽然将研发流程中的操作尽可能自动化了，但有些内容还是需要人工配合。比如：在提交代码时按照规范提交，将需要关联的需求 ID 和缺陷 ID 添加到 message 里，从而建立提交的代码与需求和缺陷的关联。需求的拆解，任务的启动、过程跟踪以及完成后的关闭操作，都需要人工配合，才能使数据更加准确。
STEP 2 ：分析数据。
基于收集的数据进行分析，以便能发现当前存在的问题。举个例子，通过数据收集系统发现：需求完成的数量在减少，代码行数在增加，同时缺陷的数量在增长。下面通过这些数据进行分析：
& 需求完成的数量减少，说明团队花在需求上的时间减少了，是什么原因导致的呢？继续往下分析。
& 代码行数在增加，说明团队成员花费大量的时间在修改代码上。既然完成的需求在减少，可以断定代码不是为开发需求而写的。
& 缺陷的数量在增加，可以说明当前在测试阶段，并且测试出了很多问题。
通过分析得出结论：说明软件进入到测试阶段后，问题很多，导致团队成员需要花费大量的时间修复缺陷，从而影响了正常的需求开发。
STEP 3：调整流程。
根据上面的分析判断，开发人员在开发阶段对软件质量的控制效果并不好，可能的原因有：
& 开发人员没有进行有效自测；
& 开发人员没有编写单元测试或者覆盖率较低。
因此，我们可以采取一些措施改善流程，尽早发现软件中的问题。比如在持续集成流水线中集成单元测试，通过设置门限阈值来控制单元测试的有效性和覆盖率；通过自动化的API接口测试，验证服务以及服务之间调用的正确性等。
STEP 4：重复执行。
重复上面的步骤，再次收集指标，观察指标的变化，并根据指标的值调整流程，直到满足要求。
总结
本课时是度量指标部分的开篇。前面介绍过，DevOps 以精益思想为基础，精益思想的基础是持续改进，持续改进的基础就是清晰明了的度量指标。本课时并未详细的介绍任何一个具体的指标，主要介绍了什么样的指标是好指标，如何选择指标和如何使用指标，强调了度量指标在于精，而不是多。度量指标是手段，不是目的，是用于发现企业中人员、流程、组织和软件存在的问题。在后面几个课时分别从团队能力、响应速度、软件质量和业务价值四个方面来阐述具体的度量指标。
