代码检查规则集运营一般会关注什么指标？

代码检查服务的度量运营看板，除了先前提到的告警运营模块、规则运营模块（其中的指标，可以参考这2篇文章《代码检查告警运营一般会关注什么指标？》、《代码检查规则运营一般会关注什么指标？》），对于深度推广使用了服务的团队来说，还会存在的一个模块就是规则集运营。这个模块关注于对代码检查的规则集进行分析、处理和汇报，对于团队项目管理者来说，可以监控和管理到规则集的整体状况，具体可以参考我上一篇文章《代码静态检查为什么需要对规则集去做运营？》。

还是一样我们对该模块再聊得细化一点，在看板内的规则集运营模块里，用户一般会关注哪些指标呢？大致可以分为规则集本身维度的数据：规则集名称，语言，包含的规则数，推荐类型；以及 规则集关联维度的数据：规则集相关联的维护责任主体信息，规则集相关联的被引用情况，规则集相关联的继承信息，规则集的存储位置。

规则集本身维度

规则集名称

规则集名称，可以让用户从字面上就清楚了解到该集合内规则们的作用和重点检查扫描方向，方便用户识别和选择合适的规则集。理论上，每个规则集都应该有一个唯一的名称，用于识别和区分不。作为规则集运营里最基本的几个指标之一，规则集名称可以支撑用户快速了解公司、产业线、部门下都有哪些规则集，不同的部门都更偏向于使用哪些类型的规则集。

我们以华为云CodeArts Check代码检查服务为例，规则集名称的设计就是要以清晰、简单为基准：

语言

规则集开发人员根据编程语言分类，将相同语言属性的规则集合到一起。

在运营看板里，支持对规则集根据语言进行分类，可以提高规则集的可读性和可维护性，让用户可以根据语言筛选出贴合项目主流编程语言、符合开发人员所需的规则集，更加有针对性的对业务项目进行检查扫描。

包含的规则数

包含的规则数，顾名思义就是规则集里包含了多少条规则。

这个指标可以向用户展示该规则集内规则的数量，让用户预先知晓选择该规则集是否适合在该项目内使用（比如规则数量太少，导致扫描的不够全面；或则规则数量太多，导致扫描的太细致，而该项目可能还并未到版本交付阶段，仅需关注一些重点漏洞类问题即可）。

推荐类型

推荐类型，展示的是规则集的推荐程度，适合推荐的范围，是否有必要在该范围内强制采用等等。

这个指标可以结合公司的分层方式来展开，比如公司分为公司整体、产品线、产品部门，那么我们就可以将推荐类型分为公司级推荐、产品线推荐、产品推荐。同时针对推荐的力度，也可以做划分，比如强制采用，推荐建议等。

在运营看板里，用户尤其是公司/部门管理者，可以通过筛选该指标的方式查看、统计、运营当前负责范围内不同推荐程度的规则集。

规则集关联维度

规则集相关联的维护责任主体信息

在之前关于规则维度关注指标的文章内，我有提到“规则是会随着业务发展，行业内对漏洞感知的更新而不断更新优化的，因此需要有专门的维护部门和维护责任人来负责规则的上下线，修改，发布和管理”。同理，因为规则本身的变动以及规则集内规则的增删改，规则集也需要有专门的维护部门和维护责任人来负责。

在运营看板内展示规则集相关联的维护责任人信息，大致上来说有以下2种原因：

• 一般来说规则集是谁设计创建的，后续就应该由谁来维护；因此在看板内展示维护责任人信息，可以方便用户了解规则集的来源和背景，提高规则集的可信度和权威性。
• 方便用户在作业平台服务内发现一些规则集相关问题或则建议时，能够通过看板快速联系到相关责任人，降低用户和开发者之间的沟通成本。

规则集相关联的被引用情况

这点依然类似于规则被引用状况的分析，规则集一旦被创建出来，只要其合理有效，一定会被公司内不同的产品线，部门，工程所采纳使用；理论上被引用的越多，越能代表规则集的普适应，有效性和影响力。

在运营看板内展示规则集相关联的被引用情况信息，大致上来说有以下3种原因：

• 帮助规则集的使用者和潜在使用者了解规则集的适用场景和使用对象，支撑它们选择合适的规则集，提高代码检查的效果。
• 提供规则集的维护责任人一个了解其创建规则集适用范围的平台，可以和其内心预想效果做个对比；同时也可以通过和这些使用部门相关干系人的交流反馈，及时发现规则集的不足和扩大覆盖范围的方式。
• 方便代码检查服务的管理人员和监督者了解规则集的价值和影响力，对比和评估不同规则集的差异。

规则集相关联的继承信息

创建规则集的过程中，除了让用户挑选规则从0到1直接创建之外，成熟的代码检查服务还会支持通过继承的方式来创建。所谓继承，也就是用户不再去挑选规则，而是去挑选规则集；在选中了某个规则集之后，将该规则集内所有的规则选中并继承到新的规则集内。同时，继承也可以划分为强弱之分，强继承可以说在继承者和被继承者之间存在比较强的持续的关联关系，被继承者的被动会持续的影响到继承者；弱集成则不然，在继承完成的那一刻起，两者之间就不再有关联了。

在运营看板内展示规则集相关联的继承信息，大致上来说有以下3种原因：

• 让规则集的使用者和潜在使用者了解规则集的由来，它是由维护人直接创建的，还是继承了其余的规则集而来。支持对规则集进行追本溯源，并清楚最终的责任主体。
• 让规则集的使用者和潜在使用者了解规则集的变动原因，除了规则集本身的变动外，强继承的规则集还会受到被继承规则集的变动影响。
• 方便代码检查服务的管理人员和监督者了解当前现存规则集关于继承方式的分布状况，对比和评估不同继承方式的规则集的使用现状。

规则集的存储位置

这里的存储位置，不是指规则集存在哪个服务器或则哪个数据库中，而是说基于不同的检查方式，规则集会存在于哪个层级中。比如，对于运用了三层检查（公司级、产品线级、部门级检查）模式的公司来说，不同层级相对应的规则集就要存储在相关的文件夹内。比如，规则集A是推荐公司范围内强制采用的，就适合放在公司级的文件夹内；规则集B是产品线范围内推荐使用的，就适合放在产品线级的文件夹内。

在运营看板内展示规则集相关联的存储信息，便于相关责任主体统计、摸清当前规则集是否放在了合适的文件夹内。

总结一下

通过关注如上这些指标信息，可以让相关人员获取并统计规则集相关的关键数据，帮助用户了解和评估规则集的有效性、合理性、可维护性和适应性。用户也可以从中避免不必要的时间和资源浪费，帮助从运维的角度识别不可靠不一致的规则集，避免不清晰和混乱，以提高规则集的执行效果。