线上问题管理----记录、复盘、追责

作者:cryanimal  微信:lazytest

 

导语

        线上问题的管理,不管对于开发还是测试来说,都是极为重要的一环。把好线上问题复盘和分享这道关,有助于产品质量的稳步提升。

 

 

管理目的

 

  1. 回顾复盘线上问题发生的背景、原因、解决过程、影响范围,及其避免办法。
  2. 对线上问题在一定范围内进行分享,警醒当事人,提醒身边人,避免类似问题继续发生。
  3. 使用线上问题,对线上质量进行后验,作为评价员工的后验指标之一。

 

名词解释

 

 

线上问题

 线上,以及在上线过程中,发生的故障、缺陷等

 

漏提

RD(开发)原因,导致缺陷出现在生产环境、并对生产环境服务、业务造成影响的

 如:未告知QA,私自修改上线的、人为原因merge掉代码的,等等。

 

 以下情况不属于漏提:

 

  1. 上线过程中发现并解决的;
  2. RD或QA发现的线上问题,未造成影响的;
  3. 多方达成一致,在线上环境进行测试的;
  4. 产品设计上的隐秘缺陷;
  5. 未对线上造成任何影响的;
  6. 1.0项目,对线上有轻微影响的;
  7. 其他战略层面达成一致,因为效率牺牲质量的;

 

漏测

 QA原因,导致缺陷出现在生产环境、并对生产环境服务、业务造成影响的

 

 以下情况不属于漏测:

 

  1. 上线过程中发现并解决的;
  2. QA发现的线上问题,未造成影响的;
  3. 多方达成一致,在线上环境进行测试的;
  4. 产品设计上的隐秘缺陷;
  5. 测试环境无法具备验证条件,且不能在线上进行验证的;
  6. 测试过程中发现,成本极高的;
  7. 未对线上造成任何影响的;
  8. 1.0项目,对线上有轻微影响的;
  9. 其他战略层面达成一致,因为效率牺牲质量的;

 

提报&记录原则

1、非上线过程中发生的线上问题,一旦被发现后,第一时间由测试同学邮件通知到leader邮件组报备;

2、线上问题处理完毕后,由相应前端开发、后端开发、测试在线上问题记录表中复盘,主要思考和记录其避免办法

 3、问题典型,或者其他重要原因,需要做线下复盘会。

4、所有的线上问题(包括上线过程中发现的),干系人(应前端开发、后端开发、测试)的leader需要在线上问题记录表中,根据下面的规则对该问题进行定责。

5、所有线上问题,需要在迭代总结会,或测试例会中进行简单分享。

考核原则

  1. 凡是没有第一时间邮件报备的,算做漏提、漏测,纳入KPI考核
  2. 凡是原则上不属于漏提、漏测的线上问题,未在wiki上记录分享的,算做漏提、漏测,纳入KPI考核;
  3. 凡被定义为漏提、漏测,纳入绩效考核 。
  4. 一次上线,回滚三次(含)以上的,纳入绩效考核。
  5. 如果是已有人分享过的线上问题,再犯的,计入漏提或漏测。

 

记录模板

 

【问题背景】

 此处描述问题,以及问题产生背景。

【问题发现】

 此处描述问题的发现过程,建议带上时间

【影响范围】

  此处描述问题的影响范围,包括具体的数据。

【解决过程】

此处描述问题的解决过程, 建议带上时间和解决时长。

 示例:

  21:22 研发同事通过告警短信发现异常:content_service no provider。

  21:40 通过JSF监控平台得知本有8台机器的服务,只剩一台可用。

  解决时长:4小时。

【原因分析】

  此处描述问题的原因分析

【避免办法】

此处描述问题的避免办法,从研发过程、测试机制等角度思考。

 

 

记录示例

 

标题

问题详情

分享人

分享时间

漏测

漏提

      
 缓存过期时间设置错误

【问题背景】

双十二小金库现金红包支付成功后返活动

【问题描述】

由于目前小金库现金红包有个硬性规则是月限制30元,每个用户每个月只能获取30元的现金红包,而用户得到的红包总金额记录在缓存r2m中,

时间本应该是2个月,但程序里误写了成了60小时,代码截图如下:

  1. 该金额上限缓存过期时间本应该设置为60天,但是代码中该缓存的有效期只设置了60个小时
  2. 用户在得奖60小时后,缓存失效,用户又获得获奖资格
  3. 出现一种情况:用户后返小金库现金红包(例如30元)后,缓存60小时后失效,用户再进行退单,其缓存被设置为-30元,此时用户做多可以后返60元的小金库现金红包

【问题发现】

上线后在线上环境发现统计时发现有一个Jdpin用户先后两次得到了40多元的红包,立刻通过排查,发现用户第二次领时缓存里记录的总金额为

空,怀疑是缓存过期,一看代码过期时间果然设置成了60小时

【影响范围】

由于60个小时还是能拦住别有用心的刷奖用户,当时应该就只有少量正常用户拿到了超过30元的现金红包,当晚赶紧上线修复此问题并清洗线

上缓存,截止当前时间,超发红包金额统计为40365.49元,异常用户个数为4679个,期间若用户退款,数量还会减少。且2016-12-16日会上线洗

数任务,回收多发的红包,客服同时同步到用户知悉。回收后不存在资损,但消耗研发资源较多

【解决过程】

1.于14号发现问题当时立刻修复缓存过期BUG并上线,缓存过期时间修改为:60*60*24*30*2

2.14号晚间上线洗数任务,清洗线上缓存。

3.16号上线回收超发红包任务,回收超发的红包。

【原因分析】

1.当时自己想的方案是很明确的知道缓存过期时间为2个月,还给其它开发同事说过此方案,但是粗心少写了个24,导致此问题。

2.review代码未检查出该问题(时间仓促也许是导致该问题的原因之一)

3.测试为功能测试,无法发现此问题

【避免办法】

1.以后缓存这块过期时间和缓存构成要非常仔细,做好wiki维护,每加一个缓存就在wiki上补充,并做好过期时间等缓存详细信息的填写,很有

可能在写wiki的时候就发现问题。

2.以后开发提测和测试都注意提一下缓存过期时间,并说明重要程度

XXX

20161216否,后续请增加测试机制 是,轻微,经回收补救后,不存在资损

 

已标记关键词 清除标记
相关推荐
©️2020 CSDN 皮肤主题: 编程工作室 设计师:CSDN官方博客 返回首页