技术领导力实战笔记_169_第136讲_|_钮博彦：软件研发度量体系建设（二）
你好，我是美团高级技术经理。
纽博彦主要负责美团点评研发工具站的建设。
在上一篇文章中，我分享了研发度量体系建设中度量的意义与度量体系中的前两个衡量指标及价值与效率。
今天我们继续聊一聊度量体系中的质量指标以及如何建设度量平台。
先来看度量体系中的质量指标，在我们明确了价值提高了效率之后，我们就需要判断产品质量是否能够达到预期。
质量。
度量的重点有两个，一是以结果为导向，二是质量问题越早发现越易修复。
其实这是两个老生常谈的问题了，但同时它也引发出我们对质量的两个关注点。
第一，关注线上质量，包括服务端和客户端等。
第二，关注过程质量，包括需求质量、代码质量、测试质量、发布质量和系统质量等。
首先来看线上质量，我相信多数团队都有线上质量看板从中我们能够得知很多信息。
首先，对于服务端，我们可以将度量指标分为三类，第一线上故障，以线上故障、线上故障恢复时长线上缺陷等指标来衡量。
第二，稳定性，以服务可用性、错误类型分布错误率报警。
数错误数量等指标来衡量。
第三，性能以接口响应时间慢、消息接口慢、响应率慢、吸口慢、缓存等指标来衡量。
其次，对于客户端的线上质量度量指标，多数人会从crash率、页面、错误率等维度去衡量客户端的稳定性。
而对于它的性能，我们可以关注安装包大小、页面、加载时间、启动时间FPS、卡顿、流量、CPU等影响因素。
再来聊一聊过程质量。
之前提到过程质量一般可以从需求质量、代码质量、测试、质量、发布、质量和系统质量等维度进行度量一、需求质量百分之三十。
到百分之四十的效率问题和质量问题来自于需求质量需求质量问题有很多产生原因，比如没搞清楚需求的目的不明确，需求的目标或对需求的理解，千人千面等等。
那我们怎样把控需求质量呢？我们可以将需求质量指标分为两类，第一，需求整体质量可以关注需求质量评分需求八个数，需求千行代码八个，数等因素。
第二，需求自身质量可以以需求打回次数，需求变更次数、需求质量、bug数等因素来衡量。
二、代码质量我们在工作中经常会遇到代码质量差的问题，但是有多差差在哪里又很难说清楚。
举个例子，我们有一个团队大约有三十个开发人员QA六个月报了一千五百个bug.这个数据体现了一个非常严重的问题，就是开发人员在交付代码时，无论是交付上线还是交付给QA,其代码质量都很差。
结果就是qa与开发人员会周旋。
与bug的沟通与修复导致团队效率极大降低，因此实时关注代码质量就显得尤其重要。
我们可以将代码质量指标分为基础信息、可靠性指标、可维护性指标这三类。
首先，基础信息可以通过代码质量、评分、文件、数类的数量、方法、数量等进行衡量。
其次，可靠性指标可以依据代码重复率、代码圈复杂度千行代码严重缺陷度和安全缺陷度来衡量。
最后，可维护性指标可以关注高复杂度函数数量、迷惑方法、名数量、技术债务比等因素。
另外我们有一个不成文的实践，就是你要么先单测，要么将全复杂度降到一定程度之下。
比如只要你将全复杂度降到十五以下，就可以不用写单测。
我们通过这些手段，能够让大家快速了解到自己的代码质量。
我们还会用一些短平快的方法去降低代码的复杂度，屏蔽代码质量引来了风险。
三、测试质量测试质量指标可以分为四类，第一，整体质量可以查看千行代码bug率、整体漏测率、测试覆盖率小、流量灰度、漏测率、提测打回率等。
第二，bug统计可以查看缺陷，新增趋势，解决趋势、生命周期分布和有效缺陷率等等。
第三，单元测试可以关注单测通过率与单测覆盖率。
第四，单元化测试可以通过自动化测试、通过率、覆盖率、稳定性等因素来衡量。
四、发布质量不知道你会不会很关注发布质量。
但在线上的bug中，很多都是由于发布环节的不规范导致的。
对于发布质量的度量，我们也将它分为三类，一是发布整体。
我们在发布环节，有很多数据可以用来观察。
发布失败率及次数发布和需求关联覆盖率高峰期间发布数量及占比、非窗口期间发布数量及占比等指标。
二是构建相关，我们可以关注构建成功率，构建次数与频率、构建失败、平均恢复时长等指标。
三是回滚相关，比如有预发回滚率、小流量回滚率、全量回滚率等等。
通过关注这些因素，都可以使我们知道，并保证一个平稳的发布过程。
五、系统质量我们可以从系统整体看，服务数量、最长、链路等指标，也可以看性能相关的方面，比如最大QPS、系统响应时间、CPU和客户端专项测试数据等，还有安全性指标，比如安全漏洞严重问题数等等。
下面我们再来看全流程质量度量。
我们在拿到这么多维度的质量数据之后，要做的就是全流程质量度量。
全流程质量度量的目标有三点，需求质量评估、代码质量评估和风险预警就是从多个维度去观察需求，开发过程对需求上线之前的质量进行评分，以及预测上线之后的风险，目的是提高研发过程中的效率，避免上线之后再做一些重复动作。
总而言之，建设质量度量体系能够带来三方面的好处。
第一，产品整体质量可以实施评估。
第二，可以提早暴露质量风险，使我们能够提早进行修正。
第三，可以使质量保障流程有的放矢，加快落地速度，效果也会非常明显。
说了这么多，想必你已经清楚了，我们为什么要度量以及如何度量。
接下来再聊一聊度量平台的建设。
我们先来看一张度量平台建设的云图，也是我们目前的整体架构图。
在我们公司内有各种各样的业务系统，然后有两个数据渠道，一个是实时数据流，主要用于分析代码质量。
每一次代码提交都触发持续集成。
我们可以在代码提交时了解到它的质量。
另外实时数据还可以支撑我们线上的监控情况。
大家可以看到我们在这块采用了ES来做数据存储，主要是因为我们实时分析的数据量较小。
如果你的实时数据分析需求较大的话，可以采用flink或spark streaming.另一个是离线数据流。
我们的离线数据量非常大，每天会有几百g的数据进入数仓，包括需求的流转，数据代码提交、持续集成发布数据，各种线上的监控等等，最后都会汇总到数仓。
在数据立方体建设方面，我们主要采用开联。
另外，我们的实时数据最终也会通过ETL的方式汇总到离线数据库中为之后的离线数据分析做数据支撑。
最后再讲几个难点，也是我们在建设度量平台中踩到的坑。
第一，技术选型。
我们当时有许多考虑，比如用flink或spark screming来做实时数据，最后还是决定用非常短平快的ES和离线的hive.第二指标体系建设，这是一个非常大的系统工程，非常耗费人员精力。
由于美团点评有非常多的业务，每个业务都有自己的业务形式，包括发版周期、研发流程都不一样，甚至各个业务也处在不同的发展阶段。
种种差异就造成我们的指标体系非常庞大。
因此，我们就需要以多种视图，多种维度来建设指标体系。
第三，数仓建设它有三个难点，一是数据立方体的建立，因为指标体系庞大，所以需要建立多维度多字段组合的数据立方体。
二是异构数据。
因为业务体系很多，我们需要导入大量的数据，与自己的数据格式对齐，非常耗费精力。
三是数据快照。
简单来说就是将每天的需求的change lock快照下来。
只有这样，我们才能得知最后一个需求。
在每一个状态下，停留的时间长度、处理量也非常庞大。
以上三点就是我们在度量平台建设方面踩过的一些坑。
因为度量平台建设这个话题比较大有很多，未能详见之处。
如果你感兴趣，我们可以继续在留言区讨论。
总结。
通过两篇文章，我分享了关于研发度量体系的意义。
度量体系指标和度量平台建设。
在建设研发度量体系中还有三个要点。
第一，度量数据的生产者要成为度量数据的消费者。
第二，度量是一个系统工程，不同的业务团队有不同的流程，不同的发展阶段，有不同的重点，不同的角色有不同的视角。
因此，建设度量体系应该以系统性思维去思考。
第三，度量不是绩效考核的工具，度量是为了及时解决问题，优化结果。
最后，度量体系能够帮助团队建设关注价值效率、质量的文化理念，可以使我们的目标更明确，提升团队战斗力与成就感，使现状更清晰，减少资源浪费，也能够帮助我们改进更精确。
无论是技术革新还是流程优化，我们都能够根据度量指标有的放矢。
感谢收听，我们下期再见。
如果你觉得这篇文章对你有帮助的话，也欢迎把它分享给更多的朋友。