线上问题复盘机制

版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/kaka1121/article/details/89002911

目录

 

目的

名词解释：

规则

模板

记录表格

---

目的

用于记录线上问题，以及上线过程中遇到的问题，供经验分享学习，避免同一问题重复发生。

名词解释：

线上问题	线上，以及在上线过程中，发生的故障、缺陷等
漏提	RD原因，导致缺陷出现在生产环境、并对生产环境服务、业务造成影响的 比如未告知QA，私自修改上线的、人为原因merge掉代码的，等等。 以 下 情 况 不 属 于 漏 提   上线过程中发现并解决的； RD或QA发现的线上问题，未造成影响的； 多方达成一致，在线上环境进行测试的； 产品设计上的隐秘缺陷； 未对线上造成任何影响的； 1.0项目，对线上有轻微影响的； 其他战略层面达成一致，因为效率牺牲质量的；
漏测	QA原因，导致缺陷出现在生产环境、并对生产环境服务、业务造成影响的 以 下 情 况 不 属 于 漏 测   上线过程中发现并解决的； QA发现的线上问题，未造成影响的； 多方达成一致，在线上环境进行测试的； 产品设计上的隐秘缺陷； 测试环境无法具备验证条件，且不能在线上进行验证的； 测试过程中发现，成本极高的； 未对线上造成任何影响的； 1.0项目，对线上有轻微影响的； 其他战略层面达成一致，因为效率牺牲质量的；

---

规则

1. 凡是原则上不属于漏提、漏测的线上问题，未在wiki上记录分享的，算做漏提、漏测，纳入KPI考核；
2. 凡被定义为漏提、漏测，纳入KPI考核 。
3. 一次上线，回滚三次（含）以上的，纳入KPI考核。
4. 如果是已有人分享过的线上问题，再犯的，计入漏提或漏测。
5. 解决故障后的一周之内，完成复盘，否则计入漏提或漏测。
6. 重大问题或典型问题，必须召开故障分析会进行复盘。

模板

【问题背景】

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

【问题发现】

【影响范围】

【解决过程】

建议带上时间和解决时长。示例：

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

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

解决时长：4小时。

【原因分析】

【代码示例】（可选，典型问题需填写）

【源码分析】（可选，典型问题需填写）

【避免办法】

从研发过程、测试机制等角度思考。

---

记录表格

标题	详细信息	测试	开发	时间	漏测	漏提
XXXXXXXXXXXXXX	【问题发现】 【影响范围】 【解决过程】 【原因分析】 【避免办法】	XXX	XXX	2019-3-28	否	否