目录
1、背景
2、线下跟进机制
2.1、清理流程
2.2、存在的痛点
3、自动化统计
3.1、实现方案
3.2、平台功能
4、使用效果
5、未来展望
1、背景
软件的质量保证包括外部质量和内部质量两部分，外部质量是用户的使用质量，用户能够直接感知；内部质量主要包括技术架构和代码质量等，随着业务的快速发展，内部质量往往很容易被忽视。
之前QA在进行全流程质量把控的过程中，更多的关注点都放在业务维度，主要包括：需求质量、提测质量和线上online问题等，随着业务的迭代，系统类问题如运行时异常和业务异常会不断的累积，QA也需要在日常对系统层面做关注，跟开发同学一起进行质量内建，只有将清理做到日常，我们的系统才会越来越健壮，业务也才能够快速发展。
2、线下跟进机制
在进行日志清理之前必须要有个适合的清理机制，才能使得日志清理实现正向循环，因此我们基于业务现状，和开发一起制定了一个清理机制：QA主要负责异常error的统计及清理情况的确认，而开发同学主要负责异常error的清理及清理情况的反馈。
2.1、清理流程
最初我们采用的跟进机制是线下跟进，跟进的整体流程如图：
1）异常类型维护
QA会和RD维护一份异常类型汇总的表格，主要包括：异常类型名称、是否必清、阈值。这个表格主要是作为一个基准，用于判断哪些异常可以忽略，哪些异常达到一定阈值后才需要处理，哪些异常只要出现就必须处理。当出现了不在此表格中的异常类型，则需要维护到该表格中。
2）异常类型统计
每周五QA同学会结合grafana平台业务看板整理出近一周需要清理的异常error表格。
3）异常类型处理
开发同学在接下来的一周开始确认QA统计出的异常error是否需要解决，并在共享文档中标记解决结果。
4）处理结果跟进
周五QA会与值班的开发同学逐一确认本周异常error的处理情况，并将当周的整体进度进行汇总，以及统计新周期需要解决的异常，最终以邮件的形式发送给所有相关同学。
2.2、存在的痛点
虽然该线下跟进机制已经在QA和RD磨合下运行了一段时间并达成了一致，但是仍然存在如下的一些痛点：
1）QA统计成本高
每个集群统计的方式重复且繁琐，QA每统计一个集群出现的error，都需要拿流程1中维护的表格进行比对，人工去判断是否需要处理。
对每个集群出现的每个error都需要做同样的事情。当时清理的业务方为共有13个集群，每次统计本周和汇总上周进度，耗费QA同学2~3h左右的时间。
2）统计周期长，问题解决不及时
由于QA人工统计成本的局限性，统计周期最短只能定为每周，导致有些异常日志超时查不到了，或者好几天以后才被统计到，问题解决不及时。
3）数据分析难
各个业务都在摸索自己独特的统计跟进方式，需要一定的时间与开发同学磨合，且跟进记录维护到各个业务自己的共享文档，不利于长期的数据治理和分析。
3、自动化统计
为了降低QA的统计成本，也为了后续能够尽可能的实时监控，我们设计了一种线上跟进机制：实现定时自动化统计，以群机器人通知的方式进行通知，并以页面的形式进行展示。
3.1、实现方案
采用定时任务定时对venus服务统计出的异常类型进行定制化统计，将需要处理的异常存入mysql数据库表，并将本周期的统计情况及反馈上个周期的处理情况通过企业微信群机器人在群内通知。通过前端在页面上展示各业务线需要处理的异常数据，实现统计数据的平台化。
其中，定时任务实现自动化统计的具体流程如图：
3.2、平台功能
1）异常数据统计和存储
异常类型维护到单独的页面，用于维护异常error的处理类型和统计阈值，实现基于日常的统计结果，灵活调整统计规则。
每次统计都会将新出现的异常类型、以及需解决的异常类型分别存入mysql表中。具体统计规则如下：
- 是否是已维护的error，不是则需要统计进需解决的表中，并维护到已有的异常类型中，供开发同学维护
- 是必清error，则统计进需解决的表中
- 不是必清error，且未设置阈值，则校验条数大于上周条数的N倍，是则统计进需解决的表中
- 不是必清error，且出现的条数是超过设置的阈值，则统计进需解决的表中
- 都没有，则忽略
2）实时监控和预警
我们通过3种实时通知，来完成一个闭环的实时监控和预警
- 统计周期缩短到工作日内的每天，每天早上完成新的统计并群通知给各业务线的开发同学。
- 每周五会定时进行未处理提醒。
- 每周一会定时对上周所有异常类型解决情况进行总结。
3）数据可视化
统计列表展示每个周期新统计出的异常类型数据，每个异常类型对应的负责人处理后在此填写处理结果，通过标红的方式很快查询待处理的异常。
4）可扩展性
使用apollo来配置接入的业务线集群、集群负责人、企业微信群机器人链接，可以实现业务线轻松接入。
4、使用效果
- 通过自动化统计，每周统计效率提升80%，统计过程中的人为错误和工作量得以大幅减少，提高了统计数据的准确性和可靠性。
- 由于平台自动化统计节省了统计成本，大大缩短了统计周期，实现了从每周到每天的转变，使得业务部门能够更及时地获取最新的统计结果并及时做出决策。
- 目前基本完成了存量异常日志的清零，截止到现在已进行过70多次的统计，累计统计了900+需要解决的异常error，累计解决异常问题近300条。
- 接入平台的业务线由最初的2个推广到4个，基于平台的管理让北京业务各组异常error的跟进标准和方式拉齐，逐步助力于数据的长期治理和分析。
5、未来展望
-
目前统计是集群的异常类型维度，后续可以继续提升统计的细粒度，帮助开发更快速定位到具体问题，提升解决效率。
-
扩展统计类型，例如后续可以加入sonar检测，将开发跟进解决的过程线上化。
作者：张元
转转研发中心及业界小伙伴们的技术学习交流平台，定期分享一线的实战经验及业界前沿的技术话题。
关注公众号「转转技术」（综合性）、「大转转FE」（专注于FE）、「转转QA」（专注于测试），更多干货实践，欢迎交流分享~