1 概述
在【產研測類】系列文章中，之前與大家分享文章：【產研測類】關於研發規範化的一些實踐和思考 側重於產研測宏觀規範，本篇文章側重具體的線上問題處理。
本規範致力於優化運營與產研團隊在線問題管理的效率與效果，全面覆蓋生產問題的識別、處理機制、分類分級、責任歸屬和明確獎懲機制。同時，側重資源重點解決主流程關聯的核心模塊生產問題。如此，確保各個環節責任到人，內容詳實，助力團隊高效協同。
2 線上問題
2.1 線上問題定義
在互聯網產品研發、運維、迭代及服務提供的全過程中，由於技術缺陷、流程不暢、資源配置不當、系統設計不合理或外部因素干擾等原因，導致的阻礙產品功能實現、用戶體驗下降、服務效率減低、安全性受損或業務目標受阻的一系列問題。
這些問題涵蓋了從軟件開發的前端、後端、數據處理、系統架構到運維管理、用戶體驗、市場適應性等多個層面，需要通過系統化的管理和技術手段，包括但不限於敏捷開發、持續集成與交付(CI/CD)、自動化測試、DevOps文化、項目管理工具的應用、以及細緻的用戶反饋循環機制等，進行預防、識別、分析和解決，以保障互聯網產品與服務的高質量持續發展。系統化處理互聯網生產問題還涉及建立跨部門協作機制，確保問題能夠快速響應並得到有效解決，同時促進團隊間的知識共享與經驗積累，不斷優化生產流程，提升整體的生產效能和市場競爭力。
2.2 線上問題級別
|
線上問題級別 |
級別定義 |
|
P0 |
致命/Blocker/S0: 這是最嚴重的級別，通常指那些導致系統完全無法使用、崩潰、數據丟失或嚴重安全漏洞的bug。例如，系統崩潰、死機、數據庫死鎖、應用無法啓動或異常退出等。這些問題需要立即修復，因爲它們嚴重影響了系統的穩定性和安全性。 備註：生產數據影像範圍+時間週期 |
|
P1 |
嚴重/Critical/S1: 指影響核心功能的bug，雖不至於讓系統完全不可用，但顯著影響主要功能的執行或導致重要數據的不準確。比如，主要功能失效、嚴重的性能問題、數據損壞但可恢復等。這些問題通常需要在下一個版本或補丁中優先修復。 |
|
P2 |
一般/Major/S2: 包括那些不影響系統穩定性或主要功能，但對用戶體驗有較大影響的問題，如界面錯誤、次要功能故障、性能下降等。這些問題雖然不是最緊急的，但也需要計劃修復以提升產品質量。 |
|
P3 |
輕微/Minor/S3: 涉及到的是小錯誤或建議性的改進，比如錯別字、UI小瑕疵、非核心功能的小問題等，這些bug雖然不會直接影響系統運行，但累積起來可能影響用戶體驗。修復優先級相對較低。 |
|
P4 |
建議性/低/S4: 指對功能影響極小或不影響功能的bug，通常是用戶體驗上的微小瑕疵，或是文檔、提示信息的不準確。這些問題往往被安排到最後處理，或作爲產品迭代時的優化項考慮。 |
3 線上問題處理
3.1 處理流程
注：有工單系統的公司，可通過工單來串聯各協同部門。
用戶=》運營=》產品=》技術。
- 用戶反饋：用戶通過多渠道提交問題或建議，運營團隊24小時內響應確認。
- 運營初步處理：快速分類反饋（如功能、界面問題），記錄詳盡信息，準備轉交。
- 產品分析決策：產品團隊接收匯總報告，深入分析問題，根據影響程度和資源，設定優先級和解決方案方向。
- 技術實施：技術團隊根據產品部門的方案，評估技術可行性，規劃開發時間表，執行修復或開發，通過嚴格測試保證質量。
- 反饋用戶與驗證：修復後內部驗證無誤，通知用戶更新，並邀請原始反饋者驗證處理結果，確保滿意。
- 效果跟蹤與總結：監控用戶反饋，評估處理成效，定期總結經驗，優化流程。
- 持續優化循環：基於用戶反饋持續迭代產品，提升用戶體驗，定期回顧流程，提高處理效率。
3.2 處理時間要求
注：不同級別處理時間要求，可結合公司實際情況確定
|
線上問題級別 |
級別定義 |
處理時間要求 |
|
P0 |
致命/Blocker/S0: 這是最嚴重的級別，通常指那些導致系統完全無法使用、崩潰、數據丟失或嚴重安全漏洞的bug。例如，系統崩潰、死機、數據庫死鎖、應用無法啓動或異常退出等。這些問題需要立即修復，因爲它們嚴重影響了系統的穩定性和安全性。 |
30分鐘內 備註：響應及時性（5分鐘） |
|
P1 |
嚴重/Critical/S1: 指影響核心功能的bug，雖不至於讓系統完全不可用，但顯著影響主要功能的執行或導致重要數據的不準確。比如，主要功能失效、嚴重的性能問題、數據損壞但可恢復等。這些問題通常需要在下一個版本或補丁中優先修復。 |
4小時內 |
|
P2 |
一般/Major/S2: 包括那些不影響系統穩定性或主要功能，但對用戶體驗有較大影響的問題，如界面錯誤、次要功能故障、性能下降等。這些問題雖然不是最緊急的，但也需要計劃修復以提升產品質量。 |
2天內 |
|
P3 |
輕微/Minor/S3: 涉及到的是小錯誤或建議性的改進，比如錯別字、UI小瑕疵、非核心功能的小問題等，這些bug雖然不會直接影響系統運行，但累積起來可能影響用戶體驗。修復優先級相對較低。 |
2天內 |
|
P4 |
建議性/低/S4: 指對功能影響極小或不影響功能的bug，通常是用戶體驗上的微小瑕疵，或是文檔、提示信息的不準確。這些問題往往被安排到最後處理，或作爲產品迭代時的優化項考慮。 |
最近版本 |
3.3 處理原則
注：有客服團隊公司，則客戶問題統一由客服團隊收集彙總。
處理原則遵循“一竿子原則”。所謂“一杆子到底”，指當日值班同學需將問題一追到底，直至問題閉環處理完畢爲止。
- 當日值班同學接收到問題後，必須在5分鐘內將問題傳遞給領域主要負責同學
- 領域主要負責同學接收到問題後，快速判定問題級別，然後推動相關同學快速解決
- 領域主要負責同學推動問題解決後，及時給當日值班同學反饋，完成問題處理閉環
4 線上問題歸類、定級及定責
注：不同線上問題，不同公司根據實際情況定級。
5 線上問題獎懲
注：不同級別線上問題獎懲，公司可根據實際情況確定。
懲：
|
線上問題級別 |
級別定義 |
責任人當月績效 |
|
P0 |
致命/Blocker/S0: 這是最嚴重的級別，通常指那些導致系統完全無法使用、崩潰、數據丟失或嚴重安全漏洞的bug。例如，系統崩潰、死機、數據庫死鎖、應用無法啓動或異常退出等。這些問題需要立即修復，因爲它們嚴重影響了系統的穩定性和安全性。 |
1、若當月發生一次，則當月績效爲C |
|
P1 |
嚴重/Critical/S1: 指影響核心功能的bug，雖不至於讓系統完全不可用，但顯著影響主要功能的執行或導致重要數據的不準確。比如，主要功能失效、嚴重的性能問題、數據損壞但可恢復等。這些問題通常需要在下一個版本或補丁中優先修復。 |
1、若單月發生一次，則當月績效不能爲A 2、若當月發生3次及以上，則當月績效爲C |
|
P2 |
一般/Major/S2: 包括那些不影響系統穩定性或主要功能，但對用戶體驗有較大影響的問題，如界面錯誤、次要功能故障、性能下降等。這些問題雖然不是最緊急的，但也需要計劃修復以提升產品質量。 |
1、若當月發生一次，則當月績效減15分 2、若當月發生兩次，則當月績效上限爲B |
|
P3 |
輕微/Minor/S3: 涉及到的是小錯誤或建議性的改進，比如錯別字、UI小瑕疵、非核心功能的小問題等，這些bug雖然不會直接影響系統運行，但累積起來可能影響用戶體驗。修復優先級相對較低。 |
1、若當月發生一次，則當月績效減10分 2、若當月發生三次以上，則當月績效上限爲B |
|
P4 |
建議性/低/S4: 指對功能影響極小或不影響功能的bug，通常是用戶體驗上的微小瑕疵，或是文檔、提示信息的不準確。這些問題往往被安排到最後處理，或作爲產品迭代時的優化項考慮。 |
1、當月績效減5分 2、若當月發生三次以上，則當月績效上限爲B |
獎：
- 提出建設性建議，推進團隊提質、提效的員工，績效可增加30分
6 核心模塊、功能、負責人
說明：核心模塊定義爲P0或P1級別。
|
組別 |
核心模塊 |
核心功能 |
負責人（技術/產品） |
|
金融組 |
白條 |
准入用戶、白條用戶、借款、還款、產品費率、鎖定額度、前置機、CBS、簽約授信 |
|
|
支付相關 |
公衆號支付、小程序支付、支付寶支付、代付、線下支付、充值、提現、對賬、ERP、分賬、轉賬 |
|
|
|
用戶相關 |
註冊、e籤寶、開戶、賬戶激活、賬戶解凍、修改用戶信息 |
|
7 版權區
- 轉載博客，必須註明博客出處
- 博主網址：http://www.cnblogs.com/wangjiming/
- 如您有新想法，歡迎提出，郵箱：[email protected]
- 專業.NET之家技術QQ羣：490539956
- 專業化Java之家QQ羣：924412846
- 有問必答QQ羣：2098469527
- 一對一技術輔導QQ：2098469527