标签：模块   可行性   缺陷   上线   相关   使用   异常   无法   疑难   

生产环境缺陷主要来源于用户反馈、版本内遗留、内部反馈和监控后台报警，具体内容包含以下途径：

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天内定位原因，缺陷解决时间最迟不超过下一版本。

以上可行性缺陷可以正常修复的情况外，如遇缺陷排查或解决过程中，出现的异常情况，响应机制如下：

• 如无法定位原因，需考虑其他排查方案，如随当前版本添加相应日志或联系用户协助测试，如截止到下一版本仍未定位原因，且持续用户反馈，记录至疑难问题列表中，建议作为技术项由相关业务技术人员专门安排时间解决
• 如已定位原因，并且修改成本过大时，转版本需求，需要版本内解决
• 如已定位原因，但是无修改方案时，记录至疑难问题列表中，建议作为技术项由相关业务技术人员专门安排时间解决

生产环境缺陷来源VS 缺陷管理响应机制

标签：模块   可行性   缺陷   上线   相关   使用   异常   无法   疑难   

原文地址：https://www.cnblogs.com/qq909283/p/11435271.html