你好，我是美团高级技术经理钮博彦，主要负责美团点评研发工具栈的建设。在上一篇文章中，我分享了研发度量体系建设中度量的意义与度量体系中的前两个衡量指标，即价值与效率，今天我们继续聊一聊度量体系中的质量指标以及如何建设度量平台。

度量体系之质量

在我们明确了价值，提高了效率之后，我们就需要判断产品质量是否能够达到预期。质量度量的重点有两个，一是以结果为导向，二是质量问题，越早发现，越易修复。

其实这是两个老生常谈的问题了，但同时它也引发出我们对质量的两个关注点：第一，关注线上质量，包括服务端和客户端等；第二，关注过程质量，包括需求质量、代码质量、测试质量、发布质量和系统质量等。

线上质量

我相信多数团队都有线上质量看板，从中我们能够得知很多信息。首先，对于服务端，我们可以将度量指标分为三类：第一，线上故障，以线上故障数、线上故障恢复时长、线上缺陷数等指标来衡量；第二，稳定性，以服务可用性、错误类型分布、错误率、报警数、错误数量等指标来衡量；第三，性能，以接口响应时间、慢消息、接口慢响应率、慢 SQL、慢缓存等指标来衡量。

其次，对于客户端的线上质量度量指标，多数人会从 Crash 率、页面错误率等维度去衡量客户端的稳定性，而对于它的性能，我们可以关注安装包大小、页面加载时间、启动时间、FPS、卡顿、流量、CPU 等影响因素。

过程质量

之前提到，过程质量，一般可以从需求质量、代码质量、测试质量、发布质量和系统质量等维度进行度量。

1. 需求质量
30%-40% 的效率问题和质量问题来自于需求质量，需求质量问题有很多产生原因，比如没搞清楚需求的目的、不明确需求的目标，或对需求的理解千人千面等等。那我们怎样把控需求质量呢？

我们可以将需求质量指标分为两类，第一，需求整体质量，可以关注需求质量评分、需求 Bug 数、需求千行代码 Bug 数等因素。第二，需求自身质量，可以以需求打回次数、需求变更次数、需求质量 Bug 数等因素来衡量。

2. 代码质量
我们在工作中，经常会遇到代码质量差的问题，但是有多差、差在哪里，又很难说清楚。举个例子，我们有一个团队大约有 30 个开发人员，QA 六个月报了 1500 个 bug。这个数据体现了一个非常严重的问题，就是开发人员在交付代码时，无论是交付上线，还是交付给 QA，其代码质量都很差，结果就是 QA 与开发人员会周旋于 bug 的沟通与修复，导致团队效率极大降低。

因此，实时关注代码质量就显得尤其重要，我们可以将代码质量指标分为基础信息、可靠性指标、可维护性指标这三类。首先，基础信息可以通过代码质量评分、文件数、类的数量、方法数量等进行衡量。其次，可靠性指标可以依据代码重复率、代码圈复杂度、千行代码严重缺陷度和安全缺陷度来衡量。最后，可维护性指标可以关注高复杂度函数数量、迷惑方法名数量、技术债务比等因素。

另外，我们有一个不成文的实践，就是你要么先单测，要么将全复杂度降到一定程度之下，比如，只要你将全复杂度降到 15 以下，就可以不用写单测。我们通过这些手段，能够让大家快速了解到自己的代码质量。我们还会用一些短平快的方法去降低代码的复杂度，屏蔽代码质量引来的风险。

3. 测试质量
测试质量指标可以分为四类，第一，整体质量，可以查看千行代码 bug 率、整体漏测率、测试覆盖率、小流量灰度漏测率、提测打回率等；第二，bug 统计，可以查看缺陷新增趋势、解决趋势、生命周期分布和有效缺陷率等等；第三，单元测试，可以关注单测通过率与单测覆盖率；第四，单元化测试，可以通过自动化测试通过率、覆盖率、稳定性等因素来衡量。

4. 发布质量
不知道你会不会很关注发布质量，但在线上的 bug 中，很多都是由于发布环节的不规范导致的，对于发布质量的度量我们也将它分为三类。

一是发布整体，我们在发布环节有很多数据可以用来观察发布失败率及次数、发布和需求关联覆盖率、高峰期间发布数量及占比、非窗口期间发布数量及占比等指标。二是构建相关，我们可以关注构建成功率、构建次数与频率、构建失败平均恢复时长等指标。三是回滚相关，比如有预发回滚率、小流量回滚率、全量回滚率，等等。通过关注这些因素都可以使我们知道并保证一个平稳的发布过程。

5. 系统质量
我们可以从系统整体看服务数量、最长链路等指标，也可以看性能相关的方面，比如最大 QPS、系统响应时间、CPU 和客户端专项测试数据等，还有安全性指标，比如安全漏洞严重问题数等等。

全流程质量度量

我们在拿到这么多维度的质量数据之后，要做的就是全流程质量度量。全流程质量度量的目标有三点：需求质量评估、代码质量评估和风险预警。就是从多个维度去观察需求开发过程，对需求上线之前的质量进行评分，以及预测上线之后的风险。目的是提高研发过程中的效率，避免上线之后再做一些重复动作。

总而言之，建设质量度量体系能够带来三方面的好处。第一，产品整体质量可以实时评估；第二，可以提早暴露质量风险，使我们能够提早进行修正；第三，可以使质量保障流程有的放矢，加快落地速度，效果也会非常明显。

说了这么多，想必你已经清楚了我们为什么要度量，以及如何度量，接下来再聊一聊度量平台的建设。

度量平台建设

我们先来看一张度量平台建设的云图，也是我们目前的整体架构图。

在我们公司内有各种各样的业务系统，然后有两个数据渠道，一个是实时数据流，主要用于分析代码质量，每一次代码提交都触发持续集成，我们可以在代码提交时了解到它的质量。另外，实时数据还可以支撑我们线上的监控情况。大家可以看到，我们在这块采用了 ES 来做数据存储，主要是因为我们实时分析的数据量较小，如果你的实时数据分析需求较大的话，可以采用 Flink 或 Spark Streaming。

另一个是离线数据流，我们的离线数据量非常大，每天会有几百 G 的数据进入数仓，包括需求的流转数据、代码提交、持续集成、发布数据、各种线上的监控等等，最后都会汇总到数仓。在数据立方体建设方面，我们主要采用 Kylin。另外，我们的实时数据最终也会通过 ETL 的方式，汇总到离线数据库中，为之后的离线数据分析做数据支撑。

最后再讲几个难点，也是我们在建设度量平台中踩到的坑。
第一，技术选型，我们当时有许多考虑，比如用 Flink 或 Spark Streaming 来做实时数据，最后还是决定用非常短平快的 ES 和离线的 Hive。

第二，指标体系建设，这是一个非常大的系统工程，非常耗费人员精力。由于美团点评有非常多的业务，每个业务都有自己的业务形式，包括发版周期、研发流程都不一样，甚至各个业务也处在不同的发展阶段，种种“差异”就造成我们的指标体系非常庞大，因此，我们就需要以多种视图、多种维度来建设指标体系。

第三，数仓建设，它有三个难点，一是数据立方体的建立，因为指标体系庞大，所以需要建设多维度、多字段组合的数据立方体。二是异构数据，因为业务系统很多，我们需要导入大量的数据，与自己的数据格式对齐，非常耗费精力。三是数据快照，简单来说就是将每天的需求的 Change log 快照下来，只有这样，我们才能得知最后一个需求在每一个状态下停留的时间长度，处理量也非常庞大。

以上三点就是我们在度量平台建设方面踩过的一些坑，因为度量平台建设这个话题比较大，有很多未能详尽之处，如果你感兴趣，我们可以继续在留言区讨论。

总结

通过两篇文章我分享了关于研发度量体系的意义、度量体系指标和度量平台建设，在建设研发度量体系中还有三个要点：第一，度量数据的生产者要成为度量数据的消费者；第二，度量是一个系统工程，不同的业务团队有不同的流程，不同的发展阶段有不同的重点，不同的角色有不同的视角，因此建设度量体系应该以系统性思维去思考；第三，度量不是绩效考核的工具，度量是为了及时解决问题，优化结果。

最后，度量体系能够帮助团队，建设关注价值、效率、质量的文化理念，可以使我们的目标更明确，提升团队战斗力与成就感，使现状更清晰，减少资源浪费，也能够帮助我们改进更精确，无论是技术革新，还是流程优化，我们都能够根据度量指标有的放矢。

感谢收听，我们下期再见！如果你觉得这篇文章对你有帮助的话，也欢迎把它分享给更多的朋友。

作者简介

钮博彦，美团高级技术经理，负责美团点评整体的研发工具栈建设。曾就职于微软中国、雅虎北研、唱吧等公司，从事系统开发、DevOps 和质量保障等相关工作。一直专注于提升研发整体质量与效率，及其流程和平台建设。