生产环境缺陷来源VS 缺陷管理响应机制
生产环境缺陷主要来源于用户反馈、版本内遗留、内部反馈和监控后台报警,具体内容包含以下途径:
1、用户反馈:
① 前台电话方式
② 意见反馈后台
③ 第三方平台:如微博、App Store等渠道
2、版本内遗留:
① 业务线在版本测试中,发现的线上问题(bug的影响模块需要选成“主软件用户问题反馈”)
② 业务线在版本测试中遗留的问题全部转线上需求
3、内部反馈:
① 各条业务线钉钉群反馈的线上版本产生的问题
② 各条业务线微信群反馈的线上版本产生的问题
③ 内部人员使用中反馈的线上问题
4、监控后台:
① 运营平台
② PV监控后台
③ 友盟
缺陷管理响应机制
根据缺陷严重级别划分,制定解决问题的响应机制,此机制仅针对客户端和包装接口,在生产环境下产生的缺陷有效。具体响应解决时限如下:
1、 严重级别:
不区分客户端或接口,缺陷产生0.5天内排查并完成修复。需要按照标准记录至热修复或插件更新列表中。
2、 高级别:
a)客户端缺陷
缺陷产生0.5天内定位原因,评估影响范围,随当前功能期版本解决。如遇集成期,且影响范围较广,需要结合缺陷影响范围和上线风险评估是否延期,如不延期,缺陷解决时间最迟不超过下一版本。
b)服务端缺陷
缺陷产生0.2天内定位原因,评估影响范围,及时进行修复,修复时长不超过0.5天。
3、 中级别:
a)客户端缺陷
缺陷产生0.5天内定位原因,结合影响范围、修改成本评估是否修改,缺陷解决时间最迟不超过下一版本。
4、 低级别:
a) 客户端缺陷
缺陷产生0.5天内定位原因,缺陷解决时间最迟不超过下一版本。
以上可行性缺陷可以正常修复的情况外,如遇缺陷排查或解决过程中,出现的异常情况,响应机制如下:
- 如无法定位原因,需考虑其他排查方案,如随当前版本添加相应日志或联系用户协助测试,如截止到下一版本仍未定位原因,且持续用户反馈,记录至疑难问题列表中,建议作为技术项由相关业务技术人员专门安排时间解决
- 如已定位原因,并且修改成本过大时,转版本需求,需要版本内解决
- 如已定位原因,但是无修改方案时,记录至疑难问题列表中,建议作为技术项由相关业务技术人员专门安排时间解决