代码检查服务的度量运营看板，其中必定存在的一个模块是告警运营。这个模块关注于对代码检查的告警结果进行分析、处理和汇报，对于团队项目管理者来说，可以监控和管理到其关注的不同层级各种项目的整体状况，具体可以参考我上一篇文章“代码静态检查为什么需要对告警去做运营？”。

那今天我们再聊的细化一点，在看板内的告警运营模块里，用户一般会关注哪些指标呢？大致可以分为告警本身维度的数据：告警数、告警修复数、告警屏蔽数、告警误报数等；告警关联维度的数据：告警相关联的规则、告警相关联的项目、告警相关联的时间等。

告警本身维度

告警数

告警数，或则说告警总数，这个指标应该是最直观、最显而易见的；指在一定时间范围内，代码检查扫描产生的告警的总数。一般而言，告警数又可以细分为已修复告警数+未处理告警数+屏蔽告警数的和。

这个数量可以反映出项目代码的整体质量，安全和稳定性。一般而言，告警数量越少，说明代码质量越高，越不容易出现缺陷或漏洞。

告警修复数

告警修复数，指的是对代码检查扫描产生的告警进行分析和修改之后，消除了告警所对应的缺陷和漏洞；这些被修复了的告警的数量就是告警修复数。一般来说，这个数字越小越好，代表项目代码的缺陷和漏洞少。

基于此，我们可以将告警修复数，根据修复前后状态，分为已修复告警数和未处理告警数。
已修复告警数：已经消灭了扫描出来的缺陷的告警数量。当然，这里每个公司，每个部门可能对修复有不同的定义；比如一些部门认为只有文件做了改动才算修复了告警；而另外一些部门认为即使文件本身没有改动，配置变动了，导致缺陷消失了，那也算这些告警被修复了。针对这些歧义，只需要公司内部对齐协商一致即可。
未处理告警数：那就是缺陷扫描出来，但还未被修复的告警数量。

告警屏蔽数

告警屏蔽数，指的是对代码检查扫描产生的告警进行屏蔽忽略；一般发生在团队认为这类告警没有意义或则没有修复价值，屏蔽掉这类告警之后，可以保障项目的编译或运行不受影响。一般来说，这个数字越小越好，代表需要屏蔽的告警少，项目代码质量越高。

告警的屏蔽类型还可以分为人工手动屏蔽、继承屏蔽等。前者属于常见类型，用户在碰到不值得修复的告警的时候，在得到团队可以人工手动的屏蔽掉，属于主动屏蔽；后者则属于在继承别的代码的时候，把该代码的告警也一并继承了过来，属于被动屏蔽。

告警误报数

告警误报数，指的是代码检查工具错误地报出了代码中存在的问题，产生的告警其实是不存在的，项目代码实际上并没有违反扫描规则。一般来说，这个数字越小越好，代表工具这种错误告警的情况较少发生，需要人工再次排查的场景少。

告警误报的触发原因很多，一般可能是代码检查引擎工具出错，误判了某种场景，或则是代码检查的规则没有被100%准确的执行。因此，无论多么优秀的代码检查工具，人工复核代码与告警都是有必要的。

告警关联维度

在关注了如上告警本身维度的一系列数据之后，研发团队，运维人员和项目管理者肯定还会延伸的去关注告警关联的维度的数据，比如告警来自哪些规则，告警产自哪个项目，告警是在什么时候产生的。

告警相关联的规则

告警因为是由规则触发的，我们可以通过告警反推得知是哪些规则产生的告警，了解到公司，产业，部门里告警都来自于哪些规则。

通过这些规则和其产生的告警，我们可以梳理出规则在产业中的配置、引用情况，产生了多少告警（其中多少告警是有效告警，多少是误报，多少需要屏蔽），这对于相关人员了解和遵循规则有着重要的意义。

告警相关联的项目

告警和项目之间的关系是，告警是代码检查工具对项目扫描过程中产生的异常状态的通知，这些告警可以帮助项目团队及时发现并协助他们解决问题，以此来提高项目的质量和可用性。

通过这些项目和其关联的告警，我们可以梳理出每个项目的告警总数，未处理告警数，修复数，屏蔽数，误报数等数据，这对于项目管理者来说，可以及时监控项目的运行状况和现有问题，避免问题扩大影响。

告警相关联的时间

告警的诞生，也是有个先来后到顺序的。对于研发团队，运维人员来说，了解清楚告警在什么时候产生，在什么时候被修复，在什么时候屏蔽，这对于把控整个项目的健康状况是非常有益的。

通过告警相关联的时间维度，我们可以梳理出每个产业/部门底下每个时间段都产生了多少告警，修复了多少告警，屏蔽了多少告警。再结合当月的安排，可以了解整个团队的工作状况，把控好所有项目的运维进度。

总结一下

通过关注如上这些指标信息，可以让相关人员及时获取关键数据，监控到项目和业务的健康状况；通过数据分析，协助发现和找出异常问题的原因和影响，制定合理的解决方案；共享运维数据信息，促进团队合作，提高运维效率和质量，保障项目和业务的可用性和稳定性。

文章来源:华为云社区