【产研测类】线上问题处理机制 - Alan_beijing
source link: https://www.cnblogs.com/wangjiming/p/17926779.html
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
在【产研测类】系列文章中，之前与大家分享文章：【产研测类】关于研发规范化的一些实践和思考 侧重于产研测宏观规范，本篇文章侧重具体的线上问题处理。
本规范致力于优化运营与产研团队在线问题管理的效率与效果，全面覆盖生产问题的识别、处理机制、分类分级、责任归属和明确奖惩机制。同时，侧重资源重点解决主流程关联的核心模块生产问题。如此，确保各个环节责任到人，内容详实，助力团队高效协同。
2 线上问题
2.1 线上问题定义
在互联网产品研发、运维、迭代及服务提供的全过程中，由于技术缺陷、流程不畅、资源配置不当、系统设计不合理或外部因素干扰等原因，导致的阻碍产品功能实现、用户体验下降、服务效率减低、安全性受损或业务目标受阻的一系列问题。
这些问题涵盖了从软件开发的前端、后端、数据处理、系统架构到运维管理、用户体验、市场适应性等多个层面，需要通过系统化的管理和技术手段，包括但不限于敏捷开发、持续集成与交付(CI/CD)、自动化测试、DevOps文化、项目管理工具的应用、以及细致的用户反馈循环机制等，进行预防、识别、分析和解决，以保障互联网产品与服务的高质量持续发展。系统化处理互联网生产问题还涉及建立跨部门协作机制，确保问题能够快速响应并得到有效解决，同时促进团队间的知识共享与经验积累，不断优化生产流程，提升整体的生产效能和市场竞争力。
2.2 线上问题级别
|
线上问题级别 |
|
|
致命/Blocker/S0: 这是最严重的级别，通常指那些导致系统完全无法使用、崩溃、数据丢失或严重安全漏洞的bug。例如，系统崩溃、死机、数据库死锁、应用无法启动或异常退出等。这些问题需要立即修复，因为它们严重影响了系统的稳定性和安全性。 备注：生产数据影像范围+时间周期 |
|
|
严重/Critical/S1: 指影响核心功能的bug，虽不至于让系统完全不可用，但显著影响主要功能的执行或导致重要数据的不准确。比如，主要功能失效、严重的性能问题、数据损坏但可恢复等。这些问题通常需要在下一个版本或补丁中优先修复。 |
|
|
一般/Major/S2: 包括那些不影响系统稳定性或主要功能，但对用户体验有较大影响的问题，如界面错误、次要功能故障、性能下降等。这些问题虽然不是最紧急的，但也需要计划修复以提升产品质量。 |
|
|
轻微/Minor/S3: 涉及到的是小错误或建议性的改进，比如错别字、UI小瑕疵、非核心功能的小问题等，这些bug虽然不会直接影响系统运行，但累积起来可能影响用户体验。修复优先级相对较低。 |
|
|
建议性/低/S4: 指对功能影响极小或不影响功能的bug，通常是用户体验上的微小瑕疵，或是文档、提示信息的不准确。这些问题往往被安排到最后处理，或作为产品迭代时的优化项考虑。 |
3 线上问题处理
3.1 处理流程
注：有工单系统的公司，可通过工单来串联各协同部门。
用户=》运营=》产品=》技术。
- 用户反馈：用户通过多渠道提交问题或建议，运营团队24小时内响应确认。
- 运营初步处理：快速分类反馈（如功能、界面问题），记录详尽信息，准备转交。
- 产品分析决策：产品团队接收汇总报告，深入分析问题，根据影响程度和资源，设定优先级和解决方案方向。
- 技术实施：技术团队根据产品部门的方案，评估技术可行性，规划开发时间表，执行修复或开发，通过严格测试保证质量。
- 反馈用户与验证：修复后内部验证无误，通知用户更新，并邀请原始反馈者验证处理结果，确保满意。
- 效果跟踪与总结：监控用户反馈，评估处理成效，定期总结经验，优化流程。
- 持续优化循环：基于用户反馈持续迭代产品，提升用户体验，定期回顾流程，提高处理效率。
3.2 处理时间要求
注：不同级别处理时间要求，可结合公司实际情况确定
|
线上问题级别 |
处理时间要求 |
|
|
致命/Blocker/S0: 这是最严重的级别，通常指那些导致系统完全无法使用、崩溃、数据丢失或严重安全漏洞的bug。例如，系统崩溃、死机、数据库死锁、应用无法启动或异常退出等。这些问题需要立即修复，因为它们严重影响了系统的稳定性和安全性。 |
30分钟内 备注：响应及时性（5分钟） |
|
|
严重/Critical/S1: 指影响核心功能的bug，虽不至于让系统完全不可用，但显著影响主要功能的执行或导致重要数据的不准确。比如，主要功能失效、严重的性能问题、数据损坏但可恢复等。这些问题通常需要在下一个版本或补丁中优先修复。 |
||
|
一般/Major/S2: 包括那些不影响系统稳定性或主要功能，但对用户体验有较大影响的问题，如界面错误、次要功能故障、性能下降等。这些问题虽然不是最紧急的，但也需要计划修复以提升产品质量。 |
||
|
轻微/Minor/S3: 涉及到的是小错误或建议性的改进，比如错别字、UI小瑕疵、非核心功能的小问题等，这些bug虽然不会直接影响系统运行，但累积起来可能影响用户体验。修复优先级相对较低。 |
||
|
建议性/低/S4: 指对功能影响极小或不影响功能的bug，通常是用户体验上的微小瑕疵，或是文档、提示信息的不准确。这些问题往往被安排到最后处理，或作为产品迭代时的优化项考虑。 |
3.3 处理原则
注：有客服团队公司，则客户问题统一由客服团队收集汇总。
处理原则遵循“一竿子原则”。所谓“一杆子到底”，指当日值班同学需将问题一追到底，直至问题闭环处理完毕为止。
- 当日值班同学接收到问题后，必须在5分钟内将问题传递给领域主要负责同学
- 领域主要负责同学接收到问题后，快速判定问题级别，然后推动相关同学快速解决
- 领域主要负责同学推动问题解决后，及时给当日值班同学反馈，完成问题处理闭环
4 线上问题归类、定级及定责
注：不同线上问题，不同公司根据实际情况定级。
5 线上问题奖惩
注：不同级别线上问题奖惩，公司可根据实际情况确定。
|
线上问题级别 |
责任人当月绩效 |
|
|
致命/Blocker/S0: 这是最严重的级别，通常指那些导致系统完全无法使用、崩溃、数据丢失或严重安全漏洞的bug。例如，系统崩溃、死机、数据库死锁、应用无法启动或异常退出等。这些问题需要立即修复，因为它们严重影响了系统的稳定性和安全性。 |
1、若当月发生一次，则当月绩效为C |
|
|
严重/Critical/S1: 指影响核心功能的bug，虽不至于让系统完全不可用，但显著影响主要功能的执行或导致重要数据的不准确。比如，主要功能失效、严重的性能问题、数据损坏但可恢复等。这些问题通常需要在下一个版本或补丁中优先修复。 |
1、若单月发生一次，则当月绩效不能为A 2、若当月发生3次及以上，则当月绩效为C |
|
|
一般/Major/S2: 包括那些不影响系统稳定性或主要功能，但对用户体验有较大影响的问题，如界面错误、次要功能故障、性能下降等。这些问题虽然不是最紧急的，但也需要计划修复以提升产品质量。 |
1、若当月发生一次，则当月绩效减15分 2、若当月发生两次，则当月绩效上限为B |
|
|
轻微/Minor/S3: 涉及到的是小错误或建议性的改进，比如错别字、UI小瑕疵、非核心功能的小问题等，这些bug虽然不会直接影响系统运行，但累积起来可能影响用户体验。修复优先级相对较低。 |
1、若当月发生一次，则当月绩效减10分 2、若当月发生三次以上，则当月绩效上限为B |
|
|
建议性/低/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
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK