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

作者：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小时，代码截图如下： 该金额上限缓存过期时间本应该设置为60天，但是代码中该缓存的有效期只设置了60个小时 用户在得奖60小时后，缓存失效，用户又获得获奖资格 出现一种情况：用户后返小金库现金红包（例如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	否，后续请增加测试机制	是，轻微，经回收补救后，不存在资损