線上問題覆盤機制

目錄

 

目的

名詞解釋：

規則

模板

記錄表格

---

目的

用於記錄線上問題，以及上線過程中遇到的問題，供經驗分享學習，避免同一問題重複發生。

名詞解釋：

線上問題

線上，以及在上線過程中，發生的故障、缺陷等

漏提

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	否	否