研发效能度量

度量"/>

研发效能度量

文章目录

• • • 前文
    • 技术框架
    • 技术实现
    • 总结

前文

  互联网时代，在开源得到限制的情况下，研发能力的能效提高显得特别重要，而能效的提升与指标的度量离不开，正所谓无数据何来的量化以及展示？领导层更是看不到数据的变化，即看不到所谓的"提升"。研发数据的度量，维度非常广，包括但不限于：
1.平台维度：bug相关、测试用例相关、需求相关、任务相关、CI/CD相关、代码相关等
2.聚合维度：个人、项目(产品)、团队、体系等
3.类别维度：效能、效率、质量、工程等
4.活动维度：开发、测试、需求、项目等
5.属性维度：可观测性、滞后性、引领性等

  其中每一个分类则根据指标所需可以继续分类，最终演变的指标是非常之多。
  本文更多是以技术视角来简单分享研发效能度量的相关，写的不会很专业，更多的是想到哪写到哪，而且会更侧重于从技术角度来阐述一些思考。主要研发的指标度量，公司的不同，则研发的管理与对应平台的管理也千变万化，重点是要因地制宜地来制定对应的指标。而且部分指标，无法100%精确，需要考虑到误差，同时在误差允许的范围内，实现自身跟自身对比，比如同比和环比等。

技术框架

  在实现一个效能度量平台前，先理解这个平台需要具备什么功能，首先需要具备一个可视化平台，供用户多角度查看指标；其次要具备数据存储功能，提供指标数据的存储与捞取；接着则是数据来源采集功能，采集各个平台的数据到本地，实现数据存储。故此分为三大块：数据采集、数据存储、数据展示。
  前端上可以用vue（v-charts），根据后端返回的数据做对应图表的展示；后端上推介用es做数据存储，因为es可以快速地检索亿级数据（秒级），同时es自身分布式的特性，可以对数据做多副本保证数据的可靠性，非常具有优势；同时需要redis来做部分指标的缓存，mysql/pg 做平台业务数据的展示，最后web框架则相对随意，我这选用的是python的flask。
  所以框架上的选择： vue + flask + es + pg + redis

技术实现

  指标的展示更多的是对公式的应用，这里的复杂度不是很高，难的是公式的统一认可。因为不同维度聚合的公式，同时加上一些排除的规则，会让指标的产生出现完全不一样的变化。而公式的细化，可能会给性能带来巨大的压力，此时有两个方向选择：
1.考虑用redis做指标缓存
2.考虑对es的索引做二级乃至三级索引

  上面的第二点比较难理解，意思是我们采集数据是发生在后台异步任务中，当数据采集完后，es里存储了该平台最原始的数据；此时我们针对这个原始索引在做一个二级索引，二级索引就相当于是初级的公式，提前帮忙算好部分数据，最后在计算的时候直接计算就相当快。
  数据展示只是对存储的数据应用，如果数据存储做的好，则数据展示不是问题，同时准确性也是很大的保证。一开始做平台时，对如何用es存储数据存在着比较大的困惑，比如 很多平台存在着关联表，以及自己平台指标因为不同维度需要额外增加不同维度的属性来方便后续的聚合，那该如何定义存储结构呢？而es本身和mysql、redis也不尽相同，其中更多的是用记录来存储，记录中可以存储json对象来扩展字段。但很明显，es不适用于存储关系复杂的数据，也不适用于用关联查询捞出对应的记录。
  针对上述问题，可以考虑两种解决方式：
1.提前用关联查询将数据捞出，然后定格存储到es中，此时可以利用es的对象来存储
2.第1种方法无法解决关联表中变化频繁的表，此时就必须分开索引存储，然后做二级索引将各自索引再进行合并，动作发生在每次采集后

  一般推介用第二种，因为用第一种，很容易因为更新不及时，导致历史数据中的数据不准；当然，如果指标中有需要观察历史数据的变化趋势这类，则可以采用第一种。至于第2种，就涉及到了数据采集。采集这篇很大，我理解研发效能平台要做得好，采集至关重要。采集包含：定时采集、全量采集、增量采集这三种本平台的采集，同时还包含直接在目标平台的采集、日志采集（filebeat）等非本平台的采集。先讲后者，这类数据因为量大，同时只是一次性的，所以可以建议直接在目标平台插入数据库的时候，直接发条记录到效能平台，效能平台捕获记录并采集，这类要考虑发送失败记录等场景；前者定时采集，可以用些定时采集框架，需要可视化来管理，这里推介go语言开发的开源框架gocron来实现；而全量采集和增量采集也是顾名思义，第一次采集采用全量，后续则用增量保证数据的更新。

总结

  写的较多较杂，后续主要考虑分享部分指标的实现策略。